So what's the status on this? Should I open an issue in controller's bugzilla?
________________________________ Od: Tom Pantelis <tompante...@gmail.com> Odoslané: 13. októbra 2016 20:24 Komu: Alexis de Talhouët Kópia: Martin Dindoffer; rele...@lists.opendaylight.org; controller-dev Predmet: Re: [release] Memory leaks on blueprint restart 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<mailto: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<mailto: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<mailto: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<mailto:tompante...@gmail.com>> Odoslané: 13. októbra 2016 18:33 Komu: Alexis de Talhouët Kópia: Martin Dindoffer; rele...@lists.opendaylight.org<mailto: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<mailto: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<mailto: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 ) * Blueprint patches: 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 [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<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/> [logo] _______________________________________________ release mailing list rele...@lists.opendaylight.org<mailto: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<mailto:martin.dindof...@pantheon.tech> reception: +421 2 212 93 331 / www.pantheon.sk<http://www.pantheon.sk/> [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<mailto:martin.dindof...@pantheon.tech> reception: +421 2 212 93 331 / www.pantheon.sk<http://www.pantheon.sk/> [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 [logo]
_______________________________________________ controller-dev mailing list controller-dev@lists.opendaylight.org https://lists.opendaylight.org/mailman/listinfo/controller-dev
