I committed a "fix" to 3.2 yesterday that should
solve your problem.
The spec isn't very clear. The closest I could come
to an answer was the javadoc for QueueSession
My fix, nacks (negative acknowledgement) all
unacknowledged messages at session close
or when the connection to the client drops.
NOTE: There is still an outstanding bug, where
if you shutdown jboss it loses the "redelivered"
flag. It's not top of my list of things to fix at
the moment, so maybe you can look at this? :-)
> I committed a "fix" to 3.2 yesterday that should
> solve your problem.
> The spec isn't very clear. The closest I could come
> to an answer was the javadoc for QueueSession
> My fix, nacks (negative acknowledgement) all
> unacknowledged messages at session close
> or when the connection to the client drops.
Thanks a lot! That solved my problem.
> NOTE: There is still an outstanding bug, where
> if you shutdown jboss it loses the "redelivered"
> flag. It's not top of my list of things to fix at
> the moment, so maybe you can look at this? :-)
Sure, I can give it try, but I don't have a deep knowledge of the sources, so it will take some time.
I tested a little bit more and it seems there is a little bug. I can't change the message selector of a durable subscription. In my test I make a durable subscription with clientId=TestClient and message selector EventName='test1'. All works fine, I send messages with the right property and the subscriber gets them. But when I shutdown the client and reconnect again with the same clientId but a selector like EventName='test2', the subscriber gets no messages at all (I send new messages with the property set to 'test2'). The jbossmq-state.xml isn't updated too. When I reconnect with the selector for test1 all works fine again. I could only change the selector when I unsubscribe from the topic.
A few days ago it was possible to reconnect with the same clientId and a different selector.
The state of acknowledgeMode or deliveryMode doesn't change the behaviour.
I don't think my fix has broken this. :-)
It looks like an existing bug.
The following comment appears in AbstractStateManager
// The topic previously subscribed to is not the same as the
// one in the subscription request.
// TODO: we do currently no check if the selector has changed.
else if (!subscription.getTopic().equals(topic.getName()))
I would guess it should have an extra check something
else if (!subscription.getTopic().equals(topic.getName())
If you have a testcase and the source do you want to
try this fix?
It's more complicated than that,
so don't waste your time :-)
I think I've got a working, just writing some tests...
Testcases are no problem, should I test your last fix? I have a cvs version from yesterday and could update/patch to whatever you want :).
Sorry for the delay, I've been firefighting some
other problems. :-(
I've committed the fix for selector changes into 3.2
Thank you very mutch! It works very well.
Is the bug you mentioned above still valid? I didn't find it in Bugzilla.
The redelivered flag after a server restart?
It is still a bug.
Try www.sf.net/projects/jboss and click on bugs if
you want to report it.