This appears to be caused by the change from bridge/src/connection.js (revision 15520).
Perhaps our Grizzly integration is returning an empty response when not expected by the JS bridge.

Making the following change appears to resolve the problem:

— ../bridge/src/connection.js (revision 15866)
+++ ../bridge/src/connection.js (working copy)
@@ -49,7 +49,7 @@
}

This.Receive = function(response)

This.Ok = function(response) {

Is the test for an empty response necessary for the Portlet fix?

I think Firefox would go into a infinite loop trying to create a blocking connection. This can happen when a session expires and the server responds with empty requests.

Can the server respond with an error during session expiry?

Changes made after ICE-2606 fixes have made the test for empty request useless.

More specifically ICE-1899 fixed the tight loop problem we've been seeing.

Revision: 15968
Although there is significant improvement but a delay of 2-3 seconds is still seen on the clocks on both windows.

I cannot see any delay when running on Glassfish 9.1_01 on Mac.

Also see following javascript errors on the second window when the first window is closed.

$A is not defined
(no name)()ice-extras.js (line 5856)
these()icefaces-d2d.js (line 193)
[Break on this error] return _29.apply(_2b,_2a.concat($A(arguments)));
icefaces-d2d.js (line 150)
$A is not defined
[Break on this error] return _29.apply(_2b,_2a.concat($A(arguments)));
icefaces-d2d.js (line 150)
$A is not defined
[Break on this error] return _29.apply(_2b,_2a.concat($A(arguments)));
icefaces-d2d.js (line 150)
$A is not defined
[Break on this error] return _29.apply(_2b,_2a.concat($A(arguments)));

Refactor XMLHttpRequest callbacks to not make use of any library.

This issue needs to be re-tested with the fix for ICE-2842.

According to this ( http://weblogs.java.net/blog/jfarcand/archive/2007/01/configuring_gri.html ) we need to change a few configuration parameters in domain.xml file to have a responsive Ajax application.

Mainly we should change these values:

• change jvm option
  <jvm-options>-server</jvm-options>

• add jvm option
  <jvm-options>-Dcom.sun.enterprise.server.ss.ASQuickStartup=false</jvm-options>

• change 'thread-count' related attributes
  <request-processing header-buffer-length-in-bytes="8192" initial-thread-count="10"
  request-timeout-in-seconds="30" thread-count="130" thread-increment="10"/>

• increment number of acceptor threads to match number of processors/cores
  <http-listener id="http-listener-1" address="0.0.0.0" port="8080" acceptor-threads="2".....

The bug described here was actually fixed on commit with revision: 15968.

The 1-2 seconds delay we see when using the chat in auctionMonitor happens also when running with Tomcat. The delay occurs only on the first 4 chat messages when large DOM updates arrive to the server and their processing introduce the delay. After that when the updates for the listed chat messages arrive as individual updates for each row the browser has to do less processing thus no visible delay in clocks.

Assign to Ted for evaluation.