-
1. Re: Multiple Writers and load balancing
pra Dec 11, 2001 3:08 PM (in response to andawyr)Hi,
yes this looks rather exactly as a typical "queue" solution: a JMS queue is exactly that: you may have multiple "workers" poping their job of the queue.
MDB:s are nice in this respect:
- You get multithreaded subscribers for free.
- They are darn easy to write (no JMS plubming code)
- You have easy access to other beans, data sources and so forth.
As for the load, that might be a problem. But it is work a test.
//Peter -
2. Re: Multiple Writers and load balancing
andawyr Dec 11, 2001 11:32 PM (in response to andawyr)Can you clarify your first statement? Everything I've read regarding P2P JMS queues indicates that you can only have one worker/reader. Or am I completely out to lunch? If I can have mulitple workers, then the first cut might not use EJB. I'll move there later, certainly, but for now, I may stick with what I know :-)
Do you think that the overhead of the MDB might impact performance? My current system can turn around a request in about 0.02 of a second (for my application, this is quite sufficient, since I process less than 200000 requests a day). C++ application, Oracle backend. If I can get under 0.1 response time, I'll be happy, since I can always increase the number of servers (hardware is cheap. I'm sure that as time passes, JBoss will be further optimized, and the turnaroud time should decrease.
Of course, I'm assuming that the time spent mucking about in the database far outweighs the time spent in the framework....
-klm. -
3. Re: Multiple Writers and load balancing
pra Dec 12, 2001 3:03 AM (in response to andawyr)> Can you clarify your first statement? Everything
> I've read regarding P2P JMS queues indicates that you
> can only have one worker/reader. Or am I completely
> out to lunch?
I would guess so. PtP is a queue where first at it get it. The JMS provider will store the messages until a consumer fetches it (or its TTL ends).
You may have a whole bunch of consumers competing for the messages (sync, i.e connection when they have time) or as subscribers (async). When they do the work as subscribers it is much up to the JMS provider how it has implemented its suff (round robin between consumer or some other algoritm).
With ptp it is fairly easy to write multithreaded client code (create one connection and multiple sessions and run the sessions in different threads). For topics it is much harder and here MDB really shines).
> If I can have mulitple workers, then
> the first cut might not use EJB. I'll move there
> later, certainly, but for now, I may stick with what
> I know :-)
>
> Do you think that the overhead of the MDB might
> impact performance? My current system can turn
> around a request in about 0.02 of a second (for my
> application, this is quite sufficient, since I
> process less than 200000 requests a day). C++
> application, Oracle backend. If I can get under 0.1
> response time, I'll be happy, since I can always
> increase the number of servers (hardware is cheap.
> I'm sure that as time passes, JBoss will be further
> optimized, and the turnaroud time should decrease.
>
I don't remember the figures for JBossMQ, if you run the in VM stuff (default for MDB) its very fast...but you will have to test.
//Peter
>
> Of course, I'm assuming that the time spent mucking
> about in the database far outweighs the time spent in
> the framework....
>
> -klm. -
4. Re: Multiple Writers and load balancing
hchirino Dec 12, 2001 6:56 PM (in response to andawyr)> Can you clarify your first statement? Everything
> I've read regarding P2P JMS queues indicates that you
> can only have one worker/reader. Or am I completely
> out to lunch? If I can have mulitple workers, then
Well, the JMS Spec leaves the behaviour undefined if you have multiple consumers. JBossMQ and some other implementations (like MQSeries) round robin the messages to consumers.
Regards,
Hiram