[Libwebsockets] [1357004006:1893] ERR: Unable to spill ext 2819 vs 1448
"Andy Green (林安廸)"
andy at warmcat.com
Fri Apr 12 06:53:36 CEST 2013
On 12/04/13 05:42, the mail apparently from Gregory Junker included:
> On Thu, Apr 11, 2013 at 1:56 PM, Gregory Junker <ggjunker at gmail.com
> <mailto:ggjunker at gmail.com>> wrote:
> On Tue, Apr 2, 2013 at 5:55 PM, "Andy Green (林安廸)"
> <andy at warmcat.com <mailto: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()
I think your problems boil down to trying to give huge packets to the OS
to send and it can't cope with it.
Why don't you use the FIN / CONTINUATION stuff with a send size of
More information about the Libwebsockets