Member since
07-30-2019
3431
Posts
1632
Kudos Received
1012
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 100 | 01-27-2026 12:46 PM | |
| 506 | 01-13-2026 11:14 AM | |
| 1110 | 01-09-2026 06:58 AM | |
| 944 | 12-17-2025 05:55 AM | |
| 449 | 12-17-2025 05:34 AM |
05-07-2018
12:50 PM
@Mahmoud Shash Please do not forget to login and click "accept" at the bottom of whichever answer provided was able to address your original question. This helps user of this forum focus in on the working solutions. Thank you, Matt
... View more
05-07-2018
12:17 PM
1 Kudo
@Mahmoud Shash - I noticed that you have this processor configured to run "primary node" only. You should never run processors that operate on incoming FLowfiles from a source connection with "primary node" only. In a NiFi cluster, the zookeeper elected primary node can change at anytime. So it becomes possible that the data queued in that connection feeding your InvokeHTTP processor is sitting on what was previously a primary node. Since your invokeHTTP processor is configured for "Primary node" only it will not be running anymore on the old primary node to work on those queued FlowFiles. - Suggestion: 1. From Global menu in upper right corner of NiFi UI, click on "cluster". From the UI that appears take note of who the current Primary node is in your cluster. exit out of that UI. 2. From Global menu in upper right corner of NiFi UI, click on "Summary". With "CONNECTIONS" tab selected form across top, locate the connection with the queued data (You can click on "Queue" column name to sort the rows). To the far right of that row you will see 3 stacked boxes icon. clicking this will open a new UI where you can see exactly which node(s) have these queued FlowFiles. If it is not the current primary node, then the invokeHTTP processor is not going to be running there to consume them. - Only processors that ingest new Flowfiles that do not take an incoming connection form another processor and that are using non cluster friendly protocols should be scheduled for "primary node" only. All other processors should be scheduled for all nodes. - If queued data is actually on the primary node, you will want to get a thread dump to determine what the invokeHTTP processor thread that is active is waiting on. ( ./nifi.sh dump > <name of your dump file> ). In this case it is likely waiting on some response from your http end-point. - Thank you, Matt
... View more
05-04-2018
06:50 PM
@Veerendra Nath Jasthi The DN there is coming from the keystore being used by your NiFi nodes. I have no idea why the certs created for your servers all have nifiadmin in them.... ... But just like your user DN, the node identities must match exactly with what is in those server certs in the keystore.. - <property name="Node Identity 1">CN=nifiadmin, OU=NIFIrsdevhdf1.medassurant.local, OU=NIFI</property>
<property name="Node Identity 2">CN=nifiadmin, OU=NIFIrsdevhdf2.medassurant.local, OU=NIFI/</property>
<property name="Node Identity 3">CN=nifiadmin, OU=NIFIrsdevhdf3.medassurant.local, OU=NIFI</property> - so you will need to edit your node identities so they match the above and once again stop NiFi, remove your users.xml and authorizations.xml files, and then start NiFi again via Ambari. - Thank you, Matt
... View more
05-04-2018
04:16 PM
@Veerendra Nath Jasthi You are so very very close. Remember how i commented above that the DN string must match exactly? Your admin DN is: CN=nifiadmin, OU=NIFI But you entered the following as your Initial Admin Identity: CN=nifiadmin,OU=NIFI Note that you are missing the space between "CN=nifiadmin," and "OU=NIFI" - Thanks, Matt
... View more
05-04-2018
03:57 PM
@Prakhar Agrawal @Felix Albani is correct. There is no way to automatically have a node delete his flow.xml.gz in favor of the clusters flow. If we allowed that it could lead to unexpected data loss. Lets assume a node was taken out of the cluster do perform some side work and the user tries to rejoin it to cluster, if it just took the clusters flow, any data queued in a connection that doe snot exist in clusters flow would be lost. It would be impossible for Nifi to know if the joining of this node to this cluster was a mistake or intended, so NiFi simply informs you there is a mismatch and expects you to resolve the issue. - Also noticed you mentioned "NCM" (NiFi Cluster Manager). NIFi moved away from having a NCM staring with Apache NIFi 1.x version. Newer version have a zero master cluster where any connected node can be elected as the cluster's coordinator. - Thanks, Matt
... View more
05-04-2018
03:46 PM
@Veerendra Nath Jasthi Your latest two screenshots confirm what is suspected above. You did not have the correct/full DN configured as your "Initial Admin Identity". The corrective actions I provided in previous response should get you squared away here.
... View more
05-04-2018
03:30 PM
@Veerendra Nath Jasthi You can see in your users.xml file that the usr identity does not match exactly with what is in your nifi-user.log. They must match exactly. <user identifier="49527e2e-41db-3e98-9926-49021fd68a56" identity="CN=nifiadmin,OU="/> while user.log has: CN=nifiadmin, OU=NIFI Assuming you had above set as your Initial Admin Identity in Ambari NiFi configs and you deleted the users.xml and authorizations.xml files on all nodes before staring NIFi via Ambari, new users.xml and authorizations.xml files should have been generated correctly. - So you have two options here: 1. Stop NiFi and manually edit the users.xml file on every node so that the identity matches exactly and restart NiFi on all nodes. or 2. Stop NiFi via Ambari, verify "Initial Admin Identity" NIFi property is set correctly, delete the users.xml and authorizations.xml on all nodes, and teh start NiFi via Ambari. Lates configs will be written to NiFi config files and NiFi will create new users.xml and authorizations.xml files on each node on startup. - Thanks, Matt
... View more
05-04-2018
02:57 PM
@Veerendra Nath Jasthi So nifi-user.log shows that authentication was successful for your user "CN=nifiadmin, OU=NIFI". This puts the issue squarely on the authorization side of things. Authorization configurations are in the authorizers.xml file. - Since it sounds like you are using the default file based authorization provider, you will want to inspect what is in your users.xml and authorizations.xml files NiFi generated. - What do you have in your users.xml? You should find an entry for "CN=nifiadmin, OU=NIFI" in there associated to a unique UUID. That UUID is then used to associate that user to various access policies in the authorizations.xml file. Be mindful that NiFi is case sensitive and blank spaces are valid characters including leading and trailing whitespace. "CN=nifiadmin, OU=NIFI" is not equal to "CN=nifiadmin, OU=NIFI " (trailing white space) to NiFi. - Also confirm what URL you are trying to access? (https://<nifinode-hostname>:9091/nifi ) - Thanks, Matt
... View more
05-04-2018
12:36 PM
@vincent yernaux *** Forum tip: Try to avoid responding to an answer by starting a new answer. This makes following a single threaded discussion hard. Instead use the "add comment" on the answer you want to have open dialog. - Not really sure how you ended up in this state... Permission denied tells me the user you are currently logged in as does not own the NiFi process, have execute permissions on the nifi.sh file, or it could be some bogus output simply because the pid file is missing. - I know there was a bug in the HDF 3.1 nifi service install that failed to properly set ownership on a number of NiFi files/directories to the nifi user. So you may want to go to /usr/hdf/3.1.1.0-35 directory and performa recursive ownership change on the nifi directory ( chown -R nifi.nifi nifi ). - You can use the "ps -ef|grep nifi" command to get the process ID for the two java processes associated to NiFi. You can then manually kill those two processes. - Then try starting NiFi again from Ambari UI. - Thanks, Matt - If you found this answer addressed your question, please take a moment to login to the forum and click "accept" on the answer.
... View more
05-04-2018
12:17 PM
@Benjamin Bouret - It is common for the cluster Coordinator and Primary Node to change from time to time in a NiFi cluster, so you need to careful when designing your flows that utilize processors running "Primary node" only to make sure processing can still continue when a switch occurs. - I am going to assume since you got duplicates here that the local directory you have your GetFile processor pointing at is mounted across all your NiFi nodes. In order to avoid duplicates you will need to use processors that support state. The GetFile processor is one of our original processors that was developed before state management was put in place. It has been deprecated in favor of the newer listFile and FetchFile processors. The ListFile processor has the ability to store state either local to each node (not shared for cases where each node is pulling from its own non shared directory) or cluster state (state is stored in zookeeper where same processor on every node has access to it). Cluster state here would allow you to run this processor against a shared mount to all you nodes in "Primary node" only setup. If primary node changes the new primary node will start this processor and pull the last known recorded cluster state before performing a new listing. This should greatly reduce the likelihood of seeing duplicates. - NiFi will favor duplicate data over lost data. So there will still exist a small window of opportunity where duplication could occur. For example original primary node ingested data but some network issue for example prevented last state to be written to zookeeper. The new node would then not get the most current state which may result in duplication. - The list/fetch processor model also allows you to spread the workload across your cluster more easily. A flow would consist of: listFile (Scheduled primary node only) --> Remote Process group (configured to point back at cluster to redistributed listed files) ---> fetchFile ( running on all nodes to retrieve content of listed files) --> rest of flow... - Thanks, Matt - If you found this answer addressed your question, please take a moment to login to the forum and click "accept" on the answer.
... View more