[JMS_SPEC-85] Clarify how Message.receiveNoWait() is expected to behave Created: 09/Mar/12  Updated: 18/Jul/13

Status: Open
Project: jms-spec
Component/s: None
Affects Version/s: 1.1, 2.0
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Nigel Deakin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-7279 receiveNoWait should poll broker Open
Tags: jms21-forreview-minor

 Description   

The javadoc for the java.jms.MessageConsumer method receiveNoWait() states that this method "Receives the next message if one is immediately available."

Several, if not most, JMS providers interpret the meaning of "immediately" (and "no wait") literally and only return a message is one is already available on the client. They do not attempt to contact the server to fetch a message from the server, even if there is one available.

This means that the effect of calling receiveNoWait() is unpredictable and experience suggests that developers are best advised never to use it.

It is proposed that the behaviour of this method should be clarified to state what it says above, and to recommend the use of the other receive methods in most cases.

Edit Following comments, this issue has been broadened to consider all possible interpretations of this method. See below



 Comments   
Comment by David Zhao [ 18/Jun/13 ]

GLASSFISH-7279 was created for that too.

Comment by Nigel Deakin [ 17/Jul/13 ]

Whilst the JMS expert group and others are considering this issue they may also wish to consider whether a new method (called, say, receiveIfAvailable) should be added which blocks for as long as is required to determine whether there are any messages in the queue or topic subscription.

Comment by clebertsuconic [ 17/Jul/13 ]

I thought most implementors would do a roundtrip to the server these days. Can't we just clarify that receiveNoWait should make a roundtrip to the server?

We used to do that on earlier implementations of Messaging products at JBoss, but our latest implementations are doing the round trip.

Comment by Nigel Deakin [ 17/Jul/13 ]

Yes, the alternative (to my initial suggestion) would be to clarify the definition of receiveNoWait to allow it to wait for as long as is required to determine whether there are any messages on the queue or topic subscription. It's helpful to hear that this is what JBoss products do.

Comment by clebertsuconic [ 17/Jul/13 ]

Yes, FYI: we used to only look at the client buffer on older implementations but we were hammered by users complaints.. .so we switched the implementation.

So, that's probably what most users would expect... so I would favour users' interpretation here as opposed to implementors interpretation.

just IMHO

Comment by Nigel Deakin [ 18/Jul/13 ]

Indeed. Let me reword the description of this issue as follows, to offer three alternatives. Here it is:

The javadoc for the java.jms.MessageConsumer method receiveNoWait() states that this method "Receives the next message if one is immediately available."

Some JMS providers interpret the meaning of "immediately" (and "no wait") literally and only return a message is one is already available on the client. They do not attempt to contact the server to fetch a message from the server, even if there is one available. This means that the effect of calling receiveNoWait() is unpredictable and experience suggests that developers are best advised never to use it.

Some other JMS providers interpret the meaning of "immediately" (and "no wait") more leniently and always contact the server to see if a message is available. This makes the method more predictable and more useful to users, and is probably closer to what users would expect.

It is proposed that the behaviour of this method should be reviewed and clarified if possible. There are three options:

1. To clarify that the receiveNoWait() should only return a message is one is already available on the client.

2. To clarify that the receiveNoWait() may wait for as long as is required to determine whether there is a message on the queue or topic subscription, and to remove the words "if one is immediately available" which is ambiguous.

3. To leave the interpretation open to vendors to decide.

As Clebert says, users probably expect (2).

If we adopt (1) then we might want to define a new method which behaves as in (2).

Comment by clebertsuconic [ 18/Jul/13 ]

>> If we adopt (1) then we might want to define a new method which behaves as in (2).

for me, this point narrow us on (2)... because:

  • Any option given to vendors will make them implement a method that will have to perform (2). There won't be a choice, right?

I would say: lets just make sure receiveNoWait is such method.

I mean... for me, in logical terms (1) == (2)... I would then just make this into two options:

(2) and (3)

and I vote for (2)

Generated at Mon Jul 14 08:44:38 UTC 2014 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.