Multiple Writers and load balancing

[andawyr]

While this isn't a specific JBoss related question, since I'm planning on using JBoss as my EJB container, I thought this would be the appropriate forum to ask the question.

I have an application I'm going to be developing that works on a very simple request/response paradigm; you could almost say it's very HTTP-like. Current implementations of the software use a queue (hand crafted, not JMS-based) to distribute work to multiple worker processes (Unix C++ based system). A front end collects the incoming requests, queues them, and then the next available back end services the request.

I'd like to do something similar with JMS, but can't see how - you have either Point-to-Point, or Publish-Subscribe. Publish-Subscribe is close, but I don't want every message delivered to every reader - I want the next available reader to get the request.

I need this to be wickedly fast, since I'm dealing with a fairly high volume of requests.

Being new to JMS and EJB, perhaps I'm looking at this the wrong way. Should I be looking at using message driven beans, and let the queuing service dispatch the request to a bean? Can I tell the container that I have, oh, 15 beans ready to service requests, and then have the load distributed between them?

Suggestions and Guidance are most appreciated.

Thanks!

-klm.

[pra]

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

[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.

[pra]

> 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.

[hchirino]

> 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