On 09/12/2014 12:51, Nigel Deakin wrote:
> Here's the next proposed correction for the JMS 2.0 errata release.
> https://java.net/jira/browse/JMS_SPEC-125
> (Define whether a JMS provider should call reset after sending a BytesMessage asynchronously)
Matthew White commented on the issue (which is fine): I'll reply here. Thank you for the comments.
> A side issue this raises is if the message object reference
> by the completion listener is the same object as referenced
> by the thread that sending the message.
The spec is written on that basis. The javadoc for onCompletion states that the object that is passed in is "the message
that was sent".
> Another option would be suggest that the message that is passed
> to the completion listener be a clone in read-only mode. This
> would let the main thread retain the message in write-only.
Indeed. However a message (especially a BytesMessage) could potentially be very large - so large that you don't want to
be forced to clone its body (especially for async send, whose purpose is high performance). That's why when we discussed
async send for JMS 2.0 we ended up with the rather complicated restrictions on concurrent access described in Section 7.3.9.
> The implication as well is that behavior with 'foreign' messages
> is identical to 'own' messages. Reasonable - but would be worth
> adding in the messaging section.
the use of "Foreign" messages is defined in section 3.12. "Provider implementations of JMS message interfaces".
"A provider must be prepared to accept, from a client, a message whose implementation is not one of its own. A message
with a ‘foreign’ implementation may not be handled as efficiently as a provider’s own implementation; however, it must
be handled."
There's no suggestion here that the requirements of JMS don't apply to "foreign" implementations, but I'm open to
confirming this.
Thanks for the comments. Further views are welcome.
Nigel