On Fri, 2003-12-05 at 13:57, Stephane Nicoll wrote: > Adrian, > > Thanks A LOT for the explanation. Actually, yes I do know the client by > advance but we add some of them from time to time. We need to be able to > add a new one without restarting Jboss > > Is there a solution with a queue per client? >
Why can't you just deploy a new one? I assume you have no security if everybody is sharing the same queue. You could create an mbean that reads the queues from a database. Include operations to add/remove them maintaining the db at the same time. Use one of the createQueue() operations on the destination manager. Feel free to contribute back such a service. But a more generic solution would include topics, security and configuration of user/roles through the statemanager. I included a JDBC statemanager in 3.2.2, but it does not yet have mbean operations to maintain the db, only the internal operations used by jbossmq itself. Regards, Adrian > Kind regards, > > Stephane > > > On Fri, 2003-12-05 at 14:29, Adrian Brock wrote: > > On Fri, 2003-12-05 at 12:41, Stephane Nicoll wrote: > > > 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. > > > > A topic subscription with a selector runs the selector during the > > send. If it does not match, the message is not added to the > > subscription. > > > > With your clientId, the message will only go into one subscription. > > > > > > > > In my case it's a one to one relationship. Could you please explain a > > > bit more? > > > > > > > Yes, topic subscriptions are one-one as well. > > > > > I assume creating one queue per client is a worst solution right? > > > > > > > Why? Unless two subscriptions match the selector, you will have > > exactly the same number of messages. But they will have already been > > divided into their relevent queues. > > > > The overhead of the queue is minimal, a few extra data structures in > > memory. The data structures entries (messages) are made anyway whether > > you have one or 2500 queues. It is faster to > > access smaller data structures that contain relevent data > > than it is to access one big datastruture with lots of contention. > > > > > I have around 2500 clients and yes I do know them by advance, > > > > If you know all the clients in advance, > > why don't you create 2500 queues? One for each client. > > You remove the need for a selector altogether! > > See above about the overhead of a queue. > > > > > 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) > > > > > > > So potentially the first receive is skipping 1250 (2500/2) messages. > > The second 3250 (1250 + 2500). > > > > I'm assuming worst case where the queue looks like: > > clientID1 > > clientID2 > > ... > > clientID2500 > > clientID1 > > etc. > > > > Using a topic to split them would turn the selector into a constant > > time 2500 invocations. Also the message is in memory during the add, > > no need to load it from the cache if it is not present. > > > > Regards, > > Adrian > > > > > 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 > > > ------------------------------------------------------- > 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 -- xxxxxxxxxxxxxxxxxxxxxxxx Adrian Brock Director of Support Back Office JBoss Group, LLC xxxxxxxxxxxxxxxxxxxxxxxx ------------------------------------------------------- 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
