Member since
07-30-2019
3436
Posts
1633
Kudos Received
1012
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 158 | 01-27-2026 12:46 PM | |
| 575 | 01-13-2026 11:14 AM | |
| 1272 | 01-09-2026 06:58 AM | |
| 1039 | 12-17-2025 05:55 AM | |
| 505 | 12-17-2025 05:34 AM |
04-02-2020
11:45 AM
@Gubbi I think your ListFile proc is still executing 0 sec. Reference our private message.
... View more
04-01-2020
06:09 AM
The site does not use SSL, but shares an IP address with some other site that does.
... View more
03-31-2020
08:31 AM
There was a bug [1] in the TLS handshake negotiation process in Apache NiFi 1.11.0 - 1.11.3. NiFi 1.11.4 was released on March 22, 2020, which fixes this issue. I recommend upgrading to the latest version. [1] https://issues.apache.org/jira/browse/NIFI-7223
... View more
03-30-2020
10:10 PM
Yes @MattWho, you are awesome, adding the node resolved the issue
... View more
03-27-2020
01:39 PM
1 Kudo
@Petr_Simik No matter which processor you are looking at the stats presented all tell you the same information: In <-- Tells you how many FlowFile were processed from one or more inbound connections over the last rolling 5 minute window. With this processor you have it configured the "wait mode" to leave the FlowFile on the inbound connection. So the processor is constantly looking at the file over and over again until the configured expiration time has elapsed. Read/Write. <-- Tells you how much FlowFile content was read from or written to the NiFi content repository (helps user identify processors that may be disk I/O heavy) Out. <-- Tells you how many FlowFiles have been released to an outbound connection over the last rolling 5 minute window. Here you see a number that reflects only those flowfiles that expired and where sent to your outbound expired connection. Tasks/Time. <-- Tells you how many threads this processor completed execution over the last rolling 5 minutes and the total cumulative time those threads consumed from the CPU. (helps user identify what processors consume lots of CPU time) So the stats you are seeing are not surprising. While this processor works for your use case i guess, it has overhead needing to connect to a distributed map cache on every execution against an inbound FlowFile. If your intent is only to delay a FlowFile for 1 second before it proceeds down the flow path, a better solution may be to just use an updateAttribute processor that creates an attribute with current time and RouteOnAttribute processor that checks to see if that recorded time plus 1000 ms is less than current time. Then loop that check until it is not. Hope this helps, Matt
... View more
03-27-2020
01:20 PM
@NY Anything you can do via the NiFi canvas, you can also accomplish via the rest-api. So you can create a queue listing via a rest-api call: curl http://<nifi-hostname>:<port>/nifi-api/flowfile-queues/<connection-uuid>/listing-requests The above call will return a response that includes the URL you need to use to retrieve those results. for example: http://<nifi-hostname>:<port>/nifi-api/flowfile-queues/<connection-uuid>/listing-requests/1d98d557-0171-1000-ffff-ffffd559ca47 Then query for the listings results curl http://<nifi-hostname>:<port>/nifi-api/flowfile-queues/<connection-uuid>/listing-requests/1d98d557-0171-1000-ffff-ffffd559ca47 This return a json with all the FlowFiles from that specific connection queue from all nodes in your NiFi cluster. That json would need to be parsed for info like nodes where the "lineageDuration" epoch time is x amount of time older then now, the "clusterNodeAddress" (which node holds the file), and maybe filename". and then delete the queue listing when done. (this is important or it stays around using heap space). curl -X DELETE http://<nifi-hostname>:<port>/nifi-api/flowfile-queues/<connection-uuid>/listing-requests/1d98d557-0171-1000-ffff-ffffd559ca47 Hope this helps, Matt
... View more
03-27-2020
01:18 PM
exactly, for some reason though my nifi is 2 nodes secured cluster when I logged in it shows 4 nodes . two with secured and two with unsecured ports. stopped and followed the shared process. It came up clean.
... View more
03-25-2020
02:37 PM
@Faerballert Perhaps you clone your flowfile before the mergeContent processors. So whichever relationship you are connecting to your current mergeContent, you drag a second connection containing that same relationship to a parallel notification flow. Down this parallel flow path you use a replaceText processor to replace the content with the value from the attribute you want to merge. Then you use a mergeContent processor on this path to merge these files using a "," as your delimiter. Then from this mergeContent you do you notification. You may also want to open an Apache Jira with your use case and desired improvement for the existing mergeContent. The more details the better. Hope this helps, Matt
... View more
03-25-2020
12:27 PM
@MattWho Is HDF 3.5 already released? If not, do you know when it is planned to be released? I saw page with release notes, but repository locations are still not updated. https://docs.cloudera.com/HDPDocuments/HDF3/HDF-3.5.0/release-notes/content/hdf_repository_locations.html
... View more