messaging
messaging copied to clipboard
jakartaee
Basic metadata/management via JMS
Possibility for metadata in JMS API. Ex. retrieving Queue depth. Although providers will probably not be able to supply real-time accurate readings, it can be very handy to read out the current depth even if not 100% accurate. Currently the only way is to browse a queue and count messages (or use provider specific commands). Other suggestions are: max queue depth, max queue message size and so forth
Management like moving data between objects or deleting messages in one time. The latter one has currently be accomplished by doing (destructive) reads which is of course not not performant. (alternatives are provider custom commands, which we would like to avoid for very basic management things like described)
Affected Versions
[2.0]
- Issue Imported From: https://github.com/javaee/jms-spec/issues/59
- Original Issue Raised By:@glassfishrobot
- Original Issue Assigned To: Unassigned
@glassfishrobot Commented rdohna said: @Koen: I think this suggestion needs to be more specific before it can be reasonably evaluated. Could you provide more information of what you are interested in... and why?!? The current and maximum number of messages in a destination look like monitoring to me. Or do you do load balancing with that?
@glassfishrobot Commented koen.serneels said: I did not mean it from the point of load balancing.
The JMS metadata API (I compare it with the JDBC metadata API) would allow users to obtain information about the object they are working with. The example I gave is queue depth. Just look to a Q object in for example MQ and see what kind of metadata you can retrieve of it. I understand that some of them are provider specific, but queue depth is something very universal.
The reason to obtain queue depth could be from a "monitoring" point of view. It could also be from a debug point of view. Fact is that such data could be interesting to retrieve via de JMS metadata API, which is now all provider specific. Another one would be to get a list from existing MOM objects.
Which is also possible via the JDBC metadata API, you can also ask the question "why do you want to know which tables are in a db, or which are the columns of a given table?" It is just handy in some circumstances and imho should be part of the JMS api (as metadata)
Fact is that MOM's are mostly used in asynch systems, any help of getting information about status or processing progress is welcome. This now all needs to be done via provider specific APIs
@glassfishrobot Commented rdohna said: Okay... fair enough. I only see monitoring and management clearly out of the scope of JMS.
@glassfishrobot Commented koen.serneels said: What's in name. You see queue depth for monitoring, I see it for other use cases. Management; the JMS API currently allows to create temporary queue's, that is also management for me.
The goal of the JMS API is to make developers as easy as possible to access a broad set of MOM related features in an non obscure way. Imho the JMS API is currently:
- Very obscure
- Very limited in functionality
Just look at the JDBC API, why would the JMS API just limit itself to putting and reading messages?
There are techniques in which you can clearly separate these kind of functions from the core JMS API (again , see the JDBC API). You now have the chance to enchance this API so that a lot of functionality will become standerd instead of falling back to provider specific APIs.
Afaik I don't see any good reason why meta data about the MOM objects would form a problem to incorporate as part of the JMS API.
@glassfishrobot Commented @nigeldeakin said: For project management reasons I'll ask the expert group to consider this after the JMS 2.0 Early Draft.
@glassfishrobot Commented @nigeldeakin said: This issue should consider the following specific requirements:
#14 - a durable subscription browser #15 - API to return queue depth #16 - API to return durable subscription depth #17 - API is a way to find out the names/clientIDs of all durable subscriptions
@glassfishrobot Commented @nigeldeakin said: This issue should also consider a feature to allow users to obtain information about those messages on a queue or topic subscription which have not yet reached their delivery time and so are not yet eligible for delivery to consumers.
@glassfishrobot Commented @nigeldeakin said: Here's another suggestion from a EG member:
Maybe it's worth adding a completely new QueueBrowser-Interface called DestinationBrowser. This would allow it to: a) fetch current and future messages (getCurrentMessages and getFutureMessages, boolean arguments always have the potential of getting mixed up) b) return an Iterator instead of an Enumeration c) delete messages through the Iterator d) return future messages in a topic as well! e) return a Destination with getDestination, not only a Queue with getQueue.
The QueueBrowser-Interface would be soft-deprecated, i.e. only in the comment.
@glassfishrobot Commented nwright said:
Maybe it's worth adding a completely new QueueBrowser-Interface called DestinationBrowser. This would allow it to: a) fetch current and future messages (getCurrentMessages and getFutureMessages, boolean arguments always have the potential of getting mixed up) b) return an Iterator instead of an Enumeration c) delete messages through the Iterator d) return future messages in a topic as well! e) return a Destination with getDestination, not only a Queue with getQueue.
The QueueBrowser-Interface would be soft-deprecated, i.e. only in the comment.
As discussed, were this to be implemented I'd like clarify that it includes full durable/non durable topic browsing.
@glassfishrobot Commented This issue was imported from java.net JIRA JMS_SPEC-59