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.
I will add cleanup of XHR calls when leaving page.
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.