@mirkom  Yes Parameter Context inheritance does exist now.  Been implemented since Apache NiFi 1.15, but had numerous bugs/improvements addressed/implemented since then. From within the "Parameter Contexts" UI, select the parameter context used by Process group and select "edit" from 3 dot menu to far right.  Will open UI that looks like this: Select the "Inheritance" tab along the top of this UI.  Drag and drop any of the Available Parameter Contexts form the left-hand side to the "selected Parameter Contexts" list on the right-had side.  The order in which the Selected Parameter Contexts are ordered in the list is important.  The top most takes precedence over those below it.    So above shows an example where my "test-param" parameter context is inheriting parameters from the "Root-PG-PC" parameter context. So lets say you have an identical parameter "name" defined in multiple selected parameter contexts.   The one defined directly on the PG assigned Parameter context is used.  If parameter by that name does not exist there its starts searching inherited parameter contexts from top down.  First match found is used.   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

@Sanga  What is the specific Apache NiFi version being used? Any disk space issues on Node-0? Any other exceptions in the NiFi logs? Logs shared cover the reconnection attempt.  What was the reason given for the node disconnection? Thank you, Matt ... View more

@pnac03 Has the reply helped resolve your issue? If so, please mark the appropriate reply as the solution, as it will make it easier for others to find the answer in the future. Thanks. ... View more

@casaui  You have multiple issues with your setup. Issue 1: Problem:  Missing ClientAuth certificate in MutualTLS exchange between NiFi's NiFiRegistryFlowRegistryClient and your NiFi-Registry. [NiFi Registry Web Server-50] o.a.n.r.w.s.a.x.X509CertificateExtractor No client certificate found in request. Solution: The NiFiRegistryFlowRegistryClient will use the keystore and truststore defined in the nifi.properties file if a SSL Context service has not been configured in the registry client directly.  For a mutualTLS exchange to be successful, the client side must present a clientAuth certificate that is trusted by the truststore being used on the server side (NiFi-Registry) of the TLS connection.  Likewise, the serverAuth certificate presented by the server (NiFi-Registry) must be trusted by the truststore the client (NiFiFlowRegistryClient) is configured to use.   I have no idea why you have an ALB setup for NiFi-registry since there is just one NiFi-Registry.  The NiFiRegistryFlowRegistryClient should be configured with the direct NiFi-Registry URL: https://nifi_ec2server.com:18443/nifi-registry Without a clientAuth certificate presented in the mutualTLS exchange your Registry client is going to be anonymous. Issue 2: Authorization Problem:  Every action is authenticated and authorized when it comes to interacting with a secured NiFi or NiFi-Registry. When the Registry Client attempts to establish a connection to the NiFi-registry, it uses the DN from clientAuth certificate from the configured keystore (provided server can trust it) as the client/user identity.   From your shared authorizers.xml I can see you are using the managed authorizer --> file-access-policy-provider --> ldap-user-group-provider.   So unless your ldap is returning the DN for your clientAuth certificate, you won't be able to setup the necessary authorization needed for the client. Solution: The authorizers.xml could be setup instead to use managed-authorizer --> file-access-policy-provider (modified to use composite-configurable-user-group-provider instead of ldap-user-group-provider) --> composite-configurable-user-group-provider (configured to use configurable provider = file-user-group-provider and provider ldap-user-group-provider).    Both the file-user-group-provider and ldap-user-group-provider configured in the composite-configurable-user-group-provider need to also be configured.  The file-user-group-provider will allow you manually added client/user identities not provided via your ldap-user-group-provider to which you can set authorization policies needed.  The clientAuth certificate DN (may be unique for each NiFi node in a NiFi cluster) would need to be authorized for "Can proxy user requests (read, write, delete)" and "Can Manage Buckets (read)". Issue 3: Authorizers - ldap-user-group-provider use of {0}. Problem:  I suspect you are not getting any users returned by this provider because your user search filter is using "sAMAccountName={0}" and group search filter is using "member={0}".  "{0}" is going to treated as a literal string.  It only has special meaning in the ldap-provider.   Solution:  Stop using {0} in the authorizers.xml file ldap-user-group-provider.  This provider executes every 30 minutes to sync users and groups from ldap.  It doe snot take any outside input.  The ldap-provider does however.  The username entered at login is inserted in place of the {0} in the ldap-provider to be used to verify the username and password provided at login. Issue 4: Authorizers and login-provider - Auth strategy mismatch Problem:  You configured auth strategy as Simple; however, configured a ldaps url: <property name="Authentication Strategy">SIMPLE</property> ... <property name="Url">ldaps://ldapserver.com:636</property> Solution: This provider is not going to work configured like this.  Auth strategy should be "LDAPS" when connecting to "ldaps://..." or your Url should be unsecured "ldap://..." if you still want to use "SIMPLE" ------ Your user identity as displayed (case sensitive) in the upper right corner of the NiFi UI, must also exist as a user in NiFi-Registry and be properly authorized on the bucket(s) that user can use for version control.  Keep in mind that the NiFiRegistryFlowRegistryClient will proxy read/write request on behalf of your NiFi user.  So the authorizations I stated early for the registry client and the authorizations for the NiFi user must both exist in NiFi-Registry. 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

