Clarify how Message.receiveNoWait() is expected to behave

[glassfishrobot]

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

Affected Versions

[1.1, 2.0]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/jms-spec/issues/85
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: Unassigned

[glassfishrobot]

@glassfishrobot Commented Reported by @nigeldeakin

[glassfishrobot]

@glassfishrobot Commented liang.x.zhao said: GLASSFISH-7279 was created for that too.

[glassfishrobot]

@glassfishrobot Commented @nigeldeakin said: 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.

[glassfishrobot]

@glassfishrobot Commented clebertsuconic said: 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.

[glassfishrobot]

@glassfishrobot Commented @nigeldeakin said: 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.

[glassfishrobot]

@glassfishrobot Commented clebertsuconic said: 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

[glassfishrobot]

@glassfishrobot Commented @nigeldeakin said: 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).

[glassfishrobot]

@glassfishrobot Commented clebertsuconic said:

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)

[glassfishrobot]

@glassfishrobot Commented Issue-Links: blocks GLASSFISH-7279

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA JMS_SPEC-85