ESPAsyncWebServer icon indicating copy to clipboard operation
ESPAsyncWebServer copied to clipboard

Deadlock when Serving Static Files with ESP32AsyncWebServer Library

Open corke2013 opened this issue 1 year ago • 2 comments

Hi :wave:

I'm encountering an issue while trying to serve static files using the ESP32AsyncWebServer library. Specifically, I see the following error message:

E (18862) task_wdt: Task watchdog got triggered. The following tasks did not reset the watchdog in time: 
E (18862) task_wdt:  - async_tcp (CPU 0/1)

TL;DR:

It appears there's a deadlock between the async_tcp and tiT threads when the _async_queue (located here) becomes full. This causes the watchdog timer to be triggered. More details about why this happens can be found here.

Possible Workaround:

Some users have suggested increasing the size of _async_queue (from the default 32 to values like 64, 128, or even 512). While this can alleviate the issue in some cases, I don't believe it's a reliable long-term fix, as the underlying deadlock bug still persists.

Suggested Solution:

In my testing, using the AsyncTCPSock library has successfully resolved the deadlock issue without introducing compatibility problems with ESPAsyncWebServer. More on this fix can be found in this comment.

Given that ESPAsyncWebServer is the go-to async web server library for ESP32, I propose that we replace AsyncTCP with AsyncTCPSock to eliminate the deadlock issue once and for all.

I've had limited testing with AsyncTCPSock, but it works well in my setup.

Looking forward to your thoughts!

corke2013 avatar Nov 23 '24 01:11 corke2013

Hello,

Just to let you know that there has ben a lengthy discussion around this problem here: https://github.com/mathieucarbou/ESPAsyncWebServer/discussions/165

A fix was implemented: (we could call that a workaround or patch though because the real fix would be to get rid of the current queue design)

  • https://github.com/mathieucarbou/AsyncTCP (3.2.15)
  • https://github.com/mathieucarbou/ESPAsyncWebServer ( 3.4.0)

There is also some perf tests available in my fork.

mathieucarbou avatar Dec 11 '24 19:12 mathieucarbou

Hi @mathieucarbou 👋

Thanks for your response.

I actually did end up trying your fork and it solved the deadlock issue for normal HTTP requests however, the project I am busy with also needs to use a websocket.

I was getting similar issues using the websocket with your fork - can't remember exactly what the issue was, but I am quite certain it was more watchdog timeouts. Happy to try again and provide more info if you'd like?

For now, I ended up using the standard WebServer included in the Arduino core as stability is more important to me than perf at this stage. I've also had to drop using websockets which is disappointing.

corke2013 avatar Dec 11 '24 19:12 corke2013