[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

FreeBSD Rubyists? Do Remote Objects work for you?

Miles Keaton

3/29/2005 4:45:00 PM

Looking for any Ruby users on FreeBSD.

I think Ruby in FreeBSD freezes when receiving a reference to a remote object.

Can you please try the code-sample, here?
http://www.ruby-doc.org/stdlib/libdoc/drb/rdoc/classe...
The one under the header "Remote objects under dRuby", halfway down the page.

Try having it communicate across two different computers, where
FreeBSD is the server.

Can you get it to work?

For me, on many different FreeBSD boxes, it freezes when it tries to
call this line:
logger.log("Hello, world!")
Everything works until that point.

This same freeze happens with
http://pragmaticprogrammer.com/titles/ruby/code/s...

It works when both processes are on the same box, but not if they are
on two separate computers.

What they all have in common is DRbUndumped - so I'm guessing that's
the problem.

But I can't for the life of me figure out what would make a FreeBSD
server not-respond when receiving a reference to a remote object.

If you pass a copy of the object, with Class defined on both sides, it
works fine.

But if you make it a reference to the original object, it doesn't respond.

Is this a Ruby bug or a FreeBSD threads-bug?
10 Answers

Dick Davies

3/29/2005 5:00:00 PM

0

* Miles Keaton <mileskeaton@gmail.com> [0344 17:44]:
> Looking for any Ruby users on FreeBSD.
>
> I think Ruby in FreeBSD freezes when receiving a reference to a remote object.
>
> Can you please try the code-sample, here?
> http://www.ruby-doc.org/stdlib/libdoc/drb/rdoc/classe...
> The one under the header "Remote objects under dRuby", halfway down the page.
>
> Try having it communicate across two different computers, where
> FreeBSD is the server.

> Can you get it to work?

Yeah, fine here (yesterdays stable on client and server).

Firewall?

--
'The pie is ready. You guys like swarms of things, right?'
-- Bender
Rasputin :: Jack of All Trades - Master of Nuns

Brian McCallister

3/29/2005 5:16:00 PM

0

Works fine for me as well under 5.3 and ruby 1.8.2 from ports.

brianm@morphy:~$ uname -a && ruby -v
FreeBSD morphy.skife.org 5.3-RELEASE FreeBSD 5.3-RELEASE #0: Fri Nov 5
04:19:18 UTC 2004
root@harlow.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC i386
ruby 1.8.2 (2004-12-25) [i386-freebsd5]
brianm@morphy:~$

-Brian

On Mar 29, 2005, at 12:00 PM, Dick Davies wrote:

> * Miles Keaton <mileskeaton@gmail.com> [0344 17:44]:
>> Looking for any Ruby users on FreeBSD.
>>
>> I think Ruby in FreeBSD freezes when receiving a reference to a
>> remote object.
>>
>> Can you please try the code-sample, here?
>> http://www.ruby-doc.org/stdlib/libdoc/drb/rdoc/classe...
>> The one under the header "Remote objects under dRuby", halfway down
>> the page.
>>
>> Try having it communicate across two different computers, where
>> FreeBSD is the server.
>
>> Can you get it to work?
>
> Yeah, fine here (yesterdays stable on client and server).
>
> Firewall?
>
> --
> 'The pie is ready. You guys like swarms of things, right?'
> -- Bender
> Rasputin :: Jack of All Trades - Master of Nuns
>
>

Mark Probert

3/29/2005 7:11:00 PM

0

Hi ..

On Tuesday 29 March 2005 08:44, Miles Keaton wrote:
>
> I think Ruby in FreeBSD freezes when receiving a reference to a remote
> object.
>

Worked fine on my FreeBSD (5.3-RELEASE) with ruby 1.8.2 (2004-12-25)
[i386-freebsd5.3] with a Win2k client.

> Can you please try the code-sample, here?

I needed to modify this code to make it work correctly. The code as posted
won't be able to write the logger to a non-existing directory (/tmp/dlog).
Change the logger.initialize to look something like (require 'ftools'):

def initialize(n, dir, fname)
@name = n
File.makedirs(dir)
@filename = dir + "/" + fname
end

With the appropriate change in the Factory creation did the trick for me.

>
> Is this a Ruby bug or a FreeBSD threads-bug?
>
If it is still a problem, the next question would be about the kernel you are
running. Is it the standard kernel or has it been modified? If so, how?

HTH,

--
-mark. (probertm at acm dot org)

Miles Keaton

3/29/2005 11:27:00 PM

0

On Tue, 29 Mar 2005 08:44:32 -0800, Miles Keaton <mileskeaton@gmail.com> wrote:
> Looking for any Ruby users on FreeBSD.
>
> I think Ruby in FreeBSD freezes when receiving a reference to a remote object.
>
> Can you please try the code-sample, here?
> http://www.ruby-doc.org/stdlib/libdoc/drb/rdoc/classe...
> The one under the header "Remote objects under dRuby", halfway down the page.
>
> Try having it communicate across two different computers, where
> FreeBSD is the server.
>
> Can you get it to work?
>
> For me, on many different FreeBSD boxes, it freezes when it tries to
> call this line:
> logger.log("Hello, world!")
> Everything works until that point.
>
> This same freeze happens with
> http://pragmaticprogrammer.com/titles/ruby/code/s...
>
> It works when both processes are on the same box, but not if they are
> on two separate computers.
>
> What they all have in common is DRbUndumped - so I'm guessing that's
> the problem.
>
> But I can't for the life of me figure out what would make a FreeBSD
> server not-respond when receiving a reference to a remote object.
>
> If you pass a copy of the object, with Class defined on both sides, it
> works fine.
>
> But if you make it a reference to the original object, it doesn't respond.
>
> Is this a Ruby bug or a FreeBSD threads-bug?



Thanks for the replies, guys. I've spent about 12 hours on this so
far, and I'm still totally stumped, though, could anyone take a quick
look at this and see if they have any other ideas?

- I reverted my FreeBSD 5.3 back to the default GENERIC kernel. No change.
- I completely shut off all firewalls all around. No change.
- I tried newest stable-CVS build of Ruby. No change.

Here are my results with the EXACT SAME client.rb and server.rb
scripts all running the newest stable Ruby 1.8.2 (2004-12-25) on
different computers, all with no firewall, and all (except Linux)
right next to eachother on the same 192.168.0.* subnet

DRb TESTS:

CLIENT SERVER SUCCESS?
Mac Mac YES!
FreeBSD Mac no
Mac FreeBSD no
FreeBSD FreeBSD no
OpenBSD Linux YES
Mac Linux YES
FreeBSD Linux YES
FreeBSD OpenBSD YES

In other words:
If Linux is the server, ALL work.
If OpenBSD is the server, ALL work.
If Mac is the server, MAC works.
If FreeBSD is the server, NONE work.


I've got it printing all these little "I'm here" statements, so I know
exactly where it dies.

DRb server returns a reference to an object where class = "Logger" and
object_id = 67897744.
Client receives an object where class = "DRb::DRbObject" and object_id
is 364316.

It gets as far as saying it received the Object-reference back, and
can call local/generic kernel methods on it like .class and .object_id

But when I try to call any remote methods on the Object-reference, it
waits for a few minutes, then gives this error:

/usr/local/lib/ruby/1.8/drb/drb.rb:724:in `open': druby://server:8787
#<Errno::ETIMEDOUT: Operation timed out - connect(2)> (DRb::DRbConnError)

(All platforms die at that exact same line. Same error.)

Could it be that a remote-method called on a DRbUndumped
object-reference sends a different kind of TCP/IP packet than all the
other successful DRb calls up to that point?

Can anyone think of anything else it might be?

I'm not just hobbying with this. I really need to use DRb for work.
Thanks!

Mark Probert

3/30/2005 12:54:00 AM

0

Hi ..

On Tuesday 29 March 2005 15:26, Miles Keaton wrote:
> /usr/local/lib/ruby/1.8/drb/drb.rb:724:in `open': druby://server:8787
> #<Errno::ETIMEDOUT: Operation timed out - connect(2)> (DRb::DRbConnError)
>
> (All platforms die at that exact same line.  Same error.)

Your problem is in here, somewhere, I would think ;-)

