@manishg  I am a bit unclear with your query, Are you saying that you developed custom nars for your NiFi? Migrating to a different version of NiFi would not introduce new properties into your custom nars. Or are you saying that you are using standard components (processors, controller services, reporting tasks, etc) included already in your NiFi 1.15 and after upgrade those same standard components have introduced new properties (which is a valid scenario)? While you take some NiFi nars from an older version and drop them in to a newer NiFi, I strongly recommend against this.  Doing so would introduce duplicates of all the processors that a duplicated nar(s) provide.  Those older version processors would not have the bug fixes, enhancements, and security fixes that the newer versions have.   It is a better approach, especially when making such a large leap from 1.15 to 1.22, to migrate your flow and update any processors that may have been made invalid after upgrade (typically this happens to very few component classes). If you choose the unrecommended path, you can follow this procedure for adding additional nars to and existing NiFi: https://nifi.apache.org/docs/nifi-docs/html/administration-guide.html#installing-custom-processors If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more

@Luwi  Your screen shot while showing no tasks completed in the past 5 minutes, does show that your PutEmail processor has an active thread (denoted by the (1) in the upper right corer).  In a later screen shot you shared I see that you have a terminated active thread (denoted by the 0(1) in the upper right corner).  Terminating does not kill the thread in Java (only a restart of the entire JVM can kill off an active thread).  All "terminate" does is isolate the terminated thread and release the FlowFile tied to that thread back to the inbound connection queue.  A terminated thread will hang around until it finally competes (provided it is not hung indefinitely). In scenarios like this where you have a very long running thread / hung thread, you'll want to collect a series of thread dumps for your NiFi and look for the email thread to see if it making any progress between thread dumps (indicates a potentially long running thread) or every thread dump is the same (indicates a potentially hung thread).  Then you'll want to start your investigation around that thread state to figure out why it is not progressing which may require you looking at the configured email server.  Perhaps it has some kind of quota on max emails over a period of time and starts blocking???  If you have not restarted your NiFi yet, you may also be able to take a look at the "terminated" thread in the thread dump to see what it's dump shows. As far as the other thread you referenced related to the hung thread, the following Jira was created to add ability to include dynamic smtp mail properties:  https://issues.apache.org/jira/browse/NIFI-9758 It was addressed as of Apache NiFi 1.17 and your screenshot indicates you are running Apache NiFi 1.16, so you'll need to upgrade to get this new processor functionality.  You can find a list of mail.* properties and their description here: https://javaee.github.io/javamail/docs/api/index.html?com/sun/mail/smtp/package-summary.html If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more

@Fabricio Is your DEV running the exact same version of NiFi on the same OS version? Cloudera has not released an Apache NIFi 1.20 based release of Cloudera Flow Management yet (CFM). However, even with the latest CFM 2.1.5.1000 release (based off Apache NiFi 1.18+), the minimum supported JDK version is JDK 1.8 update 252 or newer.  We always recommend using the latest JDK 8 or 11 release with NiFi for bug and security reasons. At a minimum, i'd suggest reinstalling your JDK as it seems to be a bad install. Also make sure you have installed the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files 8 in your JDK.  Another suggestion would be to but NiFi in DEBUG from the logback.xml config file to see if you can get more log output on the (java.lang.UnsupportedOperationException) Implementation not available in this environment exception.   If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more

@Diga  In a scenario like this, the first thing to ask yourself is "How would I do this outside of NiFi?".  If you were to use curl from command line, how would you handle authentication with the Polarion ALM rest-api endpoints?  The answer there would help with how you would handle it within NiFi and assist in getting a better response in the community.  @SAMSAL provided some great suggestions of possible methods. Matt ... View more

@theKiteRunner  NiFi token based OIDC authentication generates a token that is only valid for the NiFi instance on which the token was obtained. There are really tow tokens in play here, the client token issued for the authenticating user stored with the browser and a corresponding server side token stored in NiFi.  If you have a NiFi cluster setup with a load balancer in front of your cluster'sNiFi nodes, you'll need to make sure you have sticky sessions (also known as session persistence) setup in your load balancer.  So when you authenticate with NiFi node A and get a Client Token, the sticky sessions will make sure all follow-on request continue to route to node A instead of other nodes in the NiFi cluster. It sounds like you obtained a user token directly from Azure AD without going through NiFi's URL or you don't have sticky sessions setup resulting in the subsequent request post Azure AD auth routing to a different NiFi node. This would result in the "no matching key(s) found" exception when client JWT token is sent to a NiFi node that does not have the corresponding server token.  If the OIDC properties are configured correctly in NiFi, when you try to access the NiFi URL without a client token, it should redirect you to the the configured OIDC discovery URL. Once you authenticate, your browser obtains a client token and the NiFi node that redirected to your Azure AD OIDC URL will store the corresponding server side token. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more

@Fabricio you area using a very old version of JDK 1.8.0.  I suggest you try upgrading your JDK version to the latest release and try again. I believe the latest JDK is 1.8.0_381.   Is you found this answered sister you, please take a moment to login in and accept it as a solution.  Thanks, Matt ... View more

@shamika  NiFi based authorization is case sensitive. 2023-07-12 10:46:40,800 INFO [NiFi Web Server-19] o.a.n.w.a.c.AccessDeniedExceptionMapper identity[myuser], groups[bigG, bigdGer] does not have permission to access the requested resource. No applicable policies could be found. Returning Forbidden response the nifi-user.log is telling you that your successfully authenticated user "myuser" is known by NiFi to belong to groups "bigG" and "bigdGer".  In Ranger you'll need to make sure that yoru user "myuser" or one of these groups "bigG" and/or "bigdGer" has been authorized for "READ" on the "/flow" NiFi resource Identifier.  If Ranger has the group as "bigg" or "BIGG", "bigDGER", etc it will not work because NiFi is case sensitive. You could also share your authorizers.xml if you'd like use to verify your configuration there. If you found that the provided solution(s) assisted you with your query, please take a moment to login and click Accept as Solution below each response that helped. Thank you, Matt ... View more