DRb recycled objects.

[Kevin Brown]

I started this as a question but figured out the answer while I was
researching, so I'm posting this here for others that may have the same
problem.

The error I received from my code was as follows:

(druby://*:9000) /usr/lib/ruby/1.8/drb/drb.rb:375:in `_id2ref': 0xdbe53cf6 is
recycled object (RangeError)
from (druby://*:9000) /usr/lib/ruby/1.8/drb/drb.rb:375:in `to_obj'
from (druby://*:9000) /usr/lib/ruby/1.8/drb/drb.rb:1343:in `to_obj'
from (druby://*:9000) /usr/lib/ruby/1.8/drb/drb.rb:1626:in `to_obj'
from (druby://*:9000) /usr/lib/ruby/1.8/drb/drb.rb:601:in
`recv_request'
from (druby://*:9000) /usr/lib/ruby/1.8/drb/drb.rb:899:in
`recv_request'
from (druby://*:9000) /usr/lib/ruby/1.8/drb/drb.rb:1453:in
`init_with_client'
from (druby://*:9000) /usr/lib/ruby/1.8/drb/drb.rb:1465:in
`setup_message'
from (druby://*:9000) /usr/lib/ruby/1.8/drb/drb.rb:1435:in `perform'
... 22 levels...
from /usr/local/lib/site_ruby/1.8/Qt/qtruby.rb:1040:in
`method_missing'
from /usr/local/lib/site_ruby/1.8/Qt/qtruby.rb:1040:in `exec'
from /usr/local/lib/site_ruby/1.8/KDE/korundum.rb:395:in `exec'
from ./init.rb:1123
KCrash: Application 'init.rb' crashing...

This was happening consistantly from the same place in the code. I finally
tracked down the line that was giving me grief, and the issue was that I had
a method called Order#id. When I was running the code without DRb, this
worked just fine, but calling id on a DRb proxy object will get you its DRb
object id. I was returning this value, etc.

I fixed the problem by changing the method name to order_id, so I know how to
avoid the error, but I would still like a little more explaination as to why
exactly this occurred so I can get DRb just that much clearer in my mind.

 

[Hugh Sasse]

I started this as a question but figured out the answer while I was
researching, so I'm posting this here for others that may have the same
problem.

The error I received from my code was as follows:

(druby://*:9000) /usr/lib/ruby/1.8/drb/drb.rb:375:in `_id2ref': 0xdbe53cf6 is
recycled object (RangeError) [stacktrace]

This was happening consistantly from the same place in the code. I finally
tracked down the line that was giving me grief, and the issue was that I had
a method called Order#id. When I was running the code without DRb, this
worked just fine, but calling id on a DRb proxy object will get you its DRb
object id. I was returning this value, etc.

I fixed the problem by changing the method name to order_id, so I know how to

You will now run into a problem when you port this to Rails

[Rails uses the method #{name}_id to reference the primary key in table
"name" (cf Foreign Key)]

avoid the error, but I would still like a little more explaination as to why
exactly this occurred so I can get DRb just that much clearer in my mind.

-------------------------------------------------------------- Object#id
obj.id => fixnum
------------------------------------------------------------------------
Soon-to-be deprecated version of +Object#object_id+.

uniquely identifies an object in the Ruby process. I'm not sure how
DRb uses it, but probably to make sure the objects are distinct.Thank you for flagging this up.
HTH
Hugh

 

[Eric Hodel]

I started this as a question but figured out the answer while I was
researching, so I'm posting this here for others that may have the
same
problem.

The error I received from my code was as follows:

(druby://*:9000) /usr/lib/ruby/1.8/drb/drb.rb:375:in `_id2ref':
0xdbe53cf6 is
recycled object (RangeError)

This was happening consistantly from the same place in the code. I
finally
tracked down the line that was giving me grief, and the issue was
that I had
a method called Order#id. When I was running the code without DRb,
this
worked just fine, but calling id on a DRb proxy object will get you
its DRb
object id. I was returning this value, etc.

I fixed the problem by changing the method name to order_id, so I
know how to
avoid the error, but I would still like a little more explaination
as to why
exactly this occurred so I can get DRb just that much clearer in my
mind.

DRb uses the __id__ of the object and the URL of the process it is
running on to create a proxy object on other DRb processes.
Redefining #id to #object_id probably had nothing to do with fixing
your problem.

Usually this error comes when a remote DRb process has a reference to
an object that was garbage collected before the remote process tried
to access it.

 

[Richard Dale]

I started this as a question but figured out the answer while I was
researching, so I'm posting this here for others that may have the same
problem.

The error I received from my code was as follows:

(druby://*:9000) /usr/lib/ruby/1.8/drb/drb.rb:375:in `_id2ref': 0xdbe53cf6
is recycled object (RangeError)
from (druby://*:9000) /usr/lib/ruby/1.8/drb/drb.rb:375:in `to_obj'
from (druby://*:9000) /usr/lib/ruby/1.8/drb/drb.rb:1343:in
`to_obj' from (druby://*:9000)
/usr/lib/ruby/1.8/drb/drb.rb:1626:in `to_obj' from
(druby://*:9000) /usr/lib/ruby/1.8/drb/drb.rb:601:in
`recv_request'
from (druby://*:9000) /usr/lib/ruby/1.8/drb/drb.rb:899:in
`recv_request'
from (druby://*:9000) /usr/lib/ruby/1.8/drb/drb.rb:1453:in
`init_with_client'
from (druby://*:9000) /usr/lib/ruby/1.8/drb/drb.rb:1465:in
`setup_message'
from (druby://*:9000) /usr/lib/ruby/1.8/drb/drb.rb:1435:in
`perform'
... 22 levels...
from /usr/local/lib/site_ruby/1.8/Qt/qtruby.rb:1040:in
`method_missing'
from /usr/local/lib/site_ruby/1.8/Qt/qtruby.rb:1040:in `exec'
from /usr/local/lib/site_ruby/1.8/KDE/korundum.rb:395:in `exec'
from ./init.rb:1123
KCrash: Application 'init.rb' crashing...

This was happening consistantly from the same place in the code. I
finally tracked down the line that was giving me grief, and the issue was
that I had
a method called Order#id. When I was running the code without DRb, this
worked just fine, but calling id on a DRb proxy object will get you its
DRb
object id. I was returning this value, etc.

I fixed the problem by changing the method name to order_id, so I know how
to avoid the error, but I would still like a little more explaination as
to why exactly this occurred so I can get DRb just that much clearer in my
mind.

I'm not sure about the cause of your problem.. But as you using Korundum you
could use DCOP instead of DRB. So I'm interested in what you think are the
relative merits of using Drb or DCOP for your application.

-- Richard

 

[Kevin Brown]

I'm not sure about the cause of your problem.. But as you using Korundum
you could use DCOP instead of DRB. So I'm interested in what you think are
the relative merits of using Drb or DCOP for your application.

We _do not_ want to have to have KDE installed on the server. Much less
running.

 

[Kevin Brown]

--Boundary-00=_pJtaDksassjOcYD
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: 7bit


Eric, I really REALLY am not trying to point a finger here at ALL, but I guess my question is why did Ruby garbage collect the object consistantly (I mean at least 30 executions in the exact same place)? Where as now that I've axed all the .id calls it consistantly (at least 100 executions) works now.

Richard and everyone else may also like that I was getting Korundum warnings about Object#id being depracated and to use Object#object_id. These only showed up when I started using DRb. This was what made me change the names in the first place, because it was obvious to me that MY code wasn't getting called. I don't know the Korundum bindings too well, but I'm guessing the Korundum method_missing fired instead of the call being passed across the wire. Perhaps this was a nasty interaction between the two? Korundum object id used instead of a DRb object id which later tried to get passed down the wire? Maybe? There is a lot of two way communication between the server and client.

Either way, I'm _relatively_ sure that it works now...?

And this is exactly why I posted, because I still don't get it.

I do know how to change the garbage collection method for DRb, but I simply haven't had the need at all, since it consistantly works now (I'll continue to monitor).
--Boundary-00=_pJtaDksassjOcYD--

 

[Kevin Brown]

We _do not_ want to have to have KDE installed on the server. Much less
running.

Forgot to mention this is only one front end. It is possible (but
uh...personal yuck there) that we'll have a Windows front end in the future.
For now we're already going to have both web and KDE front ends, so the
communication method has to be generic.

 

[Eric Hodel]

Eric, I really REALLY am not trying to point a finger here at ALL,
but I guess my question is why did Ruby garbage collect the object
consistantly (I mean at least 30 executions in the exact same
place)? Where as now that I've axed all the .id calls it
consistantly (at least 100 executions) works now.

The garbage collector is not random in how it collects garbage.
Which objects are considered garbage can be affected by which methods
are called.

Richard and everyone else may also like that I was getting Korundum
warnings about Object#id being depracated and to use
Object#object_id. These only showed up when I started using DRb.
This was what made me change the names in the first place, because
it was obvious to me that MY code wasn't getting called. I don't
know the Korundum bindings too well, but I'm guessing the Korundum
method_missing fired instead of the call being passed across the
wire. Perhaps this was a nasty interaction between the two?
Korundum object id used instead of a DRb object id which later
tried to get passed down the wire? Maybe? There is a lot of two
way communication between the server and client.
Possibly.

Either way, I'm _relatively_ sure that it works now...?

And this is exactly why I posted, because I still don't get it.

I do know how to change the garbage collection method for DRb, but
I simply haven't had the need at all, since it consistantly works
now (I'll continue to monitor).

You can either rewrite your application to ensure it holds onto all
remote references or you can use one of the alternate id conversion
classes:

http://segment7.net/projects/ruby/drb/idconv.html