ICEfaces
  1. ICEfaces
  2. ICE-5649

Deadlock on session invalidation

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.8.2-EE-GA_P01
    • Fix Version/s: 1.8.3, EE-1.8.2.GA_P04
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      WebSphere 6.1

      Description

      Customer reports that a deadlock can occur during session invalidation on WebSphere 6.1

      "Two threads used an instance of View class (on session invalitation), and one thread locked the HTTP session, the second thread locked the lifecycleLock field. They were waiting for each others monitors."

        Issue Links

          Activity

          Hide
          Deryk Sinotte added a comment -

          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(); }
          Show
          Deryk Sinotte added a comment - 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(); }
          Hide
          Mircea Toma added a comment -

          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.

          Show
          Mircea Toma added a comment - 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.
          Hide
          Mircea Toma added a comment -

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

          Show
          Mircea Toma added a comment - Applied patch recommended by client. The introduced change exits the potential dead-lock after 30 seconds to allow the session to expire.

            People

            • Assignee:
              Mircea Toma
              Reporter:
              Deryk Sinotte
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: