I'm working on stabilizing ESPAsyncWebServer for WLED, and I ran in to a problem with AsyncTCP deadlocking under load (>5 inbound connections). The issue turned out to be that the event queue overflowed, resulting in the lwip task blocking to put something in the queue, while the async service task was in turn blocked waiting for lwip to service a synchronous tcpip_api_call().
Since there doesn't seem to be a reasonable way to handle a queue overflow in this architecture -- discarding the overflowing event could confuse the state machine, resulting in leaked objects and connections -- I've oped to increase the queue size until it's big enough that I can fill service CONFIG_LWIP_MAX_ACTIVE_TCP connections without locking up. Empirical testing suggested this seemed to work well at 4 events per connection.
This patch set restores the existing CONFIG_ASYNC_TCP_EVENT_QUEUE_SIZE to operation, and then increases the default size.
I'm working on stabilizing ESPAsyncWebServer for WLED, and I ran in to a problem with AsyncTCP deadlocking under load (>5 inbound connections). The issue turned out to be that the event queue overflowed, resulting in the lwip task blocking to put something in the queue, while the async service task was in turn blocked waiting for lwip to service a synchronous tcpip_api_call().
Since there doesn't seem to be a reasonable way to handle a queue overflow in this architecture -- discarding the overflowing event could confuse the state machine, resulting in leaked objects and connections -- I've oped to increase the queue size until it's big enough that I can fill service
CONFIG_LWIP_MAX_ACTIVE_TCPconnections without locking up. Empirical testing suggested this seemed to work well at 4 events per connection.This patch set restores the existing CONFIG_ASYNC_TCP_EVENT_QUEUE_SIZE to operation, and then increases the default size.