From: Matthew White <WHITEMAT_at_uk.ibm.com>
Date: Fri, 19 Dec 2014 16:22:47 +0000

Hello;

Happy with that wording.

I can completely see the outline of the correlating message there. The
application can then take action at a suitable point for handling messages
that aren't delivered.
It's perfectly reasonable I think to state that the equals method of these
objects in the main thread and the completion listener should return true.
 I would expect that most people would have assumed this to be the case.


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: 18/12/2014 17:03
Subject: [jms-spec users] [jsr368-experts] Re: Re: Re: JMS 2.0
errata: JMS_SPEC-125 (Define whether a JMS provider should call reset
after sending a BytesMessage asynchronously)



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



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