Adrian, > Why don't you use durable topic subscriptions? > This will effectively create multiple queues, one for each clientId. > The selector is run during the publish() for each subscription. > When you come to do the receive, the subscriber's queue will only > have messages relevent to them.
You got a point. However I don't get the sender part. A Topic, as far as I know, is a Destination where multiple components can retrieve the same info. In my case it's a one to one relationship. Could you please explain a bit more? I assume creating one queue per client is a worst solution right? I have around 2500 clients and yes I do know them by advance, even If will have to add them at runtime (meaning I create a new client, it's registered on the fly and we can post/receive message without ar estart. Restart will keep the changes) Regards, Stephane ------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ JBoss-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-user
