qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Fraser Adams <fraser.ad...@blueyonder.co.uk>
Subject Transport endpoint not connected error???
Date Tue, 22 May 2012 17:59:02 GMT
Hi All,
on one of our brokers my colleagues have started seeing errors of the form:

error could not accept socket: Transport endpoint is not connected 
(qpid/sys/posix/Socket.cpp 58)

Does anybody have a good idea what is likely to be causing this??

The broker appears to be functioning and there are only a modest number 
of connections to it, we'd even upped the default connection limit "just 
in case" but the number of connections was way lower than that (only a 
couple of dozen or so).

Because the error seemed to be relating to "accept" I did wonder if 
there was a backlog issue, but it's not as if we seem to be having lots 
of things trying to connect at once so it shouldn't be an issue - 
nonetheless we tried upping the backlog "just in case" again it doesn't 
seem to have changed things.

We still appear to be able to connect to the broker and use the qpid 
tools and even created federated links, but I don't like seeing this 
error. I've got no idea what it relates to and can't see what we might 
be doing wrong.

This is in a qpid 0.8 C++ broker.

I had a look through Socket.cpp and the error seems to be kicked off in 

     int result = -1;
     if (local) {
         result = ::getsockname(fd, (::sockaddr*)&name, &namelen);
     } else {
         result = ::getpeername(fd, (::sockaddr*)&name, &namelen);


the QPID_POSIX_CHECK is line 58 which is mentioned in the error message.

Looking through man for getsockname and getpeername getsockname doesn't 
seem to have relevant errors but getpeername mentions:

               The socket is not connected.

Which looks to be a likely place for the error to have originated.

So this looks like it was a result of a remote (to the broker) 
connection endpoint not being present but I'm not at all sure what 
circumstances would cause this in a qpid broker. The brokers have been 
restarted and the host has been rebooted and we're still seeing these 
messages appear regularly (every few seconds) we don't have anything 
(knowingly!!) persisted.

Some more digging suggests that Socket::getName seems to be called by 
getPeername and getPeerAddress but grepping getPeername seems to 
indicate that nothing actually calls getPeername, doing the same for 
getPeerAddress indicates qpid/client/TCPConnector.cpp as the most likely 
thing to be calling it, but I'm not an expert in the code base and this 
would seem to be odd as the error is (I believe) in the broker logs.

I'm wondering if there's something fishy up with a federated connection, 
I'm guessing that could potentially show up as a client error presumably 
a source route might be implemented as if it were a client?

I'd love to know if anyone else has seen this.


To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
For additional commands, e-mail: users-help@qpid.apache.org

View raw message