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

Gregg Wonderly wrote:
> 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.
> 

Which I group into the general category of service lifecycle issues.

> 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.
> 

Yep - I had thought about that.  It sparks a bunch of thoughts for me tho'

(1)     We have this flag on the BasicJeriExporter

(2)     We might end up with a similar flag on JoinManager

(3)     What if someone wants to use something else than JoinManager?

It seems to me that there are many ways we could "fix" this but I
suspect it could lead to putting keepalive options in all sorts of
places all of which, for me, would be indicative of a need to establish
a pattern or simple piece of code which should be generally used to
tackle the keepalive issue outside of JoinManager, BasicJeriExporter etc.

I'd say it's almost a Jini Service philosophy kind of thing - "when
programming Jini Services consider the keepalive problem, here's what's
recommended for the back-end/proxy situation, here's what's sane for the
proxy only situation" and so on.

Feels maybe like a pattern we should write up somewhere more than a code
fix?

> Gregg Wonderly
> 

Cheers,

Dan.

--------------------------------------------------------------------------
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]