@jame1997  Since you are running a NiFi multi-node cluster, your ListS3 processor should be configured so this it only scheduled on the Primary node.  The outbound connection feeds a FetchS3Object processor.  That connection should have the "Load Balance Strategy" configured for Round Robin (this allows 0 byte listed FlowFiles to be distributed across all your nodes so that each node share the workload of fetching the content and processing it).  ListS3 should only have the "1" concurrent task set.  FetchS3Object can have multiple concurrent task if needed to keep up with listing.  Also keep in mind that using Tracking timestamps can result in objects being missed and not listed.  "Tracking Entities" is a more robust option but requires a map cache to hold those entities metadata. With 2,103 running processors and a timer driven thread pool of only 10, you may see delays in processors getting threads to do the work once they are scheduled for execution.  What does not makes sense here is your statement that all you needed to do to get listS3 executing successfully was to stop just that processor and start it again.  A common issue seen with concurrent tasks is users setting high concurrent tasks on some processor impacting other processors ability to get a thread. Otherwise there is not enough info here to speculate on the cause.  I looked through Apache NiFi jira project for any known bugs that may relate to what you described and found none unless other details are missing.  I can only suggest capturing a serious of thread dumps (spaced apart by 5 mins) should issue occur again and analyze those to see what the listS3 thread might be doing. Maybe take a look at these listS3 bugs that impact your version and are fixed in a newer release: NIFI-12732  NIFI-12594 Please help our community grow. 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

@PepeVo  "When I set the ip address (not localhost) on nifi.web.https.hosts and connect it with error "the proxy server is refusing connections".  Do I need to set the nifi.web.proxy.host to ipaddress too?" This because the IP does not exist in a SAN in your certificate.   The first step here is create a proper clientAuth certificate that includes the SAN entries and EKUs.  Apache NiFI out-of-the-box would have created a proper format keystore certificate. The CN value in the certificate is typically the hostname of the server it is being used on.  I've seen multiple different value snippets in what has been shared by you.   That hostname you are trying to use in the NiFi URL must exist as a SAN entry in the certificate. (This is not a NiFi specific requirement, this is enforced by the JDK) Please help our community grow. 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

@Pashazadeh  Apache NiFI 2.0.x was a technical milestone/preview releases that underwent many changes before the first GA release with NiFi 2.1.x.  I would not expect a change in behavior going forward, unless some bug is introduced or the community agrees on a change in functionality/behavior.   While I don't have a specific answer to what bug resulted in the difference in behavior you encountered, here are some changes that affected the JsonRecordSetWriter. NIFI-14331 NIFI-13963 / NIFI-13843 NIFI-12670 If you still have your NiFi 2.0.0 running, you could run your flow using a convertRecord with same record readers and writers and then compare the output content with what you see with 2.7.1 output.  Maybe that can help figure out what is happening and if either of those bugs affecting earlier NiFi 2.x versions is related. Thanks, Matt ... View more

@PepeVo  Look at the output from following java keytool command: keytool -v -list -keystore <nifi-keystore.p12/jks You'll want to verify the EKU, KeyUsage, and SubjectAlternativeName (SAN) fields in the output. EKU must contain clientAuth and serverAuth SAN must contain your server hostname and any other hostname your node may also be known as.  One of these SAN names is what you must use in the browser URL. Hostname verification in the TLS exchange between your browser and NiFi is done using the certificate SAN and not the Certificate DN. You also can add the same IP address (127.0.0.1) to the /etc/hosts file multiple times.  it will resolve to the first entry.   If you want to assign additional names to 127.0.0.1, it needs to be done on same line.  But SNI is not going to allow you to use 127.0.0.1 in the browser URL.  You should set the "nifi.web.https.host" property in the nifi.properties file to one of the SAN values from your keytstore and then use that name in your url to access the NiFi UI. On NiFi startup, you can also tail the nifi-app.log looking for the line that looks like this: ... [main] org.apache.nifi.web.server.JettyServer Started Server on https://<hostname>:8443/nifi   Please help our community grow. 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

@PepeVo  The invalid SNI is not a NiFi thing.  It is related to trying to use 127.0.0.1 local IP in the URL.  You are going to need to use a hostname. I see in you set https.host=localhost in the nifi.properties.  Is "localhost" a SAN entry in the certificate? Can you share the verbose output from the NiFi generated keystore and the keystore you manually created?  The NiFi generated keystore should have SAN entry for localhost and your server/computer hostname. Please help our community grow. 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

