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

SimpleServiceRegistry can be leaking services on BeanDeployment creation

XMLWordPrintable

      After deploying a huge amount of Java application in a JBoss EAP environment, it looks like a lot of Jandex index are retained in heap:

      Class Name                                              |   Objects | Shallow Heap | Retained Heap
---------------------------------------------------------------------------------------------------
java.lang.Object[]                                      | 1,460,530 |     85.52 MB |  >= 622.78 MB
java.util.ArrayList                                     |   939,474 |     21.50 MB |  >= 533.32 MB
org.jboss.jandex.Index                                  |       435 |     13.59 KB |  >= 460.42 MB
org.jboss.as.server.deployment.annotation.CompositeIndex|       224 |      3.50 KB |  >= 458.73 MB
java.util.HashMap                                       | 1,143,351 |     52.34 MB |  >= 405.49 MB
java.util.HashMap$Node[]                                |   897,613 |     89.82 MB |  >= 395.81 MB
java.util.HashMap$Node                                  | 4,110,870 |    125.45 MB |  >= 317.86 MB
org.jboss.jandex.ClassInfo                              |   491,618 |     22.50 MB |  >= 301.04 MB
---------------------------------------------------------------------------------------------------

      Test done with heap defined with 4Gb, started nicely with about ~150 applications and slowly increased it until about 200. Less heap then that leads into OOME.

      Heap: Size: 1.4 GB Classes: 49.5k Objects: 38.6m Class Loader: 1.8 + 900mb ready for GC.

      The same behavior is not seen in EAP 6.4.21 and all those 200 can be easily deployed within 1 GB heap size.
      *
      EDIT: A bit of Weld background*
      org.jboss.weld.bootstrap.api.helpers.SimpleServiceRegistry currently holds a map and a set. The set is in fact a subset of map's values - it contains bootstrap services.
      Now, org.jboss.weld.bootstrap.BeanDeployment object creation entails copying of services which is done based on map keys. This works fine unless the set contains duplicate classes twice which can happen when deploying on WFLY.

      Solution is to remove this set and only operate on the map.
      Along with that we should also modify WeldStartup.endInitialization() to contain following one-liner that will force clean all the instances:

      beanDeployment.getBeanDeploymentArchive().getServices().cleanupAfterBoot();

              manovotn Matěj Novotný
              rhn-support-pdelbell Patrick Del Bello
              Votes:
              0 Vote for this issue
              Watchers:
              9 Start watching this issue

                Created:
                Updated:
                Resolved: