Member since
06-26-2015
515
Posts
137
Kudos Received
114
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
2073 | 09-20-2022 03:33 PM | |
5710 | 09-19-2022 04:47 PM | |
3085 | 09-11-2022 05:01 PM | |
3426 | 09-06-2022 02:23 PM | |
5409 | 09-06-2022 04:30 AM |
02-14-2022
02:52 AM
Hi, @rzilber , The latest release of Cloudera Flow Management, CFM 2.1.3, is tested and supported on Java 8 and 11, as listed here. This release contains NiFi and NiFi Registry 1.15.2. I believe the upstream version of NiFi also currently supports only Java 8 and 11, as per release notes of version 1.10.0. Cheers, André
... View more
02-13-2022
05:24 PM
@Chhavi , Please try this: curl -X POST \ -H 'Content-Type: application/x-www-form-urlencoded' \ -d 'username=bob&password=supersecret1' \ "https://nifi-1.example.org:8443/nifi-api/access/token" Regards, André
... View more
02-13-2022
04:56 PM
1 Kudo
Hi @n_tulett , The Set-Cookie attribute returned by the first processor must be added as a Cookie header for the next InvokeHttp processor. You can do this by adding the following dynamic property to the second InvokeHttp processor: Regards, André
... View more
02-13-2022
02:40 PM
Nice article, @carrossoni ! I know it's been a while, but just saw this for the first time 🙂
... View more
02-13-2022
02:30 PM
@Saraali , To call the API, the first thing you need is the processor UUID, which you can find in the UI: With the processor UUID, I can call the process API endpoints. For example, to get details about the processor I can do a GET on the /processor/{id} enpoint: $ curl "https://nifi-1.example.org:8080/nifi-api/processors/f525c671-017e-1000-ffff-ffffa16ab615" { "revision": { "clientId": "f52573c3-017e-1000-62a7-8b0be35e3b2e", "version": 6 }, "id": "f525c671-017e-1000-ffff-ffffa16ab615", "uri": "https://nifi-1.example.org:8080/nifi-api/processors/f525c671-017e-1000-ffff-ffffa16ab615", "position": { "x": 384, "y": 176 }, ... } To make modifications to the processor we have to pass the revision information retrieved in the command above. So, for example, to call run-status to stop the processor I can execute the following command, using the revision from the previous output: $ curl \ -X PUT \ -H 'Content-Type: application/json' \ -d '{"state": "STOPPED","revision":{"clientId":"f52573c3-017e-1000-62a7-8b0be35e3b2e","version":6}}' \ "https://nifi-1.example.org:8080/nifi-api/processors/f525c671-017e-1000-ffff-ffffa16ab615/run-status" Cheers, André
... View more
02-13-2022
02:07 PM
@yamaga , does the above help?
... View more
02-12-2022
08:42 PM
1 Kudo
Some time ago I faced an interesting problem with a cluster failing to start after I replaced an MIT KDC with a FreeIPA KDC.
For the replacement, I installed the ipa-client package on the cluster nodes, and then, changed the KDC configuration in Cloudera Manager (CM) (changed realm and KDC details, imported Kerberos user, re-generated credentials, etc..)
The cluster refused to start. Besides that, CM's KDC Login monitor kept complaining about the KDC not being healthy. I could manually kinit successfully, though, and there seemed to be no KDC problems at first glance.
After enabling debug at different places I saw that there were socket timeouts when processes tried to connect to the KDC and that those processes were actually trying to connect to the KDC over UDP, rather than TCP. The UDP requests explained the problem, since UDP traffic was blocked between the cluster and the KDC.
What's strange, though, is that the krb5.conf created by the ipa-client install had the following configuration:
udp_preference_limit = 0
According to the MIT documentation, this should force all the communication to be over TCP, instead of UDP. From the MIT website:
"When sending a message to the KDC, the library will try using TCP before UDP if the size of the message is above udp_preference_limit. If the message is smaller than udp_preference_limit, then UDP will be tried before TCP. Regardless of the size, both protocols will be tried if the first attempt fails."
Even though the "library" above doesn't refer to the Java library, Java does recognize the udp_preference_limit parameter from the krb5.conf, as explained here.
So, I'd expect that, with that setting, TCP would be tried first for all requests, but it was not. And after 3 UDP attempts, the connection would actually fail altogether without trying to connect over TCP.
I found it interesting, though, that the ipa-client installation set that value to 0. At Cloudera, we have always recommended to customers to set it to 1 instead. So I went ahead and changed the entry in the krb5.conf to:
udp_preference_limit = 1
And amazingly everything worked after that!! The debug logs didn't show traces of UDP requests any longer, the cluster came up correctly and the CM alerts went away.
Interesting how something really small can badly break things leaving very little vestiges of what's going on...
The JDK behavior is coming from this.
So, in short, to be on the safe side always set udp_preference_limit to 1 and never to 0.
... View more
02-12-2022
08:02 PM
1 Kudo
If the different types of files are in different directories in HDFS, for example, you can use Expression Language to set the values for fragment.index and metric, using a single ListHDFS -> FetchHDFS -> UpdateAttribute. The expression below sets the value for metric according to the path where the file came from: ${path:equals("/tmp/input/dir1"):ifElse("a", ${path:equals("/tmp/input/dir2"):ifElse("b", ${path:equals("/tmp/input/dir3"):ifElse("c", ${path:equals("/tmp/input/dir4"):ifElse("d", ${path:equals("/tmp/input/dir5"):ifElse("e", ${path:equals("/tmp/input/dir6"):ifElse("f", "other")})})})})})} You can do the same for fragment.index.
... View more
02-12-2022
07:40 PM
How do you differentiate the files in HDFS? Are they in different directories? Have different filenames?
... View more