qpid-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From CLIVE <cl...@ckjltd.co.uk>
Subject Re: Transport endpoint not connected error???
Date Tue, 22 May 2012 19:10:01 GMT

It sounds like your endpoint is terminating the connection before accept 
has had a chance to 'accept' the TCP connection and return a valid 
socket descriptor.

Have you tried using tcpdump to determine the TCP handshakes that are 
going on (tcpdump dst port 5672)


On 22/05/2012 18:59, Fraser Adams wrote:
> 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 getName()
>     int result = -1;
>     if (local) {
>         result = ::getsockname(fd, (::sockaddr*)&name, &namelen);
>     } else {
>         result = ::getpeername(fd, (::sockaddr*)&name, &namelen);
>     }
>     QPID_POSIX_CHECK(result);
> 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:
>        ENOTCONN
>               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.
> regards,
> Frase
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@qpid.apache.org
> For additional commands, e-mail: users-help@qpid.apache.org
> .

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

View raw message