On 11 July 2012 at 12:42 Nigel Deakin <nigel.deakin_at_oracle.com> wrote:
> Rüdiger,
>
> Many thanks for your comments...
>
> (Reminder: The key issue 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. I proposed (b) to
> simplify the implementation for existing vendors.)
>
> On 11/07/2012 07:12, Rüdiger zu Dohna wrote:
> > I'd prefer (a), but, as you say, this may impose a significant burden on the
> > providers. Why not leave it unspecified?
>
> I think this is a core issue related to message delivery to consumers which
> the spec should try to define one way or the
> other.
>
> (unless we require both to be supported, which I think we should avoid unless
> we really think some *users* would want
> one and other users would want the other)
>
> More views please!
>
> > The providers would be asked to document their behavior, and they may even
> > choose to make it configurable per topic
> > or so.
>
> > OTOH 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.
>
> (Reminder: I suggested that the QueueBrowser should only return messages which
> are eligible to be delivered immediately.
> I therefore propose that this be clarified to state that "a message must not
> be returned by a QueueBrowser before its
> delivery time has been reached.")
>
> There is no feature even now to "cancel" messages, so if a QueueBrowser
> returned a message which hadn't reached its
> delivery time they couldn't do anything with it - they couldn't even use a
> consumer to consume it. So I think it is more
> consistent for the QueueBrowser to behave like an ordinary consumer and only
> see messages which have reached their
> delivery time.
>
> More views please!
>
This makes the browser consistent as a consumer, but not as a management object
which is how I interpret it's desired usage. In my previous response I queried
the addition of a method to specifically determine the presence of messages that
are not yet eligible for delivery. Whilst we cannot mutate this we can at least
determine that there are items awaiting delivery.
> This is a big area where vendors offer features beyond those provided by JMS,
> including browing a durable subscription
> (or topic), cancelling messages, editing messages which have already been
> sent, and so on. No doubt vendors will want to
> extend these features to do useful things with messages which have not reached
> their delivery time. Some people have
> proposed we add more standard features in this area, though the proposals
> JMS_SPEC-59 (management API) and JMS_SPEC-14
> (durable subscription browser) received no votes in the recent voting.
>
> Nigel
Regarding the metadata API on JIRA (
http://java.net/jira/browse/JMS_SPEC-59
<
http://java.net/jira/browse/JMS_SPEC-59> ), as we move towards cloud/PaaS
environments in JEE7 I think a more standardised API for viewing and managing
subscriptions certainly becomes a lot
more important. Certainly there are a number of times I have found it greatly
beneficial to monitor and purge complex, clustered messaging systems in test and
production environments to clear unexpected system states. Were something like
this made available I would like to see the ability to centrally view cluster
subscriptions regardless of the attach point of a consumer; given
that implementations must maintain some sort of routing table for producer
message input I expect that something of
this nature would be available on all JMS cluster nodes.
Unfortunately I think there are some more pressing standardisations (hence my
votes!), so perhaps the API is a good
candidate for JMS 2.1?
Nick