Message expiration in JBossMQ - JBAS-4328

[dimitris]

There is already some discussion on the following jira issue about message expiration with JBossMQ:
http://jira.jboss.com/jira/browse/JBAS-4328

There is disaggrement as to if this is bug or not, nevertheless, Carlo's testcase fails as follows:
http://cruisecontrol.jboss.com/cc/artifacts/jboss-4.2-testsuite-sun-1.5/20070502004420/results/org/jboss/test/jbossmq/test/JBAS4328UnitTestCase.html

Maybe we need a 3rd party (Tim) to express an opinion.

If there is no resolution by Friday/4th, I'm going to exclude the test from the testsuite.

[clebert.suconic]

From what I looked on the testcase you should be receiving three messages, as time to live is set to 1 second, the MessageListener is set on the ConnectionConsumer and there is no wait between the send and connection start.

If you want that behavior on the testcase I guess you should wait some time before you start the connection.

[clebert.suconic]

just as a reference, this is the URL for the testcase:


http://anonsvn.jboss.org/repos/jbossas/branches/Branch_4_2/testsuite/src/main/org/jboss/test/jbossmq/test/JBAS4328UnitTestCase.java

[timfox]

What's happening in this test is the messages are sent, then almost immediately they are received by the connection consumer (which lives on the client side) - at this point they are not expired.

Later on the connection consumer passes the messages onto the message listener and a delay is introduced, but by this time the messages are already on the client so won't get expired since JBossMQ doesn't do an extra client side check.

I haven't actually run this test against JBoss Messaging but we do an extra client side expiration check as well as a server side one. This is particularly important to us since we buffer messages on the client side, therefore I would expect this test to pass for JBM.

However, having said all that, the JMS spec is pretty loose about JMSExpiration:

When GMT is later than an undelivered message?s expiration time, the
message should be destroyed. JMS does not define a notification of message
expiration.
Clients should not receive messages that have expired; however, JMS does not
guarantee that this will not happen.

Since there are no guarantees I would say the JBossMQ is sub-optimal but not incorrect and is fully spec compliant.

You can't expect a general jms provider to fully honour JMSExpiration in all circumstances.

[clebert.suconic]

From what I looked on the testcase you should be receiving three messages, as time to live is set to 1 second, the MessageListener is set on the ConnectionConsumer and there is no wait between the send and connection start.

If you want that behavior on the testcase I guess you should wait some time before you start the connection.

Just for the record.. I didn't realize the wait on the MessageListener when I wrote that.. duh :-)

[wolfc]

"timfox" wrote:
You can't expect a general jms provider to fully honour JMSExpiration in all circumstances.

Oi, I thought we were talking about a JBoss product here. :-)

I would say either is does expiration or it doesn't, not a weird mixture were I don't expiration but others do.

I understand that the expiration isn't real time, so there is always some slack between expiration and consumation of the message.

"JMS 8.2.7" wrote:
The JMS provider retains control of its messages until they are delivered to the MessageListener. This insures it is under direct control of message acknowledgment.

Given the above JMS should provide full service to the message until it has passed through the message listener.
BTW, does persistence work when the message has passed the consumer, but not the listener?