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

Reply via email to