ICEfaces
  1. ICEfaces
  2. ICE-4717

Simplify thread blocking code

    Details

    • Type: Bug Bug
    • 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:
      server

      Description

      Through studying the semaphore logic of the Thread Blocking environment a race condition was discovered causing another thread leak. Due to time-slicing it could happen that the Servlet Container supplied thread decides to use the semaphore logic to block and another thread trying to send a response decides the semaphore logic is not in effect yet and will not release the semaphore eventually. This causes the Servlet Container supplied thread to block and never gets unblocked.

          public void respondWith(final ResponseHandler handler) throws Exception {
              try {
                  super.respondWith(handler);
              } finally {
                  if (semaphore == null) {
      --> timeslicing
                      blockResponse = false;
                  } else {
                      semaphore.release();
                  }
              }
          }

          public void blockUntilRespond() throws InterruptedException {
              if (blockResponse) {
      --> timeslicing
                  semaphore = new Semaphore(1);
                  semaphore.acquire();
                  boolean acquired = semaphore.tryAcquire(TIMEOUT, TimeUnit.MINUTES);
                  if (acquired) {
                      semaphore.release();
                  } else {
                      // log some warning
                      semaphore.release();
                  }
              }
          }

      The thread blocking code (ThreadBlockingAdaptingServlet) should use immutable objects to avoid any synchronization issues.

        Activity

        Repository Revision Date User Message
        ICEsoft Public SVN Repository #19071 Wed Jul 15 16:43:57 MDT 2009 mircea.toma ICE-4717 Simplify interaction with semaphore. Make ThreadBlockingRequestResponse immutable.
        Files Changed
        Commit graph MODIFY /icefaces/trunk/icefaces/core/src/com/icesoft/faces/webapp/http/servlet/ThreadBlockingAdaptingServlet.java
        Mircea Toma created issue -
        Mircea Toma made changes -
        Field Original Value New Value
        Salesforce Case []
        Fix Version/s 1.8.2 [ 10190 ]
        Assignee Mircea Toma [ mircea.toma ]
        Hide
        Mircea Toma added a comment -

        Simplify interaction with semaphore. Make ThreadBlockingRequestResponse immutable.

        Show
        Mircea Toma added a comment - Simplify interaction with semaphore. Make ThreadBlockingRequestResponse immutable.
        Mircea Toma made changes -
        Status Open [ 1 ] 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
        Repository Revision Date User Message
        ICEsoft Public SVN Repository #19087 Mon Jul 20 10:45:42 MDT 2009 ted.goddard TimeUnit.MINUTES from JDK 1.6 and backport-concurrent not available on JDK 1.5 (ICE-4717)
        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 The thread blocking code (ThreadBlockingAdaptingServlet) should use immutable objects to avoid any synchronization issues. Through studying the semaphore logic of the Thread Blocking environment a race condition was discovered causing another thread leak. Due to time-slicing it could happen that the Servlet Container supplied thread decides to use the semaphore logic to block and another thread trying to send a response decides the semaphore logic is not in effect yet and will not release the semaphore eventually. This causes the Servlet Container supplied thread to block and never gets unblocked.

            public void respondWith(final ResponseHandler handler) throws Exception {
                try {
                    super.respondWith(handler);
                } finally {
                    if (semaphore == null) {
        --> timeslicing
                        blockResponse = false;
                    } else {
                        semaphore.release();
                    }
                }
            }

            public void blockUntilRespond() throws InterruptedException {
                if (blockResponse) {
        --> timeslicing
                    semaphore = new Semaphore(1);
                    semaphore.acquire();
                    boolean acquired = semaphore.tryAcquire(TIMEOUT, TimeUnit.MINUTES);
                    if (acquired) {
                        semaphore.release();
                    } else {
                        // log some warning
                        semaphore.release();
                    }
                }
            }

        The thread blocking code (ThreadBlockingAdaptingServlet) should use immutable objects to avoid any synchronization issues.
        Ken Fyten made changes -
        Fix Version/s 1.8.2-RC1 [ 10210 ]
        Ken Fyten made changes -
        Status Resolved [ 5 ] Closed [ 6 ]

          People

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

            Dates

            • Created:
              Updated:
              Resolved: