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();

            [WELD-2592] SimpleServiceRegistry can be leaking services on BeanDeployment creation

            Stuart Douglas (Inactive) added a comment - - edited

            This is being held by org.jboss.as.weld.discovery.WeldClassFileServices, it appears the cleanupAfterBoot() method is not being called anywhere.

            I think this is something that Weld itself should call rather than WildFly, so it should be followed up with the Weld team.

            Stuart Douglas (Inactive) added a comment - - edited This is being held by org.jboss.as.weld.discovery.WeldClassFileServices, it appears the cleanupAfterBoot() method is not being called anywhere. I think this is something that Weld itself should call rather than WildFly, so it should be followed up with the Weld team.

            JBoss SET added a comment -

            [OnPayloadWithout3Acks] Issue in on the payload but is missing some acks.

            BugClerk (automated tool) lives at this address: https://github.com/jboss-set/bug-clerk

            JBoss SET added a comment - [OnPayloadWithout3Acks] Issue in on the payload but is missing some acks. BugClerk (automated tool) lives at this address: https://github.com/jboss-set/bug-clerk

              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: