@asand3r  A node must be "disconnected" before it can be offloaded.  Only a running node can be offloaded.  So as long as a node is running. it's UI will be accessible. A couple options: https://<nifi-node>:<nifi-port>/nifi-api/controller/cluster. <-- this end point when hit will return the following type responses: If node is connected, it will return json that includes the connection status of all nodes that are part of cluster.  So this response could be parsed to see if any nodes are disconnected. So you could parse status of all nodes from a single connected node's response If node is not connected, it will return "Only a node connected to a cluster can process the request" which tells you that node is disconnected. https://<nifinode>:<nifi-port>/nifi-api/flow/cluster/summary If node is connected, it will return a response like this:  {"clusterSummary":{"connectedNodes":"3 / 3","connectedNodeCount":3,"totalNodeCount":3,"connectedToCluster":true,"clustered":true}} If node is disconnected, it will return a response like this: {"clusterSummary":{"connectedNodeCount":0,"totalNodeCount":0,"connectedToCluster":false,"clustered":true}} You'll need to parse the responses for connectedToCluster. If true use that node's UI, if false, exclude that node's UI. Of course if node is completely down, above will not help unless you mark as unavailable if no response. 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

@asand3r  It is important to understand what offloading does and does not do. Offloading is the moving of queued NiFi FlowFiles from the offloading node to other nodes in the NiFi cluster.  A NiFi FlowFile consists of two parts: FlowFile attributes/metadata (stored in the flowfile_repository) and FlowFile content (stored with claims inside the content_repository). A content claim can contain the content for 1 too many individual FlowFiles.  Offloading does not move content claims (what you see in the content_repository) from one node to the other.  It moves FlowFiles, which means it moves the FlowFile attributes and the content for that FlowFile over into FlowFiles on the node it is being transferred to.   I suspect that the 21GB of content equated to the amount of content currently queued FlowFiles on node 2.   The cumulative size of the active FlowFiles queued on a NiFi node does not equal the cumulative size of active content claims in the content_repository.   Every content claim has a claimant count. This claimant count keeps track of how many FlowFiles have a claim against some bytes of data in the content claim. As a FlowFile reaches a point of termination in a NiFi dataflow, the claimant count on a content claim is decremented. Only once the claimant count reaches 0 on a content claim does that content claim become eligible to be moved to an archive sub-directory and considered for removal under the archive configurations set in the nifi.properties file.   So it is possible for a 1 byte FlowFile still queued on the NiFi canvas to prevent a much larger content_claim from being archived.  So I do not suspect you lost any data during offload.    1. Are you working with many very small FlowFiles? 2. Are you leaving FlowFiles queued in connections that never get processed through to termination? You are also correct that your other nodes would have begun processing the transferred FlowFiles as they were being placed in the queues on those nodes. The large difference in FlowFile count of disk usage between nodes is often the direct result of the dataflow design choices.   I suspect the node 2 was your elected primary node at the time prior to disconnect and offload operations.  The elected primary node is the only node that will schedule "primary node" only configured processors.  So unless you utilize load balanced configurations on the connection following the "primary node" only scheduled ingest processor, all the FlowFiles will be processed only on that primary node in the downstream processors in the dataflow. Also keep in mind that you are using a fairly old version of Apache NiFi (~4 years old) The latest and final release of Apache NiFi 1.x line is 1.28. So I recommend upgrading to this latest 1.28 version and start planning for an upgrade to the NiFi 2.x release versions.   Apache NiFI has also release the Apache NiFi 2.x new major release version.  There is a fair amount of work that must be done before you can migrate from Apache NiFi 1.28 to Apache NiFi 2.x version. 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

@HeniNechi  Try configuring an absolute path for the location of both the users.xml (generated by file-user-group-provider) and authorizations.xml (generated by the file-access-policy-provider) files instead of using "../data/".  Make sure that the absolute path is accessible by yoru NiFi service user and that That service provide has permission to allow it to create the users.xml and authorizations.xml files in that directory path. NiFi will fail to start if the authorizers.xml fails to successfully execute which is what you are encountering. I suspect a permission issue or similar that is preventing NiFi from being able to create the necessary files in the defined directory path. 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