Uploaded image for project: 'JBoss Enterprise Application Platform'
  1. JBoss Enterprise Application Platform
  2. JBEAP-21498

[GSS](7.3.z) Caching of managed beans in WebInjectionContainer can cause memory leaks in distributed JSF applications following session timeout

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Critical Critical
    • 7.3.8.CR1, 7.3.8.GA
    • 7.3.6.GA
    • Clustering, JSF
    • None
    • False
    • False
    • +
    • Undefined
    • Hide

      Steps to reproduce of scaling up scenario with the attached jsf-managedbean-test.zip in the local environment:

      1. Extract jsf-managedbean-test.zip and build jsf-test.war

      $ unzip jsf-managedbean-test.zip
$ cd jsf-managedbean-test/
$ mvn clean package

      2. Deploy the generated jsf-test.war to all nodes of your cluster
      3. Start node1
      4. Send many requests to node1 and create new sessions

      ab -n 10000 -c 200 http://node1:8080/jsf-test/index.xhtml

      5. Start node2 and form a cluster
      6. Wait 1 minute for session timeout
      7. Check heap dump of node1

      jmap -dump:live,format=b,file=/tmp/headump.hprof <JAVA_PID>

      or you can do a quick check with "jmap -histo:live" to count the number of remaining JSF Managed Bean (com.example.beans.*ScopedBean)

      jmap -histo:live <JAVA_PID> | grep com.example.beans

      Actual Result: Some JSF Managed Bean (half = around 5000 instances) remains in heap even after session timeout.
      Expected Result: All JSF Managed Bean should be GCed after session timeout.

      Show
      Steps to reproduce of scaling up scenario with the attached jsf-managedbean-test.zip in the local environment: 1. Extract jsf-managedbean-test.zip and build jsf-test.war $ unzip jsf-managedbean-test.zip $ cd jsf-managedbean-test/ $ mvn clean package 2. Deploy the generated jsf-test.war to all nodes of your cluster 3. Start node1 4. Send many requests to node1 and create new sessions ab -n 10000 -c 200 http: //node1:8080/jsf-test/index.xhtml 5. Start node2 and form a cluster 6. Wait 1 minute for session timeout 7. Check heap dump of node1 jmap -dump:live,format=b,file=/tmp/headump.hprof <JAVA_PID> or you can do a quick check with "jmap -histo:live" to count the number of remaining JSF Managed Bean (com.example.beans.*ScopedBean) jmap -histo:live <JAVA_PID> | grep com.example.beans Actual Result: Some JSF Managed Bean (half = around 5000 instances) remains in heap even after session timeout. Expected Result: All JSF Managed Bean should be GCed after session timeout.

      Distributed web session ownership changes as a consequence of scaling up (or down) can result in session timouts, and their correspond events being triggered on a different member than the once that last handled requests for that session. Consequently, it is never safe for the server (nor application) to cache session scoped objects separately from references within the HttpSession itself.

      org.jboss.as.web.common.WebInjectionContainer caches references to all created managed beans and their managed references in order to call ManagedReference.release(). This caching doesn't appear to be necessary - and causes a memory leak in the above scenario.

        1. jsf-managedbean-test.zip
          17 kB

              pferraro@redhat.com Paul Ferraro
              pferraro@redhat.com Paul Ferraro
              Votes:
              0 Vote for this issue
              Watchers:
              7 Start watching this issue

                Created:
                Updated:
                Resolved: