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
