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#4068103 Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4068103 _______________________________________________ jboss-user mailing list [email protected] https://lists.jboss.org/mailman/listinfo/jboss-user
