search

gautamaino / gwteventservice

Automatically exported from code.google.com/p/gwteventservice
Other
0 stars 0 forks source link

Connections stays open #33

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
What steps will reproduce the problem?
1. Add Listeners
2. Remove Listeners by RemoteEventService.removeListeners
3. Monitor connections by Firebug/Fiddler2

What is the expected output? What do you see instead?
I was expecting the connection would be closed, like in the Documentation 
described. But it still remains

What version of the product are you using? On what operating system?
I have the problem with Version 1.1.1 and 1.2 Trunk

Original issue reported on code.google.com by Peter.Nu...@googlemail.com on 6 Apr 2011 at 6:42

GoogleCodeExporter commented 8 years ago 
Connections on IE6 are still open after the window close event.
This old browser can only handle 2 connections to a web serveur.
This issue is critical ...

See attached patch.

Thx for this great library!

Original comment by pierrick.hymbert on 6 Apr 2011 at 3:53

Attachments:

GoogleCodeExporter commented 8 years ago 
im not talking about ie6 specially... i can reproduce this in any browser

when u use the tool fiddler2 it will monitor each connection on any browser 
except connections to the localhost

Original comment by Peter.Nu...@googlemail.com on 6 Apr 2011 at 6:02

GoogleCodeExporter commented 8 years ago 
The patch fix the issue for all browsers ;-)

Original comment by pierrick.hymbert on 6 Apr 2011 at 6:52

GoogleCodeExporter commented 8 years ago 
Hi,

I just tried it on localhost with the latest trunk version (without the patch). 
The connections are shown with Firebug and Chrome Developer Tools, but each 
connection is closed correctly. Is it not reproducable on localhost? Could you 
please try if the problem does also occur with the demo conversation app (war 
file attached to the post)?

Thank you in advance and thank you for the patch!

Original comment by sven.strohschein@googlemail.com on 6 Apr 2011 at 10:14

Attachments:

GoogleCodeExporter commented 8 years ago 
close the issue...

im sorry i found the problem in front of the monitor :(

Original comment by Peter.Nu...@googlemail.com on 7 Apr 2011 at 7:17

GoogleCodeExporter commented 8 years ago 
The problem is that the unlisten() method does not force the end of the user 
pending listen() connection.
The listen() method waits until the max.time.wait occurs.
If the browser is closed before the max.time.wait occurs (20s), the connections 
are not closed properly.

With IE6 the TCP connections are still CLOSE_WAIT for ever when Ajax request 
are not close properly.
@see
http://bytes.com/topic/javascript/answers/643080-ajax-crashes-ie-close-window
http://www.coderanch.com/t/117945/HTML-JavaScript/Too-many-CLOSE-WAIT-due

To reproduce :
1. Add Listeners
2. Remove Listeners by RemoteEventService.removeListeners
3. Monitor connections by Firebug

Thx for your reactivity!

Original comment by pierrick.hymbert on 7 Apr 2011 at 7:35

GoogleCodeExporter commented 8 years ago 
I can still not reproduce this issue (also tested with IE9). I could imagine 
that the connection is not closed correctly when the max. waiting time is still 
active (like perrick described), but this should not happen because an unlisten 
event is send when the unlisten()/removeListeners() method is called. This 
unlisten event should terminate the waiting connection automatically and that 
worked in my tests. Therefore the unlisten() method forces the end of the 
listen() connection. Can someone still reproduce this issue?

Original comment by sven.strohschein@googlemail.com on 3 Oct 2011 at 10:22

GoogleCodeExporter commented 8 years ago 
We can reliably reproduce this issue.  We are using version 1.1.1.

The client sends a request to the gwteventservice to listen for events and the 
server responds in 30s (proven by our apache server logs and timestamps), 
however, on occasion, the response does not reach the browser.  As a result, in 
the browser (via HttpFox plugin) it looks like there is a hung connection.  
After a period of time, some node on the network sends the brower a TCP/IP FIN 
command and only then the browser closes the connection.   The issue of the 
brower not receiving the response even though the server has sent a response is 
clearly a network issue.  However, the client should be more robust in how it 
handles bad networks.  Is there anything that can be done within the 
gwteventservice javascript code that can deal with long connections that 
surpass the configured timeouts?   

thanks,

JK

Original comment by j...@architech.ca on 1 Nov 2011 at 6:05

GoogleCodeExporter commented 8 years ago 
I could still not reproduce the issue in a live test, but the listening request 
is now terminated/returned directly when the user gets removed (via unlistening 
/ removing listeners) like in the proposal of Pierrick. This is now fixed in 
the trunk version (GWTEventService 1.3).

Could someone please confirm/check if the fix is completely solving the problem?

@JK: A client-side timeout handling could get implemented together with the 
feature of Issue46 which is also planned for GWTEventService 1.3.

Original comment by sven.strohschein@googlemail.com on 8 Aug 2012 at 10:32