On 22 Jan 2014, at 03:20, Rodrigo Rosenfeld Rosas <rr.rosas / gmail.com> =
wrote:
>>> But in the case where the returned DRb objects will always hold a =
reference to all required objects created in the server-side, there =
remains another problem. How do I detect that the objects have been =
collected in the client-side so that I could free them in the =
server-side as well? This has always been my main concern with regards =
to manually keeping a reference by artificial means in the server-side.
>> A context object allocated on the server and explicitly terminated =
from the client when it is finished using the service can overcome this =
problem.
>=20
> But the problem is that with a transparent server the client won't =
explicitly terminate anything or it would be a too complex service to =
use and very error-prone.
>=20
>> The context object could communicate with the id conversion handler =
either by tracking peers (possibly difficult) or through time stamps on =
created references.  A keep-alive mechanism would allow the context =
object to auto-expire.
>=20
> The idea of auto-expire is actually pretty good since we already have =
an upper bound for non-streaming responses of 60s (nginx timeout). But =
the problem remains with streamed responses as they could take longer =
than 1 minute.


Rinda=92s Renewer handles this type of problem through the use of =
keep-alive callbacks.

> But maybe using ObjectSpace.define_finalizer would take care of =
freeing the references in the server-side. In that case, I'd still need =
to worry about the drb connection being closed. Is there anyway I could =
detect any connection close from the DRb server-side so that I could =
remove all references to objects created using that connection?

I think ObjectSpace.define_finalizer will be harder to implement =
correctly than keep-alive callbacks.  For example, what happens if the =
client uses a finalizer to destroy a remote object what happens for =
network failures or client crashes?

For the keep-alive callback, if the timeout is greater than the expected =
request duration you should be OK even when there is a temporary network =
failure.=