Testing with IE 6 under Wine and two tabs showed no connections to the server at the point of failure. Possibly the jsf.js queue has determined that the queue is full.

Four Win XP machines have been used for the following test. Tomcat 6 is running on each of the machines, and a single browser is used for each server.

Glimmer revision #: 20013

1) IE8 (with 2 tabs open)

• In one tab, clocks stopped at 15:00:04
• Within the other tab, clocks stopped at 7:32:23
• Reloading the page freezes the browser. "Not Responding" showing on the page title
• No error/Exception showing in the server logs and console

2) IE7 (with 2 tabs open)

• Clocks stopped at 19:36:30 for both windows
• Reloading the page makes the browser frozen. "Not Responding" showing on the page title
• No error/Exception showing in the server logs and console

3) IE6 (with 2 windows open)

• Clocks stopped at 19:32:34 for both windows
• Page reloading helps reducing the clock values, but does not bring the clocks back to tick
• No error/Exception showing in the server logs and console

4) Safari 4 (with 2 tabs open)

• Still ticking fine

(will test single browser with one tab open and post the result)

Still, used 4 Win XP machines for the test. Tomcat 6 is running on each of the machines, and a single browser is used for each server.

Glimmer revision #: 20015

1) IE8 (with 1 tab open)

• clocks stopped at 14:53:56
• Reloading the page freezes the browser for a couple of minutes, and then bring the clocks back to tick

2) IE7 (with 1 tab open)

• Clocks stopped at 14:53:35
• Reloading the page freezes the browser for several seconds, and then bring the clocks back to tick

3) IE6 (with 1 window open)

• Clocks stopped at 14:47:19
• Page reloading updates the clocks to reduced values, but does not make the clocks ticking again

***For all IE browsers:***

• Click on the warning icon on the bottom left corner of the page, the displayed message says "Not enough storage is available to complete this operation."
• No error/Exception showing in the server logs and console

4) Chrome 3 (with 2 tabs open)

• Still ticking fine

I have confirmed the "Not enough storage is available to complete this operation" with two IE 6 windows stuck at 23:53:52. This error is not displayed upon initial loading of the page so likely indicates the root cause. The final exchange with the server was:

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Powered-By: JSF/2.0
Cache-Control: no-cache
Cache-Control: no-store
Cache-Control: must-revalidate
Pragma: no-cache
Expires: 0
Content-Type: text/xml;charset=UTF-8
Content-Length: 67
Date: Thu, 07 Jan 2010 16:35:14 GMT

<notified-pushids>1262881755809 1262881743192 </notified-pushids>

No further requests to /auction/listen.icepush.jsf were issued by the browser.

On other occasions, IE6 can be observed to crash. It will not likely be effective to debug this problem with the current test case: ICEpush should be tested standalone on IE6.

IE6 crash has been reproduced reliably with 5 tabs open on icepush-basic from snowplow.

The debugging done was mostly a trial and error process since IE does not provide much feedback (especially when it crashes). The areas of the code that were mostly analyzed were the ones that were executing continuously, such as request/response processing an cookie handling. During the analysis of the cookie handling I verified if the strings used for names and values are using forbidden characters. It seems that cookie values are not allowed to contain blank characters which turn out that we used (source: http://www.thesitewizard.com/javascripts/cookies.shtml ).
To solve the issue the value string were encoded to avoid using forbidden characters.

Use 'encodeURIComponent' and 'decodeURIComponent' functions to encode and respectively decode cookie values.

Crash was observed again, re-opening issue.

For the initial verification, cookies were cleared, and the test ran until the server was restarted.

If cookies are not cleared and the test is restarted, it can be observed to crash within 10 minutes.

There may be a problem with BROWSERID assignment: the ID before the ":" in the window name is different for the first window than the subsequent windows.

Just before IE crashed it briefly displayed "The website 10.18.3.59 wants to save a file on your computer called a "cookie""

Some failures are due to Internet Explorer memory leaks. Request attribute resolves push failures under multiple browser connections, but push failures for long running connections need further investigation.

Changes to remove the ThreadLocal and use request attributes have remedied the problem of staring push with multiple browsers instances running. However, push is still timing out after a variable amount of time which at this point does not look related to the type or version of browser.

Our current data indicates that push groups are being cleaned up too early and the cause may be related to the calculation of the lastAccess time in PushContext.Group class. Typically, each incoming request with valid push ids would touch the lastAccess time indicating the push group was still valid. However, there seems to be an issue which causes these requests to not update the lastAccess time. Continuing to investigate.