Member since
07-30-2019
3436
Posts
1632
Kudos Received
1012
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 157 | 01-27-2026 12:46 PM | |
| 573 | 01-13-2026 11:14 AM | |
| 1265 | 01-09-2026 06:58 AM | |
| 1038 | 12-17-2025 05:55 AM | |
| 504 | 12-17-2025 05:34 AM |
12-23-2020
07:46 AM
@Nyk That is correct, dynamically added properties are all of type non-sensitive. You would need to build a custom processor with static configurable properties that have a PropertyDescriptor with ".sensitive(true)". I am not a developer myself, but you may find this resource useful: https://itnext.io/deep-dive-into-a-custom-apache-nifi-processor-c2191e4f89a0 If you found my answer addresses your question, please click on "Accept as Solution" below the answer. Hope this helps you, Matt
... View more
12-23-2020
06:15 AM
@te04_0172 It appears you have hit a known issue: https://issues.apache.org/jira/browse/NIFI-7954 https://issues.apache.org/jira/browse/NIFI-7831 Looks like these will be addressed in Apache NiFi 1.13 These fixes have already been incorporated in to the Cloudera HDF 3.5.2 release that is currently available. Hope this helps, Matt
... View more
12-07-2020
11:28 AM
I recommend not using nifi and working with the console. Using nifi is not recommended because additional logs are generated. It is recommended to divide and compress the files that you want to move from the console into appropriate sizes and send them. For HDFS, you can use the distcp command. https://hadoop.apache.org/docs/current/hadoop-distcp/DistCp.html
... View more
12-01-2020
06:53 AM
1 Kudo
@dzbeda Seeing "localhost" in your shared log output leads to what may be the issue. When you configure the URL in the Remote Process Group (RPG), it tells that NiFI RPG to communicate with that URL to fetch the Site-To-Site (S2S) details. Included in those returned details are things like: - number of nodes in target NiFi cluster (if standalone returns only one host) - The hostnames of those node(s) (in this case it looks like maybe localhost is being returned - Configured RAW port if configured - Whether HTTP transport protocol is enabled - etc... So when you RPG actually tries to send FlowFiles over S2S it is trying to send to localhost which results in itself rather than the actual target linux NiFi it fetched the S2S details from. When some properties are left unconfigured, NiFi returns whatever the OS resolves. I am going to guess your linux server is returning localhost rather than the actual hostname. You will want to verify your S2S configuration setup in the target NiFi (linux server): http://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#site_to_site_properties Try setting the "nifi.remote.input.host" to see if that helps you. Hope this helps, Matt
... View more
11-23-2020
05:56 AM
@venkii User/client authentication via a user certificate and Authentication via login provider are handled completely differnetly Looking at your login-identity-providers xml, I see you have configured the following: <property name="Authentication Strategy">START_TLS</property> However, you have not configured any of the TLS properties in the provider. Are you sure "START_TLS" is what you want to be using here? Your ldap URL looks to be using just ldap:// and the default unsecured port. If that is the case the "Authentication Strategy" should be set to "SIMPLE" instead of "START_TLS". The exception points to at an SSL handshake exception. It implies that a server certificate returned by the ldap server did not match (IN either DN or SAN entry) the hostname used in your ldap URL configured in the login provider. So in this case you either need to switch to "SIMPLE" (if possible) or validate the server certificate being returned by your ldap server and setup needed TLS properties in your provider. Hope this helps, Matt
... View more
10-19-2020
08:34 AM
@sarath_rocks55 If you are looking for assistance with an issue, please post a "question" in the community rather than adding a comment to a community article. Comments on community articles should be about the article content only. Thank you
... View more
09-24-2020
12:59 PM
Hi, @MattWho we actually already implemented prototypes of such custom processors and the basic principles are clear. By processor logic, I did not mean the structure of the processor like relationships. The structure is static in our case. By the processor logic, I refer, the code which is called in "onTrigger" in "StreamCallback.process". In my case, the logic can be parametrized by some configuration data (These configuration data is provided by a service or database tables). The configuration data is static during the whole processor run and must be provided during instantiation of the business logic object. You might see it as lookup, which must not happen during the processing "onTrigger", but "onScheduled" (sorry I wrote in "init" previously, that was not right)
Best regards Jaro
... View more
09-21-2020
05:53 AM
1 Kudo
@dvmishra It always best to start a new thread/question rather than adding a new question to an existing thread that already has an excepted answer. As far as being able to reset the offset for a specific consumer group from within NiFi itself, this is not something that can be done via the ConsumeKafka processors. The offset is not stored by NiFi. Offsets for each consumer group are stored in Kafka. Would not make make much sense to build such an option in to a NiFi processor if it was possible. Every time the processor executes it would reset in that case which is probably not the desired outcome. There are numerous threads online around reseting the offset in Kafka you may want to explore. Here are a couple: https://gist.github.com/marwei/cd40657c481f94ebe273ecc16601674b https://gist.github.com/mduhan/0e0a4b08694f50d8a646d2adf02542fc If you can figure out how to accomplish reset via a custom script of external command, NiFi does offer several script execution and command line execution processors. You may be able to use these processors to execute your script to rest the offset in Kafka. Aside from above, you can change the "group id" (new consumer group) and change the "offset reset" to "earliest". Then restart processor to start consuming topic form beginning again as a different consumer group. Hope this helps, Matt
... View more
09-14-2020
09:20 AM
2 Kudos
@Umakanth From your shared log lines we can see two things: 1. "LOG 1" shows "StandardFlowFileRecord[uuid=345d9b6d-e9f7-4dd8-ad9a-a9d66fdfd902" and "LOG 2" shows "Successfully sent [StandardFlowFileRecord[uuid=f74eb941-a233-4f9e-86ff-07723940f012". This tells us these "RandomFile1154.txt" are two different FlowFiles. So does not look like RPG sent the same FlowFile twice, but rather sent two FlowFiles with each referencing the same content. I am not sure how you have your LogAttribute processor configured, but you should look for the log output produced by these two uuids to learn more about these two FlowFiles. I suspect from your comments you will only find one of these passed through your LogAttribute processor. 2. We can see from both logs that the above two FlowFiles actually point at the exact same content in the content_repository: "LOG 1" --> claim=StandardContentClaim [resourceClaim=StandardResourceClaim[id=1599937413340-1, container=default, section=1], offset=1073154, length=237],offset=0,name=RandomFile1154.txt,size=237] "LOG 2" --> claim=StandardContentClaim [resourceClaim=StandardResourceClaim[id=1599937413340-1, container=default, section=1], offset=1109014, length=237],offset=0,name=RandomFile1154.txt,size=237] This typically happens when a FlowFile becomes cloned somewhere in your dataflow. For example: when a relationship from a processor is defined twice. Since you saw that GetFile only ingested file once, that rules out GetFile as the source of this duplication. But had it been GetFile, you would have not seen identical claim information. LogAttribute only has a single "success" relationship, so if you had drawn two connections with "Success" relationship defined in both, you would have seen duplicates of every ingested content. So this seems unlikely as well. Next you have your PutFile processor. This processor has both "success" and "failure" relationships. I suspect the "success" relationship is assigned to the connection going to your Remote Process Group" and the "failure" relationship assigned to a connection that loops back on the PutFile itself(?). Now if you had accidentally drawn the "failure" connection twice (one may be stack on top of the other), anytime a FlowFile failed in the putFile it would have been routed to one failure connection and cloned to other failure connection. Then on time they both processed successfully by putFile and you end up with the original and clone sent to your RPG. Hope this helps, Matt
... View more