@apk132  What the first image you shared tells me is that your PublishKafka_2_6 processor received 3 FlowFile on its inbound connection.  Two of those were processed (at least one of those two resulted in an error triggering the red bulletin in upper right corner of the processor).  The third FlowFile is still associated to a running thread on the processor (indicated by the small "1" in the upper right corner or the processor) The stats show that 48 tasks successfully completed in the past 5 minutes yet you are saying this one FlowFile has been stuck that entire time?  How has the processor been scheduled? Is this a multi-node NiFi cluster?  Are the FlowFiles that are successfully processed being processed on a different node than the hung FlowFile is queued? When it comes to what appears to be a hung thread, getting a series of thread dumps of NIFi JVM spaced apart by 1 min or more can be useful for analysis.  You'll be looking to see if this thread stack is progressing or always showing exact same stack.  If it is changing then thread is not hung, but rather just long running.  If it is not changing, closure examination of the thread stack would help determine what that thread is waiting on.   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

@mslnrd  The NiFi Registry configuration property: nifi.registry.security.needClientAuth= is used to control whether NiFi-registry whether the TLS exchange is mutual (2-way TLS handshake if set to true) or 1-way TLS handshake (when set to false). At a very high level, in a mutual TLS handshake both the server and the client need to provide their certificate in the the TLS handshakes.  When you changed this to false, NiFi-Registry no longer "required" that a client certificate is presented to identify the client who connected to the NiFi-Registry. If no other method of authentication is enabled, NiFi-Registry will treat the client as "anonymous".   NiFi-Registry supports anonymous user access to the NiFi-Registry UI.  This access is limited to accessing already created "public" buckets and ability to read flows version controlled in to a "public" bucket. The ability to create buckets, administer buckets and flows, and write version controlled flows to any bucket would require an authenticated and authorized user.   So it is not clear how this simple change solved your issue.  I think this change simple allowed the anonymous access only. You'll need to inspect the keystore and truststore used by both NiFi (registry client ssl context) and NiFi-Registry (configured in nifi-registry.properties file) to make sure a mutual TLS exchange is possible.   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

@sarithe Mainly seen with ReplavceTEXT?  This processor reads and writes to the content repository.  How is Disk I/O for your content_repository?  How many concurrent tasks configured on this processor? How large is the content that the replaceText is evaluating?  How is this processor configured? This processor will also read all or part of that content (depending on configuration) in to heap memory in order to do the text replacement. Matt ... View more

@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

@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