Member since
07-30-2019
3257
Posts
1592
Kudos Received
956
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
76 | 05-14-2025 10:29 AM | |
36 | 05-13-2025 07:01 AM | |
140 | 05-02-2025 07:25 AM | |
272 | 04-25-2025 05:54 AM | |
254 | 04-25-2025 05:44 AM |
05-14-2025
12:43 PM
@asand3r With Archive disabled, NIFi is no longer tracking the files left in the archive sub-directories. You can remove those files while NiFi is running. Just make sure you don't touch the active content_repository claims. Matt
... View more
05-14-2025
11:54 AM
@alan18080 The Single-User-Provider for authentication was not intended for production use. It is a very basic username and password based authenticator that support only a single user identity. When you access the UI of a NiFi node, you are authenticating with only that node. The provider generates a client token which your browser holds and a corresponding server side token/key held only by the node you authenticated with. This is why you need to use sticky sessions (Session Affinity) in your load-balancer so that all subsequent request go to same NiFi server. There is no option in NiFi that would allow that client JWT token to be accepted by all nodes in a NiFi cluster because of the uniqueness of the JWT generated token to a specific node. Related: NIFI-7246 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
05-14-2025
10:29 AM
1 Kudo
@asand3r Changing following to false turns off archiving. nifi.content.repository.archive.enabled NiFi does not clean-up files left in these directories once archive is disabled. Since archive is disabled the archive code that would scan these directories to remove old archive data is not longer executing. You'll need to manually purge the archived content claims from the archive sub-directories after disabling content_repository archiving. So your two nodes that still have archive data had that data still present at shutdown while the others did not have archive data after shutdown. 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
05-14-2025
05:52 AM
@asand3r Need some more detail to provide a good answer here... What version of Apache NiFi or Cloudera Flow Management are you using? After changing "nifi.content.repository.archive.enabled" to false in the nifi.properties file, did you restart NiFi? If you manually inspect the archive sub-directories, do any of them still hold files or are all of the archive sub-directories within the content_repository empty? If they are empty then archive clean-up is complete. You mention " I've saw messages, that archived data is never cleanup", can you share this message you are seeing which I assume is from the nifi-app.log? Keep in mind that disabling archive will not prevent content_repository from filling the disk where it resides to 100%. Content claims associated to actively queued FlowFiles within your dataflows on the NiFi canvas will still exist in the content_repository. 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
05-14-2025
05:24 AM
@s198 There is no other processor that provides this same functionality. This Apache community processor is not tested or maintained by Cloudera and thus is not included in the list of Cloudera supported NiFi processor components. This does not mean that the processor has any known issues, but does mean that Cloudera would not be obligated to provide bug fixes if they did arise nor provide support for this processor component. If this is an important processor for you and you have a Cloudera Flow management license, I would encourage you to raise this with your Cloudera Account owner requesting that Cloudera add this component to the list of supported components. Just making this formal request does not guarantee it will be added, but gets visibility around the processor for consideration. Thank you, Matt
... View more
05-13-2025
12:33 PM
1 Kudo
@s198 I can't think of any NiFi stock processors that would create dynamic attributes nor can I figure out why you would so this. I understand that you are using these "dynamic" ("${SourceFilePath}/${SourceFile}") attributes downstream in your dataflow, but to do so you are configuring these strings in that downstream processor meaning you need to know what they will be before even starting your processors. If that is the case, these are not really dynamic since you need to know what they are to configure your downstream processors. If the following strings exist in all your source json, you can just declare them manually with EvaluateJsonPath processor to get the corresponding values from the FlowFile content: SourceFilePath SourceFile SourceFilePattern Can you share more info about your complete dataflow for better understanding? What is happening downstream of your custom processor? Thank you, Matt
... View more
05-13-2025
09:02 AM
@noncitizen Can you share your PostHTTP and ListenHTTP processor configurations and scheduling? What is the volume of FlowFiles queued to the PostHTTP? How many PostHTTP processors sending to same ListenHTTP? Does ListenHTTP outbound connection queue fill resulting in backpressure being applied on the ListenHTTP? Since this is a sporadic issue, trying to get a better idea of setup and conditions at time of issue. Thanks, Matt
... View more
05-13-2025
07:01 AM
@melek6199 When you setup an Apache NiFi cluster versus a standalone NiFi instance, the cluster coordinator and zookeeper become part of the setup. Since a NiFi cluster is a zero master cluster, the UI can be access from any cluster connected node. So your user authenticates to the specific node you are accessing and then that node proxies the user request (initially that would "access the flow") on behalf of that user to the cluster coordinator that replicates request to all connected nodes. The exception means that node with node identity derived from certificate DN "CN=vtmrt3anifit04.x.com, OU=NIFI" was not properly authorized to "proxy user requests". All your NiFi node identities must be authorized to "proxy user requests". While it appears that your NiFi authorizers.xml is setup correctly with your 4 node's identities (case sensitivity also correct), I suspect it was only setup correctly after NiFi having already being started before it was configured correctly. The "file-access-policy-provider" will only generate the authorizations.xml during NiFi startup if it does NOT already exist. It also will not modify an already existing authorizations.xml file. The "file-user-group-provider" will only generate the users.xml during NiFi startup if it does not already exist. It also will NOT modify an already existing users.xml file. So I would inspect the users.xml to make sure it contains all 4 node identities (case sensitive correctly) and then verify the authorizations.xml has those node's properly authorized. So I would start here to make sure above is correct on all 4 nodes. 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
05-02-2025
07:25 AM
@shiva239 There are numerous things happening when a node is disconnected. A disconnected node is different then a dropped node. A cluster node must be disconnected before it can be dropped. A node can become disconnected in two ways: Manually disconnected - User manually disconnects a node via the NiFi Cluster UI. A manually disconnected node will not attempt to auto-rejoin cluster. A user can manually reconnect the node from another node in the cluster via the same Cluster UI. A node becomes disconnected due to some issue. A node that is disconnected is still part of the cluster until it is dropped. Once dropped the cluster no longer considers it part of the cluster. This distinction matter when it comes to load balanced connections that use a load balance strategy other then Round Robin. Load balance connections use NiFi Site-To-Site protocol to move FlowFiles between nodes. Only Connected nodes are eligible to have FlowFiles sent over Site-To-Site. Even a disconnected node is still able to load-balance FlowFiles to other nodes still connected in the cluster. (so when you had 1 node disconnect from cluster, if you went to that nodes UI directly the load balanced connection would appear to processing all FlowFiles normally. This is because the two nodes where it sends some FlowFiles by attribute are still connected and thus it is allowed to send to them. The other FlowFiles by attribute destined for disconnected node never leave the node and get processed locally. Over on the still cluster connected nodes the story is different. They can only send to connected nodes and any FlowFiles destined for that disconnected node will begin to queue. Even if you stopped the dataflows on the disconnected node the FlowFiles would continue to queue for that node. So stopping the dataflow on a node that disconnects would still present same issue. A disconnected node is still aware of what node are part of the cluster and can still communicate with ZK to know which node is the elected cluster coordinator. Lets say a second node disconnects. The disconnected node would stop attempting to send to that now disconnected node and queue FlowFiles destined for that node. Only the round robin strategy will attempt to redistribute FlowFile to remaining connected nodes when a node becomes disconnected. The Partition by attribute and Single Node strategies are used when it is important that "like" FlowFiles end up on the same node for downstream processing (So once a like FlowFile, which in your case are FlowFiles with same value in the orderid FlowFile attribute, is marked for node 3, all FlowFiles with that same orderId will queue for node 3 as long as node three is still a member of the cluster. A disconnected node is still part of the cluster and will have some "like" FlowFiles already on it, so we would not want NiFi to start sending "Like" data to some other node all of a sudden. Now if manual user action was taken to drop the disconnected node, then the load-balanced connections would start using a different node for the FlowFiles original being allocated to the disconnected node. NiFi also offers an off-loading feature. This allows a user with proper authorization to off-load a disconnected node (IMPORTANT: only a reachable and running node can be offloaded successfully. Attempting Offloading of a down or unreachable node will not work). Once a node is disconnected a user can choose to offload the node this is typical if say a user want to decommission a node in the cluster. Initiating off-load will send a request to that disconnected node to stop, terminate all running components and then off load the queued FlowFiles to other nodes connected to the cluster. If cluster nodes where allowed to continue to load-balance to disconnected node(s), this capability would fail as you would end-up with a constant loop of FlowFiles back to disconnected node. Once offloading completes that disconnected node could be dropped and the FlowFiles that were offload would get load balanced to remaining nodes still members of the cluster. I think I covered all the basic behind the scenes functionality of load-balanced connection with regards to disconnected node behaviors. In your scenario, your node, the node became disconnected due to some issue when changing the version of a version controlled process group. I would recommend a new community question if you need help with that issue as it has no direct relationship with how load-balance connection function or disconnected nodes still running discussed here. 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
04-28-2025
05:41 AM
1 Kudo
@shiva239 Is this expected behavior for NiFi node to be active although it is not in cluster Yes: A disconnected node that is still running will continue to run its enabled and running NiFi components processing the existing FlowFiles on that specific node and ingesting new data as well. The node will still be aware that it is a node that belongs to a cluster, so components will still utilize Zookeeper for any cluster stored state data (read and update). It is simply no longer connected but all functionality persists. What i can not do while disconnect is receive and configuration changes that the elected cluster coordinator is replicating to all nodes currently part of the cluster. From a node in the cluster, you should be able to go to the cluster UI and look at the node that is marked as disconnected to see the recorded reason or disconnection (such as lack of heartbeat). A node that disconnects not as the result of user manual action, should automatically attempt to reconnect as it will still attempt to send heartbeats to the elected cluster coordinator reporting from Zookeeper. When the cluster coordinator receives one of these heartbeats from the disconnected node, it will initiate a node reconnection. During this reconnection the nodes dataflow (flow.json) is compared with the cluster's current dataflow. In order for the node to rejoin its local flow must match cluster flow. If it does not, the node will attempt to inherit the cluster flow. It inheritance of the cluster flow is not possible, this will be logged with reason (one common reason is cluster flow no longer has a connection that the local flow still has which contain FlowFiles. NiFi will not inherit a flow that would result in dataloss on the local node). Can we alter the behavior through configuration to stop processors temporarily while node is not connected to cluster? NiFi has no option to stop processors on a disconnected. Not clear on the use case why you would want to do this? The expectation is that an unexpected disconnection (commonly due to lack of heartbeat) would auto reconnect once heartbeats resume to cluster coordinator. Plus a disconnected node does not mean loss of functionality in the disconnected node. The disconnected node can still execute its dataflow just as it was while connected. While all nodes in the cluster keep their dataflows in-sync and use zookeeper for any cluster state sharing, they all execute base do their local copy of the flow.json and execute their own node specific set of FlowFiles. This continues even when a node is disconnected because that node still knows it was part of a cluster. I find this comment interesting: "Furthermore, the affected node did not attempt to reconnect to the cluster on its own." Did you check the reason recorded for why this node disconnected? (Did a user manually disconnect the node? or was it disconnected for another reason) Did you inspect the logs on the disconnected node and the elected cluster coordinator around the time of the disconnection? Do you see disconnected node logging any issue communicating with Zookeeper? Do you see disconnected node attempting to send heartbeats to the currently elected cluster coordinator? Is the current cluster coordinator logging receiving these heartbeats? 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