lws-team
commented
7 years ago OK. I appreciate the reproducer.
I will have a look at this over the weekend.
It is surprising wrt Autobahn. When I did the last fix I updated the logs on libwebsockets.org from autobahn, they are all fine.
https://libwebsockets.org/clients/index.html
Autobahn strictly uses echo semantics though. And it always takes data as fast as it provides it. So there are probably significant gaps between what that synthetic test actually stresses and what might have trouble hiding in the real world.
IvanKuchin
Hello lws-team,
Nice to meet you again ! This time I actually can't complain on lws-library, due to issue reproducing with no error's in log. But let me rise my concern, hope you'll give me direction where should I dig in.
Our project having very intensive exchange over WebSockets in peak hours. After working few hours it comes to stuck state and can't send/receive/close connection.
Tested libs: 1) 2.1.0 with fix from my previous issue 2) 2.2.0 with fix from my previous issue
------ debug1: last lines in debug (pay attention to draining 1 and final 0) - > stuck
-------------- DEBUG2: last lines in debug (pay attention to draining 1 and final 1) -> stuck
It is easily reproduces on production environment by waiting several hours, but the repro on test-server end up with different log. To reproduce issue on test-fraggle, I took 2 big images (nothing special in there: https://github.com/IvanKuchin/lws-quality-assurance/tree/master/image_example), convert them to blob and sending to test-fraggle. I can't paste source of html here because of the volume, you can get it https://github.com/IvanKuchin/lws-quality-assurance/tree/master/src. ---------------------- Repro step
I looked through autobahn tests and they sending even bigger files over WebSocket (20 MB). This is looks strange to me.