Rinda::RingFinger.primary hangs on UDPSocket.open

The hanging happens regardless of whether a RingServer is running. What it should do is either find the RingServer and terminate silently, or report a RingNotFound RuntimeError.

jvm thread dump attached. Java HotSpot(TM) 64-Bit Server VM (1.5.0_13-b05 mixed mode).

This doesn't happen in trunk, at least for me. Could you try trunk on your machine? (I promise it's quite easy, ask on jruby irc channel if you need help with it).

Just tested it with trunk. Most of the time I see the same behavior (hangs), but on 2 runs I got the RingNotFound error. That happened after I'd run the same program (list_services.rb) with ruby first. But I haven't found a scenario to reproduce it. There may be some environmental things in play here, but I don't really know what to look for.

Another thing that's changed with trunk is that I can now start the ringserver.rb example. This used to fail* in 1.0.1. Ruby list_services.rb does not detect the ring though.

*) /home/menno/develop/jruby-1.0.1/lib/ruby/1.8/rinda/ring.rb:34:in `initialize': uninitialized constant Rinda::RingServer::UDPSocket (NameEr/home/menno/develop/jruby-1.0.1/lib/ruby/1.8/rinda/ring.rb:34:in `initialize': uninitialized constant Rinda::RingServer::UDPSocket (NameError)
from :1:in `new'
from :1

Similar results with trunk on Windows XP. But here a RingNotFound error is raised most of the time and hanging occurs rarely.
Pointers on what to try next / what to look for would be appreciated.

Can you try this again and confirm it's still blocking? I just committed a fix for TCPServer#accept that makes it use select like it's supposed to. I don't think that would fix it hanging, but it could.

Hopefully we'll have a chance to look at your script in more depth; a bit swamped right now.

I tried with the latest changes but now instead of hanging I get the RingNotFound error. I am on XP. I have tried having the server side with plain ruby but that does not help.

I need more help on this...a simple set of scripts that can reproduce the problem and instructions for running them. This is in danger of getting pushed to 1.0.3. We'd really like to fix it...but need community help.

http://segment7.net/projects/ruby/drb/rinda/ringserver.html

Three little scripts, start the first two and then the third
The third fails on Rinda::RingFinger.primary
Note: that if one or other of these is run with ruby MRI you get somewhat better results. All three together run fine in MRI.

#!/usr/bin/env ruby -w
# rinda_ts.rb
# Registering a TupleSpace with Rinda::Ring

require 'rinda/ring'
require 'rinda/tuplespace'

DRb.start_service

ts = Rinda::TupleSpace.new

provider = Rinda::RingProvider.new :TupleSpace, ts, 'Tuple Space'
provider.provide

DRb.thread.join

#!/usr/bin/env ruby -w
# ringserver.rb
# Rinda RingServer

require 'rinda/ring'
require 'rinda/tuplespace'

# start DRb
DRb.start_service

# Create a TupleSpace to hold named services, and start running
Rinda::RingServer.new Rinda::TupleSpace.new

# Wait until the user explicitly kills the server.
DRb.thread.join

#!/usr/bin/env ruby -w
# list_services.rb
# List all of the services the RingServer knows about

require 'rinda/ring'

DRb.start_service

ring_server = Rinda::RingFinger.primary
services = ring_server.read_all [:name, nil, nil, nil]

puts "Services on #{ring_server.__drburi}"
services.each do |service|
  puts "#{service[1]} on #{service[2].__drburi} - #{service[3]}"
end

Unfortunately this won't make 1.0.2.

Using ruby 1.8.6 (2007-03-13 patchlevel 0) [i386-mswin32] the script below works

require "rinda/tuplespace"
require "rinda/ring"


include Rinda
DRb.start_service

ts = TupleSpace.new
ring = RingServer.new(ts)
puts "started #{ring}  #{ts}"
DRb.thread.join

Using jruby 1.0.1 the following error occurs.

C:/jruby-1.0.1/lib/ruby/1.8/rinda/ring.rb:34:in `initialize': uninitialized constant Rinda::RingServer::UDPSocket (NameError)
from :1:in `new'
from :1

The scripts appear to work fine under JRuby 1.1.5, although there is a very long delay in listing the services. That delay appears to be unrelated to the original issue, however (Inet6 lookup timeout) and I'll file a separate bug for it.