@G_B  NiFi cluster deployments expect that all nodes in the cluster have same hardware specifications.  There is no option in NiFi's Load Balanced connections to customize load-balancing based on current CPU load average of some other node.  Even doing so would require NiFi nodes to continuously ping all other nodes to get the current load average before sending FlowFiles which would impact performance.  The only thing that would result in any form of variation in distribution would be a node receive rate being diminished, but that is out of NiFi's control. Round Robin will skip a node in rotation if the node is unable to receive FlowFiles as fast as another node. Also keep in mind that a NiFi Cluster elects a node the roles "cluster coordinator" and "primary node".  Sometimes both roles get assigned to same node.  The assignment of these roles can change at. anytime.   The primary node is only node that will schedule "primary node" only processors to execute.  So your one node lighter on CPU could also end up assigned this role adding to its CPU load average.   Often CPU load average is not only impacted by volume, but also content size of the FlowFiles.  The LB connections also do not take in to account FlowFile content size when distributing FlowFiles. While your best option here performance wise is to make sure all nodes have same hardware specifications, there are a few less performant options you could try to distribute your data differently. 1. Use Remote Process Group (RPG) which uses Site-To-SIte (S2S) to distribute FlowFiles across your NiFi nodes.  Always recommend using RPG to push to a Remote Input port rather then pull from an Remote output port to achieve better load distribution.  Issue here is you need to add RPGs and Remote ports everywhere you were previously using LB configured connections.   2. Build a smart data distribution reusable dataflow.  You could build a data flow that sorts FlowFiles by their content size ranges, merges bundles via mergeContent using FlowFile Stream, v3 merge format, send bundles based on size ranges to your various nodes via invokeHTTP to listenHTTP, and then unpackContent once received to extract the FlowFile bundle.  This mergeContent is going to add addition cpu load. 3. Consider using DistributeLoad (can be configured with weighted distribution allowing you to create three distribution relationships with maybe like 5 FlowFile per relationship 1 and 2, and relationship with only 1 per iteration.  This allows you to send 1 to you lower core node for every 5 sent to other two nodes.  You would still need to use updateAttribute (set custom target node URL), mergeContent, invokeHttp, ListenHTTP, and unpackContent in this flow. So if addressing your hardware differences is not option, Number 1 is probably your next best choice. Please help our community thrive. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@alan18080  NiFi-Registry only pushes to the GitFlowPersistenceProvider while running.  NIFi-Registry will only read from Git on startup.  The GitFlowPersistence Provider also only contains the flow definitions for the version controlled process groups.  Each NiFi-Registry has a metadata database maintains the knowledge of which buckets exist, which versioned items belong to which buckets, as well as the version history for each item.  So if you are trying to share a single Git Repo across multiple running NiFi-Registry instances this will explain why you are seeing missing versions at times across your multiple instances. Please help our community thrive. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt   ... View more

@inkerinmaa  An Apache NiFi multi-node clustered setup is much different then a standalone NiFi installation. Your exception is related to a TLS exchange trust issue going on between your nodes.  In a NiFi cluster one of the nodes will be elected to the role of "cluster coordinator" by Zookeeper (ZK).  All of the nodes will communicate with ZK in order to learn which node is currently assigned to this role and then begin sending heartbeats to that elected node in order to join the cluster.   It looks like you are just allowing your NiFi nodes to auto generate their own self-signed certificates on each node?  Works fine to do this in a standalone NiFi setup; however, you'll need to create keystores and truststores for your NiFi cluster nodes so that proper mutual trust can be established.   I also see that your are using the Single-User login provider and authorizer.   For a NiFi cluster you'll also want to be using more production ready providers like the ldap-provider for login and the StandardManagedAuthorizer for all your authorizations.    Please help our community thrive. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@hegdemahendra  The small number in upper right corner of any processor shows the number of active threads at time the UI was last refreshed.  The default auto refresh of the UI is every 30 seconds. It turns red when their is an active terminated thread.  So with your example above 2(1), it is telling you that this processor as 2 active threads and 1 terminated thread. A terminated thread is the result of manual user intervention.  When a processor asked to change run-status from "running" to "stopped", (Stopping Component)  it first transition into a state of "stopping".  It does not transition to "stopped" until all active threads complete.  NiFi provides and option to "terminate" when in a stopping state because of active threads. Terminate (Terminating a components tasks) does not kill that active thread since all thread belong to a single JVM.  What the terminate function does is release any FlowFile tied to the active thread(s) back to their originating connection and marks the thread as terminated.  That terminated thread will continue to execute until it completes or the JVM is restarted.  Should that now "terminated" thread complete, all output is sent to dev null instead of resulting in any down stream movement. This allows users to handle scenarios where there are long running threads or hung threads preventing the stopping, changing of configuration, and starting of a processor. When a terminated processor is restarted it will re-process the FlowFile(s) that were originally tied to the terminated thread(s).   This prevents any data loss from occurring.  If a terminated thread is in a permanently hung state, the only way to get rid of it completely is a restart of NiFi which will kill the JVM after a graceful shutdown period.  As far as your custom processor getting stuck, you would need to collect thread dumps and inspect those to see what your thread is waiting on that is blocking it from progressing and address that in your custom code. Please help our community thrive. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more