@NagendraKumar  The image you shared indicates that your PublishKafka processor is producing a bulletin.  What is the nature of the exception being reported in that bulletin? I also see what appears to be only one connection exiting your PublishKafka processors.  The publishKafka processor has multiple relationships. Are you auto-terminating the failure" relationship?  If so, i never recommend doing that. ----------- Now when it comes to monitoring queue sizes/thresholds, you could use the ControllerStatusReportingTask NiFi reporting task to output these stats for all connections to a dedicated logs (see Additional Details... for how to setup dedicated logs via NiFi's logback.xml).   You can then create a NiFi dataflow that tails the dedicated connection log and parses the ingested log entries for connections where thresholds exceed your 80% threshold and route those to a putEmail processor for yoru notification needs. (preferred) Another option here is to use the SiteToSiteStatusReportingTask to report specifically on NiFi connections and feed that data in to a dataflow that parses for threshold in excess of 80% and route those to a putEmail processor.  This method has less overhead as it does not write to a NiFi log, require tailing logs, can be setup to report on connections, and reports in a more structured format (see Additional Details... ). ---------- From your image I can also see your PublishKafka processor reporting 3 actively running threads.  You mentioned the processor becomes hung?  Have you analyzed a series of thread dumps to identify where it is getting hung?   NiFi also offers a way to monitor for long running tasks: Runtime Monitoring Properties You could use this in conjunction with the SiteToSiteBulletinReportingTask to construct a dataflow that could send an email alert when task are detected on processor that have been running in excess of the configured threshold.  This runtime monitoring does have an impact on your overall NiFi performance due to the overhead needed to run it.  So if you find it impacts your throughput performance negatively, you'll need to stop using it. __________ 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

@wasabipeas @Adhitya  In the thrown exception it reports which node has the mismatched revision. Is that node the currently elected cluster coordinator? Have you tried on just that reported node: 1. Stopping NiFi 2. Remove or rename both the flow.xml.gz and flow.json gz files (only deleting one will not work) 3. Restart that NiFi node.  It will inherit the flow from the cluster coordinator when it joins. If this node was the elected cluster coordinator, when you shut it down another node will assume the cluster coordinator role. ---- Another option is to disconnect the node reporting the mismatch in revision.  Then from the same cluster UI used to disconnect that node, select to drop/delete it from cluster.  Your cluster will now report one less node.  See if you can then move the process group or if it reports another node with mismatched revision? NOTE: Deleting/Dropping a node from cluster using the Cluster UI does nothing to that node.  If you restart that node that was deleted/dropped it will rejoin the cluster again.   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

@kk-nifi Has the reply helped resolve your issue? If so, please mark the appropriate reply as the solution, as it will make it easier for others to find the answer in the future. Thanks. ... View more

@kleyson Has the reply helped resolve your issue? If so, please mark the appropriate reply as the solution, as it will make it easier for others to find the answer in the future. Thanks. ... View more

The term "headless" means that "I have access to NIFI server through REST API only!" Anyways, I used below curl to get root level process group: curl --location 'https://localhost:8443/nifi-api/process-groups/root' \ --header 'Authorization: Bearer eyJraWQiOiI1NGU4ZWRkNi00ZTY1LTQ3MmUtYTI5Ni1mNmI3MDJjZDYzNWEiLCJhbGciOiJQUzUxMiJ9.eyJzdWIiOiJkZWVwYWtkb2 I am closing this thread ... View more

@MattWho  We are using Jndi Configurations, there is no option to pass ssl with jndi configurations.   ... View more

@CDC-  I encourage you to start a new community question rather then adding to an existing question with an accepted answer.   Your query is really unrelated to this question.  Something appears to be happening to your content prior to even reaching the PutDataBaseRecord processor.  I say this because the exception shared indicates the processor is looking for the content in an "archived" content claim.  Content claims are only moved to archive once the claimant count is zero (meaning no actively queued FlowFiles are still referencing content on that claim).  Any content claims moved to archive are subject to removal/deletion by the background archive clean-up thread.  So not surprised the content is missing.  The real question here is what is the lineage of this FlowFile and at what point upstream from your putDatabaseRecord  processor did the problem develop. Please start a new community question and provide as much detail as possible. Thanks, Matt ... View more

@SAMSAL , Thanks for the reply but  our current nifi version is 1.23.2 , where it doesn't have that completion strategy. So thinking of  implementing executeScript or executeStreamcommand in order to delete the files from SMB after fetchSMB. Please let me know if you have any suggestions for this script , nifi hosted on kube clusters and i've credentials for SMB as well.   ... View more

HI Matt, thanks for your reply and info shared. We did some changes, so now signing then encrypting the files: signing encrypting When our next system tries to decrypt the file we get this error: gpg: encrypted with unknown algorithm 183 gpg: decryption failed: Invalid cipher algorithm Googling on this, encrypted with unknown algorithm 183, doesn't really give anything usefull.  So were trying to figure out, if the issues we're facing is nifi related or on the decrypting side. Any idea's would help. Thank you.     ... View more