[collectd] generic JMX plugin

[matthew sporleder]

On Wed, Aug 12, 2009 at 8:30 AM, Florian Forster<octo at verplant.org> wrote:
> 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.

This is kind of a naive suggestion as I haven't tried to trace the
code paths, but could collectd fork() the java plugin into its own
proc before instantiation and then, hopefully, just work until the
parent collect was killed and cleaned up its children?