river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Elijah Menifee <elijahcmeni...@gmail.com>
Subject Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Date Wed, 15 Jul 2009 06:31:48 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message