GauravBasu / jquery-stream

Automatically exported from code.google.com/p/jquery-stream
0 stars 0 forks source link

Timeouts due to reconnect milliseconds too late #48

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
I'm not sure if this is or bug or even a serious issue, but the behavior I see 
seems not correct. 

I see this in my log:
11:26:49.752 [qtp1975214396-19] DEBUG n.t.wicket.filter.CacheFilter - Invoking 
cache filter for /raris/streamservlet
11:27:19.751 [qtp1975214396-21] DEBUG n.t.w.j.servlet.StreamServlet - client 
20b8380e-ca45-4369-a5db-e3004b6f8cbf timed out
11:27:19.752 [qtp1975214396-21] DEBUG n.t.w.j.servlet.StreamServlet - client 
20b8380e-ca45-4369-a5db-e3004b6f8cbf completed
11:27:19.769 [qtp1975214396-19] DEBUG n.t.wicket.filter.CacheFilter - Invoking 
cache filter for /raris/streamservlet

So at 11:26:49.752 the client made a GET request to the servlet, at 
11:27:19.751 the onTimeOut method of the AsyncListener is called. This seems 
correct, as it is 30 seconds after the get request. The next get request is 17 
milliseconds too late. 

The weird thing is, clients don't show this behavior all the time and I can't 
find a cause which triggers this. I've seen this behavior from Firefox, IE and 
Chome.

I'm using a servlet inspired on the chat servlet example, client settings are 
the following:

$.stream.setup({enableXDR: true});
$.stream("${url}", {
        dataType: "json",
        type:"http",
        message: function(event) {
                try {
                    streamLog(event.data.javascript, "debug");

                    eval(event.data.javascript);
                } catch(ex) {
                    streamLog(event.data.javascript, "debug");
                }
        },
        openData: {
            type: "json",
            clientid: "${clientid}"
        }
});

Original issue reported on code.google.com by sven.rie...@topicus.nl on 5 Oct 2011 at 9:48

GoogleCodeExporter commented 9 years ago
Hello,

The reconnection delay caused by timeout depends on the browser and sometimes 
the networks status. There is no room for control the delay. It could be larger 
than 17ms. If you need a seamless stream, you can use heatbeat.

http://ajaxpatterns.org/Heartbeat

To implement the heartbeat pattern, you have to execute a timer from the server 
using java.util.Timer or from the client using iterative setTimeout which sends 
heartbeat message periodically. When the heartbeat message is received, the 
client have to send back it to the server, and the server have to extend 
timeout. After the stream is closed you have to clear the timer.

--Donghwan

Original comment by flowersi...@gmail.com on 7 Oct 2011 at 6:54

GoogleCodeExporter commented 9 years ago

Original comment by flowersi...@gmail.com on 11 Oct 2011 at 8:35