On 17/12/2014 16:18, Matthew White wrote:
> 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.
OK, how about this.
In the javadoc for BytesMessage, insert new text after the sentence ending "After the first call to reset has been made,
the message body is in read-only mode.":
Inserted text:
When a BytesMessage is sent sent asynchronously, the provider must call reset
on the BytesMessage passed to the CompletionListener. This means that the
CompletionListener can read the message body without needing to call
reset.
(i.e. the wording would not prevent it being a clone, without explicitly stating that it can be)
> 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.
I was thinking of how you would correlate the message that is being sent, with the message passed to the completion
listener, using information available before the call to send(). For example, prior to calling send() the application
might create a Map, with the message object as the key, and whose value was some object which needs to be accessed by
the completion listener.
SomeObject someObject = ....
BytesMessage bytesMessage = ...
map.put(bytesMessage,someObject);
context.createProducer().setAsync(completionListener).send(bytesMessage);
If the same object is passed to the completion listener then it can lookup the object using
onCompletion(Message m){
SomeObject so = map.get(m);
m.doSomeCleanup();
}
If a clone is passed, then this would work so long as an ordinary HashMap was used (rather than an IdentityHashMap), and
equals()/hashcode() made them equal.
You couldn't use messageID as the key since this may not be set until the completion listener is called (that's because
it might be provided by the server).
The application could define some key of its own and save it in the message as a property, though this would increase
the size of the message.
> Maybe something for JMS2.1 would be defining what message equality
> should be?
Perhaps...
Nigel
> 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 _ <mailto:WHITEMAT_at_uk.ibm.com>*
> About.me: *_about.me/matthewbwhite _ <http://about.me/matthewbwhite>*
> Find me on: *LinkedIn: http://uk.linkedin.com/in/matthewbwhiteuk <http://uk.linkedin.com/in/matthewbwhiteuk>GooglePlus:
> https://plus.google.com/113767332098102143685/posts?hl=en
> <https://plus.google.com/113767332098102143685/posts?hl=en>SlideShare: http://www.slideshare.net/calanais/
> <http://www.slideshare.net/calanais/>Github: https://github.com/mbwhite <https://github.com/mbwhite>Twitter:
> https://twitter.com/calanais <https://twitter.com/calanais>*and within IBM on: *IBM Connections:
> https://w3-connections.ibm.com/profiles/html/profileView.do?userid=ba8237c0-8f09-1028-85a4-db07163b51b2&lang=en
> <https://w3-connections.ibm.com/profiles/html/profileView.do?userid=ba8237c0-8f09-1028-85a4-db07163b51b2&lang=en>
> IBM
>
> 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