From: Rodrigo Rosenfeld Rosas Date: 2014-01-22T19:17:16-02:00 Subject: [ruby-core:59995] Re: About unmarshallable DRb objects life-time --047d7b3435c041d9ab04f095a674 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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" escreveu: > On 22 Jan 2014, at 03:20, Rodrigo Rosenfeld Rosas > 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. --047d7b3435c041d9ab04f095a674 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

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> escrev= eu:
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 hol= d a reference to all required objects created in the server-side, there rem= ains 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? Th= is has always been my main concern with regards to manually keeping a refer= ence 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 pr= oblem.
>
> 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 handle= r either by tracking peers (possibly difficult) or through time stamps on c= reated references. =A0A 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 mi= nute.


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

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

I think ObjectSpace.define_finalizer will be harder to implement correctly = than keep-alive callbacks. =A0For 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 re= quest duration you should be OK even when there is a temporary network fail= ure.
--047d7b3435c041d9ab04f095a674--