Issue Details (XML | Word | Printable)

Key: JMS_SPEC-125
Type: Improvement Improvement
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Nigel Deakin
Votes: 0
Watchers: 0

If you were logged in you would be able to see more operations.

Define whether a JMS provider should call reset after sending a BytesMessage asynchronously

Created: 17/May/13 06:09 PM   Updated: 22/May/13 08:33 AM
Component/s: None
Affects Version/s: 2.0
Fix Version/s: None

Time Tracking:
Not Specified

Tags: jms20-bug
Participants: John D. Ament and Nigel Deakin

 Description  « Hide

This issue concerns the behaviour of the JMS provider when it sends a BytesMessage.

The spec is not clear on what state the body of a BytesMessage is left in after it has been sent. I'm talking about the message object in the sending program, not in the receiving program. There are three possibilities:

1. The JMS provider leaves the body in the same state as it was before the call to the send method. That is, it is in write-only mode with the stream positioned at the end. That allows the application at append data to the message after sending.

2. The JMS provider calls reset(). This leaves the BytesMessage in read-only with the stream positioned at the start.

3. Leave the behaviour undefined.

I would rather not adopt (3) if we can avoid it. The state that the message body is in affects the portability of applications between JMS providers so the required behaviour should be defined if possible.

This issue applies to both synchronous and asynchronous send. In the sync case the issue is what state the message is left in after the call to send() returns. In the async case the message is what state the message is in when the CompletionListener callback is performed. Let's consider these separately.

Asynchronous send

Asynchronous send is a new feature, so although the JMS 2.0 spec is not specific about this, it's not too late to add define the required behaviour more specifically.

I think with an asynchronous send there is a clear benefit in adopting (2). It is possible that a CompletionListener callback method may want to read the message in order to identify the message that was successfully sent. After all, what the point is of passing a message to onCompletion() if its body is not readable?

Another reason for adopting (2) is that I don't think that it is practically possible to adopt (1). This is because of the need to support the case where the JMS provider is used to send a message whose implementation is not its own (JMS 2.0 section 3.12). In that case the JMS provider must use the public API to read the data from the "foreign" message, which means it will need to call reset() before doing so. That would leave the message in read-only mode.

Synchronous send

JMS 1.1 was not specific about this and different vendors already adopt different behaviour. There are no TCK tests which rely on a specific behaviour. I therefore think it is probably too late to define more specific behaviour.

In practice I would suggest that for a synchronous send there is little reason for a sending application to want to read a the body of a BytesMessage after it has been sent.

Nevertheless, for consistency, we should perhaps change the spec to recommend that when a message is sent synchronously, the provider should call reset before the send() returns. But this will need to remain a recommendation since existing JMS 1.1 providers may have interpreted this differently, making it too late to standardise this.

John D. Ament added a comment - 21/May/13 11:30 PM

What is the use case for trying to read data from a BytesMessage that you just sent?

Nigel Deakin added a comment - 22/May/13 08:33 AM

The reason the Message is passed to the CompletionListener is to allow it to determine which message has been sent (e.g. there may be more than one incomplete send). To do that it might need to read the message.

This is a somewhat obscure use case (though it came up in a TCK test) but we have the opportunity to define the required behaviour here and so should take it.