>On Mon, 2002-04-08 at 17:47, Hiram Chirino wrote: > > I don't think we can apply the patch. It would break the case where we >have > > 2 receiving clients with different message selectors grabbing messages >out > > of one queue. > > >See below .. > > So, the idea is client 1 is not interested in all the message in the >queue, > > so he applies a message selector. But this does not mean that the other > > messages in the queue should be expired. There is a possibility that >there > > is another client that is intrested in some of the other messages. He >just > > needs to use a different message selector, and then he can get those > > messages. > > >So what if we just clone the message and return it expired. Then the >cloned message will expire and will be acknowledged but the orginal can >be passed around to the rest of the subscribers? > > > Are you trying to fix the problem that we have with durable topic > > subscriptions that have a selector? (the bug is that we store messages >in > > the durable subscription even if it does does not match the selector, > > therefore we build up messages that can never be devliver since they do >not > > match the selector). > > >Yes this is what I am trying to fix. >
Durable subscriptions are kept in seperate persistent queues that are maintained by the to topic. I think the right way to fix it is to store the selector as part of the DurableSubscriptionID so that later on when we do a addMessage(...) in the org.jboss.mq.server.JMSTopic, we can skip adding messages to the durable subsciption queue if the message does not match the subscription message selector. This would also mean we have to store the durable subscription selector in the StateManager etc. Regards, Hiram _________________________________________________________________ Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp. _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
