Closed elafargue closed 8 years ago
This is a tricky one. The back-end waits for a change to happen within the area of interest, but waits at most 2 minutes. Simple polling from the client would be quite inefficient. I have seen cases where many connections are open but this is a while ago. I haven't seen resource starvation on clients, but I have seen it on the server side when there are many clients.
In the client code there is a timeout on calls where the call is cancelled after 2.5 minutes and the browser re-loads if this fails. At least this is the intended behaviour.
Blocking HTTP requests like this to implement asynchronous callbacks is complex and not very efficient. A better solution would be to use the new web-socket protocol.
I have now opened a branch for moving to web-sockets.
That's great, thanks Øyvind,
Ed
(phone) On Dec 20, 2015 13:20, "LA7ECA, Øyvind Hanssen" notifications@github.com wrote:
I have now opened a branch for moving to web-sockets.
— Reply to this email directly or view it on GitHub https://github.com/PolaricServer/webapp/issues/12#issuecomment-166155671 .
Implemented and merged. Testing results are promising.
I noticed that in many occasions, the web app ends up opening dozens of http sockets, leading the browser to issue "waiting for available sockets" messages and waiting for about 2 minutes before updating again. Is this something you have seen on other installations? Is there an Apache setting that needs to be modified to avoid this?
This might actually be connected to aprsd who leaves connections open waiting for a certain amount of time before returning the data. The front-end should be the one making sure there is a certain interval between regular requests, and the back-end should just return the data immediately, imho. Browsers don't seem to cope very well with http sockets that remain open with no data for a long time...