Scheduling for next EE release. Customer has proposed a fix they would like us to validate for correctness and potential side-effects:

Index: src/com/icesoft/faces/context/View.java
===================================================================
— src/com/icesoft/faces/context/View.java (revision 21174)
+++ src/com/icesoft/faces/context/View.java (working copy)
@@ -53,6 +53,7 @@
import edu.emory.mathcs.backport.java.util.concurrent.locks.ReentrantLock;
import org.apache.commons.logging.Log;
import org.apache.commons.logging.LogFactory;
+import edu.emory.mathcs.backport.java.util.concurrent.TimeUnit;

import javax.servlet.http.HttpSession;
import java.lang.reflect.Constructor;
@@ -247,12 +248,16 @@

public void dispose() {
try {

• acquireLifecycleLock();
  + if (!lifecycleLock.isHeldByCurrentThread()) { + lifecycleLock.tryLock(30, TimeUnit.SECONDS); + }

  dispose.run();
  ContextEventRepeater.viewNumberDisposed(
  facesContext.getExternalContext().getSession(false),
  sessionID,
  Integer.parseInt(viewIdentifier));
  + } catch (InterruptedException exception)

  { + // do nothing. }

  finally

  { releaseLifecycleLockUnconditionally(); }

The proposed patch is safe to apply. Timing out the lock should not introduce any side effects. By the time the timeout has elapsed any JSF lifecycle (still running at the moment of session invalidation) has had enough time to fully execute.

Applied patch recommended by client. The introduced change exits the potential dead-lock after 30 seconds to allow the session to expire.