Em 21-01-2014 19:36, Eric Hodel escreveu:
> ...
>> My concern is that with a generic drb server that will evaluate arbitrary code in the server-side there are good chances more objects will be created in the server-side that are not referenced by any of the objects transferred over DRb, don't you agree?
> If such objects are created and not accessible locally (server side) and not accessible remotely (client side) then they are by definition garbage and should be collected.
>
> You only need to care about objects that are not accessible locally (server side) but are accessible remotely.  With the default id conversion these objects are treated as garbage on the server side.  By holding a reference to them on the server through id conversion they will no longer be garbage.

Yes, I think you're right.

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

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?