[collectd] (Generic) Java plugin available for development/testing.
sh at tokkee.org
Fri Feb 20 10:12:17 CET 2009
I'm short of time, so here are just two quick comments ... ;-)
On Thu, Feb 19, 2009 at 09:31:44AM -0800, Doug MacEachern wrote:
> On Feb 18, 2009, at 6:34 AM, Florian Forster wrote:
> I haven't tried it yet, but i think it'd be most interesting to
> integrate with JRuby, JPython, etc., then we can have in-process plugins
> in ruby and python. There's plenty of other nice scripting languages
> that run on the jvm, Groovy, Ioke, etc.
That sounds cool. However, as far as I know, Ruby hardly supports any
multi-threaded access to an interpreter. Python seems to allow that but
it uses a "big interpreter lock" to serialize basically anything but IO,
so we might run into quite a few problems in regard to deadlock
prevention. I'm not sure about other interpreted languages, but I'd
expect problems with all of them at first ;-/ (Perl sucks as hell in
that respect - that caused me quite some pain.) Do you happen to know if
the J* implementations of those languages handle multi-threading
specifically in some way?
>> * I was going to write a Java representation of the `config_item_t'
>> data structure, so Java plugins can be configured more or less
>> C plugins. Does that make sense or is there some magic and
>> ized way to configure Java programs/components?
> As with most 'standards' there are many to choose from ;) I think it'd
> be best to have it the collectd way
Ack! Having all configuration in one place and using the same syntax
would be a good thing imho.
>> * Would it be better to implement the `plugin_register_*' interface
>> Java, too? As far as I know function-pointers are a bit tricky in
>> Java, right?
On Thu, Feb 19, 2009 at 05:27:45PM -0800, Doug MacEachern wrote:
> There are no `function-pointers' in Java, at least not the way you're
> used in C or something like a Perl CV. You just need to use an
> Object for callbacks..
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 was easy to handle, at least made a
_little_ sense to me and, afaik, did not introduce a lot of overhead. If
that makes sense in Java as well, you might want to consider to go that
way as well - then we'd be more consistent. Of course, if that makes
only little sense or would introduce a non-intuitive (for Java
programmers) interface, then don't do it ;-)
(I just got the idea to introduce an object-oriented interface to
collectd in Perl as well ... possibly in addition to the currently
existing interface ... ;-))
> so I think the only advantage I'd see to having `plugin_register_*'
> in Java would be for plugins to construct the objects themselves
> should they need more context than you might get from env->NewObject.
> And perhaps having the callback registration driven by the code rather
> than the config.
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.
Well, that's more than two comments now ... ;-)
Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/
Those who would give up Essential Liberty to purchase a little Temporary
Safety, deserve neither Liberty nor Safety. -- Benjamin Franklin
-------------- 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/20090220/7ca16ca0/attachment-0001.pgp
More information about the collectd