[Libwebsockets] ah excessive hold for 370 seconds

Andy Green andy at warmcat.com
Mon Feb 25 06:25:54 CET 2019

On 25/02/2019 12:01, Xi Chen wrote:
> Hi Andy,
> I hit this issue in my test:
> ===========
> NOTICE: ah excessive hold: wsi 0x3c0dc
>    peer address: x.x.x.x
>    ah pos 179
> NOTICE:    content-type: = multipart/related; boundary=------abcde123; 
> type=application/json
> NOTICE:    :status = 200
> NOTICE:    access-control-allow-origin: = *
> INFO: __lws_header_table_detach: wsi 0x3c0dc: ah 0x3616c (tsi=0, count = 1)
> [DEBUG: __lws_header_table_detach: wsi 0x3c0dc: ah held 370s, role/state 
> 0x10000000 0x117,
> ===========
> Any clue on how to debug this issue?

Ah are used to hold parsed http headers.

Ah cost memory, if lws or your code is holding them for a long time, it 
mans your code is bloating your memory usage needlessly.   For ws 
connections the ah is detached automatically after the ESTABLISHED 
callback, since ws doesn't need http headers after it's established and 
expects to live a long while.

The ah timestamp themselves when an http connection acquires them, and a 
periodically the ah are checked for having been held an unreasonable 
time, > 6 minutes.  Any connections holding ah that long are killed and 
the ah freed.

For intentionally long-lived http connections, you can copy or parse any 
headers that you are interested in, and then drop the ah manually.


> I have no idea of when should ah entry be removed ...

http connections and streams are subject to timeouts set by lws that are 
much shorter than 6m by default.  If an http connection or stream is 
living 6 minutes+, you must have extended or disabled its timeout.  So 
you'd detach the ah at the same place you did that, typically.


> Thanks
> -Xi
> _______________________________________________
> Libwebsockets mailing list
> Libwebsockets at ml.libwebsockets.org
> https://libwebsockets.org/mailman/listinfo/libwebsockets

More information about the Libwebsockets mailing list