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 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