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>

Reply via email to