users@jms-spec.java.net

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

From: Chris Barrow <chris.barrow_at_kaazing.com>
Date: Tue, 15 Jan 2013 11:52:59 -0800

Hi Nigel,

I definitely support (b), because it is simpler, easier to understand
(it is what I would expect intuitively), and potentially more performant
to implement, as you pointed out.

Chris

On 1/15/2013 7:52 AM, 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
>