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

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?

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.

Now, supposing there was a reliable way to detect this and I could keep 
a reference to all those objects so that they wouldn't be GC'ed: how 
could I possibly know when I should free them, based on the reference 
count of the client-side for any of those objects. Or more strictly, how 
could I know the reference count for them for all clients? This is why I 
think this is not feasible, since it's too complex to handle with custom 
code... It's very low-level in my opinion.


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

Good question, and yet another reason why tracking those references is 
too complex to be implemented and why I gave up on that idea...

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

Ok, I understand. I didn't even suggested that DRb should handle such 
references tracking among DRb end-points, I just said that if this would 
be implemented that I think it should happen in the DRb implementation 
itself. But as you pointed out already, there are many reasons why this 
would be too hard for being implemented.

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

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). 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. But the main problem is that I can't finish the 
algorithm because at some point it will need an object that no longer 
exists...

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

I'm not saying that DRb is useless. I'm just saying that it's not 
suitable for my original idea, and that's fine. I'm still trying to use 
DRb in my application but using another approach, where I write all the 
logic in the DRb server-side and only call a few methods on the exported 
object, like I described in another message. But I'm facing some bugs 
that I didn't have the chance yet to understand. I'll give more details 
in another message.

Thank you,
Rodrigo.