Good point. I'll try to find some time to implement and test this
keep-alive suggestion.

Thank you :-)
Em 22/01/2014 19:07, "Eric Hodel" <drbrain / segment7.net> escreveu:

> 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 remai=
ns
> 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? Thi=
s
> 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 fro=
m
> the client when it is finished using the service can overcome this proble=
m.
> >
> > 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 objec=
t
> to auto-expire.
> >
> > The idea of auto-expire is actually pretty good since we already have a=
n
> 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-al=
ive
> 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 correctl=
y
> 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.