river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Grahn <jgr...@simulexinc.com>
Subject Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Date Wed, 15 Jul 2009 15:02:43 GMT
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()
>>>    }
>>>
>>> }
>>>
>>>
>>>
>>>
>>>
>>>
> 

Mime
View raw message