activemq-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fulko Hew <>
Subject Re: how to detect end-of-dataset ?
Date Tue, 06 Nov 2012 19:00:11 GMT
On Tue, Nov 6, 2012 at 1:14 PM, <> wrote:

> ------Original Message------
> From: rajdavies
> To:
> ReplyTo:
> Subject: Re: how to detect end-of-dataset ?
> Sent: Nov 6, 2012 10:22 AM
> I see the problem - there is no way to determine the end of  dataset. The
> assumption is that the request for stats and the handling of the messages
> would be decoupled - so you could periodically query the stats - but then
> process the results asynchronously. Like you say, if the list of
> destinations is constantly changing, you don't know when the end of the
> stats generated finishes. We may need to add an additional null message so
> you can determine this - but it will need to be optional (default off).
> I'll
> look at adding this in.

Thanks, but in the mean time:

a) I need something now (so I've implemented a timer-based decision/caching
b) It would take a while to add the new feature, and then the added
   complication of getting the 'other' group in my company to deploy
   the new version of ActiveMQ.

Probably a more appropriate way would be to provide, as an additional
field in the 'broker' dataset, the value of  'Queues'; and that would
let me iterate across them.  Same goes for 'Topics'.

When it comes down to it... having more of the info in the various beans
also available via this broker plugin would be useful. For example:

  QueueProducers   - and the attributes of the (connector?) entity it can
refer to
                     so I can see who is putting/getting and where.
  QueueSubscribers - similar to QueueProducers
  Queues           - so you can get the list of queues
  Topics           - to get the list of topic (and also the ability to get
                     attributes (similar to

The easy answer is: 'make accessible, everything in the various beans',
The more specific answer is: 'it would take me a while to come up with
the list of "important items for manageability (versus application


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message