[Libwebsockets] [1357004006:1893] ERR: Unable to spill ext 2819 vs 1448

Gregory Junker ggjunker at gmail.com
Thu Apr 11 23:42:46 CEST 2013


On Thu, Apr 11, 2013 at 1:56 PM, Gregory Junker <ggjunker at gmail.com> wrote:

> On Tue, Apr 2, 2013 at 5:55 PM, "Andy Green (林安廸)" <andy at warmcat.com>wrote:
>
>>
>> Currently lws takes action to reserve OS buffers for each connection of
>> the size of the read buffer for the protocol to stop this happening.
>>
>
> I may simply be missing where this happens, but I am not seeing any
> evidence of this in the code as of yesterday's HEAD -- can you point me to
> where this is happening?
>

OK NM I see it now (the SOL_SNDBUF commit that went in on 23 March). But
either it is not "taking" (regardless the absence of error condition on
setsockopt call) or there is something else involved in the send() call in
lws_issue_raw refusing to send more than 272K of my data:

[1365712303:0963] PARSER: libwebsocket_parse sees parsing complete
[1365712303:0963] PARSER: lws_parse calling handshake_04
[1365712303:0963] PARSER: issuing resp pkt 159 len
[1365712303:0963] PARSER: written 13 bytes to client
[1365712303:0963] INFO: Allocating RX buffer 16777238
[1365712303:0963] PARSER: accepted v13 connection
[1365712303:0972] PARSER: spill on aaas
[1365712303:0973] PARSER: written 87 bytes to client
[1365712303:0996] PARSER: spill on aaas
[1365712303:1001] PARSER: written 50762 bytes to client
[1365712303:1005] PARSER: written 47120 bytes to client
[1365712303:1008] PARSER: written 23576 bytes to client
[1365712303:1008] PARSER: written 3152 bytes to client
[1365712303:1009] PARSER: written 2736 bytes to client
[1365712303:1010] PARSER: written 1384 bytes to client
[1365712303:1011] PARSER: written 3152 bytes to client
[1365712303:1011] PARSER: written 2736 bytes to client
[1365712303:1012] PARSER: written 1384 bytes to client
[1365712303:1012] PARSER: spill on aaas
[1365712303:1151] ERR: Unable to spill ext 1722426 vs 278528
...

it looks like the default for wmem_max is 128K and setting it to 16MB sorts
this out for me....but....that's not a feasible option.

Can we just make non-blocking behavior optional, and allow the previous
blocking behavior? None of this was an issue previously for me, and I do
not see any way for my server code to handle this condition, since
libwebsocket_write simply returns -1 when this write fails. Additionally,
forcing non-blocking behavior on send() is introducing exactly the problem
I am trying to avoid with atomic send()/recv() behavior.

Thanks
Greg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20130411/91f303aa/attachment-0001.html>


More information about the Libwebsockets mailing list