ICEfaces
  1. ICEfaces
  2. ICE-3027

Memory leak in applications with ConcurrentDomViews = true, ICEfaces 1.7

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.7
    • Fix Version/s: 1.7.1
    • Component/s: Framework
    • Labels:
      None
    • Environment:
      ICEfaces, ICEfaces with just-ice, several web-servers

      Description

      Applications with concurrentDomViews = true appear to have a memory leak which is noticeable in a couple of ways.

      Hitting reload on the same page.
      Having a JMeter or other load tool create a View, interact with the application, dispose the View, repeat.

        Activity

        Hide
        Greg Dick added a comment -

        There were a couple of ThreadLocal variables being held in the BridgeFacesContext and PersistentFacesState class. Instances of these classes were accumulating in the HTTP server threads, as well in the scheduled executor threads performing server push. This has been fixed for 1.7.1. Instance of the View are held by these two objects, giving the impression that the View was leaking, but those by themselves are not.

        While not an unbound memory leak, as the number of instances retained would be capped by the number of threads used by the servlet container, that can still be quite a number and an error condition.

        There is a new utility class, com.icesoft.util.ThreadLocalUtility that can perform checks to be sure the ThreadLocal variables are null in outbound code paths. It's both verbose, and only really useful once. To check the outbound Servlet threads, it's easiest to create a Filter instance and just call the checkThreadLocals( String location ) method. Any non-null references will be logged in the error category, while non-null confirmations will be logged if the ThreadLocalUtility has Debug log level.

        The RunnableRender class has a call to this class protected by a TRACE level logging test in com.icesoft.faces.async.RenderHub. Again, these checks can confirm that the ThreadLocals are null, but are intended more for internal testing during development cycles.

        Show
        Greg Dick added a comment - There were a couple of ThreadLocal variables being held in the BridgeFacesContext and PersistentFacesState class. Instances of these classes were accumulating in the HTTP server threads, as well in the scheduled executor threads performing server push. This has been fixed for 1.7.1. Instance of the View are held by these two objects, giving the impression that the View was leaking, but those by themselves are not. While not an unbound memory leak, as the number of instances retained would be capped by the number of threads used by the servlet container, that can still be quite a number and an error condition. There is a new utility class, com.icesoft.util.ThreadLocalUtility that can perform checks to be sure the ThreadLocal variables are null in outbound code paths. It's both verbose, and only really useful once. To check the outbound Servlet threads, it's easiest to create a Filter instance and just call the checkThreadLocals( String location ) method. Any non-null references will be logged in the error category, while non-null confirmations will be logged if the ThreadLocalUtility has Debug log level. The RunnableRender class has a call to this class protected by a TRACE level logging test in com.icesoft.faces.async.RenderHub. Again, these checks can confirm that the ThreadLocals are null, but are intended more for internal testing during development cycles.
        Hide
        Greg Dick added a comment -

        Also, as part of 1.7.1 development we found that there are other paths into the PersistentFacesState's execute() and render() methods (from the dispose+ monitor thread of execution) that have ThreadLocal variables set. There is new code in these methods that checked to see if the PersistentFacesState objects had already been disposed, and if so, threw a FatalRenderingException without clearing the threadLocal instances. These code paths have been fixed in 1.7.1.

        see ICE-3073

        Show
        Greg Dick added a comment - Also, as part of 1.7.1 development we found that there are other paths into the PersistentFacesState's execute() and render() methods (from the dispose+ monitor thread of execution) that have ThreadLocal variables set. There is new code in these methods that checked to see if the PersistentFacesState objects had already been disposed, and if so, threw a FatalRenderingException without clearing the threadLocal instances. These code paths have been fixed in 1.7.1. see ICE-3073
        Hide
        Marat Nemo added a comment -

        This issue is not fixed 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. 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 fixed 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. 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

          People

          • Assignee:
            Unassigned
            Reporter:
            Greg Dick
          • Votes:
            1 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: