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

Reply via email to