hawtio seems to swamp server with "canInvoke" Jolokia calls - UI becomes unresponsive

[Martin Lichtin]

Is it an expected hawtio behaviour that it makes a large amount of "canInvoke" calls to the server?
   type: "exec", mbean: "org.apache.karaf:type=security,area=jmx,name=...

We've seen it causing a high load CPU load on the server (Karaf) and also the hawtio console becomes very unresponsive.

[Stan Lewis]

The console should be batching those requests but it does basically do this to check (and cache) authorization for mbeans in the JMX tree.  I think we also do this check whenever the JMX tree is updated.  So if you've a case where mbeans in JMX are registered or unregistered often then yeah, you'd probably see these checks occur often as well.  Note that this could be the symptom of another problem, namely that something in the JVM is registering short-lived mbeans.

If you don't care about user authorization then getting rid of Karaf's JMX guard mbean should fix it I'd think, as the frontend will fall back on a dummy mbean or disable those checks entirely.  I'm fairly certain that disabling authentication in hawtio would also have the same effect.

Thanks!

Stan

--
You received this message because you are subscribed to the Google Groups "hawtio" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hawtio+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Martin Lichtin]

I see, hawtio periodically scans for new MBeans.
It seems to be caused by ActiveMQ. Without the broker running, hawtio stays calm. With the broker, hawtio goes wild and continously re-checks.

It repeatedly sends circa 1000 'canInvoke' execs. Does it re-check all MBeans perhaps and not just the new ones?

[James Strachan]

I suspect this is due to an incorrect use of ActiveMQ pooling. If you don't have pooling enabled of connections/sessions/produces/consumers then ActiveMQ will keep creating/destroying mbeans all the time as connections come and go; causing hawtio to fire thinking loads of real mbeans are being created/destroyed.

Disabling mbeans for connections/producers/consumers in ActiveMQ might help work around this maybe...

--

James
-------
Red Hat

Twitter: @jstrachan
Email: jstr...@redhat.com
Blog: http://macstrac.blogspot.com/

hawtio: http://hawt.io/

fabric8: http://fabric8.io/

Open Source Integration

[Martin Lichtin]

Right. I'm not sure the pooling is incorrect, though.

I use Camel JMS endpoints, always with a JmsConfiguration with a pooled "connectionFactory" (either org.apache.activemq.pool.PooledConnectionFactory or com.atomikos.jms.AtomikosConnectionFactoryBean).

In the case of non-transactional JMS endpoints, I configure cache level as CACHE_CONSUMER, but for transactional endpoints (local Spring or distributed Atomikos txs) I set (ie. need to reduce) cache level to CACHE_CONNECTION.

Cf. https://access.redhat.com/documentation/en-US/Fuse_ESB_Enterprise/7.1/html/EIP_Transaction_Guide/files/FMRTxnJMSConfig.html or http://tmielke.blogspot.ch/2012/03/camel-jms-with-transactions-lessons.html

So I guess the TX setup will continuously cause new sessions, new consumers. And there seems no way around it (or is there).

Best workaround might indeed be to disable MBean for producers/consumers/sessions in ActiveMQ.
Is there an option for this? I can't find one..

Thanks
- Martin