[
https://issues.apache.org/jira/browse/NIFI-1085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14980703#comment-14980703
]
Michael Moser commented on NIFI-1085:
-------------------------------------
Many many threads in this state:
parking to wait for
java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync
...
at
org.apache.nifi.cluster.manager.impl.WebClusterManager.getNodeIds(WebClusterManager.java:1919)
at
org.apache.nifi.cluster.manager.impl.WebClusterManager.applyRequest(WebClustermanager.java:2019)
One thread in this state:
"Heartbeat Monitor"
... lots of stack lines in XML unmarshalling ...
at org.apache.nifi.cluster.HeartbeatPayload.unmarshal(HeartbeatPayload.java:163)
at org.apache.nifi.cluster.node.Node.setHeartbeat(Node.java:133)
atorg.apache.nifi.cluster.manager.impl.WebClusterManager.processPendingHeartbeats(WebClusterManager.java:1813)
> WebClusterManager starves immutable API requests under heavy load conditions
> ----------------------------------------------------------------------------
>
> Key: NIFI-1085
> URL: https://issues.apache.org/jira/browse/NIFI-1085
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
> Affects Versions: 0.3.0
> Reporter: Michael Moser
>
> With a 6 node cluster with thousands of components on the graph, we noticed
> that the ReentrantReadWriteLock in WebClusterManager can starve NiFi Web
> Server threads that are waiting on the read lock.
> Thread dumps shows the HeartbeatMonitoringTimerTask thread holding the write
> lock while many Web Server threads are parked waiting on the read lock.
> Modify the ReentrantReadWriteLock to operate in fair mode (to give the lock
> to threads waiting the longest, such as those wanting the read lock).
> Modify the HearbeatMonitoringTimerTask timer to not be scheduleAtFixedRate()
> but instead use schedule() to execute it less often if garbage collection
> blocks it.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
