Member since
07-30-2019
3406
Posts
1622
Kudos Received
1008
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 97 | 12-17-2025 05:55 AM | |
| 158 | 12-15-2025 01:29 PM | |
| 104 | 12-15-2025 06:50 AM | |
| 238 | 12-05-2025 08:25 AM | |
| 397 | 12-03-2025 10:21 AM |
05-10-2018
01:07 PM
@Mustafa Ali Qizilbash *** Forum Tip: please try to avoid responding to an existing answer by starting a new answer. Instead use "add comment" to respond an answer. - The Firefox version you are trying to use is to old. https://wiki.mozilla.org/Release_Management/Calendar - Firefox 17.0.10 was released back on October 29, 2013. The developer tools are very likely going to show some JS issues here. You need to upgrade to a newer version of Firefox or switch to a new version of another browser like Chrome. - Thank you, Matt
... View more
05-09-2018
07:35 PM
@Mustafa Ali Qizilbash Do you experience same issue with a different browser? What version of Firefox and NiFi are your using? - Have tried using the developer tools (Network) available in the Firefox browser to check for any Java Script errors? From Firefox menu in upper right corner select "web developer" and then "network". A new window will open. Then try reloading NiFi page. You should be able to see where it stalls on loading the page. - Thanks, Matt
... View more
05-09-2018
07:28 PM
@Prakhar Agrawal Then your issue is going to be the backend validation that is going on. How much validation that is occurring depends on what you are doing. Shu's recommendation for disabling processors that are not running should help a great deal. - There is no such thing as "Max Cron Driven Thread Count". I am going to assume you meant "Max Event Driven Thread count." There is nothing you will add to your canvas that will use the "Event Driven" scheduling strategy. You physically need to change the configuration on a component to use "Event Driven". Event Driven is consider experimental and deprecated in favor of advance made with the Timer driven Scheduling strategy. By setting "Max Event Driven Thread count" to 50 you are creating a pool of 50 reserved threads. I recommend not using "Event Driven" Scheduling strategy anywhere and reducing the max Event Driven thread count setting to "1". Reducing the "Max Event driven thread count" setting will require a NiFi restart.
... View more
05-09-2018
05:26 PM
2 Kudos
@David Miller Sorry for leaving out some of the details. The ListSFTP and FetchSFTP processors where originally developed and added to NiFi back in Apache NiFi 0.4.0. The 0.x versions of NiFi did not use zookeeper for cluster or state. ZK was introduced with the major redesign work that went into Apache NIFi 1.x. - To avoid issues for users upgrading from 0.x to 1.x+ versions of NiFi, the distributedMapCache properties remained in all the state keeping processors created prior to 1.x release. NiFi 1.x and newer version will automatically store state in ZK. Having the DistributeMapCache configured gives users who had state previously stored in a cache server to be read and NiFi would then write that state to ZK moving forward. - So in newer versions (NiFi 1.x +), there is no need to use the distributeMapCache property. - Thanks, Matt
... View more
05-09-2018
04:45 PM
@David Miller The use of the distributedMapCache controller service by ListSFTP processor is used to store state information and has nothing to do with distribution of FlowFiles to all nodes in a NiFi cluster. - The ListSFTP processor should still only be scheduled to run on primary node only. Then fed to a RPG to redistribute the listed Flowfiles to all nodes before a FetchSFTP processor retrieves the content. - Zookeeper is used to elect a primary node in your NIFi cluster and from time to time a new primary node may be elected. The purpose of the distributeMapCache is so the last known state of the running listSFTP processor can be stored somewhere all nodes can access it. That way when a primary node change occurs, the ListSFTP processor that starts running on a different node does not list files the previous primary node ListSFTp processor already listed. - Thanks, Matt
... View more
05-09-2018
04:00 PM
1 Kudo
@Prakhar Agrawal Shu's answer deals purely with the responsiveness of the NiFi UI and has nothing to do with the performance of running dataflows. Disabling a processor does not mean it is removed from the canvas. A processor component in a disabled state is not validated by the NIFi controller. You can enable and run processors anytime you like and then stop and disable them when done. At a minimum you should disable all your invalid processors since they are not capable of running anyway. - So the real question is what you mean by "responding very slow" specifically the canvas or do you notice flows processing Flowfiles slower. How did you come to that conclusion? - This may come down to tuning your dataflow(s) themselves. What is "Max Timer Driven Thread Count" set to in "controller settings" found in global menu. Default is only 10. Which means all processor must share only 10 cpu threads. Processors that appear to be processing slowly, how many concurrent tasks have they been configured to use, run schedules, etc...? - Thanks, Matt
... View more
05-09-2018
12:12 AM
@Hans Feldmann - You are hitting a known bug in MiNiFi 0.4.0: https://issues.apache.org/jira/browse/MINIFI-435 - Fix is part of MiNiFi 0.5.0 or you can roll back to MiNiFi 0.3.0 which i understand works as well. - Thank you, Matt
... View more
05-07-2018
05:46 PM
1 Kudo
@Davide Vergari @srinivas p - Let me explain what is going on here so you can understand why the configuration change made helps in some cases and not others. - When you add a component to the canvas of a NiFi cluster the following steps are performed. 1. That request is forwarded to the current elected cluster coordinator on behalf of the user who added the component. 2. The cluster coordinator then replicates that request to all the nodes connected in the cluster. (the nifi.cluster.node.protocol.threads=10 setting dictates how many concurrent request can be made, so larger clusters will need to have this value increased) 3. Each node must then make the change and respond back to the cluster coordinator. - While this process is consistent for every such replicated request, not all changes are equal. The action of selecting a bunch of components on the canvas copying and pasting them or instantiating a large template to the canvas also constitutes a single replication requests instead of many requests. These component bundles are referred to as snippets in NiFi. This action is not asynchronous. this means that each node must add every component (processors, connections, controller services, etc..) from this snippet before it responds to the cluster coordinator. Depending on size of the snippet and load on the server, this request may very likely exceed to configured timeout. This results in those nodes that timed out being disconnected from cluster. - Increasing the timeouts allows more time for these snippets to be instantiated and response to be received. Because there is no way to know how large these snippets are, the timeout setting that works for one user may not work for others. - Two things to keep in mind here: 1. How many node requests can be made concurrently (as shown above default is 10). Using a 16 node NiFi cluster as an example, 10 nodes must respond before the other 6 even get the request. so increase this value. 2. The nifi.cluster.node.connection.timeout and nifi.cluster.node.read.timeout can be set to much higher values. Even settings these timeouts to 2 - 5 minutes does not mean every request will take that long. It simply means that you will allow that much time before the cluster coordinator makes the decision to disconnect the node due to timeout. - There is work on the roadmap to redesign these types of replication requests in to asynchronous type requests eventually. Once that happens user will not need such high timeouts configured. - Thank you, Matt
... View more
05-07-2018
05:02 PM
@John T The ListenHTTP processor works just like any one of our other Listen based processors. This processor should be configured to run on every node. That way every node can receive data. The listen based processors are configured to Listen on a specific port. So the endpoint for a listenHTTP would be something like: - http(s)://<hostname>:<listenerport>/<base path> - You could have an external load-balancer that is configured to receive all your inbound traffic and load-balance it all the node sin the NiFi cluster. - You could also install NiFi or MiNiFi at each of your data sources and use NiFi's Site-To-Site (S2S) protocol to load-balance the delivery of FlowFiles to this target cluster. - Listen based processors are not ideal for the Listen (primary node) --> RPG (S2S) --> input port (all nodes) --> rest of dataflow model. Tat is because the Listen based processor receive the entire payload. This means your primary node has to handle a lot of writes to content repo (all data) before then sending that data across the network to other nodes (redistribution). can be an expensive waste of resources. That is why load-balancing with this type of processor is better done out front of NiFi. - Thanks, Matt
... View more
05-07-2018
04:48 PM
@srinivas p *** Forum tip: Avoid responding to existing answers with a new answer. Instead use comments to correspond within a single answer. - That being said, your environment is very different from environment in this original question. Far fewer nodes. Are you running same version of HDF/NiFi? - - I actually recommend starting a new question with your environment specific details. You'll get my traction answer wise that way. - Thanks, Matt
... View more