From: Eric Hodel <drbrain@...7.net>
Date: 2014-01-22T13:06:55-08:00
Subject: [ruby-core:59994] Re: About unmarshallable DRb objects life-time

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