[collectd] generic JMX plugin
octo at verplant.org
Wed Aug 12 14:30:02 CEST 2009
the problem is probably way too obvious – I had to talk to a co-worker
to figure it out ;)
When creating a JVM, ‘libjvm’ will create a couple of threads (garbage
collector, finalizer and whatnot). This happens as soon as the first
line within the <Plugin java> block is read from the configuration. This
happens because the configuration of the Java-based plugins is handled
just like the other, “normal” configuration.
collectd will fork *after* the configuration is read. By that time, the
JVM is already up and running and already executed code. What happens is
that the threads created by the JVM will no longer be available after
And that's it, really: By forking after creating the JVM we destroyed
the threads used by the VM.
Unfortunately I didn't find something like a ‘PrepareForFork’ or
‘RestartThreads’ function in the “Java Native Interface” (JNI), so I'm
afraid this may simply not be possible.
The only work-around I can think of right now it to delay loading of
classes and parsing of the configuration until after the fork. The
plugins can still complain about invalid configuration, but they won't
have access to STDOUT / STDERR anymore.
Florian octo Forster
Hacker in training
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20090812/48229fbe/attachment.pgp
More information about the collectd