Connection refused on AWS works fine locally on osx and Linux

[brentgreeff]

This is probably not an issue with your fine software, but I am unable to figure out where
the problem is coming from.
The error I get is the following.

druby://ci.companyx.co.uk:38318 - #<Errno::ECONNREFUSED: Connection refused - Connection refused> (DRb::DRbConnError)
(druby://127.0.0.1:40856) -e:1
./features/step_definitions/web_steps.rb:20:in `/^(?:|I )am on (.+)$/'

I have writen a simple drb server bound to the address:

druby://127.0.0.1:40856

This seems to work fine.
If on the other hand I dont specify a port and let DRb find one on its own,
then this does not work, I get a timeout.

If I try and bind to the other address:

druby://ci.companyx.co.uk:38318

/drb.rb:861:in `initialize': Cannot assign requested address - bind(2) (Errno::EADDRNOTAVAIL)

The actual error above that I see during test runs is slightly different:

ECONNREFUSED.

There is probably something in the environment, but I was wondering if
you can point me in the right direction?

Help much appreciated.

Thanks
-Brent

[josephholsten]

Seems similar to http://groups.google.com/group/ruby-capybara/browse_thread/thread/7873cdddd9c8a0c8

I'm guessing if DRB can't bind, there's multiple akephalos processes trying to use the same port.

[brentgreeff]

Thanks for posting,

In our case it seemed the AWS has got a strage way of using IP addresses,
locally ci.companyx.co.uk was not resolving to a local ip,
externally it does. Not sure how it gets the domain name btw or why.

Using the hosts file we were able to map this "resolved" ip to localhost.

When we were debugging this we used a combination of DRb by itself,
and telnet.

Have u tried reproducing it with 2 DRb scripts?
What we found is that there was a missing error,
its the one where it fails to bind to the IP,
probably in your case because its already in use,
the "other" process I guess then tries to connect on this.

Have u found places where Akephalos is not working for you,
hence using @env-js?

[ebeigarts]

This should be fixed in #69