Details
Description
In trying to replicate a separate issue, I was running AuctionMonitor and opening two browser windows from the same browser. Going back and forth between them, I couldn't get the issue to happen so I opened a 3rd browser window. This appeared to cause the first 2 browser windows to start having communication issues. The behaviour is that the asynch communication appears to get an invalid response and re-open the connection, which generates another invalid response and repeats very quickly.
I was able to replicate the behaviour on Firefox, IE, and Safari. It would happen after 3 browser windows were opened but sometimes it would require 4 or 5. The typical output from the malfunctioning browser windows is as follows:
Firebug in Firefox shows this:
POST http://localhost:8080/auctionMonitor/block/receive-updated-views (46ms)icefaces-d2d.js (line 2219)
[window.vjZR#1.async-connection.blocking] [6997550] : receive [200] OKicefaces-d2d.js (line 2017)
[window] Parsing erroricefaces-d2d.js (line 2029)
POST http://localhost:8080/auctionMonitor/block/receive-updated-views (69ms)icefaces-d2d.js (line 2219)
[window] XML Parsing Error: no element found Location: http://localhost:8080/auctionMonitor/block/receive-updated-views Line Number 1, Column 1:icefaces-d2d.js (line 2029)
[window.vjZR#1.async-connection] receive broadcast failed TypeError: sourceNode is null message=sourceNode is null
Our own bridge console in Safari shows this:
[window.Dpp9#2.async-connection] : receive broadcast failed
TypeError: Null value
Our own bridge console in IE 7 shows this:
[window.NH1C#6.async-connection] : receive broadcast failed
[object Error]
There is nothing on the server side to indicate that anything is wrong (the server logs don't show any stack traces or errors) and you can still generally interact with the application but due to the rapidity of the communication cycle, CPU usage tends to go up pretty dramatically.
I was able to replicate the behaviour on Firefox, IE, and Safari. It would happen after 3 browser windows were opened but sometimes it would require 4 or 5. The typical output from the malfunctioning browser windows is as follows:
Firebug in Firefox shows this:
POST http://localhost:8080/auctionMonitor/block/receive-updated-views (46ms)icefaces-d2d.js (line 2219)
[window.vjZR#1.async-connection.blocking] [6997550] : receive [200] OKicefaces-d2d.js (line 2017)
[window] Parsing erroricefaces-d2d.js (line 2029)
POST http://localhost:8080/auctionMonitor/block/receive-updated-views (69ms)icefaces-d2d.js (line 2219)
[window] XML Parsing Error: no element found Location: http://localhost:8080/auctionMonitor/block/receive-updated-views Line Number 1, Column 1:icefaces-d2d.js (line 2029)
[window.vjZR#1.async-connection] receive broadcast failed TypeError: sourceNode is null message=sourceNode is null
Our own bridge console in Safari shows this:
[window.Dpp9#2.async-connection] : receive broadcast failed
TypeError: Null value
Our own bridge console in IE 7 shows this:
[window.NH1C#6.async-connection] : receive broadcast failed
[object Error]
There is nothing on the server side to indicate that anything is wrong (the server logs don't show any stack traces or errors) and you can still generally interact with the application but due to the rapidity of the communication cycle, CPU usage tends to go up pretty dramatically.
"Mark empty responses that are supposed to terminate the blocking connection (as opposed to empty responses randomly send by some app. servers)."
This introduced a new X-Connection extension response header to indicate blocking connection termination. This affects the ICEfaces AHS as well, therefore I created a follow up JIRA to address this specifically for AHS:
ICE-2869