[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

DRb / dRuby - freezes on DRb::DRbUndumped - any ideas?

Miles Keaton

3/28/2005 8:57:00 AM

Using the "Remote objects under dRuby" example here:
http://www.ruby-doc.org/stdlib/libdoc/drb/rdoc/classe...
Following it, exactly.

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

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

I'm running Ruby 1.8.2 on different/remote computers to do this test
(client names server by IP address.)

It works when I run both on the same computer, but as soon as I try to
put client and server on different computers, it seems unable to use
objects passed by reference.

NOTE where it froze, above. It's able to pass the object by
reference. It receives it back on the client. But when the client
tries to use it, that's when it freezes.

I've tried this on various FreeBSD and Mac OS X computers, at home and
work, without firewalls. All other DRb code works fine except when
using DRbUndumped.

Any suggestions?


3 Answers

Miles Keaton

3/28/2005 5:09:00 PM

0

New information on the post, below.

I got a hold of a Linux(Debian) box, and it works:

FreeBSD, OpenBSD, and Mac OS X all freeze if they are the remote server.
(Mac OS X as remote server freezes even earlier than FreeBSD does.)

But all O.S. work as the client if Linux is the remote server.

I don't know anything about threads, and I install Ruby via the
default installation in FreeBSD ports, knowing that lots of Ruby
experts use FreeBSD, and have probably set up the ports-version the
best. But could this be a reason to get Ruby to use Linux threads?
http://www.freebsd.org/cgi/url.cgi?ports/devel/linuxthreads...

Any info appreciated. I really want to get DRb / dRuby working across
remote boxes besides Linux.




On Mon, 28 Mar 2005 00:56:10 -0800, Miles Keaton <mileskeaton@gmail.com> wrote:
> Using the "Remote objects under dRuby" example here:
> http://www.ruby-doc.org/stdlib/libdoc/drb/rdoc/classe...
> Following it, exactly.
>
> But 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...
>
> What they all have in common is DRb::DRbUndumped - so I'm guessing
> that's the problem.
>
> I'm running Ruby 1.8.2 on different/remote computers to do this test
> (client names server by IP address.)
>
> It works when I run both on the same computer, but as soon as I try to
> put client and server on different computers, it seems unable to use
> objects passed by reference.
>
> NOTE where it froze, above. It's able to pass the object by
> reference. It receives it back on the client. But when the client
> tries to use it, that's when it freezes.
>
> I've tried this on various FreeBSD and Mac OS X computers, at home and
> work, without firewalls. All other DRb code works fine except when
> using DRbUndumped.
>
> Any suggestions?


Miles Keaton

3/30/2005 8:54:00 AM

0

On Mon, 28 Mar 2005 00:56:10 -0800, Miles Keaton <mileskeaton@gmail.com> wrote:
> Using the "Remote objects under dRuby" example here:
> http://www.ruby-doc.org/stdlib/libdoc/drb/rdoc/classe...
> Following it, exactly.
>
> But 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...
>
> What they all have in common is DRb::DRbUndumped - so I'm guessing
> that's the problem.
>
> I'm running Ruby 1.8.2 on different/remote computers to do this test
> (client names server by IP address.)
>
> It works when I run both on the same computer, but as soon as I try to
> put client and server on different computers, it seems unable to use
> objects passed by reference.
>
> NOTE where it froze, above. It's able to pass the object by
> reference. It receives it back on the client. But when the client
> tries to use it, that's when it freezes.
>
> I've tried this on various FreeBSD and Mac OS X computers, at home and
> work, without firewalls. All other DRb code works fine except when
> using DRbUndumped.


I started putting little "pp" statements inside drb.rb to find out
what was happening.

Is there any reason that URI should ever be nil?

See here:

~~~ DRbConn.open called
REMOTE_URI: "druby://10.0.1.1:2001"
@mutex: #<Mutex:0x6d52a0 @locked=false, @waiting=[]>
CONN: nil

### DRbProtocol.open has been called
URI: "druby://10.0.1.1:2001"
FIRST?: true
PROTOCOL:DRb::DRbTCPSocket
=== DRbTCPSocket.open has been called
URI: "druby://10.0.1.1:2001"
Parsing uri...
HOST: "10.0.1.1"
PORT: 2001
OPTION: nil
Doing TCPSocket.open(host, port)
SOC: #<TCPSocket:0x682078>
~~~ DRbConn.open called
REMOTE_URI: nil
@mutex: #<Mutex:0x6d52a0 @locked=false, @waiting=[]>
CONN: nil

### DRbProtocol.open has been called
URI: nil
FIRST?: true
PROTOCOL:DRb::DRbTCPSocket
=== DRbTCPSocket.open has been called
URI: nil
Parsing uri...

### DRbProtocol.open has been called
URI: nil
FIRST?: false
PROTOCOL:DRb::DRbTCPSocket
=== DRbTCPSocket.open has been called
URI: nil
Parsing uri...
~~~ DRbConn.open called
REMOTE_URI: nil
@mutex: #<Mutex:0x6d52a0 @locked=false, @waiting=[]>
CONN: nil

### DRbProtocol.open has been called
URI: nil
FIRST?: true
PROTOCOL:DRb::DRbTCPSocket
=== DRbTCPSocket.open has been called
URI: nil
Parsing uri...

### DRbProtocol.open has been called
URI: nil
FIRST?: false
PROTOCOL:DRb::DRbTCPSocket
=== DRbTCPSocket.open has been called
URI: nil
Parsing uri...
/usr/local/lib/ruby/1.8/drb/drb.rb:739:in `open': can't parse uri:nil
(DRb::DRbConnError)


Miles Keaton

3/30/2005 3:37:00 PM

0

The answer to this was just given by Brian Candler in another thread,
but I'm putting it here, too, for Google's sake, for future people
having this problem:


======= THE SOLUTION : (WORKS!) ==========
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.
========= (THANKS BRIAN!) ===============