[#59462] [ruby-trunk - Bug #9342][Open] [PATCH] SizedQueue#clear does not notify waiting threads in Ruby 1.9.3 — "jsc (Justin Collins)" <redmine@...>

9 messages 2014/01/02

[#59466] [ruby-trunk - Bug #9343][Open] [PATCH] SizedQueue#max= wakes up waiters properly — "normalperson (Eric Wong)" <normalperson@...>

11 messages 2014/01/02

[#59498] [ruby-trunk - Bug #9352][Open] [BUG] rb_sys_fail_str(connect(2) for [fe80::1%lo0]:3000) - errno == 0 — "kain (Claudio Poli)" <claudio@...>

10 messages 2014/01/03

[#59516] [ruby-trunk - Bug #9356][Open] TCPSocket.new does not seem to handle INTR — "charliesome (Charlie Somerville)" <charliesome@...>

48 messages 2014/01/03

[#59538] [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed — "shyouhei (Shyouhei Urabe)" <shyouhei@...>

33 messages 2014/01/03
[#59582] Re: [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed — SASADA Koichi <ko1@...> 2014/01/06

Intersting challenge.

[#59541] Re: [ruby-trunk - Feature #9362][Assigned] Minimize cache misshit to gain optimal speed — Eric Wong <normalperson@...> 2014/01/04

Hi, I noticed a trivial typo in array.c, and it fails building struct.c

[#59583] [ruby-trunk - Bug #9367][Open] REXML::XmlDecl doesn't use user specified quotes — "bearmini (Takashi Oguma)" <bear.mini@...>

12 messages 2014/01/06

[#59642] [ruby-trunk - Bug #9384][Open] Segfault in ruby 2.1.0p0 — "cbliard (Christophe Bliard)" <christophe.bliard@...>

11 messages 2014/01/08

[#59791] About unmarshallable DRb objects life-time — Rodrigo Rosenfeld Rosas <rr.rosas@...>

A while ago I created a proof-of-concept that I intended to use in my

16 messages 2014/01/15
[#59794] Re: About unmarshallable DRb objects life-time — Eric Hodel <drbrain@...7.net> 2014/01/15

On 15 Jan 2014, at 11:58, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:

[#59808] Re: About unmarshallable DRb objects life-time — Rodrigo Rosenfeld Rosas <rr.rosas@...> 2014/01/16

Em 15-01-2014 19:42, Eric Hodel escreveu:

[#59810] Re: About unmarshallable DRb objects life-time — Eric Hodel <drbrain@...7.net> 2014/01/16

On 16 Jan 2014, at 02:15, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:

[#59826] Re: About unmarshallable DRb objects life-time — Rodrigo Rosenfeld Rosas <rr.rosas@...> 2014/01/17

Em 16-01-2014 19:43, Eric Hodel escreveu:

[#59832] Re: About unmarshallable DRb objects life-time — Eric Hodel <drbrain@...7.net> 2014/01/17

On 17 Jan 2014, at 04:22, Rodrigo Rosenfeld Rosas <rr.rosas@gmail.com> wrote:

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

From: Rodrigo Rosenfeld Rosas <rr.rosas@...>
Date: 2014-01-15 19:58:44 UTC
List: ruby-core #59791
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 worked in my little tests and today I finally decided to use it in 
the process of migrating a Grails application to a Rails one. I couldn't 
find any Ruby library to edit an Excel (XLS, not XLSX) template and 
create a new spreadsheet so I decided to keep up with the implementation 
using Apache POI, but I needed to access it in the JVM somehow.

At the same time I didn't want to convert the whole project to JRuby, as 
MRI is much faster for me to develop due to the short start-up time of 
the processes.

When I put the concept to work with real data from my application I got 
tons of random errors in different places. It didn't happen if I 
selected only a few records to export to Excel, but if I decided to 
generate the spreadsheet for all (~ 1k) results, it would always fail in 
random places.

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.

I could somehow "confirm" my suspicions by implementing another 
interface in the DRb server where only regular marshallable Ruby data 
would be transmitted so that I wouldn't take the risk of having my data 
being garbage collected in the server-side. After this change it worked 
all the times I tried but I could no longer use the DRb server as a 
generic platform for accessing the JVM libraries.

So, I'd like to confirm my theory by asking you if this is the intended 
behavior of the DRb protocol.

I mean, suppose I get a Java object from a call to the DRb server. It's 
not marshallable to MRI, of course, so I only get a reference to that 
object in the MRI side. Then, later I want to use that object, but it no 
longer exists in the DRb server as it has no references in that side.

Is DRb supposed to be called only with marshallable data? Or is there a 
way for DRb to know that a reference still exists in a DRb client and 
prevent the object from being GC'ed?

I also read about this:

http://www.ruby-doc.org/stdlib-2.1.0/libdoc/drb/rdoc/DRb/DRbUndumped.html

And if you take a look at the code in my article, you'll find this:

result.extend DRb::DRbUndumped if result.respond_to? :java_class

But even extending the object with DRb::DRbUndumped doesn't seem to 
prevent it from being garbage collected by JRuby. And Charles told me he 
only uses the MRI implementation of DRb, so I'm asking here to try to 
understand if this is how it works by design.

Also, in case this is a bug and DRbUndumped should mark the object as 
not available for being GC'ed, how would it be freed after the DRb 
client no longer needs it?

Sorry if it got confused but I did my best to try to make it as clear as 
possible.

Thanks in advance,
Rodrigo.

In This Thread

Prev Next