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

[Doug MacEachern]

On Feb 20, 2009, at 1:12 AM, Sebastian Harl wrote:

> Hi,
>
> 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?
>

They are both pure-Java implementations of their respective  
languages.  And being thread-safe unlike their C runtimes is one of  
the main reasons I thought it'd be interesting.
I feel your pain on the Perl impl, having gone through it myself in  
the early versions of mod_perl2.. I don't know of any JPerl ;)

>>>   * I was going to write a Java representation of the  
>>> `config_item_t'
>>>     data structure, so Java plugins can be configured more or less
>>> like
>>>     C plugins. Does that make sense or is there some magic and
>>> standard-
>>>     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
>>> in
>>>     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 ;-)
>

Yeah, the syntax tree can be shared but not the PADLIST (lexicals)   
iirc and my 'r' there has faded after many years.  To get the syntax  
tree sharing we'd load up (compile) as many of .pm's as possible at  
startup before any threads/forks/perl_clones and lookup the functions  
by name at request time.