@Hafiz    The ExtractText processor will evaluate a Java regular expression containing capture group against the inbound FlowFile's content. Then creates FlowFile attributes by processor dynamic property name that is assigned the value from the capture group from that Java regular expression. Above would result in FlowFiles with attributes like:   Things to keep in mind. SplitText takes the inbound FlowFile and splits it in too many FlowFiles.  If you are producing a lot of splits from a single source FlowFile, it will have an impact of NiFi's heap usage during that process.  As each Split FlowFile is created, the FlowFile attributes/metadata fro each produced FlowFile (splits) is held in heap memory.  Once all splits are created, all those produced Split FlowFiles are committed to the downstream relationship. One on the relationship, NiFi can then swap as needed out of heap memory.  NiFi does this to avoid data duplication.  Let's say you have a split that is in progress and NiFi dies.  Since nothing has been committed to a downstream relationship yet, when NiFi is brought back online, it will reprocess the original FlowFile.  You can reduce heap usage by splitting your source File multiple times if it is large (more than 20,000 - 50,000 splits).  For example, split by every 5,000 lines in first SplitText and then by every 1 line in second SplitText. While NiFi does not hold FlowFile content in heap memory (Some processor will load content in to heap to execute on that content), FlowFile attributes/metadata is held in heap memory.  So the more attributes/metadata exists on a FlowFile, the more heap that FlowFile is going to use.  FlowFiles are held in connection between processor components.  NiFi has a connection swap threshold that is applied per connection.  The default is to produce swap files that contain 10,000 FlowFiles each (these swap files are for FlowFile attributes/metadata and not content since it is not always held in heap). So swap default set in nifi.properties file is 20,000.  This means the first swap file for a connection is generated connection reaches 20,000 queued FlowFiles on one node (if multi-node NiFi cluster, swap is per node and not across all nodes) Just keep above in mind when designing dataflows where you are splitting/merging, creating a lot of FlowFile Attributes, or creating FlowFile attributes with large values. If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post. Thank you, Matt ... View more

@Jarinek    As part of changing the value of a parameter, all the components that are configured to use that parameter must be stopped and restarted.  Some components like controller services have dependent components like processors. So to stop such a controller service, the dependent processor must be stopped first.  When NiFi requests that a component stop, it transition in to an intermediate stage fo "stopping" where NiFi asks the thread to exit.  The UI would reflect component as stopped or disabled even though it is still in the transition stage. But that does not always guarantee a component will ever complete the transition from "stopping" to stopped.  Some client libraries used by components and not written by NiFi developers do support interrupting running threads.  In scenarios like this the the "stopping" thread kicked off by NiFi stays active against that component until the active processor thread finally exits (if it ever does).  And as i said that specific component thread never completing is out of NiFi's core control.  Restarting NiFi is only way to kill any threads that do not gracefully exit.   Things you can try here: 1. When you try to enable or delete a controller service, I'd expect the exception to provide the component UUID and host where it claims it is running.  You could go to the cluster UI and manually "disconnect" the node where it is still running.  Then open a web browser to that specific, now disconnected" node's UI.  Use the UUID of the component to locate that component and check its status.  Try disabling it and if that does not work, try restarting that node only.  If disabling the component worked, go back to UI of another node still in cluster and via the cluster UI request that the disconnected node reconnect.  While the exception might point out one host as the issue, it may be more than one host. The UI simply returns the first exception. 2. If above is not successful, have you tried restarting the entire cluster? 3. You could also inspect the the flow.xml.gz from each host to make sure they match.  Component state (started, stopped, enabled, and disabled) is retained in the flow.xml.gz, but is not included within the flow fingerprint used when connecting a node to the cluster.  As a connecting node is suppose to inherit the state from the cluster.  You could check each flow.xml.gz for the component UUID and see what its current recorded state is in the flow.xml.gz.  If you find one or more with a state of enabled/running and other nodes with an alternate state, simply copy the flow.xml.gz with the desired state to the nodes with the undesired state.  Make sure flow.xml.gz ownership and permissions are correct and restart your NiFi cluster. As far as to why a component never transitioned from state to another, that would require examining numerous thread dumps spaced apart by at least 5 minutes.  This would allow you to identify active thread making no progress over the course of those numerous thread dumps.  Then you would have to to dig in to those threads to see what they are waiting on or blocked by.  Sometimes there are limitation within some clients that NiFi has no control over. If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post. Thank you, Matt ... View more

@emmanuel  Does your truststore on each NiFi host contains a separate TrustedCertEntry for each of your three CA certificates in your trust chain? Your openssl command output does not list your root or intermediate CAs: Acceptable client certificate CA names /C=FR/O=SAFRAN/OU=SAFRAN SA/OU=0002 562082909/CN=nifi-node3 /C=FR/O=SAFRAN/OU=SAFRAN SA/OU=0002 562082909/CN=niif-node2 /C=FR/O=SAFRAN/OU=SAFRAN SA/OU=0002 562082909/CN=nifi-node1 /C=FR/OU=SAFRAN SA/OU=0002 562082909/O=SAFRAN/CN=Safran Nifi Admin /C=FR/OU=SAFRAN SA/OU=0002 562082909/O=SAFRAN/CN=localhost Have you tried converting your PKCS12 keystore to a JKS keystore? Matt ... View more