[collectd] (Generic) Java plugin available for development/testing.

Florian Forster octo at verplant.org
Fri Feb 20 15:40:11 CET 2009


Re,

On Fri, Feb 20, 2009 at 10:12:17AM +0100, Sebastian Harl wrote:
> > integrate with JRuby, JPython, etc., [...]
> 
> That sounds cool. However, as far as I know, Ruby hardly supports any
> multi-threaded access to an interpreter.

as far as I see it `JRuby' is an implementation of Ruby (the language)
in Java and has nothing to do with the ``standard'' Ruby interpreter /
runtime environment.

> Python seems to allow that but it uses a "big interpreter lock"

Another nice way to get more scripting languages might be through
`Parrot'. From a quick glance the embedding interface seems quite
usable.

> to serialize basically anything but IO, so we might run into quite a
> few problems in regard to deadlock prevention.

I've run into problems with this, too:
  Read thread enters the java plugin via the read callback
  -> acquires the JVM
  -> enters `Read' in Java bytecode
  -> reenters the Java plugin via `DispatchValues'
  -> enters `plugin_dispatch_values'
  -> enters the Java plugin via the write callback
  -> acquires the JVM (a no-op)
  -> enters `Write' in Java bytecode
  -> leaves `Write'
  -> releases the JVM
  => BOOM!

This this I've implemented `plugin_dispatch_async' in ba6497bd. It
dispatches the values to a special `dispatch thread' in src/plugin.c, so
that this `read -> dispatch -> write' loop back into the same plugin can
be avoided. Maybe this is of use for the Perl plugin, too..?

> Ack! Having all configuration in one place and using the same syntax
> would be a good thing imho.

That's how it currently is, so since we all agree, that's how it stays
;)

> JFTR: In the perl plugin, I cannot use CVs either, because Perl does not
> allow to share function pointers between threads. I decided to use
> function names instead.

That'd be easy to implement in the Java plugin, too, but IMHO that's a
big hack!

> Imho, the biggest advantage of having `plugin_register_*' is to be
> able to _explicitly_ state (in the code) what you want to do. I'm not
> a big fan of letting things happen magically.

Alright, I'm sold ;)

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/20090220/0d5f7be4/attachment.pgp 


More information about the collectd mailing list