javaserverfaces
  1. javaserverfaces
  2. JAVASERVERFACES-1940

Potentional memory leaks in CompositeComponentTagHandler and ContextualCompositeMethodExpression

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 2.1.0
    • Fix Version/s: current
    • Component/s: None
    • Labels:
      None
    • Status Whiteboard:
      Hide

      size_medium importance_large

      Show
      size_medium importance_large

      Description

      Both the tag handler and teh method expression keep a UIComponent refernce in a local ivar.

      CompositeComponentTagHandler:
      As it seems the tag handler for the composite component exists only once in the system, that is a less big problem from the memory aspect. But still it keeps the UIComponent representing the composite component (and its children) from the last request (what about concurrent requests using the same composite component tag handler?). The ivar seems to make that tag handler not multi-thread-save.

      ContextualCompositeMethodExpression:
      This method expression keeps a reference to the cc UIComponent - and it ends up in the state (also with partial state saving). Including the cc UIComponent reference and it's children.

      The attached patch removes the local ivar references on both.

      1. mojarra_cc_leak.patch
        6 kB
        Hanspeter Duennenberger

        Activity

        Hide
        rogerk added a comment -

        triage

        Show
        rogerk added a comment - triage
        Hide
        Daniel Lichtenberger added a comment -

        I stumbled upon the same issue in CompositeComponentTagHandler because it also increases the memory usage quite drastically. At least in Mojarra 2.0.2, the tag handlers are created per view ID - so if you have, say, 50 front-end pages that all use the same composite component set, 50 instances of these components end up being referenced in the DefaultFaceletFactory. Just by removing the cc reference in CompositeComponentTagHandler the memory used per view definition shrank from 1-2 MB to less than 50k. We're using the patch by dueni now and haven't seen any issues so far.

        Show
        Daniel Lichtenberger added a comment - I stumbled upon the same issue in CompositeComponentTagHandler because it also increases the memory usage quite drastically. At least in Mojarra 2.0.2, the tag handlers are created per view ID - so if you have, say, 50 front-end pages that all use the same composite component set, 50 instances of these components end up being referenced in the DefaultFaceletFactory. Just by removing the cc reference in CompositeComponentTagHandler the memory used per view definition shrank from 1-2 MB to less than 50k. We're using the patch by dueni now and haven't seen any issues so far.
        Hide
        rogerk added a comment -

        Unfortunately this patch breaks out system tests. The example test includes a SystemEvent.
        See attachment.

        Show
        rogerk added a comment - Unfortunately this patch breaks out system tests. The example test includes a SystemEvent. See attachment.
        Hide
        Ed Burns added a comment -

        Increase importance to importance_large

        Show
        Ed Burns added a comment - Increase importance to importance_large
        Hide
        Hanspeter Duennenberger added a comment -

        Hi Roger,

        I think this one is a duplicate/related issue to JAVASERVERFACES-1988 - which you solved recently. I think this one is then resolved too.

        regards
        Hanspeter

        Show
        Hanspeter Duennenberger added a comment - Hi Roger, I think this one is a duplicate/related issue to JAVASERVERFACES-1988 - which you solved recently. I think this one is then resolved too. regards Hanspeter
        Hide
        rogerk added a comment -

        Duplicate to already resolved issue.

        Show
        rogerk added a comment - Duplicate to already resolved issue.
        Hide
        Daniel Lichtenberger added a comment -

        Has this really been fixed? I'm running into this issue again with Glassfish 3.1.2 and Mojarra 2.1.6.

        ContextualCompositeMethodExpression#cc has been marked transient which helps when the view state is serialized (JAVASERVERFACES-1943). But every time a ContextualCompositeMethodExpression ends up in the viewstate (e.g. through a method attribute of a composite component), the entire component tree is pulled into the viewstate (and thus the user session)!

        I have no idea how to fix the SystemEvent issue, but putting UIComponents into the viewstate is wrong...

        Show
        Daniel Lichtenberger added a comment - Has this really been fixed? I'm running into this issue again with Glassfish 3.1.2 and Mojarra 2.1.6. ContextualCompositeMethodExpression#cc has been marked transient which helps when the view state is serialized ( JAVASERVERFACES-1943 ). But every time a ContextualCompositeMethodExpression ends up in the viewstate (e.g. through a method attribute of a composite component), the entire component tree is pulled into the viewstate (and thus the user session)! I have no idea how to fix the SystemEvent issue, but putting UIComponents into the viewstate is wrong...
        Hide
        Hanspeter Duennenberger added a comment -

        Hi Daniel.

        I agree that the transient cc attribute in ContextualCompositeMethodExpression is a problem when this method expression ends up in viewstate. Well, it shouldn't, but apparently you have an example where this happens. Unfortunately we did not find a way to prevent to have cc initialized on creation of ContextualCompositeMethodExpression.

        I think it would be best to open a new issue regarding this and add your example or even better a small example how this can be reproduced.

        Regards
        Hanspeter

        Show
        Hanspeter Duennenberger added a comment - Hi Daniel. I agree that the transient cc attribute in ContextualCompositeMethodExpression is a problem when this method expression ends up in viewstate. Well, it shouldn't, but apparently you have an example where this happens. Unfortunately we did not find a way to prevent to have cc initialized on creation of ContextualCompositeMethodExpression. I think it would be best to open a new issue regarding this and add your example or even better a small example how this can be reproduced. Regards Hanspeter
        Hide
        ova2 added a comment -

        I can confirm, the issue with Memory Leak ist still open in Mojarra 2.2.x. We have anaylized the memory with Eclipse Memory Analyzer and seen that the session is growing rapidly in last tests (up to ca. 2 GB after 15 min. with ca. 6000 users). The problem is somewhere in com.sun.faces.util.LRUMap. And yes, we have many composite components. Bad issue, which is "no go" for a bug internet application.

        Why did you make this issue as duplicate? Users can not understand this decision (see http://stackoverflow.com/questions/19310154/jsf-leaking-memory-through-el-and-composite-components)

        Show
        ova2 added a comment - I can confirm, the issue with Memory Leak ist still open in Mojarra 2.2.x. We have anaylized the memory with Eclipse Memory Analyzer and seen that the session is growing rapidly in last tests (up to ca. 2 GB after 15 min. with ca. 6000 users). The problem is somewhere in com.sun.faces.util.LRUMap. And yes, we have many composite components. Bad issue, which is "no go" for a bug internet application. Why did you make this issue as duplicate? Users can not understand this decision (see http://stackoverflow.com/questions/19310154/jsf-leaking-memory-through-el-and-composite-components )

          People

          • Assignee:
            rogerk
            Reporter:
            Hanspeter Duennenberger
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: