ICEfaces
  1. ICEfaces
  2. ICE-5348

simplify ICEfaces threading behavior

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0-Alpha2
    • Fix Version/s: 2.0-Beta1, 2.0.0
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      ICEfaces 2.0, Tomcat 6.0.24

      Description


      Tomcat 6.0.24 reports the following during shutdown. If possible, ICEfaces 2.0 should not make use of any Threads or ThreadLocal variables, so these should be looked at in detail.

      SEVERE: A web application appears to have started a thread named [Session Monitor] but has failed to stop it. This is very likely to create a memory leak.
      Feb 3, 2010 10:27:23 AM org.apache.catalina.loader.WebappClassLoader clearReferencesThreads
      SEVERE: A web application appears to have started a thread named [Monitor Runner] but has failed to stop it. This is very likely to create a memory leak.
      Feb 3, 2010 10:27:23 AM org.apache.catalina.loader.WebappClassLoader clearThreadLocalMap
      SEVERE: A web application created a ThreadLocal with key of type [com.icesoft.faces.webapp.http.servlet.MainServlet.CurrentContextPath] (value [com.icesoft.faces.webapp.http.servlet.MainServlet$CurrentContextPath@6d0d1642]) and a value of type [null] (value [null]) but failed to remove it when the web application was stopped. To prevent a memory leak, the ThreadLocal has been forcibly removed.

        Issue Links

          Activity

          Hide
          Ted Goddard added a comment -

          Make use of timestamps rather than timer threads. If resources need to be cleaned up after a time interval, it is sufficient to either allow the session timeout to handle the cleanup or perform the cleanup on the next available request when the timestamp has been exceeded.

          Show
          Ted Goddard added a comment - Make use of timestamps rather than timer threads. If resources need to be cleaned up after a time interval, it is sufficient to either allow the session timeout to handle the cleanup or perform the cleanup on the next available request when the timestamp has been exceeded.
          Hide
          Mircea Toma added a comment -

          Removed CurrentContextPath thread local since no other part of the code base is using it anymore. Also removed the related but unused code.

          Show
          Mircea Toma added a comment - Removed CurrentContextPath thread local since no other part of the code base is using it anymore. Also removed the related but unused code.
          Hide
          Marat Nemo added a comment -

          This issue is not completely addressed actually. Please take a look at my post here for a way to address this: http://www.icefaces.org/JForum/posts/list/19497.page

          You could also flip the fix around and require applications to register method/class signatures that are allowed to have parent's thread local (PersistenFacesState) be copied into the child's thread local map. Or have a factory method that would produce a new thread instance, inside of which you would automatically register this thread as one that can have its parent threadlocals copied into its own threadlocal map.

          This way any third party library spanning threads bellow the application code will never be getting references to PersistenFacesState, etc in their own child thread's thread local

          Show
          Marat Nemo added a comment - This issue is not completely addressed actually. Please take a look at my post here for a way to address this: http://www.icefaces.org/JForum/posts/list/19497.page You could also flip the fix around and require applications to register method/class signatures that are allowed to have parent's thread local (PersistenFacesState) be copied into the child's thread local map. Or have a factory method that would produce a new thread instance, inside of which you would automatically register this thread as one that can have its parent threadlocals copied into its own threadlocal map. This way any third party library spanning threads bellow the application code will never be getting references to PersistenFacesState, etc in their own child thread's thread local
          Hide
          Mircea Toma added a comment -

          PersistenFacesState does not exist anymore in ICEfaces 2 nor the corresponding thread local.

          Show
          Mircea Toma added a comment - PersistenFacesState does not exist anymore in ICEfaces 2 nor the corresponding thread local.

            People

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

              Dates

              • Created:
                Updated:
                Resolved: