ICEfaces
  1. ICEfaces
  2. ICE-5050

tabChangeListener tag memory leak

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.8.2
    • Fix Version/s: 1.8.2-EE-Beta, 1.8.2-EE-GA, 1.8.3
    • Component/s: ICE-Components
    • Labels:
      None
    • Environment:
      Facelets, and possibly JSP.

      Description

      When a panelTabSet uses the tabChangeListener attribute, to an existing bean, there is no memory leak, but when it uses the tabChangeListener child tag, which allocated new objects itself, there is a memory leak.

        Activity

        Hide
        Mark Collette added a comment -

        Subversion 19488
        icefaces\component\src\com\icesoft\faces\component\paneltabset\PanelTabSet.java

        Initial investigation showed that TabChangeListener instances were being continually added, on every lifecycle. Assuming the application class that implements that interface holds onto some memory, this would explain the memory leak. Since the test applications uses Facelets, the TabChangeListenerHandler was investigated, to see if it was the culprit, for adding the TabChangeListener instances. It was proven to not be the culprit, as it was only adding the initial instance, and not any of the subsequent ones. Then, the method responsible for adding listeners to the component was checked, in case the application, or something else, was adding them. This was shown to not be happening. Finally, the state saving and restoring mechanism was checked, since it had some suspicious looking code for adding listeners back. That proved to be the cause of the additions.

        It was not exactly obvious how to change the state restoration code, since there turned out to be 3 different scenarios for state saving:

        1. With JSF 1.1, state saving is not done, and the component tree and all listeners are left unchanged.
        2. With some versions of JSF 1.2, our code keeps the component tree, but still calls the state saving and restoration code on them, allowing for misbehaving code to overgrow lists, as it adds new instances to old ones.
        3. With other versions of JSF 1.2, our code removes the component tree, and starts fresh, so that the state restoration code only has new instances to add to the lists.

        An integrated approach was found, to keep the optimisation of list re-use, for when the component tree was kept from before, yet not add duplicates.

        Show
        Mark Collette added a comment - Subversion 19488 icefaces\component\src\com\icesoft\faces\component\paneltabset\PanelTabSet.java Initial investigation showed that TabChangeListener instances were being continually added, on every lifecycle. Assuming the application class that implements that interface holds onto some memory, this would explain the memory leak. Since the test applications uses Facelets, the TabChangeListenerHandler was investigated, to see if it was the culprit, for adding the TabChangeListener instances. It was proven to not be the culprit, as it was only adding the initial instance, and not any of the subsequent ones. Then, the method responsible for adding listeners to the component was checked, in case the application, or something else, was adding them. This was shown to not be happening. Finally, the state saving and restoring mechanism was checked, since it had some suspicious looking code for adding listeners back. That proved to be the cause of the additions. It was not exactly obvious how to change the state restoration code, since there turned out to be 3 different scenarios for state saving: 1. With JSF 1.1, state saving is not done, and the component tree and all listeners are left unchanged. 2. With some versions of JSF 1.2, our code keeps the component tree, but still calls the state saving and restoration code on them, allowing for misbehaving code to overgrow lists, as it adds new instances to old ones. 3. With other versions of JSF 1.2, our code removes the component tree, and starts fresh, so that the state restoration code only has new instances to add to the lists. An integrated approach was found, to keep the optimisation of list re-use, for when the component tree was kept from before, yet not add duplicates.

          People

          • Assignee:
            Unassigned
            Reporter:
            Mark Collette
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: