Re: [controller-dev] [release] Memory leaks on blueprint restart

[Alexis de Talhouët]

> On Nov 10, 2016, at 11:35 AM, Colin Dixon  wrote:
> 
> I realize I'm getting here late, but did we get an issue opened.

If I’m not mistaking, yes, and it is that one: 
https://bugs.opendaylight.org/show_bug.cgi?id=6969 


> Have we made any progress?

I personally haven’t looked into it yet. I don’t know about TomP.

Thanks,
Alexis___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [release] Memory leaks on blueprint restart

[Colin Dixon]

I realize I'm getting here late, but did we get an issue opened. Have we
made any progress?

--Colin


On Tue, Oct 18, 2016 at 7:34 AM, Robert Varga  wrote:

> On 10/18/2016 12:38 PM, Martin Dindoffer wrote:
> > So what's the status on this? Should I open an issue in controller's
> > bugzilla?
>
> Yes, please open an issue so we do not lose track of this.
>
> Thanks,
> Robert
>
>
> ___
> controller-dev mailing list
> controller-dev@lists.opendaylight.org
> https://lists.opendaylight.org/mailman/listinfo/controller-dev
>
>
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [release] Memory leaks on blueprint restart

[Robert Varga]

On 10/18/2016 12:38 PM, Martin Dindoffer wrote:
> So what's the status on this? Should I open an issue in controller's
> bugzilla?

Yes, please open an issue so we do not lose track of this.

Thanks,
Robert



signature.asc
Description: OpenPGP digital signature
___
controller-dev mailing list
controller-dev@lists.opendaylight.org
https://lists.opendaylight.org/mailman/listinfo/controller-dev

Re: [controller-dev] [release] Memory leaks on blueprint restart

[Martin Dindoffer]

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/topoproces

Re: [controller-dev] [release] Memory leaks on blueprint restart

[Tom Pantelis]

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ópi

Re: [controller-dev] [release] Memory leaks on blueprint restart

[Alexis de Talhouët]

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 resta