[
https://issues.apache.org/jira/browse/NIFI-5241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16504663#comment-16504663
]
ASF subversion and git services commented on NIFI-5241:
-------------------------------------------------------
Commit ff00050266e1b607babd957253ecce08ec324c1a in nifi's branch
refs/heads/master from [~markap14]
[ https://git-wip-us.apache.org/repos/asf?p=nifi.git;h=ff00050 ]
NIFI-5241: Updated EventSumValue to use synchronized methods instead of many
atomic values. This is more efficient and uses less heap. Also noticed that the
Logger instance in ProcessorNode was not used so removed it, and in testing
this also noticed that the default connection pool size for
OkHttpReplicationClient was only 5, which can cause a lot of unnecessary HTTP
connections to be created so adjusted the pool size
NIFI-5241: Extended timeout that Jetty uses before closing an active HTTP
connection. Because the UI refreshes every 30 seconds by default, and the Jetty
connection pool times out every 30 seconds by default, we very frequently saw
new HTTP connections being created for the UI refreshes. This resulted in 4 new
connections and 4 SSL handshakes occurring every 30 seconds. By extending the
timeout, we now see those connections being reused and SSL Handshakes no longer
occurring frequently
NIFI-5241: Set Jetty idle timeout to double the amount of time for browser to
refresh
NIFI-5241: Fixed synchronization issue with EventSumValue
This closes #2752
> When calculating stats for components, use synchronized methods instead of
> atomic variables
> -------------------------------------------------------------------------------------------
>
> Key: NIFI-5241
> URL: https://issues.apache.org/jira/browse/NIFI-5241
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
> Reporter: Mark Payne
> Assignee: Mark Payne
> Priority: Major
> Fix For: 1.7.0
>
>
> Currently, the EventSumValue that is used to calculate stats for components,
> such as bytes in, bytes out, etc. using AtomicLong's and AtomicInteger's, etc
> to keep track of values. This made sense at first when there were only a few
> stats. Now, however, they hold about 17 different values and the atomic
> updates / atomic reads are more expensive than a synchronized method would
> be. This can cause sluggishness in the UI after the instance has been running
> for a while, especially if there are a lot of processors.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
