Re: [JBoss-dev] Patch for bug 532983 - JBOSSMQ
>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
Re: [JBoss-dev] Patch for bug 532983 - JBOSSMQ
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.
Love to do a test case, can I hard code the persistent message path in
the test?
> Regards,
> Hiram
>
> >From: Jason Dillon <[EMAIL PROTECTED]>
> >To: Dave Smith <[EMAIL PROTECTED]>
> >CC: "Jboss-Development@Lists. Sourceforge. Net"
> ><[EMAIL PROTECTED]>
> >Subject: Re: [JBoss-dev] Patch for bug 532983 - JBOSSMQ
> >Date: Tue, 09 Apr 2002 02:05:15 -0700
> >
> >Do you have a test case for this?
> >
> >--jason
> >
> >
> >Dave Smith wrote:
> >
> >>I have fix this bug and have included a patch for it. Could one of the
> >>JBOSS MQ guys look at it and please apply. Basically if the message
> >>selector says that the message should not be delivered, it expires the
> >>message. That way the message is still acknowledged and is cleaned up.
> >>
> >>
> >>
> >>
> >>--- BasicQueue.java Mon Apr 8 16:25:11 2002
> >>+++ BasicQueue.java.new Mon Apr 8 16:23:26 2002
> >>@@ -157,27 +157,21 @@
> >> MessageReference messageRef = null;
> >> synchronized (receivers) {
> >> // If the subscription is not picky, the first message will be it
> >>- if (sub.getSelector() == null && sub.noLocal==false ) {
> >> synchronized (messages) {
> >>- if (messages.size() != 0) {
> >>+ if (messages.size() != 0)
> >>+ {
> >> messageRef = (MessageReference)messages.first();
> >> messages.remove(messageRef);
> >>- }
> >>+/*
> >>+ If there is a selector and it is false then just expire
> >>+ the message. This way it will get cleaned up.
> >>+*/
> >>+if (sub.getSelector() != null &&
> >>!sub.accepts(messageRef.getHeaders()))
> >>+{
> >>+
> >>messageRef.getMessage().header.jmsExpiration=System.currentTimeMillis()-10;
> >>+}
> >>+ }
> >> }
> >>- } else {
> >>- // The subscription is picky, so we have to iterate.
> >>-synchronized (messages) {
> >>- Iterator i = messages.iterator();
> >>- while (i.hasNext()) {
> >>- MessageReference mr = (MessageReference) i.next();
> >>- if (sub.accepts(mr.getHeaders())) {
> >>- messageRef = mr;
> >>- i.remove();
> >>- break;
> >>- }
> >>- }
> >>-}
> >>- }
> >>
> >> if (messageRef == null) {
> >> if (wait) {
> >>
> >
> >
> >
> >___
> >Jboss-development mailing list
> >[EMAIL PROTECTED]
> >https://lists.sourceforge.net/lists/listinfo/jboss-development
> >
> >Sponsored by http://www.ThinkGeek.com/
> >
>
>
>
>
> _
> Send and receive Hotmail on your mobile device: http://mobile.msn.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Sponsored by http://www.ThinkGeek.com/
Re: [JBoss-dev] Patch for bug 532983 - JBOSSMQ
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.
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.
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).
Regards,
Hiram
>From: Jason Dillon <[EMAIL PROTECTED]>
>To: Dave Smith <[EMAIL PROTECTED]>
>CC: "Jboss-Development@Lists. Sourceforge. Net"
><[EMAIL PROTECTED]>
>Subject: Re: [JBoss-dev] Patch for bug 532983 - JBOSSMQ
>Date: Tue, 09 Apr 2002 02:05:15 -0700
>
>Do you have a test case for this?
>
>--jason
>
>
>Dave Smith wrote:
>
>>I have fix this bug and have included a patch for it. Could one of the
>>JBOSS MQ guys look at it and please apply. Basically if the message
>>selector says that the message should not be delivered, it expires the
>>message. That way the message is still acknowledged and is cleaned up.
>>
>>
>>
>>
>>--- BasicQueue.java Mon Apr 8 16:25:11 2002
>>+++ BasicQueue.java.new Mon Apr 8 16:23:26 2002
>>@@ -157,27 +157,21 @@
>> MessageReference messageRef = null;
>> synchronized (receivers) {
>> // If the subscription is not picky, the first message will be it
>>- if (sub.getSelector() == null && sub.noLocal==false ) {
>> synchronized (messages) {
>>- if (messages.size() != 0) {
>>+ if (messages.size() != 0)
>>+ {
>>messageRef = (MessageReference)messages.first();
>> messages.remove(messageRef);
>>- }
>>+/*
>>+ If there is a selector and it is false then just expire
>>+ the message. This way it will get cleaned up.
>>+*/
>>+if (sub.getSelector() != null &&
>>!sub.accepts(messageRef.getHeaders()))
>>+{
>>+
>>messageRef.getMessage().header.jmsExpiration=System.currentTimeMillis()-10;
>>+}
>>+ }
>> }
>>- } else {
>>- // The subscription is picky, so we have to iterate.
>>-synchronized (messages) {
>>- Iterator i = messages.iterator();
>>- while (i.hasNext()) {
>>- MessageReference mr = (MessageReference) i.next();
>>- if (sub.accepts(mr.getHeaders())) {
>>- messageRef = mr;
>>- i.remove();
>>- break;
>>- }
>>- }
>>-}
>>- }
>>
>> if (messageRef == null) {
>> if (wait) {
>>
>
>
>
>___
>Jboss-development mailing list
>[EMAIL PROTECTED]
>https://lists.sourceforge.net/lists/listinfo/jboss-development
>
>Sponsored by http://www.ThinkGeek.com/
>
_
Send and receive Hotmail on your mobile device: http://mobile.msn.com
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Sponsored by http://www.ThinkGeek.com/
Re: [JBoss-dev] Patch for bug 532983 - JBOSSMQ
Do you have a test case for this?
--jason
Dave Smith wrote:
>I have fix this bug and have included a patch for it. Could one of the
>JBOSS MQ guys look at it and please apply. Basically if the message
>selector says that the message should not be delivered, it expires the
>message. That way the message is still acknowledged and is cleaned up.
>
>
>
>
>--- BasicQueue.javaMon Apr 8 16:25:11 2002
>+++ BasicQueue.java.newMon Apr 8 16:23:26 2002
>@@ -157,27 +157,21 @@
> MessageReference messageRef = null;
> synchronized (receivers) {
>// If the subscription is not picky, the first message will be it
>- if (sub.getSelector() == null && sub.noLocal==false ) {
> synchronized (messages) {
>- if (messages.size() != 0) {
>+ if (messages.size() != 0)
>+ {
> messageRef = (MessageReference)messages.first();
> messages.remove(messageRef);
>- }
>+/*
>+ If there is a selector and it is false then just expire
>+ the message. This way it will get cleaned up.
>+*/
>+if (sub.getSelector() != null &&
>!sub.accepts(messageRef.getHeaders()))
>+{
>+
>messageRef.getMessage().header.jmsExpiration=System.currentTimeMillis()-10;
>+}
>+ }
> }
>- } else {
>- // The subscription is picky, so we have to iterate.
>-synchronized (messages) {
>- Iterator i = messages.iterator();
>- while (i.hasNext()) {
>- MessageReference mr = (MessageReference) i.next();
>- if (sub.accepts(mr.getHeaders())) {
>- messageRef = mr;
>- i.remove();
>- break;
>- }
>- }
>-}
>- }
>
> if (messageRef == null) {
> if (wait) {
>
___
Jboss-development mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/jboss-development
Sponsored by http://www.ThinkGeek.com/
[JBoss-dev] Patch for bug 532983 - JBOSSMQ
I have fix this bug and have included a patch for it. Could one of the
JBOSS MQ guys look at it and please apply. Basically if the message
selector says that the message should not be delivered, it expires the
message. That way the message is still acknowledged and is cleaned up.
--- BasicQueue.java Mon Apr 8 16:25:11 2002
+++ BasicQueue.java.new Mon Apr 8 16:23:26 2002
@@ -157,27 +157,21 @@
MessageReference messageRef = null;
synchronized (receivers) {
// If the subscription is not picky, the first message will be it
- if (sub.getSelector() == null && sub.noLocal==false ) {
synchronized (messages) {
- if (messages.size() != 0) {
+ if (messages.size() != 0)
+ {
messageRef = (MessageReference)messages.first();
messages.remove(messageRef);
- }
+/*
+ If there is a selector and it is false then just expire
+ the message. This way it will get cleaned up.
+*/
+if (sub.getSelector() != null &&
+!sub.accepts(messageRef.getHeaders()))
+{
+
+messageRef.getMessage().header.jmsExpiration=System.currentTimeMillis()-10;
+}
+ }
}
- } else {
- // The subscription is picky, so we have to iterate.
-synchronized (messages) {
- Iterator i = messages.iterator();
- while (i.hasNext()) {
- MessageReference mr = (MessageReference) i.next();
- if (sub.accepts(mr.getHeaders())) {
- messageRef = mr;
- i.remove();
- break;
- }
- }
-}
- }
if (messageRef == null) {
if (wait) {
