Martin Ritchie wrote:
On 09/04/2008, Rafael Schloming <[EMAIL PROTECTED]> wrote:
The test mentioned in the subject seems to test for behavior that is not JMS
compliant. Specifically it consumes from a queue with two messages, receives
one message, closes the consumer, consumes from the same queue again and
expects both messages to be there. Essentially it is testing that closing
the consumer will push the messages back onto the queue. This seems to
directly contradict the semantics described here:
http://java.sun.com/products/jms/faq.html#msg_ack_close
I'd like to change this behavior since one of the modifications I've had to
make for 0-10 support is to move certain per/message state that is currently
held by the consumer objects into the session so that we wouldn't, e.g.
forget to acknowledge messages from consumers that are closed. The natural
consequence of this change is that the state of outstanding messages is
unaffected by consumers closing, which does seem consistent with the
intended JMS semantics, but is unfortunately causing this test to fail.
I'd like to modify the test to not expect the message to be redelivered
after the first consumer is closed. Please let me know if you differ with my
interpretation of the intended JMS semantics or object to this change for
any other reason.
I think the test may have once been poor I believe that it has been
updated to now be correct but the descriptions and comments left
incorrectly. The test description should be something like:
Sends two messages. Receives one message on a transacted session but
does not commit. It then closes the consumer. A new consumer is
created that should only receive one message and that message cannot
be message 1.
The test is checking that any pre-fetched messages are flushed back to
the broker on close.
I don't see where the test is currently expecting a redelivered
message the comment say:
// if this is message 1 then it should be marked as redelivered
but the test now fails if it is message 1.
Perhaps I'm missing something but I believe that the test as it is on
M2.1 is correct.
My post was referring to the test on trunk. It appears the M2.1 test has
already been modified to conform to the expected JMS behavior.
--Rafael
