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

On 18 Jan 2014, at 15:12, Rodrigo Rosenfeld Rosas <[e-mail]> wrote:
> Em 17-01-2014 19:53, Eric Hodel escreveu:
>> On 17 Jan 2014, at 04:22, Rodrigo Rosenfeld Rosas <[e-mail]> wrote:
>>> I guess the problem is that I didn't quite understand what you meant by this id_conv thing even after looking at the examples you pointed me to. Are there any comprehensive documentation about this feature?
>> There痴 no comprehensive documentation, but it痴 not a particularly complex feature.  You implement to_id to convert an object to a reference and to_obj to convert a reference to an object.  How you do this depends on the needs of your application.
> 
> 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 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.

>> One option is to use an LRU-backed id converter with a smart client that can recreate objects for lost references.
> 
> I would have no idea on how to recreate a lost object I don't even know about (it was generated by a generic "eval" call anyway).

This is what id conversion tracks (as mentioned above).

> And I don't really thing this would be possible as those objects were generated as part of an algorithm and I'd need to re-run the algorithm to recreate the object most likely.

Fair.

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