If connect is timing out, there is something that is blocking it, router,
filter, firewall or whatever. I don't think that this you may have a network
config issue on your hands.

Regards,

--
-mark. (probertm at acm dot org)

Miles Keaton

3/30/2005 1:10:00 AM

0

On Wed, 30 Mar 2005 09:54:20 +0900, Mark Probert <probertm@acm.org> wrote:
> On Tuesday 29 March 2005 15:26, Miles Keaton wrote:
> > /usr/local/lib/ruby/1.8/drb/drb.rb:724:in `open': druby://server:8787
> > #<Errno::ETIMEDOUT: Operation timed out - connect(2)> (DRb::DRbConnError)
> >
> > (All platforms die at that exact same line. Same error.)
>
> Your problem is in here, somewhere, I would think ;-)
>
> If connect is timing out, there is something that is blocking it, router,
> filter, firewall or whatever. I don't think that this you may have a network
> config issue on your hands.


I would have thought so, except that everything else in DRb works
*except* passing an object by reference.

I've spent a whole day testing all kinds of dRuby client-server-remote
things and they all work fine... until you try to call a method on a
remote object that's been passed by reference.

I don't understand how (or if) objects passed by reference would have
such a different TCP/IP packet.

Can anyone imagine what might be blocking this kind of activity, but
not others? I've been poring through the drb.rb code for an hour
now, and can't figure out what it might be.

Eric Hodel

3/30/2005 1:27:00 AM

0

On 29 Mar 2005, at 17:09, Miles Keaton wrote:

> On Wed, 30 Mar 2005 09:54:20 +0900, Mark Probert <probertm@acm.org>
> wrote:
>> On Tuesday 29 March 2005 15:26, Miles Keaton wrote:
>>> /usr/local/lib/ruby/1.8/drb/drb.rb:724:in `open': druby://server:8787
>>> #<Errno::ETIMEDOUT: Operation timed out - connect(2)>
>>> (DRb::DRbConnError)
>>>
>>> (All platforms die at that exact same line. Same error.)
>>
>> Your problem is in here, somewhere, I would think ;-)
>>
>> If connect is timing out, there is something that is blocking it,
>> router,
>> filter, firewall or whatever. I don't think that this you may have a
>> network
>> config issue on your hands.
>
> I would have thought so, except that everything else in DRb works
> *except* passing an object by reference.
>
> I've spent a whole day testing all kinds of dRuby client-server-remote
> things and they all work fine... until you try to call a method on a
> remote object that's been passed by reference.
>
> I don't understand how (or if) objects passed by reference would have
> such a different TCP/IP packet.
>
> Can anyone imagine what might be blocking this kind of activity, but
> not others? I've been poring through the drb.rb code for an hour
> now, and can't figure out what it might be.

