hi @Zainers , you must specify the class name according to the JDBC driver (.jar) version you are using. remember that the jar must be accessible by all hosts in the NiFi cluster. ... View more

@nifirequest 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

@Rashad_K  What does NiFI provenance show for the duplicate inserts? Do you see the same NiFi FlowFile (by FlowFile UUID) being successfully inserted? Does the issue persist if your change the run duration from 25ms to 0ms? 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

@nifirequest  This appears to be a duplicate to the following community question: https://community.cloudera.com/t5/Support-Questions/How-we-ignore-hostname-verification-certificate-for-minifi/td-p/412577 Did the response in that thread not help you? Thank you, Matt ... View more

@MattWho Thanks a lot for your help! My mistake was that I specified the CN in the username as I did earlier when setting up the nifi-registry user, now I entered it without the CN exactly as it is displayed in the user-log and as you said, and this solved the problem.  Thanks again!   ... View more

In my opinion, the java.lang.OutOfMemoryError: Java heap space that you are experiencing in NiFi may not be due to a built-in memory leak as you say. This could be caused because of the result of the workload exceeding the allocated heap. With such a huge number of processors, 123 and large flowfiles (50 MB × 200), memory demand definitely will grow rapidly, and the 4 GB heap configured in bootstrap.conf may not be sufficient. In general, NiFi is designed to handle large data flows, but of course it requires proper tuning. You can try to decrease the memory usage by increasing the heap size (if hardware allows), adjusting processor concurrency so heavy processors don’t run in parallel, and configuring back pressure to limit queued flowfiles. All these can actually help with reducing memory pressure. Additionally, efficient use of NiFi’s repositories (content, flowfile, provenance) ensures less reliance on heap memory.  Following these optimisations can support your NiFi instance  to handle the workload more effectively and also to avoid frequent OutOfMemory errors. To know the different types of OutOfMemoryError and how to resolve them, you can refer to this blog: Types of OutOfMemoryError ... View more

@gunlomboy  NiFi Site-To-Site (S2S) protocol was not designed for the use case you are trying to achieve. The ability to provide a comma separated list of hostnames in the Remote Process Group (RPG) exists simply to provide fault tolerance.   The RPG will attempt to use the first hostname provided to fetch the S2S detail about the NiFi cluster from that host.  These S2S details will include all the detail about the target NiFi cluster (This is why the RPG still distributed across all nodes in target cluster when only one hostname is provided).    The extra hostnames provide fault tolerance for example lets say the hostname you configured is down, the RPG will attempt the second host to fetch S2S details. The S2S details fetched from the contacted host will include things like hostnames of all nodes connected to cluster, RAW enabled status, Raw Port for each host, Secure enabled, individual target node workload, etc. site-to-site-protocol-sequence  By setting up firewall rules, you are not changing the S2S details being refreshed regularly and the RPG will continue to build a distribution algorithm that includes all the target host nodes.  This means very inefficient transfer of FlowFiles. You might consider redesigning your dataflows to utilize PostHTTP processor (one for each host in target NiFi cluster with failure routed to other PostHTTP).   Then setup a ListenHTTP on your receiving NIFi cluster.  The postHTTP processor can be configured to "Send as FlowFile" so the NiFi Cluster will still receive the FlowFile content and associated FlowFile attributes/metadata just like how RPG sends FlowFiles.  In Front of your ListenHTTP processor you could put a DistributeLoad processor to distribute FlowFiles being sent to your different target nodes.  The downside to a setup like this is if you add additional nodes in your zone1 or zone2 of the target NiFi Cluster, You'll need to update your dataflows to add more PostHTTP processors for those new target hosts.  You also lose the benefit of the workload based FlowFile distribution build into the S2S protocol.  That being said, there is no other options since you can't change the functionality of the S2S protocol.   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