Member since
07-30-2019
3392
Posts
1618
Kudos Received
1001
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 415 | 11-05-2025 11:01 AM | |
| 291 | 11-05-2025 08:01 AM | |
| 435 | 11-04-2025 10:16 AM | |
| 660 | 10-20-2025 06:29 AM | |
| 800 | 10-10-2025 08:03 AM |
10-24-2025
11:47 AM
@Bern From what has been shared I can't tell you much more then the fact that you are having zookeeper issues. Without a ZK quorum, NiFi can't maintain the cluster and thus the UI is not available. There is not much else I can tell you from what you have shared. I suggest looking more closely at the NiFi app.log and bootstrap logs for other ERRORs or WARNs that may have been logged before or at same time your ZK communication issue started. You may also want to look at the health of your network. You mention that NiFi goes down nightly and that this started when you were building some "contingency processes". I am not clear on what this means relative to your NiFi. Do you mean you were adding additional flows to your NiFi canvas when you started having issues? What else are you seeing in the NiFi logs prior to the ZK issue starting? What about CPU load? What about memory: Any Out Of Memory (EoM), continues garbage collection or long garbage collection events? Network issues resolving hostnames of the ZK nodes? Issues telnetting to ZK nodes using the zk configured ports (2888 and 3888)? I also appears you are using the embedded ZK which I would strongly discourage in any production system. Any resource congestion issues your NiFi experience is going to have impacts on ZK quorum and cluster stability. I recommend standing up an external ZK on different hosts from where your NiFi is installed. It also worth noting that Apache NiFi 1.14.4 was released more then 6 years ago. There have been many improvements, bug fixes, and CVEs addressed since then. Upgrading to the latest 1.28 (keeping in the same Major release 1.x branch) would be very advisable. There will be No more Apache NiFi 1.x versions released now that Apache NiFi 2.x major release branch is available. 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
10-24-2025
06:49 AM
We are running the following: Cloudera Flow Management (CFM) 2.1.7.1001 1.26.0.2.1.7.1001-5 built 07/03/2024 09:38:52 EDT Powered by Apache NiFi 1.26.0 I have 4 CRON driven processors that drive their respective process flows. 3 of the processors have execute 6pm weekdays (0 0 18 ? * MON-FRI) with no issues. This one executes at 5pm as expected, but also executes at 4:07pm which is strange. This is on a single core in our development environment. We are not using clusters. Also, since this is our development core, only I have access at this time. And I did not manually execute the processor. And I just realized that our old Windows Service process is executing in development and that the 4:07pm emails came from it and not the Nifi CDF process we are developing and testing. So this is resolved and in no way an issue with Cloudera or Nifi.
... View more
10-21-2025
04:35 PM
We would need to understand first if the issue is on the CM-agent or on the Nifi-registry. Simply describing if the nifi-registry did not start at all or did start but then failed would help in knowing if the issue is with CM-agent or nifi-registry itself.
... View more
10-20-2025
06:42 AM
@mansmaan I'm afraid there is not enough information shared yet to know exactly why you are experiencing a connection refused or connection reset issue from your NiFi node. I was able to use InvokeHTTP with no issue to successfully get a response from the URL you provided. I was able to view the weather data that was returned in json format. Have you tried to reach wttr.in directly from command line on the NiFi server? This sound like an environmental issue and not a NiFi invokeHTTP issue. 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
10-20-2025
06:29 AM
@Rohit1997jio Yes it can be fast, but that depends on your dataflow(s). How many other dataflows is your NiFi also running? All these dataflows share the same JVM resources and utilize server resources. Also concurrency is important so having a match between number of partitions in your source Topic A and the concurrency within your ConsumeKafkaRecord processor is important. Concurrent tasks in the ConsumeKafkaRecord you be set using the following formula: (num partitions in Topic A) / (num NiFi nodes in cluster) = (num concurrent tasks set on ConsumeKafkaRecord) Example: Kafka Topic partions = 12 partitions NiFI cluster num nodes = 3 Concurrent tasks set on ConsumeKafkaRecord = 4 4 X 3 = 12 consumers in the consumer group (1 consumer per partition in source topic) Also in NiFI keep in mind that each concurrent task utilizes a thread from NiFi's "Max Timer Driven Thread Count" thread pool. The default pool size is 10. This means that only 10 concurrent task can execute at the same time. Generally speaking threads milliseconds, but for optimal performance you'll want to mange your server CPU load average resources and set the pool higher to maximize your throughput performance. NiFi can show you the Core Load Average (1 = 100% utilization of one physical core). So if your NiFi server has 4 cores and the load average is 4 or higher, the CPU is saturated. You'll be able to use this Core Load Average data to determine how much your can increase the size of the "Max timer Driven Thread Count" pool setting. NiFi recommends setting your "Max Timer Driven Count" initially to 2 - 4 times the number of Physical cores on the NiFi node. This assume all nodes in the NiFi cluster have same number of physical cores. If nodes have various numbers of physical cores, use the nodes with the fewest to set your initial pool size. Then monitor core load average across all NiFi nodes and adjust accordingly. There is no way to configure different thread pools per node in a NiFi cluster, NiFi expects all all servers in a NiFi cluster to have same hardware configuration. 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
10-10-2025
10:42 AM
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
10-09-2025
01:11 PM
@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
10-08-2025
10:52 AM
@Frank168 Glad I was able to identify your issue for you. Can you accept the post that solved your issue. I see you accepted your response. Thank you, Matt
... View more
10-08-2025
10:44 AM
@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
10-08-2025
10:39 AM
@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