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)
 
<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 <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 <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
>  
> <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
>>  
>> <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/>
>> 
>>  
> 
> 
> 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 <http://www.pantheon.sk/>
> 
>  
> 

_______________________________________________
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Reply via email to