Member since
07-30-2019
3387
Posts
1617
Kudos Received
999
Solutions
My Accepted Solutions
| Title | Views | Posted |
|---|---|---|
| 87 | 11-05-2025 11:01 AM | |
| 349 | 10-20-2025 06:29 AM | |
| 489 | 10-10-2025 08:03 AM | |
| 350 | 10-08-2025 10:52 AM | |
| 378 | 10-08-2025 10:36 AM |
06-09-2025
06:39 AM
@nifier I would not expect much difference between making the stop request via the NiFi UI or via a rest-api call. Even when you make a request to stop components via the NiFi UI, the UI may quickly show the "stopped" icon on the component, but any active threads are not killed in that process. In fact the processor is considered "stopping" until all its active threads complete however long that takes. While still in the state of stopping, you can not modify those components. A component is considered stopping if its "activeThreadCount" is not 0. when you are executing your rest-api script without the delay, what exception are you encountering? This one? unable to fulfill this request due to: Cannot start component with <component id> because it is currently stopping Above means you have active threads. Perhaps you can build a wait loop around above response until the active threads complete. Or you can capture that component id and execute a terminate threads command on it. ../nifi-api/processors/<component id>/threads -X DELETE Terminating threads will not cause data loss. NiFi is not killing any threads in this process, only way to kill threads is via a NiFi restart. Terminating threads on component just shifts the thread to dev null and unhooks it from the FlowFile(s) it is associated with in the inbound connection. When the processor is restarted, the FlowFile(s) will be reprocessed by the component. Should the "terminated" thread complete execution its logging and output just goes to dev null and results are not written back to a FlowFile, but depending on processor it could end up in duplicate data on a destination system if the tread is sending data out of NiFi since NiFi will reprocess the FlowFile originally associated with that terminated thread next time processor is started. The other option is to get the status of components for the process group you stopped and parse the json for any "activeThreadCount" were count is not 0 and wait 1 sec and make request again and then repeat this loop until all are 0 before making your next rest-api call. Please help our community grow. 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
06-06-2025
12:01 PM
Thanks @MattWho for your valuable inputs. This is very helpful for conducting the correct analysis on our end. I will check the possibility of customizing the processors that connect to the database.
... View more
06-05-2025
12:37 AM
@sydney- The SSL handshake error you're encountering is a common issue when connecting NiFi instances to NiFi Registry in secure environments it indicates that your NiFi instances cannot verify the SSL certificate presented by the NiFi Registry server. javax.net.ssl.SSLHandshakeException: PKIX path building failed: sun.security.provider. certpath.SunCertPathBuilder
Exception:
unable to find valid certification path to requested target Based on your description, there are several areas to address. The certificate used by NiFi Registry is self-signed or not issued by a trusted Certificate Authority (CA) The certificate chain is incomplete The truststore configuration is incorrect 1. Certificate Trust Configuration Verify Certificate Chain: # Check if certificate is in NiFi truststore (repeat for each instance)
keytool -list -v -keystore /path/to/nifi/truststore.jks -storepass [password]
# Check if certificate is in Registry truststore
keytool -list -v -keystore /path/to/registry/truststore.jks -storepass [password]
# Verify the Registry's certificate chain
openssl s_client -connect nifi-registry.example.com:443 -showcerts Ensure Complete Certificate Chain: Add the Registry's complete certificate chain (including intermediate CAs) to NiFi's truststore Add NiFi's complete certificate chain to the Registry's truststore # Add Registry certificate to NiFi truststore
keytool -import -alias nifi-registry -file registry-cert.pem -keystore /path/to/nifi/conf/truststore.jks -storepass [password]
# Add NiFi certificate to Registry truststore
keytool -import -alias nifi-prod -file nifi-cert.pem -keystore /path/to/registry/conf/truststore.jks -storepass [password] 2. Proper Certificate Exchange Ensure you've exchanged certificates correctly export NiFi Registry's public certificate keytool -exportcert -alias nifi-registry -keystore /path/to/registry/keystore.jks -file registry.crt -storepass [password] Import this certificate into each NiFi instance's truststore keytool -importcert -alias nifi-registry -keystore /path/to/nifi/truststore.jks -file registry.crt -storepass [password] -noprompt 3. NiFi Registry Connection Configuration In your NiFi instance (nifi.properties), verify # Registry client properties
nifi.registry.client.name=NiFi Registry
nifi.registry.client.url=https://nifi-registry.example.com/nifi-registry
nifi.registry.client.timeout.connect=30 secs
nifi.registry.client.timeout.read=30 secs Verify these configuration files in NiFi (production/development) # nifi.properties:
nifi.registry.client.ssl.protocol=TLS
nifi.registry.client.truststore.path=/path/to/truststore.jks
nifi.registry.client.truststore.password=[password]
nifi.registry.client.truststore.type=JKS In NiFi Registry # nifi-registry.properties:
nifi.registry.security.truststore.path=/path/to/truststore.jks
nifi.registry.security.truststore.password=[password]
nifi.registry.security.truststore.type=JKS 4. LDAP Configuration For your LDAP integration issues in authorizers.xml ensure you have <accessPolicyProvider>
<identifier>file-access-policy-provider</identifier>
<class>org.apache.nifi.registry.security.authorization.FileAccessPolicyProvider</class>
<property name="User Group Provider">ldap-user-group-provider</property>
<property name="Authorizations File">./conf/authorizations.xml</property>
<property name="Initial Admin Identity">cn=admin-user,ou=users,dc=example,dc=com</property>
<property name="NiFi Identity 1">cn=dev-nifi,ou=servers,dc=example,dc=com</property>
</accessPolicyProvider> In the authorizations.xml add appropriate policies for the dev-nifi identity <policy identifier="some-uuid" resource="/buckets" action="READ">
<user identifier="dev-nifi-uuid"/>
</policy> 5. Proxy Configuration For proxy user requests, add in nifi.properties nifi.registry.client.proxy.identity=cn=dev-nifi,ou=servers,dc=example,dc=com 6. Restart Order After making changes restart the Nifi instance in the below order NiFi Registry first Then restart all NiFi instances Happy hadoping
... View more
06-03-2025
03:46 AM
One more update if someone will read it in future. I sad that: I did it and restart NiFi service, but users.xml file was not updated. So, should I update users.xml manually? But I was wrong and my users.xml is correctly updates after user changes in NiFi UI. So, the question in not had a reason, all works fine.
... View more
06-02-2025
05:35 AM
@MattWho yeah, thanks a lot! You are totally right. 😃
... View more
05-30-2025
06:05 AM
@Ripul Welcome to the Cloudera Community! Sharing a screenshot would be helpful here, but I am assume what you are seeing is something like this when you login with your admin user or other users: This is because of an authorization issue. When NiFi is started for the first time it does not have a flow.josn.gz file yet which contains everything you see on the NiFi canvas. So NiFi will generate that flow.josn.gz which will consist of just a root process group. You'll notice on the cavas the above "Operation" panel. It will show the current selected component on the canvas. With nothing selected on the canvas, it will show details for whichever NiFi Process Group you are currently displaying. Since this is a new install, what the Operation panel is showing is this generated root process group. Anytime you see the name as just the UUID for a component, it indicates the currently authenticated user is not authorized to view that component. A greyed out "gear" (configuration) icon indicates user is not authorized to modify the component. A greyed out "key" (Access Policies) icon indicates currently authenticated user is not authorized to view and maybe modify policies (authorizations) in that component. NiFi provides very granular authorization control all the way down to the individual component level. This may sound like a lot to need to manage; however, there is policy inheritance in place. Example: You add a processor to the canvas. If not explicit policy is defined on the processor itself it will inherit policy from the process group it is inside. If there is no policy defined on the process group, it will inherit policy from parent process group. At the very top level is the above mentioned parent process group. So setting policies on the parent process group will control access on everything added to cavas until ab explicit access policy is set on a sub component. There are also global policies that can be setup and your "admin" user should have been setup on a number of these. From the above global menu found in upper right corner you should see that "Policies" is not greyed out for your admin user. Within global "Policies", all users need to be granted "view the user interface" in order to access the user interface, so it sounds like you have already done this for other users. Your "admin" user should also have "access all policies" (view and modify) which allows that user to view and modify access policies (authorizations) on every component anywhere on the canvas. This policy is what makes the "key" icon not greyed out on the "Operation" panel mentioned earlier. So to give select users (including your admin user) the ability to add components to the root process group, your admin user will need to select the key icon on the root process group and grant those users: Once your admin user and other users are properly authorized to "view the component", the Operate panel will show the process group name instead of just the process group assigned UUID. The gear icon will not be greyed out once your admin user and other users have "modify the component". "Modify the component" on a process group will also allow added users to see the component adding icon a the top of the UI. I am not going to cover all the NiFi Policies, but they can be found in the NiFi Administration guide under Configuring Users & Access Policies Please help our community grow. 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
05-30-2025
12:26 AM
Thanks a lot for your answer, @MattWho. 😃
... View more
05-28-2025
10:13 PM
Thank you @MattWho for your quick help.
... View more
05-26-2025
07:28 AM
Thanks for clarifying the ListFile vs Get<abc> usage in cluster mode. That load-balancing tip really helps when scaling out. I’ll definitely try adjusting the image size next time too, didn’t realize it could be dragged larger before replying.
... View more