I don't have made up my mind on what kind of data to supply over jmx,
but information like the number of active ObjectEndpoints or Endpoints
or any other data that might help to diagnose performance or other
transient problems during production would have my blessing.
I'm not specifically talking about jsr-160.
JMX has helped me in the past on several occasions, and when i talk to
system administrators who even are not allowed access to JMX data
supplied by just the VM alone, i feel sorry for them.
Its about turning the black box into a lighter color.
But confessing my love for JMX is probably not answering the original
question you asked.
Gr. Sim
On 12-11-10 13:36, Tom Hobbs wrote:
I'm happy to implement using JMX rather than an Admin implementation.
Thanks for the suggestion (I often forget that JMX exists...)
I'm guessing then that the idea of supplying this kind of data is not
objectionable to you?
On Fri, Nov 12, 2010 at 12:28 PM, Sim IJskes - QCG<s...@qcg.nl> wrote:
On 12-11-10 13:23, Dennis Reedy wrote:
Would using the the JSR 160 approach where a service adds
net.jini.look.entry.jmx.* attributes to its collection of attributes
it maintains with it's service registration also work? That way a JMX
connection can be established to the service's JVM, allowing jconsole
or visualvm to display (even profile) JVM details?
JMX would be nice.
Gr. Sim
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
--
QCG, Software voor het MKB, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
