@Mauro Beltrame - Keep in mind that every node in your NiFi cluster runs its own copy of the flow.xml, has its own set of repositories, and works on its own set of FlowFiles. When a "primary node" change occurs, this does not mean that FlowFiles being processed on old primary node are moved over to the new primary node. It is still the responsibility of the old primary node to finish processing FlowFiles on that node. The "primary node" execution configuration setting on processors simply sets whether this processor should be scheduled to execute on all nodes at same time or just get scheduled on which ever nodes is currently elected the primary node. This is important for non-cluster friendly protocols that some processors use (i.e listSFTP, ListFIle, etc...). - Keep in mind that only processors that are responsible for ingesting data (those that create the FlowFile in NiFi) should be configured for "Primary node" only operation. Al processors within the body of a dataflow (any processor that accepts an inbound connection to it) should be configured to always run on all nodes in your cluster. - If I had to guess one or more of the following is occurring for you: 1. Processors within the body of your dataflows are configured with "Primary node". This means that any FlowFiles ingested on old primary node will end up queued in front of one of these now primary node only configured processors that is no longer getting scheduled on that old primary node. 2. Your primary node only processors have some configuration that is dependent on a local file that that is not present on every node in same directory with same permissions. (for example, Using a private key in listSFTP and that private key was not placed on all nodes). - Thank you, Matt - If you found this answer addressed your question, please take a moment to login in and click the "ACCEPT" link. ... View more

@Poonam Mishra - When using Site-To-Site (S2S) between two secured NiFi instances a 2-way TLS handshake occurs. Based on the specific error you are getting, this handshake appears to have been successful. This means your issue purely falls on the Authorization side. - The NiFi instance running the SiteToSiteProvenanceReportingTask is acting as the client in this connection to your other NiFi instance acting as the Server side of the connection. So it is the Server side NiFi that is checking what authorizations have been granted for the client NiFi instance(s) (If source is a NiFi cluster, every node will need to be authorized). - The full DN from the PrivateKeyEntry found in your keystore on the client NIFi will be used. If your target/Server side NiFi has any configured Identity.mapping.patterns defined in its nifi.properties file, then that full DN will be evaluated against them to see fi any match. If a match is found, then resulting mapping value is passed to the authorizer; otherwise, full DN will be passed to authorizer. - You have not shared what authorizer you are using, but there must exist user entries for every client NiFi who is connecting. For S2S, these client strings passed to the authorizer (case sensitive) must be granted the following policies: 1. "retrieve site-to-site details" <-- This policy allows the client NiFi (one with reporting task) to retrieve details about the target which includes details on supported transport protocols, number of nodes, RAW port values, Node hostnames, node load, etc...). 2. "receive data via site-to-site" <-- This policy allows the authorized client to utilize this remote input port for sending FlowFiles. This would be authorization set on your "ProvenanceMonitoring" remote input port. - Check both your nifi-app.log and nifi-user.log for full stack traces and error related to this process. - Thank you, Matt - If you found this answer addressed your question, please take a moment to login in and click the "ACCEPT" link. ... View more