river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: strange problem with DGC
Date Sun, 07 Mar 2010 12:15:26 GMT
QCG - Sim IJskes wrote:
> Peter Firmstone wrote:
>>> The problem starts when you marshall it in 
>>> BasicInvocationDispatcher.marshalReturn(), and the reply has enough 
>>> latency to arive 'late' at the client side.
>>> In this window the service becomes 'weakly reachable' and if the GC 
>>> kicks in before DgcServer.dirty the object gets finalized.
>> Keep a strong reference, to the service (not the proxy), long enough to 
> Indeed, but my point is, that this is so counter-intuitive. It looks 
> like this is completely overlooked by the design of jini. Why? I can't 
> imagine. Everywhere where you have a service that has a factory method 
> for a service, and you don't register the service or save the service 
> reference, this will happen. It has never been documented.
> It is because GC has become better? Shouldn't we include a fix in the 
> BasicJeriExporter for this?
Hmm interesting, by default DGC is disabled and all exported Remote's 
are only referred to by a weak reference, unless the implementer holds a 
strong reference, when using DGC (discouraged for secure endpoints due 
to DOS attacks) the service will have a strong reference kept, while 
client remote references leases exist. However if there's an intervening 
period where there are no clients and no local strong reference the 
Remote object will be GC'd.

The same thing occurs to a Service that is registered with the lookup 
service, if there aren't any local strong references or remote 
references from clients for that matter, it will be garbage collected.

You are right, we need to document the behavior better (any volunteers?) 
it isn't intuitive.

Perhaps we could create a local BasicObjectEndpoint with the default 
lease duration in the referenced set?  This would expire after the lease 
duration, it would complicate the code though.  Or we could just provide 
better documentation.  Anyone got a better idea?

Don't be shy everyone, please make suggestions.



View raw message