@jame1997  There is not enough information yet to say what was experienced here.    When you say "had to stop and start the process", does this mean you had to stop and start NiFi, or stop and start only the ListS3 processor to get listing to start working again? When the listS3 was not producing any FlowFiles, was it showing an small number in upper right corner indicating an active thread? When this listS3 is not working, is the outbound connection from the processor "red" indicating backpressure is being applied preventing the processor from getting scheduled? What is the exact version of Apache NiFi being used?   Single NiFi instance or a multi-node NiFi cluster setup?   How many "running" processors on your canvas?  How large is the NiFi Max Timer Driven Thread pool set to (default is 10, but typically this is set to 2 to 4 times the number of cores on the NiFi host). Monitoring of CPU load average with your flow running will allow you to determine if you can increase this even more.  Perhaps the canvas was. thread starved.  As more dataflows are built on the canvas, there is more chance the default thread pool may not be large enough to run your flow smoothly.  Any long running threads can prevent other processors that are scheduled from getting a thread for extended periods of time.  If you saw a small number displayed on the processor indicating it was scheduled to execute while it as not producing any FlowFiles, you could take a serious of thread dumps which you could inspect to see if the listS3 processor thread was making any progress or just blocked/waiting. Please help our community grow. 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

@pnac03  1). The keystore configured in NiFi (nifi.properies and in SSL Context Service controller services) and NiFi-Registry (nifi-registry.properties) must contain only 1 PrivateKeyEntry since there is no way to control which is used when multiple exist.  The verbose output you shared for your keystore shows it containing only 1 PrivateKeyEntry. 2) TLS will negotiate the highest mutually supported version between client and server in the mTLS exchange. 3) You did not share the verbose output for the keystore used in the SSL Context Service you configured your NiFiFlowRegistry client to use.  Would also need to see the nifi-registry.properties file to inspect all the identity mapping properties set to see how the DNs might be manipulated. Please help our community grow. 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

@PepeVo  Without the nifi-app.log output it would be impossible for us to guess where it is failing in the startup process.   The NiFi bootstrap process simply starts the main NiFi process and monitors that child process id to make sure it still exists (NiFI has not died).   Apache NiFi should start securely out of the box without needing to make any configuration modifications to the nifi.properties file.   All you need to do is make sure Java 21 is the default java version installed on the NiFi server host first.  So my guess is issue is with some configuration you have modified from the defualt in your nifi.properties file.  Or perhaps an issue with a manual configuration you made in some other nifi configuration file within the conf directory. Thank you, Matt ... View more

@Green_  When you deploy a Dataflow (that has a parameter context assign to it) from NiFi A via NiFi-Registry to another NiFi B, the parameter context will be added to NiFi 2 if a parameter context of the same exact name does NOT already exist in NiFI 2.   If the Parameter Context with same name already exists, that local parameter context will be used.   Additionally, if the parameter context of the same name present in the original flow from NiFi has a new parameter name not present in same named pre-existing parameter context on NiFi B, that additional name/value will be added to the existing same named parameter context on NiFi B. So NiFi / NIFi-Registry was designed with the intent to handle different parameter values per NiFi deployment.   Now the first time you deploy a flow from NiFi A to NiFi B, you end up with the parameter context from NIFi A being added to NiFi B.  You'll need to update values as needed in NiFi B before starting the dataflow(s) in that Process group.  But new version after that will not be an issue (unless additional new parameter name/value pairs are added.  Those would need to be updated or you could add the new params manually in NiFi 2 before updating version. I think above solution is better since you'll have the all the parameter name/value pairs when you import the new dataflow from NiFi-Registry, you'll just need to update some values before starting the new dataflow. Please help our community grow. 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

@pnac03  Some clarification: The NiFi Registry Client (NifiRegistryFlowRegistryClient) will use the configured keystore and truststore in the defined SLS ContextService if configured to authenticate with the target NiFi Registry URL.  This Client Auth certificate will proxy the request on behalf of the user identity displayed in the upper right corner of the NiFi UI where this NiFi Registry client is being used.   If an SSL Context Service is not defined in the Registry client, the Registry client will use the keystore and truststore configured in the NiFi node's nifi.properties files.  Now it is common in a Nifi cluster setup that every node has its own unique keystore.  As such you would need to make sure that all the clientAuth certificates are properly authorized to proxy user requests in the target NiFi (this applies no matter which NiFi node you are logged into when making the call to NiFi-Registry since the request gets replicated by all nodes.).  That brings into question your statement below: I have verified the same even from Registry using tcpdump in my setup and I do see that the incoming CN name from nifi is CN=node-0-nifikop instead of what is referenced in the SSL Context. Can you share the verbose output for your PrivateKeyEntry?  Does it contain only 1 PrivateKey Entry or multiple?  (Must contain only one since NiFi Registry client does not provide a configuration option to specify a specific certificate by alias name. ----- Public bucket clarification: A public bucket allows any user to import a flow from that bucket to the Canvas of a NiFi.  It does not allow any user to write (start version control) of a new dataflow or commit new version of an existing version controlled dataflow to the public bucket.  Writing a new flow to a bucket will require proper write permission on the bucket regardless of whether the bucket is public or not. ------- User Identities:  The user identities coming from the ssl context services and proxied are case sensitive "User 2" and "user 2" would be treated as to different users in both NiFi and NiFi-Registry. The User identities are evaluated against any identity mappings that may be configured in the nifi-registry.properties file, so you'll want to take a look at these to make sure they are not manipulating the user identity string or clientAuth certificate DN. Please help our community grow. 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