ICEfaces
  1. ICEfaces
  2. ICE-4688

Add a timeout to the semaphore acquire invocation and log an error message after the timeout has been reached.

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.8.1
    • Fix Version/s: 1.8.2-RC1, 1.8.2
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      ICEfaces Core, ICEfaces Push Server

      Description

      Currently, when using the semaphore logic, trying to acquire the semaphore is done without specifying a timeout. In case of a thread leak the Servlet Container supplied thread will block indefinitely. Introducing a timeout on the acquire call provides a failsafe mechanism. On timeout a warning message should be logged stating that a request has been pending for the specified timeout, including details on the request. Though this avoids a particular thread leak in this area, the underlying problem causing this to happen still needs to be addressed in the future.

      Basically, in the ThreadBlockingAdaptingServlet the Semaphore.acquire() method is invoked which blocks the container thread. This semaphore should be released in a timely fashion. However, in case it does not get released, it should not get stuck in the acquire() invocation for the remainder of the JVM lifespan. We should introduce a timeout and an error message to inform of the situation.

        Activity

        Repository Revision Date User Message
        ICEsoft Public SVN Repository #19051 Thu Jul 09 14:24:06 MDT 2009 jack.van.ooststroom Fixed JIRA ICE-4688 : Add a timeout to the semaphore acquire invocation and log an error message after the timeout has been reached.
        Files Changed
        Commit graph MODIFY /icefaces/trunk/icefaces/core/src/com/icesoft/faces/webapp/http/servlet/ThreadBlockingAdaptingServlet.java
        Jack Van Ooststroom created issue -
        Jack Van Ooststroom made changes -
        Field Original Value New Value
        Assignee Jack Van Ooststroom [ jack.van.ooststroom ]
        Jack Van Ooststroom made changes -
        Status Open [ 1 ] In Progress [ 3 ]
        Hide
        Jack Van Ooststroom added a comment -

        Changed Fix Version(s) to 1.8.2

        Show
        Jack Van Ooststroom added a comment - Changed Fix Version(s) to 1.8.2
        Jack Van Ooststroom made changes -
        Salesforce Case []
        Fix Version/s 1.8.2 [ 10190 ]
        Hide
        Jack Van Ooststroom added a comment -

        The ThreadBlockingAdaptingServlet is now using a timeout of 10 minutes on the acquire() invocation. If the acquire failed after 10 minutes an error messages is logged with details on the pending request. Marking this one as FIXED.

        Show
        Jack Van Ooststroom added a comment - The ThreadBlockingAdaptingServlet is now using a timeout of 10 minutes on the acquire() invocation. If the acquire failed after 10 minutes an error messages is logged with details on the pending request. Marking this one as FIXED.
        Jack Van Ooststroom made changes -
        Status In Progress [ 3 ] Resolved [ 5 ]
        Resolution Fixed [ 1 ]
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #19082 Fri Jul 17 09:09:14 MDT 2009 mircea.toma ICE-4688, ICE-4717 Forward-port changes.
        Files Changed
        Commit graph MODIFY /icefaces/scratchpads/glimmer/core/src/main/java/org/icefaces/push/servlet/ThreadBlockingAdaptingServlet.java
        Jack Van Ooststroom made changes -
        Salesforce Case []
        Description Introduce a safety net in case of hanging threads when using thread blocking. Currently in ThreadBlockingAdaptingServlet the Semaphore.acquire() method is invoked which blocks the container thread. This semaphore should be released in a timely fashion. However, in case it does not get released, it should not get stuck in the acquire() invocation for the remainder of the JVM lifespan. We should introduce a timeout and an error message to inform of the situation. Currently, when using the semaphore logic, trying to acquire the semaphore is done without specifying a timeout. In case of a thread leak the Servlet Container supplied thread will block indefinitely. Introducing a timeout on the acquire call provides a failsafe mechanism. On timeout a warning message should be logged stating that a request has been pending for the specified timeout, including details on the request. Though this avoids a particular thread leak in this area, the underlying problem causing this to happen still needs to be addressed in the future.

        Basically, in the ThreadBlockingAdaptingServlet the Semaphore.acquire() method is invoked which blocks the container thread. This semaphore should be released in a timely fashion. However, in case it does not get released, it should not get stuck in the acquire() invocation for the remainder of the JVM lifespan. We should introduce a timeout and an error message to inform of the situation.
        Ken Fyten made changes -
        Fix Version/s 1.8.2-RC1 [ 10210 ]
        Jack Van Ooststroom made changes -
        Environment ICEfaces Core ICEfaces Core, ICEfaces Push Server
        Salesforce Case []
        Ken Fyten made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #21620 Wed Jun 02 10:26:28 MDT 2010 ted.goddard backport of semaphore timeout (ICE-4688)
        Files Changed
        Commit graph MODIFY /icefaces/scratchpads/patches/SF8080/icefaces/core/src/com/icesoft/faces/webapp/http/servlet/ThreadBlockingAdaptingServlet.java
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #21621 Wed Jun 02 10:29:54 MDT 2010 ted.goddard correcting test time interval (ICE-4688)
        Files Changed
        Commit graph MODIFY /icefaces/scratchpads/patches/SF8080/icefaces/core/src/com/icesoft/faces/webapp/http/servlet/ThreadBlockingAdaptingServlet.java

          People

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

            Dates

            • Created:
              Updated:
              Resolved: