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> 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/> > >
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
