On 07/12/06, Gordon Sim <[EMAIL PROTECTED]> wrote:
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.
By "locked" you mean unacknowledged?
The section of the JMS spec I read on this was brief and didn't seem to require one approach or the other.
The entire spec is very quiet on the semantics of queue browsing. It seems purposely quiet in order to give vendors a wide choice of implementation. One thing I noticed is that QueueBrowser is only valid in JMS for PTP domain. That doesn't make as much sense with AMQP as you may want to browse messages on a queue that is bound to a "topic" exchange. The spec certainly mentions that you don't need to provide a "snapshot". i.e. there does not need to be any consistency to the Enumeration returned from the QueueBrowser. http://java.sun.com/javaee/5/docs/api/javax/jms/QueueBrowser.html It just mentions that you can browse messages "on a queue". I don't believe it is described anywhere what it means to be "on the queue". i.e. perhaps it includes unacknowledged messages, perhaps not. I'd be inclined to interpret that is messages that have not been sent to a consumer. However with large prefetch windows, perhaps this point of view isn't very useful for some use cases.
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).
System admins will sometimes use a queue browsing tool to view messages on the queues (particularly if one is causing a problem - they will then perhaps delete it). Dead letter queues may be of particular interest. A better management interface (I'm thinking GUI but it would be support by some API) would allow messages on (dead letter) queues to be dropped back on to regular queues or otherwise moved/copied around or deleted. This certainly comes under "management" or "administration". Perhaps we should try to understand more the Mule use case. Maybe they're not being silly. Even though it seems odd what they are doing. Perhaps there is a good reason. Personally, I think that the Mule would not be using a QueueBrowser if it could do some kind of select() over queues to get a readiness notification. Probably good to ask on the Mule list to the author of that code that John was linking to. Cheers, Steve.
