Re: Using ServiceStarter to launch a "proxy is service" service

Dan Creswell wrote:
> Gregg Wonderly wrote:
>>Francisco Dário Mourão wrote:
>>>Ok. That was my backup "tricky" solution... I didn't think it had to
>>>be that way...
>>>I thought ServiceStarter would have some special parameters to handle
>>>it accordingly... Why isn't this code necessary for the remote case?
>>
>>There are non-daemon threads blocked on "ServerSocket.accept()" (or NIO
>>channels) that keep the VM from exiting.
>
> Gonna try and round that out some.....
>
> Basically, when one instantiates a service consisting of back-end and
> proxy there has to be some communications conduit between the two
> components something like a socket or a SOAP connection or RMI or....
>
> Many of these communications conduits are such that the server must
> spawn additional threads to handle connections, ship data back and forth
> etc.  The presence of these threads typically prevents the JVM from exiting.
>
> On my pedantic days, I would say that this behaviour is a convenient
> side-effect that a programmer shouldn't count on and thus the "tricky"
> solution is actually the "correct" solution as well.
>
> In the case of BasicJeriExporter there's a configuration option to
> enable this "keepalive" behaviour but, of course you'd need a back-end
> to make this option appropriate/useful.  In your specific example this
> wouldn't be a sane option and there's no other entity in your design
> which naturally would accept this responsibility and thus you have found
> that it's assumed you'll code something suitable yourself!
>
> Remember also the most common structure for a service is to have a proxy
> and one or more back-ends and thus it might not be entirely surprising
> to find certain things (like com.sun.jini.start) favour that model over
> others such as the much rarer proxy only service.
>
> We probably ought to post this up in a FAQ or a Wiki or whatever or
> perhaps even put this in as an open issue for River to concern itself with.

One of the issues to deal with, is how a view into all the allocated, active
resources might make it possible to determine what resources are active or not
active, and how one might decide that the VM would exit unexpectedly.

This issue, for me, is all about understanding how the JVM liveness behaves
under particular situations.

One thing that comes to mind though, is what isn't the JoinManager keeping the
JVM active?  That might be the best place to start thinking about this issue.
I'd argue that any exported service definition regardless of whether it's a
proxy or a serialized object of another nature, should cause the JVM to stay alive.

Gregg Wonderly

--------------------------------------------------------------------------
Getting Started:     http://www.jini.org/wiki/Category:Getting_Started
Community Web Site:  http://jini.org
jini-users Archive:  http://archives.java.sun.com/archives/jini-users.html
Unsubscribing:       email "signoff JINI-USERS"  to [email protected]