Frase,
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)
Clive
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
|