And of course both of those are documented at http://activemq.apache.org/jmx.html... Er, nope, that page hasn't been updated in ages, despite new features like these being added.
How can we improve the process to increase the likelihood that JMX changes make it onto the webpage? Maybe a post-commit trigger that looks for commits of files ending in MBeanView and emails the committer? And/or maybe we can automate the generation of the list of bean types and properties by using reflection (or by using JMX against a running nightly build, though reflection sounds easier)? (If we made it part of the release process to generate the HTML and update the webpage, we wouldn't need the post-commit nagging emails.) That content also needs version info: when each bean or property was added and when it was removed; the generation script could grab each prior version JAR and see what beans were present in that earlier version (i.e. removed from a later version) or missing in that earlier version (i.e. added in a later version). https://issues.apache.org/jira/browse/AMQ-4635 may lelp. there is also a destination statistic for blocked sends that could be monitored and there is an advisory that fires when a dest is full. On 17 April 2015 at 03:25, Kevin Burton <bur...@spinn3r.com> wrote: > I’m looking at implementing producer flow control so that I don’t fill up > the queues on my broker. > > It doesn’t look like there’s any way I can see that a client is blocking, > waiting for resources to be released. > > Maybe one strategy could be to put a stopwatch around each send() and then > I can see that I have some outstanding that have been open for a long time. > > > -- > > Founder/CEO Spinn3r.com > Location: *San Francisco, CA* > blog: http://burtonator.wordpress.com > … or check out my Google+ profile > <https://plus.google.com/102718274791889610666/posts> > <http://spinn3r.com>