Hi uri,

Thank you for your reply.
If you suppose 'instance' as a process or JVM,
it is slightly different.

An invocation of groovyclient, we call a session, in GroovyServ's is
corresponding to a GroovyShell object on single JVM.

When a command line with groovyclient is initiated,
a GroovyShell object is instantiated on the server
and it runs for the command line. Actuary this way
of execution is exactly same as normal groovy script
runs from command line. In source code level,
GroovyServ's GroovyMain2.java is borrowed from
Groovy original source of groovy.ui.GroovyMain2
and those are almost same.

Because of GroovyShell creates new GroovyClassLoader
for each instance, sessions are isolated at the
ClassLoader level. This means static variables defined in
groovy script can't be shared with sessions. But
static variables defined in the classes loaded by
system class loader are shared among sessions.
For example, system properties are shared
among groovyclient sessions. If one session
changes an system property, another sessions
can see the change. On the other hand, System.out/in/err
is handled specially way where those are isolated with sessions.
In the other words, those are treated as session local.

GroovyServer instance is not a process, so
System.exit() should be treated specially too.
Call to System.exit() is interrupted by SecurityManager,
and the exit status is returned to the client which invokes
the exit(), and the client exit by the status.

To sum up, normal groovy processes on JVMs are
emulated by threads in GroovyServer runtime on a JVM.
Likewise, standard streams, stdin/stdout/stderr, are
emulated by some stream classes defined in
GroovyServer.

thanks
UEHARA Junji



2010/3/12 Uri Moszkowicz <uri@(protected)>:
> Hi Uehara,
> As I mentioned before, on my desktop Groovy takes 18sec to load so this is a
> welcome feature. However, the sharing of state between instances is a bit
> concerning. Could the server not maintain a pool of unused instances to
> solve this problem?
>
> Thanks,
> Uri
>
> On Thu, Mar 11, 2010 at 3:55 AM, UEHARA Junji <junji.uehara@(protected)>
> wrote:
>>
>> Hi,
>>
>> I've developed an open source project GroovyServ that makes the
>> apparent invocation speed of groovy faster by pre-invoking groovy
>> runtime as a TCP server. You can download it from:
>>
>>  http://kobo.github.com/groovyserv/
>>
>> IMHO, when using groovy as a scripting purpose, the invocation speed of
>> script could be essential. If you are used to other scripting
>> language, like Ruby or Perl, Python, just two second or even one second
>> feels still too slow. In some environment, script invocation with
>> GroovyServ
>> is more 20-80 times faster then normal groovy because that skips whole
>> of boot sequence of groovy runtime. (I know native Windows' native
>> groovy.exe and groovy 1.8 is relatively much faster but I think I can't
>> say
>> those are extraordinarily effective).
>>
>> Following is a comparison between GroovyServ(native client) and normal
>> groovy in Windows environment with micro benchmark: -e "println 'hello
>> world' ''
>>
>>  Groovy(non native)  2.32 (sec)
>>  Groovy(native exe)  0.90 (sec)
>>  GroovyServ          0.10 (sec)
>>
>> Generally, it depends on environment, the advantage of
>> GroovyServ is bigger in MacOS/Linux environment then Windows
>> environment (with JQS).
>>
>> I'd be interested in any feedback.  Please send it to:
>>
>>  http://groups.google.com/group/groovyserv
>>
>> or tweet me @uehaj .
>>
>> thanks,
>>
>> --
>> UEHARA Junji
>>
>> ---------------------------------------------------------------------
>> To unsubscribe from this list, please visit:
>>
>>    http://xircles.codehaus.org/manage_email
>>
>>
>
>



--
UEHARA Junji

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

  http://xircles.codehaus.org/manage_email