[#DWR-235] reverse ajax with XHR poll may cause lockup in IE - DWR

Details

Type: Bug
Status: Resolved
Priority: Major
Resolution: Fixed
Affects Version/s: 2.0.3
Fix Version/s: 2.0.4
Component/s: Engine

Description:

Hide
Scenario: (tested in IE 6 and 7)
- start a default installation of IE
- open a new window and navigate to a page that is using reverse ajax
- close the window after a few seconds to be certain the page has entered a poll request
- repeat the procedure with one more window

Now there are two destroyed windows with ongoing XHR poll calls.
Each window will trigger the "zombie socket" bug in IE, which means the connection's socket will eventually be closed but not removed from IE's connection list for that server. IE will try to use the closed socket for contacting the server and will not establish any new connection to it as there are already two existing connections (both closed). This can be observed by looking for iexplore.exe sockets that stay in the CLOSE_WAIT state forever, f ex using TcpView.

Show
Scenario: (tested in IE 6 and 7) - start a default installation of IE - open a new window and navigate to a page that is using reverse ajax - close the window after a few seconds to be certain the page has entered a poll request - repeat the procedure with one more window Now there are two destroyed windows with ongoing XHR poll calls. Each window will trigger the "zombie socket" bug in IE, which means the connection's socket will eventually be closed but not removed from IE's connection list for that server. IE will try to use the closed socket for contacting the server and will not establish any new connection to it as there are already two existing connections (both closed). This can be observed by looking for iexplore.exe sockets that stay in the CLOSE_WAIT state forever, f ex using TcpView.

Activity

Ascending order - Click to sort in descending order

Hide

Permalink

Mike Wilson added a comment - 17/Mar/08 9:57 AM

I will add cleanup of XHR calls when leaving page.

Show

Mike Wilson added a comment - 17/Mar/08 9:57 AM I will add cleanup of XHR calls when leaving page.

Hide

Permalink

Mike Wilson added a comment - 08/Apr/08 1:07 PM

There are variations to what happens under different circumstances with this IE bug. Here is an attempt to summarize the bug pattern:

The client code sends an XHR request to the server.
The user leaves the page before the response arrives.
IE will wait for the response even though the page is gone, occupying the connection.
If the response is returned in chunked mode (always used by polls) AND the owning window has been closed, then the socket will become a zombie socket forever occupying the connection in CLOSE_WAIT state. Otherwise it will be returned to the browser pool.

It sounds like you are staying in the same window and thus would just experience the delay until the "old" reverse ajax connection is released.

I have fixed the problem by aborting all ongoing XHR:s at page unload.

Show

Mike Wilson added a comment - 08/Apr/08 1:07 PM There are variations to what happens under different circumstances with this IE bug. Here is an attempt to summarize the bug pattern:

The client code sends an XHR request to the server.
The user leaves the page before the response arrives.
IE will wait for the response even though the page is gone, occupying the connection.
If the response is returned in chunked mode (always used by polls) AND the owning window has been closed, then the socket will become a zombie socket forever occupying the connection in CLOSE_WAIT state. Otherwise it will be returned to the browser pool.

It sounds like you are staying in the same window and thus would just experience the delay until the "old" reverse ajax connection is released. I have fixed the problem by aborting all ongoing XHR:s at page unload.

People

Assignee:

Mike Wilson

Reporter:

Mike Wilson
Votes:

0

Watchers:

0

Dates

Created:

17/Mar/08 9:56 AM

Updated:

08/Apr/08 1:07 PM

Resolved:

08/Apr/08 1:07 PM