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