[Libwebsockets] ah excessive hold for 370 seconds
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;
> 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.
> Libwebsockets mailing list
> Libwebsockets at ml.libwebsockets.org
More information about the Libwebsockets