users@jms-spec.java.net

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

From: John Harby <jharby_at_gmail.com>
Date: Tue, 15 Jan 2013 13:04:31 -0800

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_at_oracle.com>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
>
>