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. > serviceregistry.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/ >> controller/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/openday >> light/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> >> *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/ >> 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 >> >> 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
