@pankajgaikwad  while it is wonderful that you have shared your InvokeHTTP processor configurations, I don't think enough information has been provided to provide assistance here.  All we know from you post is that some Post rest-api call was made against some service endpoint using some URL, to send form data of some content-type to which an illegal state exception was thrown. Sharing details about your use case is always helpful.  What is the target endpoint service (Polarion? which community members may not be familiar with)?  What is the full rest-api call you are trying to make? Were you able to successfully make that same rest-api call via curl local to the NiFi server? What is the structure of your NiFi FlowFile (what is in the FlowFile's content and what are the FlowFile's attributes when the FlowFile reaches the InvokeHTTOP processor)? What are the complete configurations of the invokeHTTP processor? (Some property values are cut-off in your images) What documentation are you following for this rest-api call? As far as the exception goes... Was the "java.lang.IllegalStateException: closed" accompanied by any stack trace in the the nifi-app.log? What was logged within the target service when this post request was made? I see you shared your full dataflow in another community post: An example of the original file you are obtaining via "GetFile", what attributes you are adding to the FlowFile, and how you are modifying that content before the InvokeHTTP may also be helpful here. Sharing the additional input and details may make it possible for someone in the community to provide you with some suggestions and solutions. Thank you, Matt ... View more

@HiAnil  HDF 3.5 release is based off Apache NiFi 1.12 and was released more then 5 years ago.   It was End-Of-Life as of April 2023.   NiFi-Registry service in HDF 3.5.2 only lists PostgreSQL 9.5+, 10.x, and 11.x as tested versions. I can tell you that HDF 3.5.2 has never been tested or verified against Postgres 14 or 15 and suspect there could likely be incompatibility issues.  I would suggest testing this your self before upgrading in any production environment. Keep in mind that using such an old release exposes you to CVEs addressed in the many releases put out since HDF 3.5.2.   Additional the product has had many improvements and new features added over the years. Please help our community thrive. 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

@salahevops  I suspect you are not running Apache NiFi older then release 1.21? If so, you may be encountering this issue addressed through an improvement: https://issues.apache.org/jira/browse/NIFI-4890 Azure AD lets a lifetime on the client issued token.  That is likely 30 minutes. The token can be refreshed, but NiFi OIDC in older version does not have the ability to do the background refresh. Further improvements where added in NiFi 2.0 to add the refresh configuration timer: https://issues.apache.org/jira/browse/NIFI-12135 Please help our community thrive. 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

@vg27  If you have a support contract with Cloudera, you could open a support case where someone could connect directly with you and assist you through your many issues. ------ 1. As i have shared before, the Single-User providers are not designed with the intent of use in a NiFi clustered environment.  They should only be used for standalone NiFi evaluation purposes.  Once you start to get in to the more involved cluster based deployments, you need to use different providers for authentication and authorization.  When using the single-user-provider for authentication, each node can create different credentials which will not work in a cluster environment.    For login based authentication, you should be using LDAP/AD (ldap-provider) or Kerberos (Kerberos-provider).  For authorization, you should be using the managed authorizer.  ------ 2. Are you still using your own generated keystore and truststore with your own created private and public certificates?  Using the NiFi auto-generated keystore and truststore will also not support clustering well as each node will not have a common certificate authority.  ----- 3. The "org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode = ConnectionLoss" exception is an issue with with Zookeeper (ZK) Quorum.  This error can happen if both you nodes are not fully up at time of exception and may also happen because you do not have proper quorum with your ZK.  Quorum consists of and odd number of ZK hosts with min 3.  Strongly encourage the use of an external ZK since anytime one of your nodes goes down, you'll lose access to both nodes. ----- 4. You are using an external https Load Balancer (LB) which means that sticky sessions (session affinity) must be setup since the user token issues when you login is only valid for use with the node that issued it.  So if your LB directs you to node 1 that presents you with login UI, you enter credentials obtaining a user token from node 1, and your LB then redirects to node 2 to load UI, it will fail authentication on node 2 because the request includes the token only good for node 1.  ----- 5. I see you are using a mix of hostnames and IP addresses in your NiFi configurations, so make sure that the node certificates include both as SAN entries to avoid issues. -----     Please help our community thrive. 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

@nifier  Your putFile issue is unrelated to original query in this community question.  It is better if you start a new community questioon for unrelated queries as solutions can become confusing to others who may use the thread in the future. That being said, this exception is cause because your NiFi  FlowFile has a filename that contains a directory structure: 20242323/year/year.txt This is not a valid filename to use with putFile processor.  I am not sure where in your dataflow before putFile that the filename FlowFile Attribute  is being modified in such a way.   You might be able to address this issue there (preferred). You could use an update Attribute processor to extract the directory structure from the filename before putFile processor also.   if you want to maintain the append the extracted path from the filename to "Directory" configured in the putFile processor if you want to create that directory structure. Please help our community thrive. 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

@vg27  1. So i understand that you have created client certificates for your user.  What authority was used to sign these user certificates?  Was this authority added to the NiFi configured truststore? When you open a browser to NiFi's url, NiFi will respond with a WANT for a clientAuth certificate along with a list of trusted authorities from its truststore.  If your certificate loaded in your browser is  not signed by one of those authorities it will not be presented to NiFi.   If no clientAuth certificate is presented, NiFi will move on to another configured method of user authentication.  The fact that you are seeing  the NiFi login UI, tells me the TLS exchange did not result in a clientAuth certificate being presented by yoru browser. With certificate based mutual Auth there is no login required.  3. "nifi.security.user.login.identity.provider=singleUser" is not a valid configuration. I assume you meant "nifi.security.user.login.identity.provider=single-user-provider.   With "Single-user-provider" configured, the only username and password accepted would be for the single user credentials Nifi auto-generated and output to the logs the first time NiFi was started with that provider configured. If you have no intention of using the single-user-provider, just leave "nifi.security.user.login.identity.provider=" unset. 4. you don't need to worry about sticky sessions if you are only using certificate based authentication, since your client certificate would be passed in every request and their are no tokens involved like in login based providers. If you did decide to use a login-provider like LDAP or Kerberos later, sticky sessions would need to be setup first or you may never be able to access the UI.  Once you enter the username and password, the next request goes is to access UI using that token and if the load balancer were to redirect that to a different node, the UI would not load but instead throw and exception about the unknown user. Please help our community thrive. 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