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 <[email protected]>
Odoslané: 13. októbra 2016 18:33
Komu: Alexis de Talhouët
Kópia: Martin Dindoffer; [email protected]; 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
<[email protected]<mailto:[email protected]>> 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
<[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>>
Odoslané: 13. októbra 2016 18:00
Komu: Martin Dindoffer
Kópia: [email protected]<mailto:[email protected]>
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
<[email protected]<mailto:[email protected]>> 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
/ [email protected]<mailto:[email protected]>
reception: +421 2 212 93 331 / www.pantheon.sk<http://www.pantheon.sk/>
[logo]
_______________________________________________
release mailing list
[email protected]<mailto:[email protected]>
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
/ [email protected]<mailto:[email protected]>
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
/ [email protected]
reception: +421 2 212 93 331 / www.pantheon.sk
[logo]
_______________________________________________
controller-dev mailing list
[email protected]
https://lists.opendaylight.org/mailman/listinfo/controller-dev
