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