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

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.

> the problem is that the DRb client is creating instances in the server-side that are not hold themselves in the server-side but only referenced in the client-side using some kind of a proxy to the object that is only present in the server-side. Even if I could somehow mark those objects transparently to remain alive, I'd still have to figure out a way to detect when no references exist to it any longer in the client-side so that I could free those objects in the server-side as well or the server-side will leak.
> 
> That's why I think this must be implemented in the DRb specification itself or it wouldn't be feasible to implement in away that would be transparent for the user.

The server should not hold on to its objects if the client crashes, but how do you separate a crash from a network partition?

The answer to this question is very much dependent upon the application you build atop the protocol.  There is no one correct answer for all possible uses of DRb, so it should not be part of the protocol.

> My real goal is for the user in the client-side to have a feeling that he's programming directly in the server-side, just using DRb as a proxy to allow him to use features only available in the server-side. That includes creating temporary objects that should be freed once no references exist to them in the client-side.

One option is to use an LRU-backed id converter with a smart client that can recreate objects for lost references.

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.