It seems stable and not that bad to raise the error you spoke of. But
did you encount the problem while this test was done?
As you can notice, I am trying blindly to determine if there is a
problem in your server network configuration. It may be that your server
was set up correctly and I am sending you to a wild goose chase. I
apologize for that, but error 111 speaks mostly about a problem in
connecting to the server and since you reported that there is nothing
wrong in the CouchDB log nor in your firewall, I do not know where
exactly the problem may come from. If anyone has a better idea how to
debug this, please, by all means, override my approach.
Try to put bind_address a dedicated address (e.g., 127.0.0.1 or
107.20.142.27) and restart CouchDB. That's because 0.0.0.0 is listening
all the bind addresses generally and if there is something wrong in one
address bind setup, that may cause problems (unlikely, but not
impossible). So here is what I propose:
1. Set your bind_address to 127.0.0.1 and check from the same machine
curl http://127.0.0.1:5984.
2. If it doesn't work, try change the port to 80 (if you don't have
anything else running on that port) and restart CouchDB as root. Check
again, but do not add port number to the address.
3. If you have something running on port 80, try curl
http://127.0.0.1:80 (port number not necessary) and if it is working
properly, stop your application and follow point 2.
4. Try the same for 107.20.142.27.
5. If it is not working, then stop CouchDB, clear the log and start it
again. See if reports something wrong in accessing the
configuration/log/pid or any other file (it can be that the path toward
one of those files is broken - running as root overrides all the
permissions, so, it shouldn't be a matter of permissions).
6. If anyone has a better idea, please, disregard this post (as I said
it before).
If all these are not reporting anything wrong and still you get the same
problem, you may want to ask for the help of one of the system
administrators in charge of your server.
Cheers,
CGS
PS: If I will get any other idea, I will come back with a post.
On 10/25/2011 11:07 PM, Ron Dyck wrote:
Opened up and here are results:
64 bytes from ec2-107-20-142-27.compute-1.amazonaws.com
(107.20.142.27): icmp_seq=1 ttl=54 time=2.00 ms
64 bytes from ec2-107-20-142-27.compute-1.amazonaws.com
(107.20.142.27): icmp_seq=2 ttl=54 time=2.02 ms
64 bytes from<myaddress>: icmp_seq=3 ttl=54 time=2.02 ms
64 bytes from<myaddress>: icmp_seq=4 ttl=54 time=2.06 ms
64 bytes from<myaddress>: icmp_seq=5 ttl=54 time=2.07 ms
64 bytes from<myaddress>: icmp_seq=6 ttl=54 time=2.02 ms
64 bytes from<myaddress>: icmp_seq=7 ttl=54 time=2.19 ms
64 bytes from<myaddress>: icmp_seq=8 ttl=54 time=2.00 ms
64 bytes from<myaddress>: icmp_seq=9 ttl=54 time=2.13 ms
64 bytes from<myaddress>: icmp_seq=10 ttl=54 time=2.05 ms
On Tue, Oct 25, 2011 at 4:42 PM, CGS<[email protected]> wrote:
Try ping to the server to see the latency. If it is slow, then that may be
the problem. Also, ping should give you the stability of your connection to
the server.
On 10/25/2011 10:30 PM, Ron Dyck wrote:
That's a bit out of my range of knowledge, but we're still in testing
stage with the site. There really no traffic to speak of.
ron
On Tue, Oct 25, 2011 at 4:28 PM, Robert Newson<[email protected]> wrote:
perhaps you're running out of file descriptors or ephemeral ports?
On 25 October 2011 21:20, Ron Dyck<[email protected]> wrote:
I'm working with AWS EC2 instances and have ensured that the proper
ports are open. I'm able to access the server from remote locations
and test using curl successfully. The problem is that it's very
inconsistent. Today, except for earlier in am it's working just fine.
I'm wondering if the issue is latency, and connections are timing out.
Is that a possibility?
Cheers,
ron
On Tue, Oct 25, 2011 at 3:29 PM, CGS<[email protected]> wrote:
Try to remove the firewall and see if it is working. If it still
doesn't
work it may be a problem of permissions (if everything was installed
correctly) or path.
On 10/25/2011 02:58 PM, Ron Dyck wrote:
I've been having intermittent connection problems with my couchdb
installation. The error is: "Could not connect to server at
<myipaddress>:5984: '111: Connection refused' "
I have a remote installation with the binding address set to 0.0.0.0
My installation is on a AWS linux instance: Amazon Linux AMI x86_64
using the https://github.com/iriscouch/build-couchdb install script.
The problem is very sporadic, occasionally a reload of the page
connects, most other times it does not. I've checked the logs
immediately after the connection loss with no evidence of anything.
When I test the connection locally: curl 127.0.0.1:5984 I get error
connecting. The process is still running when I check ps ax | grep
beam. I'm forced to kill the process and start the server.
Currently we access the server from 3 different locations and my
firewall is set to restrict access to port 5984 from specified IP
addresses.
Any help is really appreciated.
Regards,
ron
--
=================
Ron Dyck
[email protected]
www.webbtech.net
=================
