Thanks Chris, that's the best strategy I've seen, I think it should be
adopted as the accepted standard practice, got any examples we can use
for doc's on our web site?
Christopher Dolan wrote:
Another strategy we've used is to hold a reference to the service in a
Thread passed to Runtime.addShutdownHook(). That serves the dual
purpose of keeping the service from being GC'd and enabling last-minute
cleanup of a service that is not explicitly unregistered and unexported.
In our code, we also use a manual unregister() method on each service
that stops the JoinManager, unexports the service, and removes the
shutdown hook. So, in this case the shutdown hook is a fail safe in
case of a developer bug.
What's interesting, is Sim appears to be creating a Remote, exporting it
and serializing it's proxy directly across to a client/s without using
the Service Registrar. I'm guessing it is basically a distributed
mutable object where mutations are controlled by one node, responsible
for managing it's mutability and providing some local information for
it's implementation, but where the parent node doesn't need to utilize
this particular object and hence doesn't keep a strong reference (if the
implementation didn't need local info and it wasn't required on the
parent node, the mutable object itself could be serialized rather than
it's proxy). So it appears the remote clients need some information
from the node on which the object is running.
Ordinarily, one would choose a service to provide the information,
however I think in Sim's case he has made this design decision due to a
corner case where the parent node's network connection is hidden behind
a firewall, so the information cannot be provided by a service. Hence
the handback Remote object. He wants to use DGC to clean it up when no
longer needed.
Cheers,
Peter.
