@HenriqueAX  It is safe to restart the NiFi service without encountering any data loss.  NiFi is designed to protect against dataloss relative to the FlowFile traversing connection between processor components added to the NiFi canvas. FlowFiles are persisted to disk (Content is store in content claims within the "content_repository" and metadata/attributes associated with a FlowFile is stored in the "flowfile_repository").   These repositories should be protected against loss through RAID storage or some other protected storage. When a processor is scheduled to execute it will begin processing of a FlowFile from an inbound connection.  Only when a processor has completed execution is the FlowFile moved to one of the processors outbound relationships.  If you were to shutdown NiFi or NiFi was to abruptly die, upon restart FlowFiles will be loaded in last known connection and execution on them will start over at that processor's execution.    There exists opportunity within some race conditions that data duplication could occur (NiFi happens to die just after processing of FlowFile is complete, but before it is committed to downstream relationship resulting in FlowFile being reprocessed by that component).  But this only matters where specific processor is writing out the content external to NiFi Or when NiFi is ingesting data in some scenarios (consuming from a topic and dies after consumption but before offset is written resulting in same messages consumed again). With a normal NiFi shutdown, NiFi has a configurable shutdown grace period. During that grace period NiFi no longer schedules and processors to execute new threads and NiFi waits up to that configured race period for existing running threads to complete before killing them. IMPORTANT: Keep in mind that each node in NiFi cluster executes the dataflows on the NiFi canvas against only the FlowFiles present on the individual node.  one node has no knowledge of the FlowFiles on another node. NiFi also persists state (for those components that use local or cluster state) either in a local state directory or in zookeeper for cluster state.  Even in a NiFi cluster some components will still use local state (example: ListFile).  So protection of the local state directory via RAID storage of other means of protected storage is important.  Loss of stare would not result in dataloss, but rather potential for a lot of data duplication through ingestion of same data again (depending on processors used). 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

@drewski7  While you added the public cert for your NiFi8444 to the truststore used in the nifi8443 StandardRestrictedSSLContetService, did you do the same in reverse? Does your StandardRestrictedSSLContetService also include the keystore?  The Keystore contains the PrivateKey that is used in the mutual TLS exchange with NiFi8444. NiFi8443's public cert (or complete trusts chain) needs to be added the truststore configured in the nifi.properties file on NiFi8444. You'll also want to look at the nifi-user.log on NiFi8444 to see the full exception thrown when NiFi8443 reporting tasks is trying to retrieve the Site-to-Site (S2S) details. Identities will be manipulated by matching identity mapping patterns setup in the nifi.properties file.  So you'll want to verify that also. Additionally, are you still using Single-User-provider on NiFI8444 along with the NiFi auto generated keystore and truststore?  (I saw CN=localhost in one of your images).  You should create a keystore and truststore with proper DN and SANs for use with S2S. Hope this helps with your investigation and troubleshooting. 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

@SS_Jin  Another option is to use the NiFi expression Language (NEL) function "literal()}" in the NEL statement: ${myattr:append(${literal('$$$')}):prepend(${literal('$$$')})} This removes the need to you are using the correct number of "$" to escape $ in the NEL. Please help our community grow. 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

@salahevops  Upgrading to Apache NiFi 1.21 or newer should resolve you issue. The latest Apache NiFi 1.x branch release is 1.27. Apache NiFi 2.x branch is still in it developmental milestone release cycle (currently at 2.0.0-M4).  There was a vote put forth in Apache NiFi to release the first official 2.0 release.   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

@HenriqueAX  The NiFi keystore contains a private key certificate. The NiFi Truststore contains trusted cert entries (public certificates). You should combine all the truststores to make one truststore containing all the public certificates and use that same truststore on all the NiFi nodes and NiFi-Registry host. It may also help to understand what is happening by looking at the output from openssl: openssl s_client -connect <nifi hostname>:<nifi port> -showcerts openssl s_client -connect <nifi-registry hostname>:<nifi-registry port> -showcerts 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