@vg27  Sounds like you may have gotten past your original issue after following the guidance I provided already?  You new questions don't seem directly related to the original query. ------- The invalid host header can be resolved by modifying the nifi.web.proxy.host property in the nifi.properties file:   nifi.web.proxy.host=20.61.182.212,20.61.182.212:9443   Or by including additional entry(s) in your certificates SAN list. --------- Questions: 1. How re you authenticating this user identity?   CN=PAVANBL   2. Have you modified your nif.properties file so that the managed-authorizer is being used?   nifi.security.user.authorizer=managed-authorizer   3. What method(s) or user authentication have you decided to use? Did you just create an clientAuth certificate that you loaded into your browser to authenticate your user or did you setup some other auth method like kerberos or ldap?   nifi.security.user.login.identity.provider= 4. When it comes to using an load balancer, if you are using any type of login provider to authenticate to your NiFi, you need to configure the load-balancer to use session affinity (a.k.a - Sticky sessions).  When you login into a NiFi node the user is issued a client side token and a corresponding server side token is stored on the node.  That client side user token is send in every request made after login.  The issued client token is ONLY valid for use with the NiFi node that issued it.  So session affinity setup in the load balancer is required to make sure that all subsequent request within that same session go to the same NiFi node. 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

@Kiranq  @livsey  If you configure "nifi.web.https.host" with your actual Windows hostname or IP rather then using the loopback address (127.0.0.1), does your NiFi start? Any custom add-ons? Have you set NiFi to debug in logback to see if any additional logging shed some light here? Thanks, Matt ... View more