I had a similar problem, the server was connecting back to a client on
a port that wasn't open. I would get a connection refused, rather than
a timeout. This is on 4.x, but I haven't had time to look into it
further.

--
Eric Hodel - drbrain@segment7.net - http://se...
FEC2 57F1 D465 EB15 5D6E 7C11 332A 551C 796C 9F04

Brian Candler

3/30/2005 9:08:00 AM

0

On Wed, Mar 30, 2005 at 10:09:55AM +0900, Miles Keaton wrote:
> On Wed, 30 Mar 2005 09:54:20 +0900, Mark Probert <probertm@acm.org> wrote:
> > On Tuesday 29 March 2005 15:26, Miles Keaton wrote:
> > > /usr/local/lib/ruby/1.8/drb/drb.rb:724:in `open': druby://server:8787
> > > #<Errno::ETIMEDOUT: Operation timed out - connect(2)> (DRb::DRbConnError)
> > >
> > > (All platforms die at that exact same line. Same error.)
> >
> > Your problem is in here, somewhere, I would think ;-)
> >
> > If connect is timing out, there is something that is blocking it, router,
> > filter, firewall or whatever. I don't think that this you may have a network
> > config issue on your hands.
>
>
> I would have thought so, except that everything else in DRb works
> *except* passing an object by reference.

It would :-)

http://www.rubygarden.org/ruby?D...
describes how this DRbUndumped stuff works, and may make things clearer,
especially the section headed "Why does the client run 'DRb.start_service'?"

You'll find that with DRbUndumped, the 'server' will end up opening a fresh
TCP connection back to the 'client'

The easy way for you to prove that it's a network issue is to put the two
FreeBSD boxes on the *same subnet* (i.e. with no router or anything in
between)

Then, once the machines are back where they were before, the solution may
involve:
- sticking the client on a fixed port number, so that you can open a
firewall hole for connections backwards from the server to the client; or
- running DRb over ssh, which is also described in that document.

Regards,

Brian.

Brian Candler

3/30/2005 9:25:00 AM

0

On Wed, Mar 30, 2005 at 10:08:24AM +0100, Brian Candler wrote:
> You'll find that with DRbUndumped, the 'server' will end up opening a fresh
> TCP connection back to the 'client'
>
> The easy way for you to prove that it's a network issue is to put the two
> FreeBSD boxes on the *same subnet* (i.e. with no router or anything in
> between)

Oh, and one other thing: the client side machine will read its own system
hostname (as shown by 'hostname' on many Unix systems), and pass that across
to the server. At the time it wishes to connect back, the server will then
try to resolve that name back to an IP address.

So it's important that 'hostname' contains a real hostname and your DNS is
working, or at least at the server side you have an entry in /etc/hosts for
the client host.

B.

Miles Keaton

3/30/2005 3:34:00 PM

0

On Wed, 30 Mar 2005 10:25:20 +0100, Brian Candler <B.Candler@pobox.com> wrote:
> the client side machine will read its own system
> hostname (as shown by 'hostname' on many Unix systems), and pass that across
> to the server. At the time it wishes to connect back, the server will then
> try to resolve that name back to an IP address.
> So it's important that 'hostname' contains a real hostname and your DNS is
> working, or at least at the server side you have an entry in /etc/hosts for
> the client host.



Oh... my.... god.

THIS JUST SOLVED EVERYTHING!

15 hours of poring over every line of drb.rb, recompiling kernels,
physically disabling firewalls, downloading new CVS-stable Ruby, and
dozens and dozens of "hello world" tests, and it was the fucking
/etc/hosts file! We have dozens of machines that address eachother by
IP address, and had never needed to put each one's full hostname into
everyone's /etc/hosts ... until now.

Brian thanks so so so much.