Robert Greig wrote:
On 06/12/06, Gordon Sim <[EMAIL PROTECTED]> wrote:
Colin Crist wrote:
> 2. It should show messages that have been delivered but not
> acknowledged/committed.
This is a good point and wasn't considered in the rough sketch I sent
out earlier. Both the java and c++ brokers would need some modification
to make this easy to do. Unacked messages are currently held in the
'channels' for the consumers they were delivered to, and not in the
queue itself.
Would we actually want to support this except through the management
interface (I think in our management interface we only support getting
the count of the number of unacked msgs in the channel but I agree we
should enhance this to allow retrieval of the actual messages)?
After thinking about this some more I had the same question. One way of
looking at the browse functionality is that it provides an indication of
what would be available to consume at a particular point in time (though
in the face of continuous activity that isn't terribly useful anyway).
Messages that have been sent but not acked are not available (at least
not until the consumer that received them does without acking).
The other view is that the browse should show all messages that are
logically still on the queue even if they are 'locked' by a consumer. In
this case, it seems to me that at the very least you would want some
indication of whether or not the message was locked. This starts to feel
more like a management interface.
The section of the JMS spec I read on this was brief and didn't seem to
require one approach or the other.
Are there any good use cases for queue browsing that anyone can share?
To me it seems to be either for some form of management or for use where
the queue contents don't change much. In the second case I think it
would be better not to show unacked messages, and in the first case I
think you would want to know the status of each message shown (i.e. is
it unacked or fully available).
