[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [Libevent-users] Re: libevent2 stuck in Linux, CPU 100%



Nick, that was not the very bottom of it :)

I got email from Alexander Drozdov with a note that this behavior only happens when IP_RECVERR is set on the socket. Well, that's true: without this flag, there is not such effect. Why I am setting this flag is another story. But, supposedly, when a person is setting this flag, he/she must understand what the person is doing.

Still, it would be probably nice-to-mention in the documentation, for Linux only. Something like that: "if a Linux socket is having an error stored in the message queue, then it will result in a "read" callback with empty input data. This callback will be poppoing up indefinitely until the error queue got cleaned in the application code, by using recvmsg with MSG_ERRQUEUE flag."

May be future UDP-based bufferevents can somehow provide a higher interface to that.

By the way, I have, to some extend, a similar situation with TCP sockets. When I have a listening socket, and the number of socket exceeds the system limit, then I am getting messages from the listening libevent callback like:

[warn] Error from accept() call: Too many open files

Basically, the system just has to wait till the socket number decreases. Reporting million errors to the stderr at this moment, from my point of view, rather pointless. Understandably, accept() has problems in the too many open files condition, but I am not sure that it has to be reported to stderr so many times.

Thanks !
Oleg




On Sat, Jul 20, 2013 at 8:22 AM, Nick Mathewson <nickm@xxxxxxxxxxxxx> wrote:
On Sat, Jul 20, 2013 at 2:12 AM, Oleg Moskalenko <mom040267@xxxxxxxxx> wrote:
> I drilled down, eventually, to  the bottom of this problem.
>
> When some kind of socket problem is reported on a UDP socket, then the
> EV_READ is generated but  there is no data is available. So it will go in
> indefinite cycle with libevent.
>
> The solution is to use recvmsg on a socket in this condition, with flag
> MSG_ERRQUEUE. It will read the error message and restore the socket
> condition.
>
> BSD-compatible systems do not do that, this is obviously a Linux
> lesser-known extension.
>
> I am working on including this workaround into the TURN server code, but my
> pilot code tests shows that it works perfectly and this is the right
> solution.

Thanks for sharing this, Oleg!

Is there any reasonable place in the Libevent documentation for us to
mention this?  (I guess that a UDP-based bufferevent-like thing could
wrap this naturally and hide the detail form the user, but we don't
have one of those yet.)

--
Nick
***********************************************************************
To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
unsubscribe libevent-users    in the body.