Are you saying we’re missing something? e.g. quiesce the list of Bundle that we be restarted, using [0]?
[0]: https://aries.apache.org/downloads/javadocs/quiesce/0.3/org/apache/aries/quiesce/manager/QuiesceManager.html#quiesce(java.util.List) <https://aries.apache.org/downloads/javadocs/quiesce/0.3/org/apache/aries/quiesce/manager/QuiesceManager.html#quiesce(java.util.List)> > On Oct 13, 2016, at 1:13 PM, Tom Pantelis <tompante...@gmail.com> wrote: > > Aries registers each BlueprintContainer as an OSGI service but it doesn't > look like it unregisters it on destroy. It does appear to when the bundle is > stopping (via qiesce()). > > On Thu, Oct 13, 2016 at 1:00 PM, Martin Dindoffer > <martin.dindof...@pantheon.tech <mailto:martin.dindof...@pantheon.tech>> > wrote: > The detailed path to GC roots starts like this: > > org.opendaylight.topoprocessing.impl.provider.TopoProcessingProviderImpl @ > 0x88b54aa0 > '- service org.apache.aries.blueprint.container.ServiceRecipe @ 0x88b54720 > '- val java.util.concurrent.ConcurrentHashMap$Node @ 0x88b54700 > '- next java.util.concurrent.ConcurrentHashMap$Node @ 0x88b54328 > '- next java.util.concurrent.ConcurrentHashMap$Node @ 0x88b542f0 > '- [20] java.util.concurrent.ConcurrentHashMap$Node[32] @ > 0x88b53ae8 > '- table java.util.concurrent.ConcurrentHashMap @ 0x88b53aa8 > '- recipes > org.apache.aries.blueprint.container.BlueprintRepository @ 0x88b53a80 > '- repository > org.apache.aries.blueprint.container.BlueprintContainerImpl @ 0x88b38f98 > '- service > org.eclipse.osgi.internal.serviceregistry.ServiceRegistrationImpl @ 0x88f51a20 > > The entire tree to the GC roots is huge. I'm putting it in pastebin: > http://pastebin.com/raw/HYtxGUbe <http://pastebin.com/raw/HYtxGUbe> (probably > need to download it to avoid line wrapping) > > > Martin > > > Od: Tom Pantelis <tompante...@gmail.com <mailto:tompante...@gmail.com>> > Odoslané: 13. októbra 2016 18:33 > Komu: Alexis de Talhouët > Kópia: Martin Dindoffer; rele...@lists.opendaylight.org > <mailto:rele...@lists.opendaylight.org>; controller-dev > > Predmet: Re: [release] Memory leaks on blueprint restart > > What object is hanging onto the > org.apache.aries.blueprint.container.ServiceRecipe? You need to follow the > references up the chain. > > On Thu, Oct 13, 2016 at 12:26 PM, Alexis de Talhouët <adetalho...@inocybe.com > <mailto:adetalho...@inocybe.com>> wrote: > I see, it looks good to me. Adding controller-dev that I missed and TomP, > initial contributor for the blueprint backend. > > This issue should be somewhere in this class [0]. I don’t have time now to > investigate just now. If TomP says so, you can open a BUG against > controller/blueprint component. > > Thanks, > Alexis > > [0]: > https://github.com/opendaylight/controller/blob/master/opendaylight/blueprint/src/main/java/org/opendaylight/controller/blueprint/BlueprintContainerRestartServiceImpl.java > > <https://github.com/opendaylight/controller/blob/master/opendaylight/blueprint/src/main/java/org/opendaylight/controller/blueprint/BlueprintContainerRestartServiceImpl.java> > > >> On Oct 13, 2016, at 12:18 PM, Martin Dindoffer >> <martin.dindof...@pantheon.tech <mailto:martin.dindof...@pantheon.tech>> >> wrote: >> >> The blueprint xml is at >> topoprocessing-impl/src/main/resources/org/opendaylight/blueprint/topoprocessing.xml >> ( >> https://github.com/opendaylight/topoprocessing/blob/master/topoprocessing-impl/src/main/resources/org/opendaylight/blueprint/topoprocessing.xml >> >> <https://github.com/opendaylight/topoprocessing/blob/master/topoprocessing-impl/src/main/resources/org/opendaylight/blueprint/topoprocessing.xml> >> ) >> Blueprint patches: >> https://git.opendaylight.org/gerrit/#/q/status:merged+project:topoprocessing+branch:master+topic:blueprint >> >> <https://git.opendaylight.org/gerrit/#/q/status:merged+project:topoprocessing+branch:master+topic:blueprint> >> The code you linked is from the CSS timeline, not used anymore. The >> TopoProcessingProviderModule class is now gone completely. We are relying >> solely on blueprint instantiation. >> Od: Alexis de Talhouët <adetalho...@inocybe.com >> <mailto:adetalho...@inocybe.com>> >> Odoslané: 13. októbra 2016 18:00 >> Komu: Martin Dindoffer >> Kópia: rele...@lists.opendaylight.org <mailto:rele...@lists.opendaylight.org> >> Predmet: Re: [release] Memory leaks on blueprint restart >> >> + controller-dev >> >> Martin, >> >> Can you give the following pointers: >> >> - Where is the blueprint file? >> - Can you link the patch(es) that moved the project to blueprint so we can >> spot issues? >> >> Looking here [0] it seems that you create a new TopoProcessingProviderImpl >> each time the module is loaded, which is wrong if you’re using blueprint, >> see [1] for more references. >> >> Thanks, >> Alexis >> >> [0]: >> https://github.com/opendaylight/topoprocessing/blob/18e7eb3e6615336e6c66fc26789456db76b97d95/topoprocessing-impl/src/main/java/org/opendaylight/yang/gen/v1/urn/opendaylight/params/xml/ns/yang/topoprocessing/provider/impl/rev150209/TopoProcessingProviderModule.java#L26 >> >> <https://github.com/opendaylight/topoprocessing/blob/18e7eb3e6615336e6c66fc26789456db76b97d95/topoprocessing-impl/src/main/java/org/opendaylight/yang/gen/v1/urn/opendaylight/params/xml/ns/yang/topoprocessing/provider/impl/rev150209/TopoProcessingProviderModule.java#L26> >> [1]: >> https://wiki.opendaylight.org/view/Using_Blueprint#Migrating_from_config_subsytem_.28CSS.29 >> >> <https://wiki.opendaylight.org/view/Using_Blueprint#Migrating_from_config_subsytem_.28CSS.29> >> >>> On Oct 13, 2016, at 11:54 AM, Martin Dindoffer >>> <martin.dindof...@pantheon.tech <mailto:martin.dindof...@pantheon.tech>> >>> wrote: >>> >>> Hi everyone, >>> I have noticed a memory leak in Topoprocessing that occurs during a >>> restart of (blueprint) containers initiated by a config change. >>> Topoprocessing is using a simple .cfg file and flag >>> odl:restart-dependents-on-updates="true" in blueprint xml. It has no CSS >>> compatibility layer. However, everytime the config changes and the bundle >>> tree is restarted, there is an instance of TopoprocessingProvider (and >>> other classes it references) left hanging in the memory. This can be easily >>> observed by attaching visualVM or a similar tool and watching the instance >>> count grow infinitely. Heap dump shows only blueprint holding references to >>> old instances: >>> >>> org.opendaylight.topoprocessing.impl.provider.TopoProcessingProviderImpl @ >>> 0x88b54aa0 >>> '- service org.apache.aries.blueprint.container.ServiceRecipe @ 0x88b54720 >>> >>> Do any other projects have this problem too? Can someone pinpoint the >>> problem? >>> >>> Thanks, >>> Martin >>> MartinDindoffer >>> Software Developer >>> >>> Sídlo / Mlynské Nivy 56 / 821 05 Bratislava / Slovakia >>> R&D centrum / Bôrická cesta 107 / 010 01 Žilina / Slovakia >>> / martin.dindof...@pantheon.tech <mailto:martin.dindof...@pantheon.tech> >>> reception: +421 2 212 93 331 / www.pantheon.sk <http://www.pantheon.sk/> >>> >>> >>> _______________________________________________ >>> release mailing list >>> rele...@lists.opendaylight.org <mailto:rele...@lists.opendaylight.org> >>> https://lists.opendaylight.org/mailman/listinfo/release >>> <https://lists.opendaylight.org/mailman/listinfo/release> >> >> MartinDindoffer >> Software Developer >> >> Sídlo / Mlynské Nivy 56 / 821 05 Bratislava / Slovakia >> R&D centrum / Bôrická cesta 107 / 010 01 Žilina / Slovakia >> / martin.dindof...@pantheon.tech <mailto:martin.dindof...@pantheon.tech> >> reception: +421 2 212 93 331 / www.pantheon.sk <http://www.pantheon.sk/> >> >> > > > MartinDindoffer > > Software Developer > > Sídlo / Mlynské Nivy 56 / 821 05 Bratislava / Slovakia > R&D centrum / Bôrická cesta 107 / 010 01 Žilina / Slovakia > / martin.dindof...@pantheon.tech > reception: +421 2 212 93 331 / www.pantheon.sk <http://www.pantheon.sk/> > > >
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
