Skip to main content

[jms-spec users] [jsr343-experts] Re: Late change: A.3.1 Delivery delay (Issue 1: relationship to topic subscriptions)

  • From: John Harby <jharby@...>
  • To: jsr343-experts@...
  • Subject: [jms-spec users] [jsr343-experts] Re: Late change: A.3.1 Delivery delay (Issue 1: relationship to topic subscriptions)
  • Date: Tue, 15 Jan 2013 13:04:31 -0800
  • List-id: <jsr343-experts.jms-spec.java.net>

I agree that (b) is fine in this case. I don't see where (b) prohibits some independent implementation of (a)
if a vendor chose to do so anyway.

Thanks,
John Harby


On Tue, Jan 15, 2013 at 7:52 AM, Nigel Deakin <nigel.deakin@...> wrote:
The final issue listed in Appendix A "Issues" in the draft spec that I would like to discuss is A.3.1 "Delivery delay".

This raises two separate issues which I think it's best to discuss separately. This email covers the first issue.

A.3.1 "Delivery delay" states:

-----------------------------------------------------------------------------

Delivery delay is a new feature added in JMS 2.0 and is described in section 4.12 "Delivery delay".

There is an unresolved issue regarding the delivery of messages to topics which have a delivery delay specified. This is whether the decision to add a message to a subscription (whether durable or non-durable) should be made (a) when the message reaches its delivery time or (b) when the message is sent.

Note that this is a question about deciding which subscriptions a message is added to, not about when the message would actually be delivered. In both cases the message wouldn't be delivered to a consumer until the delivery time has been reached.

If (a) were adopted it would require the JMS provider to keep all messages in the server until their delivery time is reached, even if there were no durable or non-durable subscriptions in existence. This might even be needed for non-persistent messages. Adopting (b) does not require this and by not requiring a message to be held separately from a subscription is closer to the way in which JMS providers work now. Forcing a JMS provider to implement (a) might potentially add a significant burden simply to cater for an unimportant edge case.

In this specification option (b) has been chosen, and section 4.12 "Delivery delay" states that if a message is published to a topic, it will only be added to a durable or non-durable subscription on that topic if the subscription exists at the time the message is sent and continues to exist at the time the specified message delivery time is reached.

However there were differing views on this within the JMS 2.0 expert group and further views are invited.

In addition...[second issue snipped]

-----------------------------------------------------------------------------

So the question we need to review is whether the decision to add a message to a subscription (whether durable or non-durable) should be made (a) when the message reaches its delivery time or (b) when the message is sent.

When we last discussed this (in July 2012) I proposed (b) for the reasons stated above. This was supported by Nick Wright. The only other comment received was from Rüdiger zu Dohna, who proposed that instead of choosing either (a) or (b) we left this "unspecified".

My feeling is that this is too important to be left unspecified as it relates to the fundamentals of how message with delivery delay are delivered to topics. Given the views expressed, and that no-one actually opposed (b), we should go ahead with (b), which is the wording currently in the draft spec.

Any objections? If you have any, please say so now and give your reasons.

Thanks,

Nigel




[jms-spec users] [jsr343-experts] Late change: A.3.1 Delivery delay (Issue 1: relationship to topic subscriptions)

Nigel Deakin 01/15/2013

[jms-spec users] Re: [jsr343-experts] Late change: A.3.1 Delivery delay (Issue 1: relationship to topic subscriptions)

Chris Barrow 01/15/2013

[jms-spec users] [jsr343-experts] Re: Late change: A.3.1 Delivery delay (Issue 1: relationship to topic subscriptions)

John Harby 01/15/2013
 
 
Close
loading
Please Confirm
Close