@Kiranq  Nothing stands out to me as problematic in the diagnostics output that relates to the stick FlowFile.  The verbose output indicates just 1 queued FlowFile on the canvas The Diagnostics output then tells us that this one FlowFile is queued in the connection with ID:  d8e8fe6e-38a5-3fee-8933-2e8c6bf55afa The UUID of the queued FlowFile is: ce9cbd21-455b-4191-80bc-6598609b71a1 Details of this One FlowFile:   If you clear out the FlowFile, does the very next FlowFile that enters this Process group get stuck?  Do FlowFiles only get stuck in front of this one specific processor and everywhere else FlowFiles are being processed fine? How is this specific process group configured? Can you list the connection and verify the content of this FlowFile looks correct? Have you tried adjusting NiFi's logging to DEBUG to see if any useful Debug output is produced for the issue? Thanks, Matt ... View more

@Bern  From what has been shared I can't tell you much more then the fact that you are having zookeeper issues.  Without a ZK quorum, NiFi can't maintain the cluster and thus the UI is not available.  There is not much else I can tell you from what you have shared.  I suggest looking more closely at the NiFi app.log and bootstrap logs for other ERRORs or WARNs that may have been logged before or at same time your ZK communication issue started.  You may also want to look at the health of your network. You mention that NiFi goes down nightly and that this started when you were building some "contingency processes".  I am not clear on what this means relative to your NiFi. Do you mean you were adding additional flows to your NiFi canvas when you started having issues? What else are you seeing in the NiFi logs prior to the ZK issue starting? What about CPU load? What about memory: Any Out Of Memory (EoM), continues garbage collection or long garbage collection events? Network issues resolving hostnames of the ZK nodes? Issues telnetting to ZK nodes using the zk configured ports (2888 and 3888)? I also appears you are using the embedded ZK which I would strongly discourage in any production system.  Any resource congestion issues your NiFi experience is going to have impacts on ZK quorum and cluster stability. I recommend standing up an external ZK on different hosts from where your NiFi is installed. It also worth noting that Apache NiFi 1.14.4 was released more then 6 years ago.  There have been many improvements, bug fixes, and CVEs addressed since then. Upgrading to the latest 1.28 (keeping in the same Major release 1.x branch) would be very advisable.  There will be No more Apache NiFi 1.x versions released now that Apache NiFi 2.x major release branch is available. 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

@ThierryOfNantes  Welcome to the Cloudera community. I suspect your issue is with your run.as user.  While the nifi.sh may have executable to all, does your run.as user have necessary permissions to traverse the entire directory tree to the nifi.sh script? I suggest trying to navigate the directory tree as the run as user and starting nifii.sh manually as that user.    Can you share your /etc/rc.d/init.d/nifi script? Can you share your /install_directory/nifi/bin/nifi.sh script?   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

We would need to understand first if the issue is on the CM-agent or on the Nifi-registry. Simply describing if the nifi-registry did not start at all or did start but then failed would help in knowing if the issue is with CM-agent or nifi-registry itself. ... View more

@mansmaan  I'm afraid there is not enough information shared yet to know exactly why you are experiencing a connection refused or connection reset issue from your NiFi node.  I was able to use InvokeHTTP with no issue to successfully get a response from the URL you provided.  I was able to view the weather data that was returned in json format. Have you tried to reach wttr.in directly from command line on the NiFi server? This sound like an environmental issue and not a NiFi invokeHTTP issue.    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