I think BlueprintContainer has a memory leak. Maybe we can work around it by shutting it down via "quiescing" instead of destroy.
On Thu, Oct 13, 2016 at 1:28 PM, Alexis de Talhouët <adetalho...@inocybe.com > wrote: > 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) > > > 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> 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.serv >> iceregistry.ServiceRegistrationImpl @ 0x88f51a20 >> >> >> The entire tree to the GC roots is huge. I'm putting it in pastebin: >> http://pastebin.com/raw/HYtxGUbe (probably need to download it to avoid >> line wrapping) >> >> >> Martin >> >> >> *Od:* Tom Pantelis <tompante...@gmail.com> >> *Odoslané:* 13. októbra 2016 18:33 >> *Komu:* Alexis de Talhouët >> *Kópia:* Martin Dindoffer; 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> 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/contro >>> ller/blueprint/BlueprintContainerRestartServiceImpl.java >>> >>> >>> On Oct 13, 2016, at 12:18 PM, Martin Dindoffer < >>> martin.dindof...@pantheon.tech> wrote: >>> >>> >>> - The blueprint xml is at topoprocessing-impl/src/main/r >>> esources/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.opendayli >>> ght.org/gerrit/#/q/status:merged+project:topoprocessing+bran >>> ch: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> >>> *Odoslané:* 13. októbra 2016 18:00 >>> *Komu:* Martin Dindoffer >>> *Kópia:* 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/18e >>> 7eb3e6615336e6c66fc26789456db76b97d95/topoprocessing-impl/sr >>> c/main/java/org/opendaylight/yang/gen/v1/urn/opendaylight/p >>> arams/xml/ns/yang/topoprocessing/provider/impl/rev150209/ >>> TopoProcessingProviderModule.java#L26 >>> [1]: https://wiki.opendaylight.org/view/Using_Blueprint#Migr >>> ating_from_config_subsytem_.28CSS.29 >>> >>> On Oct 13, 2016, at 11:54 AM, Martin Dindoffer < >>> 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 >>> reception: +421 2 212 93 331 / www.pantheon.sk >>> [image: logo] >>> >>> >>> _______________________________________________ >>> release mailing list >>> rele...@lists.opendaylight.org >>> 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 >>> reception: +421 2 212 93 331 / www.pantheon.sk >>> [image: logo] >>> >>> >>> >>> >>> >> 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 >> >> [image: logo] >> >> > > >
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
