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.
Regards,
Peter.
