Skip to main content

[jms-spec users] [jsr343-experts] Re: JMS 2.0 Public Draft - release candidate 1 is now ready for review

  • From: Nigel Deakin <nigel.deakin@...>
  • To: jsr343-experts@...
  • Subject: [jms-spec users] [jsr343-experts] Re: JMS 2.0 Public Draft - release candidate 1 is now ready for review
  • Date: Wed, 19 Dec 2012 15:59:24 +0000
  • List-id: <jsr343-experts.jms-spec.java.net>
  • Organization: Oracle Corporation

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@... 
<mailto:nigel.deakin@...>> 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





[jms-spec users] [jsr343-experts] JMS 2.0 Public Draft - release candidate 1 is now ready for review

Nigel Deakin 12/07/2012

[jms-spec users] [jsr343-experts] Re: JMS 2.0 Public Draft - release candidate 1 is now ready for review

John D. Ament 12/19/2012

[jms-spec users] [jsr343-experts] Re: JMS 2.0 Public Draft - release candidate 1 is now ready for review

Nigel Deakin 12/19/2012

[jms-spec users] [jsr343-experts] Re: JMS 2.0 Public Draft - release candidate 1 is now ready for review

Nigel Deakin 12/19/2012

[jms-spec users] [jsr343-experts] Re: Re: JMS 2.0 Public Draft - release candidate 1 is now ready for review

Rob Davies 12/19/2012

[jms-spec users] Re: [jsr343-experts] Re: Re: JMS 2.0 Public Draft - release candidate 1 is now ready for review

Chris Barrow 12/21/2012

[jms-spec users] [jsr343-experts] Re: JMS 2.0 Public Draft - release candidate 1 is now ready for review

John Harby 12/21/2012
 
 
Close
loading
Please Confirm
Close