Member since
07-30-2019
2906
Posts
1442
Kudos Received
844
Solutions
My Accepted Solutions
Title | Views | Posted |
---|---|---|
51 | 04-17-2024 11:30 AM | |
55 | 04-16-2024 05:36 AM | |
34 | 04-15-2024 05:31 AM | |
119 | 04-03-2024 05:59 AM | |
132 | 04-02-2024 01:22 PM |
06-10-2022
07:33 AM
@Abhishek27Apple I don't see in your authorizations for your user where you have granted permissions for the root process group. From the UI you will see an "Operate" panel on the left side of the canvas. Within the "Operate" panel you will see the component currently selected and an icon that looks like a key. With Nothing selected, it defaults to the root process group created when NiFi was started the very first time. Click on that key and add your user to the policies you want your user to have. By default these policies are not set for the admin as they are not needed by an admin. These policies are typically used by developers who will be building dataflows on the canvas. You can find all the access policies in the embedded documentation within NiFi or from the Apache NiFi site: https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#access-policies If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post. Thank you, Matt
... View more
06-09-2022
10:40 AM
1 Kudo
@benjbenj The ListenHTTP processor sets up a Listener on the configured port in the processor. So there is not fetch involved in this flow design. On your source NiFi, you would have a separate InvokeHttp processor for each unique MiNiFi agent you have deployed. So while your data ingestion is setup on the same port on each unique MiNiFi, your invokeHTTP processors are each configured with a different target hostname. When the invokeHTTP receive a FlowFile, it will connect to the http listener and transmit that FlowFile. Thanks, Matt
... View more
06-09-2022
10:33 AM
1 Kudo
@nada You can use the CompressContent processor to decompress gzip files. https://nifi.apache.org/docs/nifi-docs/components/org.apache.nifi/nifi-standard-nar/1.16.2/org.apache.nifi.processors.standard.CompressContent/index.html Set "Mode" to "Decompress", "compression format" to "gzip", and "Update Filename" to "True". If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post. Thank you, Matt
... View more
06-07-2022
05:45 AM
1 Kudo
@Vapper In a NiFi cluster each node executes its own copy of the flow.xml.gz, has its own set of repositories, and executes against only the FlowFiles on that specific node. So you need to consider this in your dataflow designs. Perhaps the dataflow that executes the groovy Script on all nodes could be designed to write all the produced files to a single destination server. Then in your http_request-> fetchfile-> http_response dataflow, instead of "fetchFile" use fetchSFTP to retrieve all those files and mergeContent to merge in to one file before the http_response. If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post. Thank you, Matt
... View more
06-07-2022
05:33 AM
@Althotta @geepark The fix for this issue is an upgrade to the Hive client used by Hive3 NiFi components. The Hive3 Client was upgraded to Hive 3.1.3 as part of Apache NiFi 1.16.2/1.17.0 https://issues.apache.org/jira/browse/NIFI-9998 This issue is noted in the Jira https://issues.apache.org/jira/browse/NIFI-9392 (fixed in Apache NIFi 1.16.0) mentioned by @mnui, but actually fully addressed by the Hive client upgrade in above Jira. So the complete fix requires both of these fixes. CFM 2.1.4 only contains NIFI-9392. If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post. Thank you, Matt
... View more
05-31-2022
05:46 AM
1 Kudo
@RB764 @ckumar is correct that what is failing here is a mutual TLS handshake. "PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target" Above is telling you that one side or the other of this TLS connection is unable to establish trust for the certificate presented during the handshake. The "PrivateKeyEntry" from the keystore file is being presented and the "trustedCertEntry"s from the truststore file are being used to verify trust for that certificate. In order to establish trust, the complete trust chain needs to be in your truststore files. Your PrivateKeyEntry will have an owner and an issuer. The issuer is the signer of the certificate. That issuer will have its own public key (TrustedCertEntry) in the truststore files. That issuer public key will also have an owner and an issuer. If the issuer DN is not the same as the owner DN, then it is an intermediate CA. So again you would need the public key for the issuer of that intermediate Public key. Once you reach the point in the trust chain where the public key owner and issuer are the same DN, then you have the complete trust chain. You can use openssl command to get the complete trustchain in most scenarios. openssl s_client -connect <nifi-hostname>:<nifi port> -showcerts openssl s_client -connect <nifi-regsitry-hostname>:<nifi-registry port> -showcerts The certs will be returned in the format of: -----BEGIN CERTIFICATE-----
MIIFljCCA36gAwIBAgINAgO...
-----END CERTIFICATE----- You can copy each and save it is a .pem file and import those that are missing in to your truststore files. If NiFi-registry is secured, then NiFi will need to be secured to talk to use it. If NiFi is secured, it is optional to secure NiFi-Registry. (You can add a http nifi-registry client in NiFi) If you found the information provided by anyone was helpful with your query, please take a moment to login and click "Accept" on every response that helped you to a solution. Matt
... View more
05-25-2022
09:48 AM
@TRSS_Cloudera When you "Enable" the DistributedMapCacheServer Controller service with UUID 5aaa327b-9ebb-1d5a-71ad-a349b8578a25, it is failing to enable because the port configured in that controller service is already being used by some other process on the server. Do you have multiple DistributedMapCache controller service configured on your NiFi (perhaps they are both enabled and first is already using that port? Did you check at OS level what process is listening on that port? My guess here is that you have multiple DistributedMapCacheServer controller services setup configured to use same port. Thus the error on one of them about being unable to bind to the port because it is already in use. I don't think above has anything to do with issue with your wait/notify flow since you say it works (at least with first FlowFile) as expected. As far as the behavior of your Wait/Notify dataflow, it is hard for me to make suggestions on what you are observing with out my detail on your dataflow configuration and use case. If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post. Thank you, Matt
... View more
05-16-2022
12:30 PM
@Eric_B CFM 2.1.4 has been released. https://docs.cloudera.com/cfm/2.1.4/release-notes/topics/cfm-whats-new.html Thanks, Matt
... View more
05-16-2022
09:24 AM
@Pypro Just to add to what @gtorres asked you to try. Make sure that you are performing the action from the NiFi host as the NiFi service user. All components execute as the NiFi service user. And in this case the NiFi service user is trying to connect to the FTP endpoint and then pass the supplied credentials. The target FTP server may not be in the NiFi service users known_hosts file. Did you also try using the ListSFTP processor? Thanks, Matt
... View more
05-16-2022
08:31 AM
@bk1937 I 100% agree with the advice given by @ckumar Also consider for a basic LB setup, you'll need to use sticky sessions. You mention that you are "logging in", so I take this to mean that your user(s) are not using certificate based authentication, but rather using a login provider like ldap-provider or kerberos-provider. When you access "https://<load-balancer>/nifi/ " without using sticky sessions, the request may go to node 1 where you get the login window. You enter your credentials and get back a bearer token that your browser now stores for the "https://<load-balancer>/nifi/ " endpoint. The issue here is that bearer token is only valid for the host that issued it (node1). So immediately after node1 sent your browser this token, it attempts to redirect your browser to UI. Without Sticky Sessions, your LB may send the redirect to node 2 - 5) and those nodes will not know anything about that client bearer token since they will not have the corresponding server side token. This the token is rejected and your user is treated as anonymous. You'll need to investigate your LB to see how to enable sticky sessions. Sticky sessions will make sure all subsequent request continue to get routed to same host as original request. If you any of the responses assisted with your query, please take a moment to login and click on "Accept as Solution" below each of those posts. Thank you, Matt
... View more