Hi Nigel,
I think mine and Rudiger's opinions are very close (Rudiger please let me
know if you disagree). Nick's approach though does make sense however I
think a fully fledged narrowing API may be too late at this time (for
example, apply selectors, where JMSXDeliveryCount > 1, etc).
My response though was primarily based on the existing API documentation's
approach that the contents of the browser need not be a snapshot, so
messages removed from the queue may still appear here.
Therefore I agree w/ (b) with the caveat that we also think about some kind
of queue browser filter API for JMS 2.1.
John
On Wed, Jan 16, 2013 at 1:28 PM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> (Note for the busy: this email proposes a spec change, see third paragraph
> from the bottom)
>
> In Appendix A "Issues" in the draft spec, section A.3.1 "Delivery delay"
> describes two issues. This email relates to the second, which is described
> as follows:
>
> ------------------------------**------------------------------**
> -----------------
> Delivery delay is a new feature added in JMS 2.0 and is described in
> section 4.12 "Delivery delay".
>
> [first issue snipped]
>
> In addition there is an unresolved issue regarding the behaviour of a
> QueueBrowser. In this specification, section 5.9 "QueueBrowser" has been
> updated to state that "a message must not be returned by a QueueBrowser
> before its delivery time has been reached." However there were differing
> views on this within the JMS 2.0 expert group and further views are invited.
> ------------------------------**------------------------------**
> -----------------
>
> So the question we need to review is whether a QueueBrowser should return
> messages whose delivery time has not been reached. There are two choices:
>
> (a) a message must not be returned by a QueueBrowser before its delivery
> time has been reached
>
> (b) a QueueBrowser will return messages on a queue irrespective of whether
> their delivery time has been reached.
>
> When we discussed this back in July I proposed (a). I said that a
> QueueBrowser should behave similarly to an ordinary consumer, and so only
> return messages which were eligible to be delivered. This is what the spec
> current says.
>
> However there was definitely less than wholehearted support for this from
> the expert group.
>
> Rüdiger zu Dohna preferred (b). He wrote "I think it's important, that the
> QueueBrowser should also report waiting messages: We use browsers for
> tooling, and in that use case, it's even more important to be able to,
> e.g., cancel messages while they are waiting."
>
> Nick Wright was ambivalent: He wrote "I would like to propose that there
> be some additional API call or mechanism for browsing/knowing about
> messages which exist in a Subscription that are not yet eligible for
> delivery do to a delayed delivery time. Otherwise we can end up in the
> situation where resources are consumed by the system but all API calls
> state that the server holds no resources."
>
> John Ament wrote (when he reviewed the public draft in December) that "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."
>
> Although these three comments also propose additional functionality, they
> are all consistent in saying that it was important to be able to find out
> all the messages on the queue, including those which have not yet reached
> their delivery time.
>
> SPEC CHANGE: Given these comments, and the fact that don't have a *very*
> strong view on which option we adopt, I would like to suggest that we
> change the behaviour required by the spec from (a) to (b). This means that
> a QueueBrowser will return messages on a queue irrespective of whether
> their delivery time has been reached.
>
> Is everyone happy with this change? Please give your views.
>
> This discussion also showed a definite interest in better administrative
> or management API to allow messages on a queue or topic to be viewed and
> perhaps deleted. This is out of scope for JMS 2.0, but is definitely
> something we should discuss for JMS 2.1.
>
> Nigel
>