Bug #4697
closedHttp::ResponseContinuation: WriteError
0%
Description
Hello,
You may already know from the forums that I am facing a lot of "Http::ResponseContinuation: WriteError" errors that prevent my custom audio Resource to be properly served.
Since this bug is really annoying for me, I managed to reproduce it using a big audio file and Firefox and to activate some debug on Wt.
My custom resource can be found here : https://github.com/epoupon/lms/blob/develop/src/ui/resource/TranscodeResource.cpp
I use it as a source for a HTML5 audio element. I set the chunk size to 256KB.
I was expecting the browser to read all the data sent by the server but that is not the case.
Chrome requests about 5MB and then does not read the last result immediately:
[2016-Jan-23 17:36:54.183661] 10338 - [error] "wthttp/async: 20 sending: 262153(buffers: 3)"
[2016-Jan-23 17:36:54.184862] 10338 - [error] "wthttp/async: 20: handleWriteResponse(): 262153 ; Success"
...
[2016-Jan-23 17:36:54.603184] 10338 - [error] "wthttp/async: 20 sending: 262153(buffers: 3)"
[2016-Jan-23 17:37:44.675874] 10338 - [error] "wthttp/async: 20: handleWriteResponse(): 262153 ; Success"
Chrome does not wait long to require more data chunks. Actually it works quite well.
Firefox requires about 10 MB but like Chrome it does not read the result of the last chunk immediately:
...
[2016-Jan-23 17:25:52.900328] 10338 - [debug] "wthttp/async: 16 sending: 262153(buffers: 3)"
[2016-Jan-23 17:25:52.900961] 10338 - [debug] "wthttp/async: 16: handleWriteResponse(): 262153 ; Success"
...
[2016-Jan-23 17:25:53.341506] 10338 - [error] "wthttp/async: 16 sending: 262153(buffers: 3)"
[2016-Jan-23 17:25:53.342145] 10338 - [error] "wthttp/async: 16: handleWriteResponse(): 262153 ; Success"
...
[2016-Jan-23 17:25:53.774102] 10338 - [debug] "wthttp/async: 16 sending: 262153(buffers: 3)"
[2016-Jan-23 17:30:08.360953] 10338 - [debug] "wthttp/async: 16: handleWriteResponse(): 262153 ; Success"
To make it work, I had to raise significantly the CONNECTION_TIMEOUT define in Wt.
Without this change, the timer makes the connection close and we get the WriteError event in the upper layers.
I was quite surprised to see this timer in wt code though. Shouldn't the TCP layer already spot any connection failures?
What do you think?
Updated by Koen Deforche almost 9 years ago
- Status changed from New to Feedback
Hey, the timers are there to prevent resources from server being occupied perpetually. It is uncommon for a browser to not consume all requested data, but we should indeed be more forgiving. I suggest we raise the timeout while reading or writing. What value did you use?
Updated by Emeric Poupon almost 9 years ago
Hello,
I thought it was uncommon, but given the wt traces it seems both Firefox and Chrome do that! I do agree this behavior is quite questionable though.
I think I hit the problem since I expose my resource as a "infinite" stream, as do web radios or remote microphones for example. But radios and microphones are actually quite slow to produce the actual data, that may explain why they do not hit the problem.
I set the timeout to 600 just to be sure, but I can't really tell how much would be fine, maybe 300?
Regards,
Updated by Koen Deforche over 8 years ago
- Status changed from Feedback to Resolved
- Assignee set to Koen Deforche
- Target version set to 3.3.6
Updated by Koen Deforche over 8 years ago
- Status changed from Resolved to Closed