[JBoss JIRA] (WFLY-12486) Memory leak in OpenTracing when deployment is redeployed multiple times
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFLY-12486?page=com.atlassian.jira.plugi... ]
James Perkins updated WFLY-12486:
---------------------------------
Git Pull Request: https://github.com/wildfly/wildfly/pull/12836, https://github.com/wildfly/wildfly/pull/12878 (was: https://github.com/wildfly/wildfly/pull/12836)
> Memory leak in OpenTracing when deployment is redeployed multiple times
> -----------------------------------------------------------------------
>
> Key: WFLY-12486
> URL: https://issues.redhat.com/browse/WFLY-12486
> Project: WildFly
> Issue Type: Bug
> Components: MP OpenTracing
> Affects Versions: 17.0.0.Final, 17.0.1.Final, 18.0.1.Final
> Reporter: Jan Stourac
> Assignee: Emmanuel Hugonnet
> Priority: Blocker
> Fix For: 19.0.0.Beta1
>
> Attachments: memory-leak-bad.png, memory-leak-good.png, wildfly-thread-leak.png
>
>
> There seems to be a memory leak when a deployment is redeployed multiple times (100 times in our test). This is very similar to what has been described in WFLY-10991. Also first commit this started to happen is [this one|https://github.com/wildfly/wildfly/commit/74170b5f49dd83f6b9ebd489f85...] - JaegerTracing and Apache Thrift dependencies update. Thus I selected MP OpenTracing component for this issue.
> Test and deployment is same as is described in WFLY-10991.
> Size of the extra heap in use is about 27MB plus when compared to the initial size before multiple redeploy operations.
> I've tried to check manually via [visualVM|https://visualvm.github.io/] tool. Screenshot with suspicious jaegertracing instances are attached - there are much more jaegertracing class instances with new version of Jager Tracing and Apache Thrift dependencies, which is suspicious.
> Interesting thing is that when microprofile-opentracing-smallrye subsystem is removed via:
> {code}
> /subsystem=microprofile-opentracing-smallrye:remove()
> {code}
> the memory leak is still present. This is kind of confusing to me.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12939) Local scheduler should trigger expiration *after* distributed web session/SFSB has expired.
by Paul Ferraro (Jira)
Paul Ferraro created WFLY-12939:
-----------------------------------
Summary: Local scheduler should trigger expiration *after* distributed web session/SFSB has expired.
Key: WFLY-12939
URL: https://issues.redhat.com/browse/WFLY-12939
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 18.0.1.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
The expiration scheduler schedules a task to expire a web sesssion/SFSB using the last modified time + the max inactive interval (or @StatefulTimeout). However, technically, the session/bean is not expired until after this time. This off-by-one bug can cause the expiration task to determine that the session is not yet expired and thus can result in delayed expiration of a session.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months
[JBoss JIRA] (WFLY-12938) Expired distributed web sessions/SFSBs not properly removed following topology change with no rehash
by Paul Ferraro (Jira)
Paul Ferraro created WFLY-12938:
-----------------------------------
Summary: Expired distributed web sessions/SFSBs not properly removed following topology change with no rehash
Key: WFLY-12938
URL: https://issues.redhat.com/browse/WFLY-12938
Project: WildFly
Issue Type: Bug
Components: Clustering
Affects Versions: 18.0.1.Final
Reporter: Paul Ferraro
Assignee: Paul Ferraro
On topology change, changes to primary session ownership determine when a given member should schedule expiration of a given session, or cancel a scheduled expiration of a previously owned session. Primary ownership is determined by 2 components: the key partitioner and a consistent hash. The key partitioner determines which the segment to which a given key is assigned. A consistent hash determines which member is the primary owner of a given segment.
Rescheduling of session expiration is triggered from a data rehash event. However, when the second to last member leaves the cluster, there is no data rehash event, thus expired session owned by the leaving member are never removed. To fix this, we must also trigger rescheduling of expiration in the event of a topology change where no rehashing occurs.
This results in expired web sessions/SFSBs remaining in memory, potentially indefinitely.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 6 months