[
https://issues.jboss.org/browse/WFLY-12167?page=com.atlassian.jira.plugin...
]
Brian Stansberry commented on WFLY-12167:
-----------------------------------------
[~pferraro] [~jmesnil] During a metrics scan do the same underlying value instances get
read for multiple attributes over the course of a single management op? If so can the
relevant OSHs cache those in the OperationContext via an Attachment? For example
ChannelMetricExecutor could use an attachment of type Map<String, JChannel>.
A weakness is while that read is going on another op could come in and result in the
service being stopped, leaving the read op with a ref to a defunct value. That potential
exists with the current code too, but caching the value across steps would increase the
size of the window wherein that could happen.
Note that this comment is getting a bit OT from the original bug report, which is
resolved. This is about further optimization.
Memory leak in metrics in standalone-ha configuration
-----------------------------------------------------
Key: WFLY-12167
URL:
https://issues.jboss.org/browse/WFLY-12167
Project: WildFly
Issue Type: Bug
Components: Clustering, MP Metrics, MSC
Affects Versions: 16.0.0.Final
Reporter: Bernd Stolle
Assignee: Richard Opalka
Priority: Blocker
Labels: memoryleak
Fix For: 17.0.0.Final
Attachments: Screenshot 2019-06-06 at 11.07.00.png
When started in standalone HA configuration every request to the recently added metrics
endpoint ({{<management-if>:9990/metrics}}) lead to an increase in memory
consumption until the JVM is slowed down significantly by GC to a point where even the
requests to {{/health}} fail within a reasonable timeout (2s) and untlimately lead to
OOM.
The same issue does not occur when WildFly is started in the default standalone
configuration (non HA).
I can provide a (compressed) heap dump if required.
--
This message was sent by Atlassian Jira
(v7.12.1#712002)