river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gregg Wonderly <ge...@cox.net>
Subject Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Date Thu, 16 Jul 2009 18:47:58 GMT
I am not concerned about any performance issues regarding Groovy based 
configuration either.  It may be that you spend 30ms loading config values 
instead of 3ms for example.  Not a big issue for me.

Gregg Wonderly

James Grahn wrote:
> Do recall that we're discussing Groovy as a replacement to the 
> reduced-java DSL that Jini uses as configuration.   So I don't really 
> see where efficiency concerns enter into this (very limited use, one 
> time cost).
> (That said, Groovy is likely as fast or faster than whatever interpreter 
> we run now.)
> jamesG
> Elijah Menifee wrote:
>> Some of the nice features of groovy is because it is a dynamic language,
>> that can be compiled down to the JVM by the parser when it it
>> reread/reloaded/redefined. According to my understanding however that
>> capability comes at a price: The dynamic code that it generates relies 
>> on a
>> lot of reflection to do some of its magic, so the code is not 
>> optimized the
>> way the standard javac does with static class/method lookup at compile 
>> time,
>> thus it runs slower.  JDK 7 is slated to  include JSR
>> 292<http://jcp.org/en/jsr/detail?id=292>
>> which is supposed to add new JVM Bytecode Ops specifically for 
>> dynamically
>> invoking and redefining class/method structures, which extend beyond just
>> groovy to being able to efficently target lots of different dynamic
>> languages to the JVM efficently, you can read more about this at Dynamic
>> Language 
>> Support<http://java.sun.com/developer/technicalArticles/DynTypeLang/index.html>

>> .
>> NOTE, I am not saying we should not use Groovy, I am just pointing out 
>> the
>> potential inefficiency until JDK 7 is available.
>> In fact one of the things I am looking at is using these type of features
>> (Groovy or another dynamic scripting language that can be run in java 
>> such
>> as Ruby) in the prototype to replace our server.  Note that our current
>> server is written in PERL, and in some ways using a dynamic scripting
>> language with simplified DBI style of untyped SQL access would greatly
>> simplify the porting of much of our buisness logic.
>> The problems we have had with the PERL include low-level bugs in the
>> Net::SSLeay code when a Socket is disconnect during packet writes. 
>> Because
>> of this low-level library bug processes sometimes hang around, 
>> consuming cpu
>> and memory trying to write and renegotiate the link instead of 
>> propogating
>> this disconnect error condition up.  In fact one of the tasks on my plate
>> during business hours is to determine a way to fix this, and submit the
>> patch to CPAN.  Another problem (which we believe was fixed sometine ago,
>> but have not rewritten our server to take advantage of) is that at one 
>> time
>> the PERL thread model was broken when run on SMP (bug on early Perl 5 and
>> 2.2 linux kernels...) machines, so our server was changed to use process
>> forks, which is not nearly as scalable as the threaded server we 
>> started out
>> with.
>> We have had no problems with the SSL layer on our client side in java,and
>> the java SSL implementation is much more heavily utilized and 
>> maintained in
>> this world of JavaEE servers, so the entire reason for prototyping the 
>> new
>> server on java using some the more recent technology is to move to a much
>> more scalable infrastructure as we add clients, using a common code 
>> base on
>> both the server and client, and limiting the number of concurrent
>> transactions on the DB  via worker threads in a que to optimize server 
>> load,
>> and support asynchronous messaging back to the client for push style 
>> updates
>> on data changes from other clients, which can not be cleanly/easily done
>> with our PERL forked server.
>> SO my two cents worth is we use Groovy knowing that it will eventually
>> become much more efficent on the JVM.
>> On Wed, Jul 15, 2009 at 12:01 AM, Peter Firmstone <jini@zeus.net.au> 
>> wrote:
>>> Gee, that looks easy Dennis,
>>> We could also support using java source too in JDK 1.6 or later as the
>>> compiler API is included, but groovy looks so much like java (less
>>> semicolon) it's not funny!
>>> I can't see any reason why we can't use Groovy?  Users can choose with
>>> their feet.
>>> What was the objection?
>>> +1 Peter.
>>> Dennis Reedy wrote:
>>>> On Jul 13, 2009, at 753AM, Tom Hobbs wrote:
>>>>> Someone on the Jini-Users (or similar, I can't quite remember) a while
>>>>> ago was talking about using Groovy classes to describe service
>>>>> configuration.  Something like this sounds pretty neat, but anything
>>>>> that needs to be recompiled for changes can take affect is likely 
>>>>> to be
>>>>> unworkable for obvious reasons.
>>>> I brought up the Groovy config support. Rio has switched over from the
>>>> Jini configuration file approach to now use Groovy classes. No 
>>>> compilation
>>>> is required, the Groovy classes are parsed when loaded by the
>>>> GroovyConfiguration utility. A simple example of a Groovy 
>>>> configuration for
>>>> Reggie follows:
>>>> @Component('com.sun.jini.reggie')
>>>> class ReggieConfig {
>>>>    String[] getInitialMemberGroups() {
>>>>        def groups = [System.getProperty(Constants.GROUPS_PROPERTY_NAME,
>>>> 'rio')]
>>>>        return (String[])groups
>>>>    }
>>>>    String getUnicastDiscoveryHost() {
>>>>        return java.net.InetAddress.getLocalHost().getHostAddress()
>>>>    }
>>>> }

View raw message