@mechtech007  Providing details such as the exact version of CFM NiFi you are using is very important in getting help as NiFi evolves over time, those who help want to know as much as possible in order to avoid providing irrelevant feedback that may not pertain to the version you are using. You could rename the flow.xml.gz and flow.json.gz (present only if new enough version of CFM) and restart the node.  The node will inherit the flow from the cluster nodes when it tries to join the cluster. Depending on how old your CFM version is, you could be hitting one of these bugs: https://issues.apache.org/jira/browse/NIFI-7920 https://issues.apache.org/jira/browse/NIFI-8204 If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@sukanta  What version of NiFi are you using? Where are are you specifically seeing this exception shown (screenshot would be helpful)? The exception is related to the URL you are trying to use to access this NiFi.  You are using an IP address that is not present as a SAN entry in the NiFi's keystore PrivateKey entry.   Thanks, Matt ... View more

@Vas  The solution is not as simple as just setting a a hostname resolution in /etc/hosts file. The hostname you type in the NiFi URL must exist as a SAN entry within the PrivateKey located in NiFi keystore configured in the nifi.properties file. Matt ... View more

@ShyamKumar  A NiFi Process Group (PG) can only have one parameter context assigned to it.  You can allow the PG configured parameter context to inherit parameters from other parameter context(s). Only parameter which are not explicitly defined in the PG configured parameter context will be inherited.  You can not have multiple parameters of same name defined.  Changing the values assigned to parameter requires the stopping and starting of components configured to use that parameter. So it is not possible to pass FlowFiles to the same PG and specify using unique contexts per FlowFile.   You would need to copy the PG and assign each copy a different parameter context for the properties that are unique and inherit all the parameters that are shared by all FlowFiles from some parent parameter context. While all component properties support being parametrized, a good number of component properties support NiFi Expression Language (NEL).  If the properties that need to be unique per FlowFile all support NEL, you could set those attributes on the FlowFiles upstream of PG and those attributes could be used uniquely tailor the execution of processor components per FlowFile.   As far as parallel execution goes, that is controlled via the concurrent tasks setting on a processor component.  By default the value is 1 meaning only a single execution at time.  but setting this to a higher value would allow parallel execution against different FlowFiles.  Be very cautious with adjusting this value and monitor your servers CPU load average.  You want to use the smallest value possible to achieve the highest throughput achievable on your hardware running your dataflow(s).  Setting to high could just lead to this processor consuming more time then needed on the CPU and preventing other processors from efficiently being able to use CPU. If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@hegdemahendra  A couple things you may want to try here. 1.  As @cotopaul stated, clear the keystoreType and truststoreType properties. 2. Set needClientAuth=false (just clearing this may not work as NiFi defaults here to true). 3. The exception shared  indicates that a tls exchange is being attempted with your MySQL server.  You should modify your nifi.registry.db.url to explicitly not use ssl if that is not what you want to happen here.  (for example: change "jdbc:mysql://localhost:3306/nifi24_registry" to "jdbc:mysql://localhost:3306/nifi24_registry?useSSL=false" If you want to use SSL with your MySQL, the exception is telling you that it wants to perform server certificate verification fo which you have no truststore defined to do so. You might try this url in that case: jdbc:mysql://localhost:3306/nifi24_registry?verifyServerCertificate=false&useSSL=true" If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@plapla  TLS based user/client authentication does not use tokens. You just need to make sure the clientAuth PrivateKey certificate in the keystore used is both trusted by the Nifi's configured truststore in the nifi.properties file and authorized against the NiFi policy(s) required to access the specific rest-api endpoint requested. If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@plapla  A secured NiFi is secured over HTTPS which means a TLS exchange happens to secure the connection with NiFi.  A secured NiFi will always support a mutual TLS exchange. If no other methods of user authentication are configured, NiFI will "REQUIRE" a clientAuth certificate be presented in the TLS exchange with NiFi. When NiFi is configured with an additional user authentication method (for example, you have enabled the ldap-provider for user authentication), NiFi will "WANT" a clientAuth certificate in the TLS exchange.  If a clientAuth certificate is not provided in the TLS exchange/handshake, NiFi moves on to the next authentication method configured. The ldap-provider will require obtaining a user token as you saw that then needs to be included with all subsequent rest-api calls.  And you are correct that the token does expire.  That is why it is easier and a better option to use mutual TLS based authentication when doing automation like this.  The clientAuth certificate is simply included in every rest-api request and there is no token involved.   About the ClientAuth certificate...  The full DN from the certificate is what is used to identify the user.  The full DN is evaluated against any identity.mapping.pattern.xxx properties configured in the nifi.properties file.  If a configured pattern (java regex) matches against the DN, the identity.mapping.value.xxx and identity.mapping.transform.xxx is applied.  These identity mappings are often used to trim the CN value from the complete DN.  The resulting string after any mappings are applied is what is then used to look up authorizations for that client/user. If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more