First explaining what happened in here. When a receive-updated-views comes into WebLogicAdaptingServlet and no update is ready this request gets "parked" by being pushed to the RequestManager. The original approach has to then pull the pending request from the RequestManager in the following two scenarios:

1. An update became available and a response containing the views to be updated is send to the pending request.
2. A new receive-updated-views comes in for the same session but the pending request is still in the RequestManager. In this case a Close response is send to the pending request.

In both cases the pending request was pulled from the RequestManager.

Apparently we overlooked a third scenario. WebLogic uses a timeout on any pending request. By default this seems to be 40 seconds. Now what happened here is that the 40 second timeout happens before our default heartbeatTimeout value of 50 seconds. As the ping doesn't come in before the WebLogic 40 second timeout to generate a NOOP response, WebLogic invokes the AbstractAsyncServlet.doTimeout(RequestResponseKey) method. Our implementation here was pretty blunt: just send a NOOP response. Unfortunately, the pending request (which now received a NOOP response) was not pulled from the RequestManager. Eventually a new receive-updated-views comes in. The logic in our doRequest(RequestResponseKey) implementation still detects a pending request and tries to send a Close response in order to close the previous connection. This results in the mentioned exception.

Our implementation logic of the doTimeout(...) method is now corrected to take this into account. As it is a WebLogic driven timeout, I decided to switch from a NOOP to a Close response in this case. At this point we can't be sure the client is still there and or still active. It made more sense to me to send a Close response and clean up the connection.

However, one additional thing needs to be done to the configuration in order to keep things under ICEfaces control. The heartbeatTimeout should be shorter then the WebLogic timeout. To give an example, if the WebLogic timeout is left to the default, the heartbeatTimeout can be set as follows:

<context-param>
<param-name>com.icesoft.faces.heartbeatInterval</param-name>
<param-value>30000</param-value>
</context-param>

Marking this one as FIXED.

Feedback from the customer regarding the patch:

While I'm no longer getting the 500 error, and I'm able to successfully do push updates, post push update my ice:outputLinks are written incorrectly. The context path gets replaced with 'eps'. So, for example, in my xhtml an ice:outputLink looks like:
<ice:outputLink value="/xhtml/messages/messageHistory.xhtml">

Upon initial render, the link gets written as:
http://gamma.networkfleet.com/portal/connect/message-history/

after a push update, it gets written as:
http://gamma.networkfleet.com/eps/connect/message-history/

He has provided a new sample application and in order to recreate the error, visit http://hostname/nwf-sample/push-clock/30. You can replace 30 with any number. The number you use will be the number of seconds between push updates. You'll see a link on the page "Link to myself (30s interval)". Upon initial load, the value of this link will be http://hostname/nwf-sample/push-clock/30 after the first push update, the value will change to http://hostname/eps/push-clock/30

Closing this one again, as the follow-up issue is addressed in http://jira.icesoft.org/browse/ICE-7991