John,
Many thanks for your comments.
On 19/12/2012 01:03, John D. Ament wrote:
> Nigel,
>
> In general, I'm good with the changes in the spec; I think there's just some minor clean up in order. Some items jumped
> out at me,
>
> First was this line (page 52) /Messages with a later delivery time may be delivered after messages with an earlier
> delivery time. /I feel like this should be a "shall" or a "should" rather than a may, unless the intention is to make
> this an optional feature. I would have assumed this to be a required feature, if the delivery time is set.
Interesting point. Here's the definition of delivery delay in 4.12:
"A message's delivery time is the earliest time when a JMS provider may deliver the message to a consumer. The provider
must not deliver messages before the delivery time has been reached."
The word "must" means this is not an optional feature.
In section 4.4.10.2. "Order of message sends" I wrote "Messages with a later delivery time may be delivered after
messages with an earlier delivery time" because this is what will happen if there is a consumer waiting and there is no
delay in processing messages.
I used the word "may" here because a message with a later delivery time will *not always* be delivered after a message
with an earlier delivery time. For example:
Consider a single producer on a queue. There are no consumers.
The time is 2pm.
Producer sends message M1 with a delivery delay of 2 hours (so delivery time is 4pm).
Producer sends message M2 with a delivery delay of 1 hours (so delivery time is 3pm).
There are no consumers so both messages wait in the queue.
Three hours elapse.
The time is now 5pm. A consumer is now created on the queue.
Both messages have passed their delivery time and so are eligible for delivery
Message M1 will be received
Message M2 will be received.
Essentially, if a message is eligible for delivery (i.e. it has passed its delivery time) then the delivery time plays
no part in determining the message order.
Does that sound reasonable? If we're agreed on the underlying behaviour I can certainly try and make this clearer.
>
> Also, section 4.9, page 60, JMS Exception is the base class for all checked JMS exceptions sounds more appropriate here.
> Likewise, JMS Runtime Exception is not listed under section 7 and should be.
Yes, this needs updating. I have changed section 4.9. "Exceptions" to be:
JMS defines two sets of exceptions. JMSException is the base class for all checked exceptions, and JMSRuntimeException
is the base class for all unchecked exceptions. See Chapter 7 "JMS exceptions" for more information.
This also reminds me that Chapter 7 "Exceptions" also needs updating to describe the new unchecked exceptions. As this
is only a small chapter I have done so. However this now leaves the new section 11.2.9, which introduces the exception
handling of the simplified API, as being somewhat redundant.
I'm going to leave chapter 11 "simplified" API for now as I think it is a useful introduction to this new feature.
However I will merge much of its contents in with the rest of the spec after the public draft.
Whilst updating chapter 7 I have realised that I haven't defined ResourceAllocationRuntimeException in the API. I have
now done so.
>
> Section 5.9, page 65, /A message must not be returned by a QueueBrowser before its delivery time has been reached./ I
> feel like this shouldn't be a requirement for the browser - it should show all available messages on a queue regardless
> of ready to deliver or not. Perhaps I missed that part of the discussion when we were talking about delivery time.
This issue is explicitly listed as unresolved in section A.3.1.
We discussed this in July/Aug/September. Rüdiger zu Dohna, Nick Wright and non-EG member Chris Barrow contributed. I
proposed the wording that the spec currently: my feeling was that a QueueBrowser should provide the same semantics as an
ordinary consumer. However Rüdiger and Nick made similar comments to the one you are making now.
My sent an email on 7th Sept which reviewed this discussion:
http://java.net/projects/jms-spec/lists/jsr343-experts/archive/2012-09/message/3
See that email for details, but essentially I didn't want this issue to hold up the delivery delay feature, so I went
ahead with my proposal, but mentioned it as an unresolved issue in the draft specification (in section A.3.1).
So we will definitely come back to this. My goal is to be able to remove the "unresolved issues" section by the time of
the final release. Thanks for the reminder (and for your view).
>
> It also feels like chapter 9 is out of place. Perhaps it was simply in the order of the original spec? I think it
> should be the last chapter, or merged with 11.4 as a new chapter, this way we can consolidate all demo code into a
> single chapter.
Chapter 9 is "JMS example code". I tried to avoid moving chapters as I thought that would make the document harder to
review. But on reflection I agree we should move it to the end and merge it in with 11.4 "Examples using the simplified
API". That's a bit too large a task to do right now so I will start this after we have submitted the public draft.
Thanks again,
Nigel
> Regards,
>
> John
>
>
>
> On Fri, Dec 7, 2012 at 3:59 PM, Nigel Deakin <nigel.deakin_at_oracle.com <mailto:nigel.deakin_at_oracle.com>> wrote:
>
> In accordance with the Java EE schedule published several months ago, the time has come for us to checkpoint the
> work we have done so far on JMS 2.0 and publish a public draft for formal review.
>
> (The complete JMS 2.0 schedule is here:
> http://java.net/projects/jms-__spec/pages/Home#JMS_2.0___schedule
> <http://java.net/projects/jms-spec/pages/Home#JMS_2.0_schedule> )
>
> I've also taken a copy of the latest draft specification and javadoc and uploaded them as "release candidate 1" to
> the project downloads area at http://java.net/projects/jms-__spec/downloads/directory/__PublicDraftRC1
> <http://java.net/projects/jms-spec/downloads/directory/PublicDraftRC1>.
>
> You can also browse the API docs online at
> http://jms-spec.java.net/2.0-__SNAPSHOT/apidocs/index.html <http://jms-spec.java.net/2.0-SNAPSHOT/apidocs/index.html>
>
> I would like to submit these to the JCP admins before the holidays, so could you all please review the spec and API
> docs and state whether or not you think this is fit to be published formally as the public draft? Please respond by
> Wednesday 19th December.
>
> Of course I'd also welcome any comments or questions. If you see any errors or typos please let me know - I'll
> update the draft as needed over the next week or so.
>
> One weakness of the document in its current form is that the simplified API is still mostly confined to its own
> section at the end rather than being integrated with the rest of the specification. I have deliberately avoided
> doing that so far to make it easier for people to see what's changed. However I do plan to restructure the document
> (essentially moving blocks of text around) before the final release.
>
> Appendix B.5 lists the significant changes in the specification. The whole document also has change bars.
>
> Please also take a look at the planning page at
> http://java.net/projects/jms-__spec/pages/JSR343Planning <http://java.net/projects/jms-spec/pages/JSR343Planning>
> This lists all the JIRA issues that have been incorporated into the public draft, and all those which have not.
> Those which have not will mostly be rolled forward for consideration for JMS 2.1.
>
> Nigel
>
>
>