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
> 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> 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> 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.serv
>> iceregistry.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/contro
>>> ller/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/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.opendayli
>>>    ght.org/gerrit/#/q/status:merged+project:topoprocessing+bran
>>>    ch: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/sr
>>> c/main/java/org/opendaylight/yang/gen/v1/urn/opendaylight/p
>>> arams/xml/ns/yang/topoprocessing/provider/impl/rev150209/
>>> TopoProcessingProviderModule.java#L26
>>> [1]: https://wiki.opendaylight.org/view/Using_Blueprint#Migr
>>> ating_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

Reply via email to