Here's a sample of the traffic showing four requests per second:

[9.5908s] – POST /auction/javax.faces.resource/listen.icepush.xml.jsf HTTP/1.1
[9.5985s] – POST /auction/javax.faces.resource/listen.icepush.xml.jsf HTTP/1.1
[9.6387s] – POST /auction/auction.jsf HTTP/1.1
[10.589s] – POST /auction/auction.jsf HTTP/1.1
[10.595s] – POST /auction/javax.faces.resource/listen.icepush.xml.jsf HTTP/1.1
[10.605s] – POST /auction/javax.faces.resource/listen.icepush.xml.jsf HTTP/1.1
[10.628s] – POST /auction/auction.jsf HTTP/1.1
[11.595s] – POST /auction/auction.jsf HTTP/1.1

And the traffic. The two blocking requests arrive only 10ms apart. This is similar to what Deryk has seen.

[13.588s]
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: 46
Date: Tue, 04 Oct 2011 16:22:42 GMT

<notified-pushids>vd8pt42</notified-pushids>

[13.598s]
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: 46
Date: Tue, 04 Oct 2011 16:22:42 GMT

<notified-pushids>vd8pt42</notified-pushids>

[13.673s] [13.645s]
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Powered-By: JSF/2.0
Cache-Control: no-cache
Content-Type: text/xml;charset=UTF-8
Content-Length: 541
Date: Tue, 04 Oct 2011 16:22:43 GMT

<?xml version='1.0' encoding='UTF-8'?>
<partial-response><changes><update id="rpt1:0:otime"><Unable to render embedded object: File (0:otime">7d 1:58:19</span>]]></update><update id="rpt1:1:otime"><) not found.[CDATA[<span id="rpt1:1:otime">3d 4:58:10</span>]]></update><update id="rpt1:2:otime"><Unable to render embedded object: File (2:otime">2d 7:59:00</span>]]></update><update id="rpt1:3:otime"><) not found.[CDATA[<span id="rpt1:3:otime">7:58:15</span>]]></update><update id="javax.faces.ViewState"><![CDATA[-1441829653106995469:-1044112092089002795]]></update></changes></partial-response>

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
X-Powered-By: JSF/2.0
Cache-Control: no-cache
Content-Type: text/xml;charset=UTF-8
Content-Length: 192
Date: Tue, 04 Oct 2011 16:22:43 GMT

<?xml version='1.0' encoding='UTF-8'?>
<partial-response><changes><update id="javax.faces.ViewState"><![CDATA[-1441829653106995469:-1044112092089002795]]></update></changes></partial-response>

Assigning to Mircea as it looks to be Push related.

Additional info:

This behaviour occurs with both Mojarra and MyFaces so seems to be related to something in Push. The second update the comes back with just a ViewState appears to occur in the DOMPartialViewContext.processPartial method. There is a guard against a null set of diffs:

} else if (null != diffs)  {

but in the case of the second push request, the list of diffs not null but empty. In that instance, we simply write out the ViewState as the only update. However, the unusual behaviour of the push connection unblocking so quickly after the initial update seems to point to something push related. If it is Push related, we should consider re-categorizing this JIRA.

In addition to creating excess traffic, this also appears to impact MyFaces because each request has a different ViewState (unlike Mojarra). When the ViewState is changed so quickly, it appears to cause an issue with client interactions on the page. You can see this by changing the clock interval from very tight (1 sec or less) to very long (60 secs). When the clock interval is quite long, the Auction example behaves quite well running under MyFaces.

This issue was introduced when ICE-6709 was supposedly fixed. It seems there is timing related problem with the clearing of the pending notifications.

Moved the notification of inbound observers (with the ids used by the browser) to the place where the server responses back with the outbound notifications (the notified pushIDs). This way the pending notifications are confirmed to be satisfied before a new blocking request has time to arrive to the server.

This change has caused a regression in Cloud Push notification – Cloud Push is now delivered even when the client is in the foreground.

Re-opened to find common solution that will work for both MyFaces and Could Push (post Beta2).

Resolving this as ICEfaces aspect is now working.

Created a follow-up JIRA: PUSH-149 for the Cloud push issue.