@Kiranq  What version of Java is your NiFi using? Sharing the output for your NiFi-Registry configured keystore and truststore in the nifi-registry.properties file would help. Sharing the keystore and truststore configured in your NiFi registry client would help as well. ./keytool -v -list -keystore <keystore or trustsore> You can also use openssl to see what is sent from the server (NiFi-Registry) to client (NiFi) in the initial TLS exchange. ./openssl s_client -connect <nifi-regisry hostname>:<NiFi-Registry port> -showcerts Matt ... View more

@Sivaluxan NiFi exposes APIs for a lot of endpoints.  So not really sure what you are trying to accomplish in your use case.  If you want to use a third party app to access info exposed by NiF that is possible.  Or are you trying to setup some custom endpoint to expose some custom data? Here you can find NiFi Rest-Api documentation for the latest NiFi release: https://nifi.apache.org/docs/nifi-docs/rest-api/index.html You can also find the NIFi rest-api documentation for your installed release directly in the application via the global menu ( 3 horizontal lines upper right corner of UI) --> help.   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

@Techie123  What is the full error logged along with stack trace if present?  Any other errors?  What log lines precede this exception? Did NiFi fully start allowing you to access the NiFi UI?  What component is throwing the error? Matt ... View more

@Phil_I_AM  Always best tot start a new question rather than commenting on an old post.  Will get you better traction that way from the community. The reason NiFi does not have native processor that can handle rar files is because there does not appear to be java native libraries available to do this. https://issues.apache.org/jira/browse/NIFI-8391   You may consider filtering and writing your rar files to a flow specific directory on disk and then use the ExecuteStreamCommand processor to unpack that rar in that directory.  You could have a new flow that uses the listFile (configured to ignore files with rar extension) and FetchFile processor to monitor that directory for new files and consume them for further processing. 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

@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

@SowmyaP  I am not clear on what you are trying to accomplish by specific order of restarts, starts and stops. Can you provide some details around the use case you are trying to implement and why? In a NiFi cluster the cluster roles "Primary" node and "Cluster Coordinator" node are elected by Zookeeper. Other nodes on the cluster have no specific assigned role.  Which node is assigned to these roles can change at anytime, so I am not clear on the importance of specific restart order.  If you have designed dataflows around a requirement that a specific node is always the "Primary" elected node, that can't be guaranteed.  In your first "Restart" scenario, assuming that what you mean by "secondary nodes" is any node that is not elected the "Primary" role,  each secondary node will restart and rejoin the cluster. If one of those secondary nodes was elected the "Cluster Coordinator" role, that role will switch to another node still running in the cluster.  The node elected the "primary" role should retain that role; however, when you then restart the "Primary" node, the "Primary" role will be elected to one of the other nodes in the cluster.  When the previous elected "Primary" node rejoins cluster, it will NOT reassume the "Primary" node role. In your second "start" scenario, assuming all nodes are currently stopped, you can start just the node you want to be elected the "primary" role and wait for that node to completely start and get elected with both the "primary" and "cluster coordinator" roles.  Essentially if you access the cluster UI at this point it would show 1 of 1 connected nodes.  Then you can start your secondary nodes and they will join the already established cluster. Third "Stop" scenario, it really does not matter which node you stop first.  They get their roles assigned by Zookeeper. 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