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

Em 15-01-2014 19:42, Eric Hodel escreveu:
> On 15 Jan 2014, at 11:58, Rodrigo Rosenfeld Rosas <[e-mail]> wrote:
>
>> A while ago I created a proof-of-concept that I intended to use in my project for using Java libraries from MRI through the use of JRuby and DRb:
>>
>> http://rosenfeld.herokuapp.com/en/articles/ruby-rails/2013-07-16-running-java-from-mri-ruby-through-drb
>>
>> [it failed randomly]
>>
>> The only explanation I could think of, and after analyzing some data I logged from the DRb server, is that that some previously objects created in the DRb server (JRuby application) were being garbage collected even if I still had a reference for them in the MRI side.
> This is possible and likely for DRb services.  DRb does nothing to track which objects are converted to DRbObjects and returned to the remote side.  This leaves them eligible for garbage collection if they池e not otherwise referenced.  If you池e returning references to local objects (DRbObjects) to your peers you will need to hold on to the local objects on behalf of your peers.
>
> DRb features pluggable id conversion (id_conv) which allows you to create an alternate way of tracking the referenced local objects and keeping them alive.  There are some examples of this in the sample/ directory.
>
>> [Stuff about DRbUndumped]
> 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.

My initial motivation for trying this approach is that I'd be able to 
use all goodness of JRuby, like integration with JVM libraries, without 
the slow boot time for JVM processes, while still being able to take 
advantage of MRI goodness, like the ability to fork quickly and C 
extensions. But it was too good to be true ;)

Thanks,
Rodrigo.