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

Em 16-01-2014 19:43, Eric Hodel escreveu:
> On 16 Jan 2014, at 02:15, Rodrigo Rosenfeld Rosas <[e-mail]> wrote:
>>> The above matters especially so for objects that you extend with DRbUndumped.  This means you must keep the object alive where you create it or the GC will throw it away when no references remain.
>> Thank you, this confirms my suspicion. Unfortunately it's not feasible to create a generic proxy to the JVM from MRI through DRb and JRuby as I first thought it would be. It would be the case if DRb was responsible for translating any references in the DRb client-side as another local reference in the server-side so that those objects wouldn't be collected by GC. In that case it should also be responsible for removing the local references as the counterpart in the DRb client goes away.
>>
>> But maybe this is too hard to implement, so I'll give up on the generic MRI-JVM bridge by using DRb. I'll try to update my article soon to explain what I found and stop recommending that approach.
> As I noted in my email (not quoted in this reply) you can use id conversion to provide a way to keep local references alive.  DRb doesn’t provide a generic way to do this as there is not a one-size-fits-all solution to this problem.
>
> You could try an id converter that combined an LRU of a reasonable size along with the ability to recreate local objects for items that fall off the LRU.

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?

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

If I'm missing something, would you mind to explain it to me in a more 
comprehensive way?

Thanks,
Rodrigo.