river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Wade Chandler <hwadechandler-apa...@yahoo.com>
Subject Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
Date Thu, 16 Jul 2009 19:47:15 GMT

How large are the required libraries for groovy which would have to be deployed to every machine
running services? That could be a draw back if we're talking fairly good sized MBs and deployment
models. I know just the main groovy JAR file itself is almost 4MB now days. Just something
to think about with the conversation. More and more dependencies means larger and larger distribution
sizes which in the end result of an application means longer download times etc depending
on the use cases and network limitations.

Wade

 ==================
Wade Chandler, CCE
Software Engineer and Developer
Certified Forensic Computer Examiner
NetBeans Dream Team Member and Contributor


http://www.certified-computer-examiner.com
http://wiki.netbeans.org/wiki/view/NetBeansDreamTeam
http://www.netbeans.org



----- Original Message ----
> From: Gregg Wonderly <gergg@cox.net>
> To: river-dev@incubator.apache.org
> Sent: Thursday, July 16, 2009 2:47:58 PM
> Subject: Re: OSGi RFC 119 Distributed OSGi - (Was [RE: OSGi and Jini])
> 
> 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
> >> 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
> >> .
> >> 
> >> 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 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