ICEfaces
  1. ICEfaces
  2. ICE-2740

Stuck thread after session expiry

          Details

          • Type: Bug Bug
          • Status: Closed
          • Priority: Major Major
          • Resolution: Fixed
          • Affects Version/s: 1.6.2, 1.7Beta1
          • Fix Version/s: 1.7RC1, 1.7
          • Component/s: Framework
          • Labels:
            None
          • Environment:
            ICEfaces 1.6.2 / 1.7-Beta 1, WebLogic Server 9.2 / JBoss AS 4.0.3.SP1

            Description

            I tested both WebLogic Server 9.2.MP2 and JBoss AS 4.0.3.SP1 using both Safari and Firefox. After the session is expired the ThreadBlockingAdaptingServlet nicely gets its shutdown() method invoked, however its service(...) method gets invoked right after which kicks off another blockUntilRespond() cycle. Within this method the semaphore.acquire() method is invoked twice. The second invocation of this method never get unblocked though, resulting in the stuck thread issue.

            I was only able to reproduce this using the head branch, not using 1.6.2.

              Issue Links

              depends on

              Bug - A problem which impairs or prevents the functions of the product. ICE-2731 Session already invalidated with seam logout

              • Major - Major loss of function.
              • Closed

                Activity

                Ascending order - Click to sort in descending order
                Hide
                Permalink
                Jack Van Ooststroom added a comment -

                Assigning to Mircea

                Show
                Jack Van Ooststroom added a comment - Assigning to Mircea
                Hide
                Permalink
                Mircea Toma added a comment -

                The refactoring done for ICE-2731 fixed this issue.

                Show
                Mircea Toma added a comment - The refactoring done for ICE-2731 fixed this issue.
                Hide
                Permalink
                Mircea Toma added a comment -

                Reopening this issue.
                The stuck thread is actually the blocking connection's request thread which we release only when the session expires. This behavior is not optimal since the thread is blocked for a long time.

                Show
                Mircea Toma added a comment - Reopening this issue. The stuck thread is actually the blocking connection's request thread which we release only when the session expires. This behavior is not optimal since the thread is blocked for a long time.
                Hide
                Permalink
                Mircea Toma added a comment -

                Add patch for 1.6.1 branch.

                Show
                Mircea Toma added a comment - Add patch for 1.6.1 branch.
                Hide
                Permalink
                Mircea Toma added a comment -

                Monitor blocking connection. Respond with no-op message after a determined period of inactivity so that request threads are released.

                Show
                Mircea Toma added a comment - Monitor blocking connection. Respond with no-op message after a determined period of inactivity so that request threads are released.
                Hide
                Permalink
                Mircea Toma added a comment -

                The blocking connection is unblocked after a period of inactivity, while previously it was unblocked only when the session expired.
                This period of inactivity can be configured with
                'com.icesoft.faces.blockingConnectionTimeout' context parameter. Its default
                value is 30000 (milliseconds). In general this value should be larger than the
                heartbeat interval to avoid unnecessary traffic (unblocking and blocking without
                any updates available).

                Show
                Mircea Toma added a comment - The blocking connection is unblocked after a period of inactivity, while previously it was unblocked only when the session expired. This period of inactivity can be configured with 'com.icesoft.faces.blockingConnectionTimeout' context parameter. Its default value is 30000 (milliseconds). In general this value should be larger than the heartbeat interval to avoid unnecessary traffic (unblocking and blocking without any updates available).
                Hide
                Permalink
                Ken Fyten added a comment -

                This needs to be backported to the 1.6 branch (1.6.3).

                Show
                Ken Fyten added a comment - This needs to be backported to the 1.6 branch (1.6.3).
                Hide
                Permalink
                Mircea Toma added a comment -

                Backported to 1.6 branch.

                Show
                Mircea Toma added a comment - Backported to 1.6 branch.
                Hide
                Permalink
                Jarkko Lietolahti added a comment -

                Running IceFaces 1.7.2 SP 1 and seeing the same message in log.
                [com.icesoft.util.MonitorRunner] Failed to run monitor: null

                2008-12-14 07:58:48,918 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null
                2008-12-14 07:58:58,921 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null
                2008-12-14 07:59:09,430 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null
                2008-12-14 07:59:19,434 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null
                2008-12-14 07:59:29,437 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null
                2008-12-14 07:59:39,441 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null
                2008-12-14 07:59:49,675 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null
                2008-12-14 07:59:59,678 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null
                2008-12-14 08:00:09,683 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null
                2008-12-14 08:00:19,686 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null
                2008-12-14 08:00:29,989 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null
                2008-12-14 08:00:39,992 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null
                2008-12-14 08:00:49,996 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null
                2008-12-14 08:01:00,000 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null
                2008-12-14 08:01:10,306 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null
                2008-12-14 08:01:20,310 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null
                2008-12-14 08:01:30,313 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null
                2008-12-14 08:01:40,317 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null
                2008-12-14 08:01:50,692 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null
                2008-12-14 08:02:00,696 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null
                2008-12-14 08:02:10,699 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null
                2008-12-14 08:02:20,702 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null
                2008-12-14 08:02:31,025 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null
                2008-12-14 08:02:41,028 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null
                2008-12-14 08:02:51,031 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null
                2008-12-14 08:03:01,035 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null
                2008-12-14 08:03:11,387 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: nul

                I think something (Tomcat,icefaces,JVM) is still leaking somewhere. This is because during load testing JVM's CMS Old Gen is commited to the max and GC is unable free any memory. Best JDK so fas has been the latest JDK 1.7.0 snapshot, it manages to free some memory where others (JDK 1.6) stay totally stuck.

                Show
                Jarkko Lietolahti added a comment - Running IceFaces 1.7.2 SP 1 and seeing the same message in log. [com.icesoft.util.MonitorRunner] Failed to run monitor: null 2008-12-14 07:58:48,918 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null 2008-12-14 07:58:58,921 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null 2008-12-14 07:59:09,430 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null 2008-12-14 07:59:19,434 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null 2008-12-14 07:59:29,437 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null 2008-12-14 07:59:39,441 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null 2008-12-14 07:59:49,675 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null 2008-12-14 07:59:59,678 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null 2008-12-14 08:00:09,683 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null 2008-12-14 08:00:19,686 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null 2008-12-14 08:00:29,989 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null 2008-12-14 08:00:39,992 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null 2008-12-14 08:00:49,996 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null 2008-12-14 08:01:00,000 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null 2008-12-14 08:01:10,306 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null 2008-12-14 08:01:20,310 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null 2008-12-14 08:01:30,313 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null 2008-12-14 08:01:40,317 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null 2008-12-14 08:01:50,692 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null 2008-12-14 08:02:00,696 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null 2008-12-14 08:02:10,699 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null 2008-12-14 08:02:20,702 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null 2008-12-14 08:02:31,025 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null 2008-12-14 08:02:41,028 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null 2008-12-14 08:02:51,031 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null 2008-12-14 08:03:01,035 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: null 2008-12-14 08:03:11,387 WARN [com.icesoft.util.MonitorRunner] Failed to run monitor: nul I think something (Tomcat,icefaces,JVM) is still leaking somewhere. This is because during load testing JVM's CMS Old Gen is commited to the max and GC is unable free any memory. Best JDK so fas has been the latest JDK 1.7.0 snapshot, it manages to free some memory where others (JDK 1.6) stay totally stuck.
                Hide
                Permalink
                Joanne Bai added a comment -

                QA cannot reproduce it on 1.6 branch subversion 18986.

                Test steps:
                1- build component showcase; replace jsf jars with myfaces jars
                2- deploy the modified showcase war file to webLogic 10.3
                3- load Showcase on FF 3; interact with Progress bar a bit and leave the page untouched till session is timeout
                4- check the server log. No Stuck Thread error is found.

                Show
                Joanne Bai added a comment - QA cannot reproduce it on 1.6 branch subversion 18986. Test steps: 1- build component showcase; replace jsf jars with myfaces jars 2- deploy the modified showcase war file to webLogic 10.3 3- load Showcase on FF 3; interact with Progress bar a bit and leave the page untouched till session is timeout 4- check the server log. No Stuck Thread error is found.

                  People

                  • Assignee:
                    Unassigned
                    Reporter:
                    Jack Van Ooststroom
                  • Votes:
                    0 Vote for this issue
                    Watchers:
                    1 Start watching this issue

                    Dates

                    • Created:
                      Updated:
                      Resolved: