From: Matthew White <WHITEMAT_at_uk.ibm.com>
Date: Wed, 17 Dec 2014 16:18:52 +0000

Hello; Thanks for the comments Nigel;

>Would you be happy with a more precise wording that made the read-only
requirement apply "only" to the message passed
>into the completion listener (but without explicitly talking about
cloning)?
Yes I think this would be a good compromise for the errata; if you work on
the premise that post synchrounous send could be write-only, and post
completion listener the message in the main thread would match sync
behaviour then to say anything else would result in a change to behaviour.
The completion listener in this scenario clone the message and setting
read-only. I can see the benefit in a provider offering to clone the
message based to a message listener.

To comment on correlating the message between completion listener and the
main thread - so long as the message ids are set and/or the
equality/hashcode methods are correctly implemented correlating the
message should not be a problem; this does relay on provider
implementation of course. Maybe something for JMS2.1 would be defining
what message equality should be?

Going forward, I would be happy with JMS2.1 making a very definite
statement re read/write on all message types.


Regards,

Matthew B. White
Architect: IBM MQ JMS, Connectivity & Integration

Phone: 44-1962-817653
E-mail: WHITEMAT_at_uk.ibm.com
About.me: about.me/matthewbwhite
Find me on: and within IBM on:


Hursley Park
Hursley , SO212JN
United Kingdom
"The wrong answers are the ones you go looking for when the right answers
stare you in the face."





From: Nigel Deakin <nigel.deakin_at_oracle.com>
To: jsr368-experts_at_jms-spec.java.net
Date: 16/12/2014 18:39
Subject: [jms-spec users] [jsr368-experts] Re: Re: JMS 2.0 errata:
JMS_SPEC-125 (Define whether a JMS provider should call reset after
sending a BytesMessage asynchronously)



Matthew White wrote:
>
> JMS_SPEC-125 Define whether a JMS provider should call reset
after sending a BytesMessage asynchronously
>
> Main observations here:
> 1) Yes the spec is vague here, and different vendors have gone
different directions. I agree with the observation
> regarding messages from different vendors.
>
> 2) The statement in JMS_SPEC-125 regarding the de facto implementation.
>
> There is nothing in the spec that says that the
> message object that is used for the completion listener should be the
same instance of the message as the one that is
> sent.

I agree it doesn't explicitly say that.

(However if it is a different instance, how should an application which
sends multiple messages asynchronously correlate
the message that was sent with the message that was passed to the
completion listener? I'm thinking of a use case in
which an application sends ten messages asynchronously and then waits for
the completion listener to be invoked for all
the messages.)

> It could be a duplicate - therefore the state of the message could be
different in both cases; read-only in the
> completion listener. But writeable in the main thread.

Understood. Is your concern that my proposed wording would render this
invalid? I hadn't thought of that case.

> 2) The spec on async send says that after completion listener has
fired, then the behaviour is as if a sync send had
> occurred. This is a useful statement to reason about the behaviour of
async send.
> It would be reasonable I would assert that this should also include the
state of the message.

Yes, good point.

> Therefore I do not believe that their should be a difference in
> the spec between async and sync send and bytes messages.
>
> The proposal here is that the errata says the spec must be changed to a
specific version; however this itself could
> present a migration issue. Could I suggest that in line with the other
changes a 'recommended' approach is used.
> JMS2.1 could move to a prescriptive model.

This errata is not intended to require any changes to existing
implementations, not even new features.

The CTS tests currently will fail if the message passed into the
completion listener is not in read-only mode. I was
simply trying to support this with words in the actual spec.

Would you be happy with a more precise wording that made the read-only
requirement apply "only" to the message passed
into the completion listener (but without explicitly talking about
cloning)?

There are other options. One is deferring the matter to JMS 2.1 if this is
getting too complicated for an "errata".
Especially as we already have a JMS 2.1 JSR up and (almost) running.

Nigel





Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU