Mailing-List: contact river-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: river-dev@incubator.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <4A5F75DE.7010403@cox.net>
Date: Thu, 16 Jul 2009 13:47:58 -0500
From: Gregg Wonderly <gergg@cox.net>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: river-dev@incubator.apache.org
Subject: Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
References: <F5DF5420-6DCA-4873-A8E4-8E9F501D5CB3@mac.com>
 	<0CC21688-E720-40BB-8237-D47B4DEE4F48@wonderly.org>
 <e736790906262107t30323f25m6f3369aa306083ec@mail.gmail.com>
 	<4A4921FA.3030408@wonderly.org>
 <510143ac0907030226i22b4d6e9tf70857d357f115f4@mail.gmail.com>
 	<e736790907030825m322488e0rcb75dfb347eab059@mail.gmail.com>
 	<e736790907030930w289e3324wd251f0b7d1489de2@mail.gmail.com>
 	<964EAC824495234A86F3C47DA8BD8AAD1776B4@sucden-exch.sucden.co.uk>
 	<E099BB07-376A-4357-9920-7D2C77F57927@gmail.com>
 <4A5D62C2.7040506@zeus.net.au>
 <93890df00907142331h24885effp59803db4c71c14d9@mail.gmail.com>
 <4A5DEF93.6010607@simulexinc.com>
In-Reply-To: <4A5DEF93.6010607@simulexinc.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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()
>>>>    }
>>>>
>>>> }
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>
>