anonymous wrote : You don't create 700,000 subscriptions that would be a management
nightmare. ;-)
| It would also require every send of a message checking 700,000 selectors to see
| which subscription matches the message.
|
| You use a "like", e.g. all customers beginning with A, B, C, etc.
| to divide them into groups according to how much concurreny you need.
|
| Or better yet, you use a "hash" of the customer id if you want a better
spread.
I am missing something totally. A queue can process multiple messages at once, depending
on the size of the thread pool, right?. Doesn't this create concurrency? If I
understood the whole JMS clustering thing then the cluster should make sure that those
processes get distributed one the cluster. If I want to make it more scalable then I only
make sure that the queue can be processed by more threads and that more machines are
available on the cluster. Lets forget about the DB for now, because that will become the
bottleneck eventually (if you don't let it scale ;)).
But I see where you are going. Doesn't your solution also mean that a subscription can
only have one thread to make sure that it processes all the messages sequentially? Because
that would indeed be the solution.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4068103#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...