On 8/17/06, jevans12 <[EMAIL PROTECTED]> wrote:
James.Strachan wrote: > > On 8/17/06, jevans12 <[EMAIL PROTECTED]> wrote: >> >> Is AMQ ALWAYS gathering statistics? > > Yes > >> Does the default of useJmx=false only >> stop the mbean interfaces being exposed? > > Yes. > > >> Im running Spring + AMQ (embedded broker topo), we are using the Spring >> MBeanExporter to expose our own mbeans. Since AMQ defaults to >> useJmx=false, > > It defaults to useJmx=true currently > >>> Sorry this page told me different. > http://activemq.org/site/broker-configuration-uri.html > http://activemq.org/site/broker-configuration-uri.html
Apologies, stale docs. I've updated them. http://activemq.org/site/broker-configuration-uri.html
>> our Spring config is actually exposing the AMQ mbeans along with >> up-to-date >> stats. > > How are you getting Spring to explose the MBeans automatically? e.g. > ActiveMQ creates lots of mbeans dynamically such as for each > conneciton, subscription, destination etc. How is Spring gonna expose > those? >>>From the misunderstanding above I see now that AMQ sets useJmx=true >>>I had the same question, Spring is looking for Java5 annontations to look for interfaces to expose via JMX.
So firstly Spring won't find any annotations :). Secondly unless you're doing some funky AOP bytecode weaving, Spring only sees the POJOs created through Spring on startup such as the BrokerService; it doesn't see the POJOs that are created during runtime such as connections AFAIK.
>> I would like to turn off completly the AMQ stats gathering, is this >> possible? > > Just out of interest - why? >>> Interesting enough in my server process i did a memory profile using >>> JProbe. When our server starts up its in a quiescemt state. Im currently >>> upgrading from an AMQ 4.0 snapshot to AMQ 4.0.1 and am noticing memory >>> oscillating from 30M -> 50M. (need to make sure if this was happening >>> before upgrade) > I did a heap dump with instance data of at time t=30M and time t1=50M then > compared snapshots. > When i sorted high -> low on the diferences in memory the > activemq.management.*Stats classes were on top. THis is all very > preliminary.
It could depend on if you are looking at the client side (JMS client) or the broker. The large numbers of instances could just be an effect - such as that you are using huge numbers of sessions/consumers/producers, or using lots of temporary destinations without closing them down or something.
I need to do more analysys and report back later. ALthough in > our production system if I can turn off stats gathering to squeek out a > couple of extra cycles and bytes of memory Id like to have the option.
As I said it should be pretty easy to disable, we just need a patch :).
> I don't think its possible currently. I'm sure it wouldn't be too hard > to patch the code to avoid this... > http://incubator.apache.org/activemq/contributing.html
-- James ------- http://radio.weblogs.com/0112098/
