@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

thank you 🙂 ... View more

In PutSql Processor, there is a property "Support Fragmented Transactions". If set its value to be false, then it is proceeding and not penalising the flow files. ... View more

@vg27 I have submitted your information to the team, they will be contacting you with the following steps, thanks! ... View more

Thank you, the matter was in "/", indeed )) ... View more

Thanks Matt,  Was able to resolve the issue with your putFile solution. ... View more

@Suayb 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. If you are still experiencing the issue, can you provide the information @mattwho has requested? Thanks. ... 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