[collectd] generic JMX plugin

[Florian Forster]

Hi again,

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
  LoadPlugin "JavaPlugin"
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
the fork.

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.

Regards,
-octo
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20090812/48229fbe/attachment.pgp