-
1. Re: A couple of questions on expected JMS behaviour / edge c
adrian.brock Sep 15, 2005 2:47 PM (in response to timfox)"timfox" wrote:
1)
Acknowledgment after consumer is closed:
Connection conn = cf.createConnection();
Session sess = conn.createSession(true, Session.TRANSACTED);
MessageConsumer consumer = sess.createConsumer(queue);
Message m = consumer.receive();
consumer.close();
sess.commit();
conn.close();
I believe the above is legal, can anyone confirm?
The ack should be sent when the session commits, by when the consumer is closed.
Correct. The state belongs to the session - or more accurately in this case
the transaction. -
2. Re: A couple of questions on expected JMS behaviour / edge c
adrian.brock Sep 15, 2005 2:52 PM (in response to timfox)"timfox" wrote:
m1.acknowledge();
then call recover() on the *other* consumer session:
sess2.recover();
My understanding is that the message should not be received again at cons1, but only received again at cons2, which corresponds to sess2 which hadn't acked it.
m1 from the first subscription should not be redelivered regardless!
After m1.acknowledge() returns successfully, it no longer exists.
Operations on sess2 should never affect sess1.
Different sessions are intended to be used on different threads, they aren't even
threadsafe. -
3. Re: A couple of questions on expected JMS behaviour / edge c
timfox Sep 15, 2005 3:08 PM (in response to timfox)Sorry, I mis-stated the second case. :)
What I meant to say was:
Sess1 acks the message
Sess2 doesn't ack the message
When sess1.recover is called, it doesn't get the message redelivered.
When sess2.recover is called, it does get the message redelivered (since it's been acked).
Is that right?
Currently (as in the current state of JBoss messaging), what actually happens is that neither of the consumers gets the message redelivered on recovery.
This is because, currently in the implementation of the channel that makes up the topic,we only say the message is unacknowledged, we don't say the message is unacked from a specific consumer. This is fine for a Queue , but not for a topic where we can have multiple consumers.
I think the current implementation is wrong.
It's curious the TCK doesn't catch this though. -
4. Re: A couple of questions on expected JMS behaviour / edge c
adrian.brock Sep 15, 2005 3:22 PM (in response to timfox)"timfox" wrote:
Sorry, I mis-stated the second case. :)
What I meant to say was:
Sess1 acks the message
Sess2 doesn't ack the message
When sess1.recover is called, it doesn't get the message redelivered.
When sess2.recover is called, it does get the message redelivered (since it's been acked).
Is that right?
It is if your last sentance was meant to be:
"When sess2.recover is called, it does get the message redelivered (since it has NOT been acked)." -
5. Re: A couple of questions on expected JMS behaviour / edge c
adrian.brock Sep 15, 2005 3:25 PM (in response to timfox)"timfox" wrote:
This is because, currently in the implementation of the channel that makes up the topic,we only say the message is unacknowledged, we don't say the message is unacked from a specific consumer. This is fine for a Queue , but not for a topic where we can have multiple consumers.
I think the current implementation is wrong.
Very broken. Two topic subscriptions == two messages (at least logically)
i.e. different redelivered flags, different message.getJMSDestination(), etc. -
6. Re: A couple of questions on expected JMS behaviour / edge c
adrian.brock Sep 15, 2005 3:35 PM (in response to timfox)"timfox" wrote:
It's curious the TCK doesn't catch this though.
Please do not discuss the TCK in public. Even if it is just flippant comments.
The TCK is licensed under NDA.
Except for whatever Sun releases via Glassfish?
Which isn't very much :-)
https://glassfish.dev.java.net/source/browse/glassfish/appserv-tests/QuickLook-README.txt?rev=1.2&view=markup -
7. Re: A couple of questions on expected JMS behaviour / edge c
timfox Sep 15, 2005 3:35 PM (in response to timfox)Ok, thanks for the clarification.
I shall add JIRA tasks for these issues (and some others), and make sure there are tests for these conditions.