@ShyamKumar  Your dataflow design is still unclear here. - 'We have different client which will call the same generic PG" --> How is this being done?  When you say "clients", are you referring to external to NiFi clients?  How are these client request being sent to/received by NiFi's PG?    We would need to understand your dataflow better before being able to provide better feedback.  A detailed use case would be very helpful here. Thanks, Matt ... View more

@sukanta  This output is normal and expected.  The SubjectAlternativeName (SAN) details are available through the public key exchanged in the TLS exchange.   The TLS spec verifies the hostname against the SAN in the serverAuth certificate to protect the client from man in the middle type attacks.  This information is returned to the client so that you are aware they you tried to access server XYZ, but server identified by these un-matching SANs responded.   There is nothing that can be changed on server side (NiFi) to change this behavior.   As a side note: You can use openssl to any HTTPS enabled server and get that server's serverAuth public certificate.  You can then also use openssl to view the contents of that public cert which will include the SAN info.  So I am really not seeing any "sensitive" information in what you have shared.   If you concern is about IP addresses... Stop using them and use DNS resolvable hostnames in your SAN.  Have a private and public resolvable hostnames in the SAN. If the ask here is not about hiding this public info, but rather allowing the client to continue to connect ignoring the possible man-in-the-middle attack, that is a different question.  It would be a question to ask your client provider (assuming your browser in this case?). 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

@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