[ https://issues.apache.org/jira/browse/NIFI-5241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16504662#comment-16504662 ]
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)