The TopologyPinger that is in charge of container state detection (STARTED or STOPPED) uses JMXService to get a JMX client to remote container.
When a remote container was restarted, the JMX client returned by JMXService can not be used because it was closed when stopping the remote container.
So the TopologyPinger should be able to invalidate the JMX client on such case. That's why it is interresting to replace the map of JMX client by a real object pool.
The TopologyPinger that is in charge of container state detection (STARTED or STOPPED) uses JMXService to get a JMX client to remote container.
When a remote container was restarted, the JMX client returned by JMXService can not be used because it was closed when stopping the remote container.
So the TopologyPinger should be able to invalidate the JMX client on such case. That's why it is interresting to replace the map of JMX client by a real object pool.
Christophe DENEUX added a comment - Wed, 18 Mar 2015 - 19:21:53 +0100
Reworked in trunk.
The JMX connection is checked using operation PetalsAdminMBean.ping() on borrowing a JMX Client from the pool. SO a JMX connection previously established on a restarted container is not returned.
Christophe DENEUX added a comment - Wed, 18 Mar 2015 - 19:21:53 +0100 Reworked in trunk.
The JMX connection is checked using operation PetalsAdminMBean.ping() on borrowing a JMX Client from the pool. SO a JMX connection previously established on a restarted container is not returned.
Reworked in trunk.
The JMX connection is checked using operation PetalsAdminMBean.ping() on borrowing a JMX Client from the pool. SO a JMX connection previously established on a restarted container is not returned.