Member since
07-30-2019
3172
Posts
1571
Kudos Received
918
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
71 | 02-14-2025 08:43 AM | |
77 | 02-12-2025 10:34 AM | |
425 | 02-06-2025 10:06 AM | |
139 | 01-31-2025 09:38 AM | |
125 | 01-30-2025 06:29 AM |
02-14-2025
01:22 PM
Thank you very much for your answer 🙂 I tried it and found it worked.
... View more
02-13-2025
01:22 PM
@OfekRo1 I looked at the StandardProvenaceEventRecord source in Github plus I know many of the open source contributors. 😀 https://github.com/rdblue/incubator-nifi/blob/master/commons/data-provenance-utils/src/main/java/org/apache/nifi/provenance/StandardProvenanceEventRecord.java Your welcome and thank you for being part of the community!
... View more
02-13-2025
09:56 AM
@mks27 What you are trying accomplish is not possible in NiFi. In my 15 years of working with NiFi, I believe this is first time I have seen such a request. So what you are expecting to happen is NiFi presents the login window and a user supplies a username and password. You then expect NiFi to attempt authentication via one ldap provider and if that results in unknown username or bad password response, move on to next ldap provider an attempt again? The users that will need access to your NiFi don't all exist in just one of your ldaps? I suppose if you have a multi node NiFi cluster setup, you could configure the ldap-provider on one node to use one of the ldap servers and the ldap-provider on another node to use the other ldap server. Since the NiFi cluster can be accessed from any node, you would just need make sure your users access the NIFi cluster from the appropriate node that is configured with their ldap server. NOTE: Authorization (happens after successful authentication) need to be identical on all nodes in a cluster, but that is not an issue here. You'll just configure the authorizers.xml so that all user and group identities from both ldaps are authorized appropriately. This bootleg way of facilitating authentication via multiple LDAPs, is not something I have ever tested/tried, but believe would work. You could also raise an improvement jira in Apache Jira NiFi project to see if the community might be interested in implementing this change, but I don't anticipate there is much demand for it. https://issues.apache.org/jira/browse/NIFI Please help our community thrive. 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
02-13-2025
06:14 AM
@mridul_tripathi The best way to check if two files have the exact same content is to generate a hash of the content and then compare that those two hashes to see if they are the same. While comparing hash values allows you to detect if the content is the same between NiFi FlowFiles, it sounds like you want to determine what is different and not just that they are different? NiFi does not have a processor that is designed to do this function. So what is the full use case here? SFTP1 is source of truth always expected to have correct content? SFTP2 is the backup or expected to have content that matches SFTP1? Example use case: You could pull a file from SFTP2 (File to be verified), create a FlowFile attribute containing the hash of this file (Hash-SFTP2), then zero out the content (Modify bytes), then pass this FlowFile to a FetchSFTP (used to fetch file of same filename from SFTP 1), create another FlowFile attribute (hash-sftp1), Now you can use a RouteOnAttribute that compares the two hash attributes to see if they are the equal. If false, route the FlowFile to PutSFTP to overwrite the file on SFTP2 withe FlowFiles current content from SFTP1 so that both SFTP server now have matching content for this filename. Now if your use case is to somehow output a FlowFile containing all the difference in the content, that is more challenging and would likely require something custom (custom processor or some custom script) Please help our community thrive. 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
02-12-2025
11:51 AM
hey @MattWho My nifi instance and little python script run on local host. My python script sends a packet as ip address 224.1.1.1 on port 10000. When i configure my processor, omitting the sending host and sending port, it still doesn't receive the packet from 224.1.1.1. If i omit the send host and port, and just have 10000 for port. It also doesn't work, since that assumes the packet is being sent from 127.0.0.1 (localhost). I removed the site to site properties like you recommended. Essentially i am just trying to send a multicast message to nifi, and trying to figure out how to configure the current processor to do that. Or I will just try and create a custom udp listener to handle multicast messages. Thanks!
... View more
02-12-2025
10:34 AM
@fy-test The NiFi node that disconnects due to a flow mismatch should inherit the cluster flow when it attempts to rejoin the cluster. The only time this is not possible is if the cluster flow includes change that would result in dataloss. Example: Cluster flow has a connection removed that on the connecting node still has queued FlowFiles. NiFi has not feature to force removal/archive of a flow.json.gz on a disconnected node. You could file an Apache NiFi improvement jira here: https://issues.apache.org/jira/projects/NIFI But first step is to identify why your node is not able to inherit cluster flow and rejoin the cluster. What is the exception logged when it attempts to rejoin the cluster? Please help our community thrive. 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
02-11-2025
09:34 AM
@nifi-srinikr The exception you shared is complaining about a null value for the "flowConfigurationFile": Caused by: java.lang.NullPointerException: Cannot invoke "java.io.File.exists()" because "flowConfigurationFile" is null On NiFi startup NiFi will check if the flow configuration file that NiFi is configured to use exists. If it does not, NiFi will create it. In your case it appears this property is null and this the if exists check is failing. The configuration file location and filename is specified by this property in the nifi.properties file: nifi.flow.configuration.file=<path to>/flow.xml.gz (Apache NiFi 1.x releases) or nifi.flow.configuration.file=<path to>/flow.json.gz (Apache NiFi 2.x releases) What version of Apache NiFi are you using? Please help our community grow and trhive. 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
02-11-2025
07:19 AM
@jfs912 Has the reply helped resolve your issue? If so, please mark the appropriate reply as the solution, as it will make it easier for others to find the answer in the future. Thanks.
... View more
02-07-2025
02:09 PM
@doora Has the reply helped resolve your issue? If so, please mark the appropriate reply as the solution, as it will make it easier for others to find the answer in the future. Thanks.
... View more
02-07-2025
12:09 PM
@Darryl You will certainly have issues using localhost even outside docker with a multi-node NiFi cluster since only the NiFi node installed in the same server as Keycloak would have any chance of connecting with Keycloak. Understand that a NiFi cluster can bae accessed form any node in the NiFi cluster. So first thing i would have suggested is using the hostname of the actual server that is hosting Keycloak rather then localhost. I am not familiar with Keycloak myself and the article you reference (while i know the author) is very old. A lot has likely evolved/changes with regards to security since it was written. Glad to hear you had some success even if it was outside of Docker and thank you with sharing what you learned with the community. Matt
... View more