I added the code provided in the forum thread to our compat-basic example as a separate page and ran it. There is indeed a time period (which varies, I imagine, depending on your hardware and other environmental factors), when making a render request fails to notify the client that an update is pending.

In the forum poster's example, the JavaScript to simulate a mouse-click is occurring before the ICEpush blocking connection can be established. Without the blocking connection being established, a notification that should be sent to the client that an update is pending is never received and the pending update is lost.

In the server console, the item of interest that is logged of interest is the following:

28-Mar-2011 1:54:19 PM org.icepush.servlet.EnvironmentAdaptingServlet <init>
INFO: Adapting to Thread Blocking environment

The EnvironmentAdaptingServlet is created when the first request of the ICEpush blocking connection is sent. If a render request is made from the backing bean before this has been established, then the notification is lost. By introducing a delay that is long enough to allow the blocking connection to establish itself:

- on the server-side as the forum poster has done in their backing bean, or
- on the client-side, which I verified by using setTimeout() and calling the simulated mouse click after a sufficient timeout value as follows:

     <script type="text/javascript">
         ice.onLoad(function() {
             var duration = 10000;
             var timeoutClick = setTimeout("simulatedClickOnLoad()", duration);
            // console.log("simulatedClickOnLoad set with timeout of " + duration);
         });

         function simulatedClickOnLoad(){
             //console.log("simulatedClickOnLoad started") ;
             var href = document.getElementById('form1:bodyLoadedSignal');
             var evt = document.createEvent("MouseEvents");
             evt.initMouseEvent("click", true, true, window, 0, 0, 0, 0, 0, false,false, false, false, 0, null);
             href.dispatchEvent(evt);
         }
     </script>


Then the notifications work as designed. There are different ways to potentially fix this:

1) We could ensure that we track any pending notifications that occur before the blocking connection has been established and ensure they are delivered when the blocking connection is ready. This is likely the correct and proper thing to do.

2) We could ensure a render request is done as soon as the blocking connection is established. This is likely a bit easier to do but is less elegant and may introduce a scalability inefficiency.

3) We could offer a callback for when the blocking connection has been established so that, rather than use ice.onload() to register actions that can trigger an Ajax Push, they could be registered with the blocking connection. This puts more onus on the developer and is less transparent that option #1. However, it might be useful to have additional API's added to ICEpush running in ICEfaces for things other than this issue as well.