@vg27  A few issues I see with what has been shared: Issue 1: IPV4 addresses like 0.0.0.0 and 127.0.0.1 are special reserved network addresses.  0.0.0.0 is not going to be resolvable to any network host.  0.0.0.0 is typically used by server applications running on multi-homed networks.  Meaning the the server has multiple NIC cards that are connected.  For example: one NIC connected to a companies internal private network and another NIC on same server connected to a public network.  BY configuring the server with 0.0.0.0, the special addresses tells the server to listen and accept connection from all NICs.  From the browser you would still need to use a resolvable IP address for accessing that server via one of the NICs.   NiFi offers a specific configuration property if you want to define multiple network interfaces you want NiFi to listen for connections on. 127.0.0.1 is the loopback address (localhost), which if used in NiFi, means NiFi is only listening on that loopback address.   So you should be configuring your "nifi.web.https.host" property for the hostname of the server on which it is running.  This hostname would need to be resolvable and reachable by your browser.   -------------------------- Issue 2: You are setting up. NiFi cluster, but are still using the single-user providers for authentication and authorization: nifi.security.user.authorizer=single-user-authorizer nifi.security.user.login.identity.provider=single-user-provider These providers were created so that users could launch NiFi standalone instances out-of-the-box for ease of product evaluation.  These providers are not suitable for clustered NiFi setups or multi-users environments. The authorizers.xml you shared is incomplete and only shows a "file-user-group-provider".   The authorizers.xml is easiest to read from bottom of the file upward.  At the very bottom you will find the authorizer (for example: "single-user-authorizer" or "managed-authorizer").   Depending on type of authorizer, the authorizer may utilize one or more additional providers ("file-access-policy-provider", composite-user-group-provider, ldap-user-group-provider", "file-user-group-provider", etc...) already loaded further up in the authorizers.xml.  So while you may have configured the "file-user-group-provider" and the that provider executes on NiFi creating a users.xml file, the configured single-user-authorizer would never use it.   --------------------------- Issue 3: Did you generate your own NiFi keystores and truststore for your 2 NiFi nodes or are you using the NiFi auto-generated keystore and truststore?   I encourage you to manage your own certificates, keystores, and truststores in a production setup.  The certificates generated  automatically are self-signed and only contain very specific Subject Alternative names.  In a cluster setup, NiFi nodes act as both clients and servers since they communicate with one another.  And the owner of those self-signed certifcates is going to be "localhost". This means that all nodes will report as same identity "localhost", which is not good for security. ------------------------------- Issue 4: I see you are using the embedded zookeeper (ZK).  ZK requires quorum in order to be useable.  With only 2 nodes, you only have 2 ZK nodes which is not a quorum.  IF either one of the nodes becomes unreachable or goes down, you will not be able to access the one remaining node either since ZK has lost quorum.   Quorum consists of an odd number of ZK nodes (typically 3 or 5) depending on how much loss tolerance you want to have.   While embedded ZK makes things easy with setup, you'll want to have at least 3 NiFi nodes (this allows you to lose up to one node and still retain access to the NiFi UI of the other 2 nodes.  Of course using an external ZK is even better and the best production option as stopping/starting or loss of NiFi nodes has no impact on quorum. --------------------------------- These are the areas to address first. 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

@Suayb I see no ERROR logging in anything you have shared. The snippet of the nifi-app.log you shared only shows that NiFi is still starting up. NiFi is not fully up and the UI is not accessible until you see the following lines output in the nifi-app.log: 2024-10-17 09:24:32,817 INFO [main] org.apache.nifi.web.server.JettyServer Started Server on https://<hostname>:8443/nifi 2024-10-17 09:24:32,818 INFO [main] org.apache.nifi.BootstrapListener Successfully initiated communication with Bootstrap 2024-10-17 09:24:32,819 INFO [main] org.apache.nifi.NiFi Started Application Controller in 11.878 seconds (11878131211 ns) Are you seeing above in your nifi-app.log? Are you seeing any ERROR lines in any of you logs? are you seeing any disk space issues? Thanks, Matt ... View more

@Suayb  NiFi- 2.x requires Java 21 The make sure your NiFi is starting with Java 21 and not another version of Java. You configure a specific java in the NiFi.bootstrap.conf file.  By default in that file java is set to "java=java" which uses system default java.  You could could change this to "java=<path to java 21 bin dir>/java" If above does not solve issue start reviewing the nifi-bootstrap.log, nifi-app.log, and nifi-request.log for any relevant details. 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

@livsey  Can you share what Java and Java version you are using and how you have configured your Apache NiFi conf/nifi.properties file? I am most interested in the Web Properties section. Thank you, Matt ... View more

@vg27  From your shared nifi.properties file, I can see you are using SSO based user authentication and Mutual TLS (always enabled) based authentication. For user authorization, you using the managed-authorizer. So when you access the NiFi UI you are being redirected to your SSO login, correct? After successful authentication, you are able to access the NiFi UI; however, when you click on the global menu in upper right corner, the menu has the users and policies greyed out and not clickable? If it is greyed out, it means the currently authenticated user is not authorized to access those items. What is the user identity string displayed in upper right corner above logout?  This case sensitive user identity string is what needs to be properly authorized. Can you share your authorizers.xml file?  This file sets up your authorizer and various sub provider it depends on for establish necessary access policies for your initial admin user and nodes.  That initial admin user's  identity string would get the minimum needed admin policies granted against it.   That admin user could then access the NiFi UI and be able to add additional user identity strings and apply policies to those new user identity strings or groups strings. A very basic authorizers.xml would have in it: File-user-group-provider --> Responsible for creating initial user identity strings for your initial admin and your NiFi nodes.   This provider generates a users.xml file only if one does not already exists.  It will not edit and existing users.xml. Your user identity must match exactly (case sensitive) with what you see in the NiFi UI.  From within the NiFi UI additional users and groups can be added later which will be also added to the users.xml file. File-access-policy-provider --> This provider is responsible for creating the authorizations.xml file that contains the policies that have been assigned to user or group identity strings.  It will only generate an authorizations.xml file if one does not exist.  It will not edit an existing authorizations.xml. When seeding initial policies for nodes and initial admin it expects to find those user and node identity strings from the file-user-group-provider.  Any newly setup policies via the NiFi UI will get added to the authorizations.xml. managed-authorizer ---> This authorizer points at the file-access-policy-provider to load the current authorizations.   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

@Krish98  Most NiFi Heap memory issues are directly related to dataflow design.  The Apache NiFi documentation for the individual components generally does a good job with reporting "System Resource Considerations".  So the first step would be to review the documentation for the components you are using to see which list "MEMORY" as system resource consideration.  Example: SplitContent 1.27.0 Then sharing your configuration of those components  might help with providing suggestions that may help you. - Split and Merge processor depending on how they are configured can utilize a lot of heap. - Distributed Map cache also resides in HEAP and can contribute to to significant heap usage depending on configuration and the size of what is being written to it. Beyond components: - NiFi loads the entire flow.json.gz (uncompressed it to heap memory).  This includes any NiFi Templates (Deprecated in Apache NiFi 1.x and removed in newer Apache NiFi 2.x version).  Templates should no longer be used.  Any templates created which are listed in the NiFi templates UI should be downloaded so they are stored outside of NiFi and then deleted from NiFi to reduce heap usage. - NiFi FlowFiles - NiFi FlowFlowFiles are what transition between components via connections in your dataflow(s).  A FlowFile consists of two parts.  FlowFile content stored in content claims in the content_repository and FlowFile metadata/attributes held in heap memory and persisted to flowfile_repository.  So if you are creating a lot of FlowFile attributes on your FlowFiles or creating very large FlowFile attributes (like extract content to an attribute), that can result in high heap usage.   A connection does have a default threshold at which time a swap file is created to reduce heap usage.  Swap files are created with 10,000 FlowFiles in each swap file.  The first swap file would not be created until a connection on a specific node reached 20,000 at which point 10,000 would be moved to a swap file and the 10,000 highest priority would remain in heap.  The default "back pressure object threshold" on a connection is 10,000 meaning that with defaults no connection would ever create a swap file.  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

@Leo3103  What are you seeing in the minifi-app.log? You could also try set DEBUG logging in the minifi logback.xml to capture more details. 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

@Leo3103  I am confused by what you are showing me. While not building the same flow as you, i have gone through the steps outlined using my minifi-2.0.0-M4 and minifi-toolkit-2.0.0-M4 downloads.  Taking my downloaded <flow-definition-download.json> from my NiFi, I ran it through the toolkit using: ./minifi2/minifi-toolkit-2.0.0-M4/bin/config.sh transform-nifi NiFi_Template_XML_to_Flow_Definition_JSON.json flow.json.raw The toolkit output file begins with: {"maxTimerDrivenThreadCount":0,"parameterContexts":[],"rootGroup":{"identifier":"e2e44df7-dbd9-3890-aeee-67a6f48fe538","instanceIdentifier":"006c844b-0192-1000-1158-841acd760276","name":"NiFi_Template_XML_to_Flow_Definition_JSON","comments":"","position":{"x":-1032.0,"y":-456.0},"processGroups":[],"remoteProcessGroups":[],"processors":[{"identifier":"e5d........ If you were to start MiNiFi with this flow.json.raw with out editing it first, a flow.json.gz will be created and you will encounter the exception about number of threads can not be "0". If you did start it, delete the generated flow.json.gz file.  Then edit the flow.json.raw file: {"maxTimerDrivenThreadCount":5,"parameterContexts":[],"rootGroup":{"identifier":"e2e44df7-dbd9-3890-aeee-67a6f48fe538","instanceIdentifier":"006c844b-0192-1000-1158-841acd760276","name":"NiFi_Template_XML_to_Flow_Definition_JSON","comments":"","position":{"x":-1032.0,"y":-456.0},"processGroups":[],"remoteProcessGroups":[],"processors":[{"identifier":"e5d You'll see here that I set my thread pool size to 5.  I then started MiNiFi again and once again the flow.json.gz was created during startup from my flow.json.raw file.  MiNiFi started successfully. DEBUG logging shows here it persisting the loaded flow.json.raw to a flow.json.gz file: 2024-10-09 08:47:17,537 DEBUG [main] o.a.n.m.commons.util.FlowUpdateUtils Persisting flow to path /opt/minifi2/minifi-2.0.0-M4/./conf/flow.json.gz with content You could edit the logback.xml to produce DEBUG output so you can see more detail about the flow being loaded.  Is your MiNiFi running on the same host as your NiFi? I see you have your Remote Process Group (RPG) configured for localhost. 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