Member since
07-30-2019
3434
Posts
1632
Kudos Received
1012
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 126 | 01-27-2026 12:46 PM | |
| 551 | 01-13-2026 11:14 AM | |
| 1184 | 01-09-2026 06:58 AM | |
| 986 | 12-17-2025 05:55 AM | |
| 489 | 12-17-2025 05:34 AM |
12-07-2021
09:24 AM
@TN08 The InvokeHTTP processor supports HTTP methods for connecting to a target server. The InvokeHTTP processor does not establish a listener for inbound http connections. The properties for Basic Authentication Username and Password on this processor are used when the target endpoint supports basic auth and the username and password would need to provided by that target endpoint. If basic auth is not supported by target endpoint, TLS is also supported. If you want to setup a listener in NiFi for inbound HTTP you would use either ListenHTTP processor or the newer HandleHttpRequest/HandleHttpResponse processors. NiFi processors do not support basic auth for inbound connections. So to connect with these processors the source systems would need to pass a client/user certificate in a mutual TLS handshake as a way to identify the client. This means the processor would need to have a StandardRestrictedSSLContextService controller service that is configured with a keystore (containing a serverAuth certificate the client system can trust) and truststore (containing the complete trust chain for the clientAuth certificate presented by your client). 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
12-03-2021
05:54 AM
Can't proceed to NiFi UI after the browser error. I will attempt the actions you mention. I did list with keytool but will do so again looking for the specifics you mentioned as well. Thanks.
... View more
12-02-2021
09:11 PM
@Jarinek, 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.
... View more
12-02-2021
10:05 AM
@Griggsy If you can share a source json, it may help with more specific guidance in the community. Thanks, Matt
... View more
12-02-2021
09:22 AM
@Ilaya This is not an issue with NiFi service itself. Chrome for some reason does not like the new certificates being used. I would start by comparing your old certificate with the new and make sure things like ExtendedKeyUsage (EKU) (needs clientAuth and serverAuth) and SubjectAlternativeName (SAN) entries are compete and accurate. Make sure that the complete authority trust chain for your new certificate is present in you browser. Perhaps this resource maybe helpful as well: https://thegeekpage.com/bad-ssl-client-auth-cert/ 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
12-02-2021
08:48 AM
@Clarfim @tiagot Neither NiFi or NiFi-Registry support creating locally managed users for the purpose of authentication in to services. NiFi provides numerous methods for authenticating a user/client. The default which is always enabled is client/user based authentication via a Mutual TLS handshake. Other methods which can be configured in addition toTLS can be found here: https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#user_authentication NOTE: As of Apache NiFi 1.14, a new Single User authentication method was introduced so that NiFi could be secure by default out-of-the-box. If you choose to use this provider, it will be the ONLY user that can access this NiFi and will have full admin access. If full multi-user access is desired, you must use another method of user authentication. The "Users" UI that you see in NiFi is used so that NiFi authorization policies can be assigned to users and group strings. It is not used for creating local users with passwords within NiFi that can be used to authenticate into NiFi. It also will not be present in UI if using the Single User authentication provider mentioned in previous note. When you configured the initial admin user string, it is used to by the authorizers.xml (depending on configuration) to initially construct a users.xml (contains user strings and group strings along with established association between them) and authorizations.xml (contains policies assigned to user and group strings) file. Keep in mind that if the users.xml and authorizations.xml files already exist, they will not be updated if you make changes to your initial admin. They are only generated f these files do not already exist. Above example that results in a users.xml if you are using the file-user-group-provider or legacy FileAuthorizer provider in your authorizers.xml. None of the other providers will produce a users.xml and none of the other providers will allow you to manually add new user strings or group strings. The other providers are all used to pull user and group strings from an external source. The File-Access-Policy-provider is used to construct the authorizations.xml file. The Initial admin string set in this provider allows NiFi to seed the authorizations.xml file when generated with the NiFi policies needed for that user to function as an Admin (reminder: file is only generated if it does not already exist). More info on setting up authorization in NiFi can be found here: https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#multi-tenant-authorization 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
12-02-2021
08:19 AM
@Hafiz The ExtractText processor will evaluate a Java regular expression containing capture group against the inbound FlowFile's content. Then creates FlowFile attributes by processor dynamic property name that is assigned the value from the capture group from that Java regular expression. Above would result in FlowFiles with attributes like: Things to keep in mind. SplitText takes the inbound FlowFile and splits it in too many FlowFiles. If you are producing a lot of splits from a single source FlowFile, it will have an impact of NiFi's heap usage during that process. As each Split FlowFile is created, the FlowFile attributes/metadata fro each produced FlowFile (splits) is held in heap memory. Once all splits are created, all those produced Split FlowFiles are committed to the downstream relationship. One on the relationship, NiFi can then swap as needed out of heap memory. NiFi does this to avoid data duplication. Let's say you have a split that is in progress and NiFi dies. Since nothing has been committed to a downstream relationship yet, when NiFi is brought back online, it will reprocess the original FlowFile. You can reduce heap usage by splitting your source File multiple times if it is large (more than 20,000 - 50,000 splits). For example, split by every 5,000 lines in first SplitText and then by every 1 line in second SplitText. While NiFi does not hold FlowFile content in heap memory (Some processor will load content in to heap to execute on that content), FlowFile attributes/metadata is held in heap memory. So the more attributes/metadata exists on a FlowFile, the more heap that FlowFile is going to use. FlowFiles are held in connection between processor components. NiFi has a connection swap threshold that is applied per connection. The default is to produce swap files that contain 10,000 FlowFiles each (these swap files are for FlowFile attributes/metadata and not content since it is not always held in heap). So swap default set in nifi.properties file is 20,000. This means the first swap file for a connection is generated connection reaches 20,000 queued FlowFiles on one node (if multi-node NiFi cluster, swap is per node and not across all nodes) Just keep above in mind when designing dataflows where you are splitting/merging, creating a lot of FlowFile Attributes, or creating FlowFile attributes with large values. 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
11-23-2021
08:05 AM
@toninghaywi The exception is implying that your NiFi is trying to connect to Zookeeper server for state management and your zookeeper is using TLS; however, your NiFi has not been configured to be able to establish that secure connection needed to your zookeeper. Apache NiFi support for TLS enabled zookeeper server was added in Apache NiFi version 1.13. https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#zk_tls_client https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#embedded-zookeeper-with-tls The Apache NiFi jira related to this feature improvement are below: https://issues.apache.org/jira/browse/NIFI-7203 https://issues.apache.org/jira/browse/NIFI-7115 https://issues.apache.org/jira/browse/NIFI-7819 <-- This one is specific to state management 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
11-23-2021
07:25 AM
@MattWho You were right, the missing rootCA and intermediate certificates missed in the nifi nodes truststore were the cause of the problem(s)! As soon as I added them in each nifi node truststore, it solved my problem and the node were able to communicate and transmit heartbeat through port 11443! Thanks a lot for your time and your help! Best regards Emmanuel
... View more
11-23-2021
07:25 AM
Thank you for your answer! All my json FlowFiles have a FlowFile attribute on them for "table_name". There may be a problem with the json schema itself. Now the task has changed. I have created a new question about Jolt. https://community.cloudera.com/t5/Support-Questions/Jolt-transform/td-p/330850 If you know the answer to it, I would be very grateful!
... View more