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.Dindoffer@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> > *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/ > 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 > > On Oct 13, 2016, at 11:54 AM, Martin Dindoffer <Martin.Dindoffer@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] > > > > >
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
