Re: [Libevent-users] 100% cpu utilization with openssl bufferevent.

[Springande Ulv <springandeulv@xxxxxxxxx>]

From my experience such "while-true" loops are typically created if you neglect to check if the connection was closed on the client side and instead reinsert the connection in libevent. In this case libevent will immediately report that the connection is readable. 

On 29. apr. 2010, at 12.10, Sebastian Sjöberg wrote:

> On Apr 29, 2010, at 11:19 AM, Sebastian Sjöberg wrote:
> 
>> Hi,
> 
> Some additions and corrections. I've tested this on the latest libevent from git.
> 
>> 
>> I've encountered a problem with openssl bufferevents where libevent reports fd:s as writeable but no action is being taken.
> 
> After adding some more debug printouts in libevent it turns out that the fd:s are reported as readable but they never get processed because the macro N_ACTIVE_CALLBACKS() reports 0.
> 
>> 
>> The program does the following:
>> 
>> An evconnlistener waits for connections and when an connection by a client is made we set up an reading event. When the new connection is readable we peek the data to see if it's tls and if it's tls we set up an openssl bufferevent on that connection. We read the http request and write some data as reply, the bufferevent is then kept as we write commands on this connection when needed.
>> 
>> The issue appears (intermittently) when I'm connecting 20-100 clients and libevent debug output continuously reports:
>> 
>> [debug] epoll_dispatch: epoll_wait reports 78
>> [debug] timeout_next: in 88 seconds
>> [debug] epoll_dispatch: epoll_wait reports 78
>> [debug] timeout_next: in 88 seconds
>> [debug] epoll_dispatch: epoll_wait reports 78
>> [debug] timeout_next: in 88 seconds
>> [debug] epoll_dispatch: epoll_wait reports 78
>> [debug] timeout_next: in 88 seconds
>> [debug] epoll_dispatch: epoll_wait reports 78
>> [debug] timeout_next: in 88 seconds
>> [debug] epoll_dispatch: epoll_wait reports 78
>> [debug] timeout_next: in 88 seconds
>> [debug] epoll_dispatch: epoll_wait reports 78
>> [debug] timeout_next: in 88 seconds
>> 
>> There is no problem when I'm connecting without tls so I think this is an issue with openssl bufferevents and my guess is that somehow the write events that openssl bufferevents sets up sometimes doesn't get removed or disabled properly.
>> 
>> Is this an issue that someone else has seen and does anyone have any pointers on how to debug this problem?
>> 
>> Best regards,
>> Sebastian Sjöberg
>> 
>> ***********************************************************************
>> To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
>> unsubscribe libevent-users    in the body.
> 
> ***********************************************************************
> To unsubscribe, send an e-mail to majordomo@xxxxxxxxxxxxx with
> unsubscribe libevent-users    in the body.

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