Details

    • Type: New Feature New Feature
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0
    • Fix Version/s: None
    • Labels:
      None

      Description

      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)

        Issue Links

          Activity

          Hide
          rdohna added a comment -

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

          Show
          rdohna added a comment - @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?
          Hide
          koen.serneels added a comment -

          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

          Show
          koen.serneels added a comment - 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
          Hide
          rdohna added a comment -

          Okay... fair enough. I only see monitoring and management clearly out of the scope of JMS.

          Show
          rdohna added a comment - Okay... fair enough. I only see monitoring and management clearly out of the scope of JMS.
          Hide
          koen.serneels added a comment -

          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.

          Show
          koen.serneels added a comment - 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.
          Hide
          Nigel Deakin added a comment -

          For project management reasons I'll ask the expert group to consider this after the JMS 2.0 Early Draft.

          Show
          Nigel Deakin added a comment - For project management reasons I'll ask the expert group to consider this after the JMS 2.0 Early Draft.
          Hide
          Nigel Deakin added a comment - - edited

          This issue should consider the following specific requirements:

          JMS_SPEC-14 - a durable subscription browser
          JMS_SPEC-15 - API to return queue depth
          JMS_SPEC-16 - API to return durable subscription depth
          JMS_SPEC-17 - API is a way to find out the names/clientIDs of all durable subscriptions

          Show
          Nigel Deakin added a comment - - edited This issue should consider the following specific requirements: JMS_SPEC-14 - a durable subscription browser JMS_SPEC-15 - API to return queue depth JMS_SPEC-16 - API to return durable subscription depth JMS_SPEC-17 - API is a way to find out the names/clientIDs of all durable subscriptions
          Hide
          Nigel Deakin added a comment -

          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.

          Show
          Nigel Deakin added a comment - 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.
          Hide
          Nigel Deakin added a comment -

          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.

          Show
          Nigel Deakin added a comment - 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.
          Hide
          nwright added a comment - - edited

          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.

          Show
          nwright added a comment - - edited 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.

            People

            • Assignee:
              Unassigned
              Reporter:
              koen.serneels
            • Votes:
              1 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated: