[ruby-core:59937] Re: About unmarshallable DRb objects life-time

On 21 Jan 2014, at 02:01, Rodrigo Rosenfeld Rosas <[e-mail]> wrote:

> Em 20-01-2014 21:51, Eric Hodel escreveu:
>> On 18 Jan 2014, at 15:12, Rodrigo Rosenfeld Rosas <[e-mail]> wrote:
>>> I still don't understand what you mean. Should I override Object#to_id and #to_obj in the DRb server-side to get this transparent proxy to work somehow?
>> Have you read the id_conv samples that ship with ruby?
>> 
>> $ ag -l id_conv sample/drb/
>> sample/drb/gw_s.rb
>> sample/drb/holders.rb
>> sample/drb/name.rb
> 
> The problem is that as far as I understand this id conversion will only take place for objects tranferred between the drb server and client, right?

Correct.

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

>>> The approach described in that article is that Ruby code is "eval"ued in the DRb server side (running JRuby). I can't easily track what intermediate objects have been created by the eval code on arbitrary code sent by the client-side.
>> The id conversion feature allows you to track such intermediate objects.
> 
> All of them, even if they are not transferred back to the DRb client? How would DRb know about them?

If they are not transferred back to the client and are not referenced they must be garbage, correct?

>>>> Another option is to have the client create a context object on the server that the client allocates and communicates through.  The context object will hold temporary objects and can be cleaned up automatically through a keep-alive mechanism after the client disconnects.
>>> This would be so complex that it wouldn't worth to implement a client that could easily run arbitrary code in the DRb server with access to the JVM
>> It could just be a proxy object that wraps all calls to the underlying API and ensures that only tracked references are returned to the clients.  It痴 basically the same as performing id conversion, but you値l know when the client disconnects so you can drop all references.  You should be able to wrap any protocol generically with such a context object regardless of the communication mechanism.
> 
> This has the same concern as the id conversion approach. I'm not sure if keeping a reference only to the returned objects would be enough or if there could be any cases where the returned objects don't hold any references to other possible required intermediate objects created in the process... I can't think of an example right now, so maybe this can't help, I'm just not confident enough about that

If object A needs object B and it does not hold a reference to object B and cannot otherwise retrieve or recreate object B you have a bug before involving DRb.

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