Can I rescue Errno::ECONNREFUSED?

Hi there,

I'm trying to put a little robustness into a Rinda::Tuplespace setup, and I've run into a slight snag.

Here's some example client code to show the problem:

require 'rinda/tuplespace'

class Producer
   def initialize
     DRb.start_service
     @tuplespace = Rinda::TupleSpaceProxy.new(DRbObject.new_with_uri('druby://localhost:8099'))

     ping
   end

   def ping
     counter = 0
     while true
       begin
         @tuplespace.write([:test, counter += 1]) # <= problem line
       rescue Errno::ECONNREFUSED => e
         nil
       end
       sleep(1)
     end
   end
end

Producer.new

My problem is this: when I make the server glitch (by calling DRb.stop_service() and DRb.start_service() with a slight delay between them), I get an Errno::ECONNREFUSED thrown in the client at the problem line marked above. The rescue doesn't catch it, though - the script always terminates at that point with a stack dump. Is there a way to catch it that I've missed? For completeness, here's the server code I'm using for testing:

require 'rinda/tuplespace'

class Consumer < Rinda::TupleSpace
   def puts
     read_all([:test, nil]).each {|t| p t}
   end
end

class ConsumerTester
   def initialize
     @tuplespace = Consumer.new
     start_drb
     Thread.new{while true do sleep(1); @tuplespace.puts; print '.'; STDOUT.flush end}
   end

   def start_drb
     DRb.start_service('druby://localhost:8099', @tuplespace)
   end

   def glitch
     DRb.stop_service
     @tuplespace = Consumer.new
     sleep(2)
     start_drb
   end

   def join
     DRb.thread.join
   end
end

tester = ConsumerTester.new
sleep(5)
puts "Glitching..."
tester.glitch
tester.join

Thanks,

···

--
Alex

Alex Young wrote:

Hi there,

I'm trying to put a little robustness into a Rinda::Tuplespace setup, and I've run into a slight snag.

<snip>

Never mind - it turns out I was trying to rescue the wrong exception class. For reference, the Errno::ECONNREFUSED is actually wrapped in a DRb::DRbConnError exception, and rescuing that is enough.

···

--
Alex