Uploaded image for project: 'Weld'
  1. Weld
  2. WELD-2750

Partial bean-graph destruction, using: dependent, singleton and predestroy with the se-container (probably memory leak)

XMLWordPrintable

    • Icon: Bug Bug
    • Resolution: Done
    • Icon: Major Major
    • 5.1.1.SP2
    • 3.1.9.Final, 4.0.3.Final, 5.1.1.SP1
    • Scopes & Contexts
    • None
    • Hide

      to execute a check, do the following steps:

      1. download the attached maven project
      2. open terminal
      3. unzip the project
      4. cd <project>
      5. run one of the five available check (more to follow)
      6. open visualvm
      7. connect to the running jvm
        1. monitor
          1. perform gc
          2. heap dump
            1. class by number of instances
            2. filter by "maybe.beans"
            3. collect data
      8. back to the terminal
      9. press <enter>
      10. back to visualvm
        1. monitor
          1. perform gc
          2. heap dump
            1. class by number of instances
            2. filter by "maybe.beans"
            3. collect data
      11. back to the terminal
      12. press <enter>
      13. back to visualvm
        1. monitor
          1. perform gc
          2. heap dump
            1. class by number of instances
            2. filter by "maybe.beans"
            3. collect data
      14. back to the terminal
      15. press <enter>
      16. done!

      to carry out a checks, use: jdk1.8, maven 3.8.5 e visualvm 2.1.6
      to run a check:

      mvn clean compile package
    exec:exec
    -Dexec.args="-Dorg.jboss.logging.provider=slf4j -cp %classpath an.issue.maybe.Weld3 [-pojo <name=PojoWithPojoWithPredestroyPojo>] [-i <n=1>]"

name -- [PredestroyPojo, PojoWithSingletonPojo, PojoWithPojowithSingletonPojo, PojoWithPredestroyPojo, PojoWithPojowithPredestroyPojo]

      every check take place in the following way:

      1. creation of the se-container
      2. creation of one or more instances of the specified bean
      3. <pause>
      4. destruction of the bean instances
      5. <pause>
      6. destruction of the se-container
      7. <pause>

      during the execution of points [2,4,6] a heapdump is produced to identify "not reclaimed" instances and check if these match the expected results

      —

      Check: PojoWithPojoWithPredestroyPojo
      Instances: 100
      Status: FAILURE

      Bean
      Create
      Destroy
      Close
      an.issue.maybe.beans.AbstractPojo 0 0 0
      an.issue.maybe.beans.AbstractPojo$1 1 1 1
      an.issue.maybe.beans.PojoWithPojoWithPredestroyPojo 100 0 0
      an.issue.maybe.beans.PojoWithPojoWithSingletonPojo 0 0 0
      an.issue.maybe.beans.PojoWithPredestroyPojo 100 1* 0
      an.issue.maybe.beans.PojoWithSingletonPojo 0 0 0
      an.issue.maybe.beans.PredestroyPojo 100 1* 0
      an.issue.maybe.beans.SingletonPojo 1 1 0

      *) not reclaimed instances ...is this a memory leak?

      Show
      to execute a check, do the following steps: download the attached maven project open terminal unzip the project cd <project> run one of the five available check (more to follow) open visualvm connect to the running jvm monitor perform gc heap dump class by number of instances filter by "maybe.beans" collect data back to the terminal press <enter> back to visualvm monitor perform gc heap dump class by number of instances filter by "maybe.beans" collect data back to the terminal press <enter> back to visualvm monitor perform gc heap dump class by number of instances filter by "maybe.beans" collect data back to the terminal press <enter> done! to carry out a checks, use: jdk1.8, maven 3.8.5 e visualvm 2.1.6 to run a check: mvn clean compile package exec:exec -Dexec.args= "-Dorg.jboss.logging.provider=slf4j -cp %classpath an.issue.maybe.Weld3 [-pojo <name=PojoWithPojoWithPredestroyPojo>] [-i <n=1>]" name -- [PredestroyPojo, PojoWithSingletonPojo, PojoWithPojowithSingletonPojo, PojoWithPredestroyPojo, PojoWithPojowithPredestroyPojo] every check take place in the following way: creation of the se-container creation of one or more instances of the specified bean <pause> destruction of the bean instances <pause> destruction of the se-container <pause> during the execution of points [2,4,6] a heapdump is produced to identify "not reclaimed" instances and check if these match the expected results — Check: PojoWithPojoWithPredestroyPojo Instances: 100 Status: FAILURE Bean Create Destroy Close an.issue.maybe.beans .AbstractPojo 0 0 0 an.issue.maybe.beans .AbstractPojo$1 1 1 1 an.issue.maybe.beans .PojoWithPojoWithPredestroyPojo 100 0 0 an.issue.maybe.beans .PojoWithPojoWithSingletonPojo 0 0 0 an.issue.maybe.beans .PojoWithPredestroyPojo 100 1 * 0 an.issue.maybe.beans .PojoWithSingletonPojo 0 0 0 an.issue.maybe.beans .PredestroyPojo 100 1 * 0 an.issue.maybe.beans .SingletonPojo 1 1 0 *) not reclaimed instances ...is this a memory leak?

      this bean-graph is composed of beans using the default scope that is the pseudo-scope dependent:

      the programmatic creation of the root instance (bean-a), involves the creation of the entire bean-graph; likewise, its destruction involves the destruction of the entire bean-graph as the life cycle of each bean is established by its parent

      however, it seems that the programmtic creation of a bean-graph which contains the annotations:
      dependent, singleton and predestroy
      cause a memory leak in java-se enviroment using weld-3.1.9.final

      there are five checks available into the attached project:

      a PredestroyPojo SUCCESS
      b PojoWithSingletonPojo SUCCESS
      c PojoWithPojoWithSingletonPojo SUCCESS
      d PojoWithPredestroyPojo FAILURE
      e PojoWithPojowithPredestroyPojo FAILURE

      the checks [d, e] have shown that the bean-graph does not come successfully destroyed, as some instances are bound to the singleton context (as parent dependent instances)

      moreover, by creating multiple instance of the same bean, it emerges that the destruction of the bean-graph, for some classes, occurs on all instances except one

        1. image-2023-08-02-15-54-28-299.png
          4 kB
          Fabio Ferrante
        2. screenshot-1.png
          4 kB
          Fabio Ferrante
        3. screenshot-2.png
          8 kB
          Fabio Ferrante

              manovotn Matěj Novotný
              forgr Fabio Ferrante (Inactive)
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated:
                Resolved: