@wang ling The "<propertyname="Node Identity 1">CN=rang2, OU=NIFI</property>" property in the authorizers.xml is only used when using NiFi's default file based authorization provider. It does not apply when using Ranger as your authorization provider. - In Ranger, you will need to make sure the user "CN=rang2, OU=NIFI" exists and has been give access to the "/proxy" NiFi Resource Identifier. - Thank you, Matt - If you found this answer addressed your question, please take moment to login and click "accept" below the answer. ... View more

@Sharoon Babu NiFi processors like these execute against FlowFiles on inbound connections to the processor. The FlowFile is only removed from the inbound connection when that code execution results in that FlowFile being transitioned to an outbound connection. - There are two types of scenarios here: 1. NiFi is shutdown or dies in the middle of a processors execution. This means the FlowFile was never transferred to an outbound connection. When NiFi is restarted, NiFi will reload FlowFiles in to the last connection they were recorded as belong to. In this case that would be an inbound connection. The consuming processor of that connection will then be scheduled to run/execute again. Processors do not record and intermediate phase fo processing and thus will begin executing against the entire FlowFile again. - 2. Some network failure results in execution not being able to complete. NiFi processors should acknowledge failures in such case which would result in the the FlowFile(s) being moved from the inbound connection to an outbound connection (like a "failure" relationship). It is the responsibility of the dataflow designer to account for such unexpected failures and route those outbound failure relationships accordingly. Often times failure type relationships may be just looped back on the same processor for retry. Wherever this FlowFile is routed (even if in a loop), Execution will again be against the entire Flowfiles content again. - The target systems should handle such scenarios and not except unconfirmed file transfers. - For example: PutFile will write the file using a "dot" rename strategy. The FlowFiles content is originally written as a ".<filename>" and then upon successful completion of writing the data, the filename is renamed from ".<filename>" to just "<filename>". Since dot files are in most cases considered hidden files and ignored by source systems that incomplete transfer would be ignored by destination system. Upon recover and re-attempt (depending on processor configuration) NiFi will repeat this process. - There are some unavoidable scenarios that at times can lead to some data duplication. Considering NiFi's design architecture, NiFi has always favored data duplication over data loss in such rare scenarios. - Thank you, Matt - If you found this answer has addressed your question, please take a moment to log in and click the "accept" link on the answer. ... View more

@Sonny Chee It is likely the flow is becoming out of sync as a result of one of the following scenarios: - 1. A change replication request was made to all nodes in the cluster. One or more nodes failed to process that request in the configured allowable nifi.cluster.node.connection.timeout and/or nifi.cluster.node.read.timeout. By default these values are set very low. Recommend setting these at a minimum of 30 secs. Additional reasons why a replication request may fail can range from network issues (high latency or packet loss) to the size of the replication request (snippets) (pasting/copying large selection of canvas components or instantiating a large template. Each node must complete adding every component, connection, controller service, etc in that snippet before responding to the replication request) - 2. A node was in a disconnected state. Every cluster has a cluster coordinator which every node sends heartbeats to. If a node is disconnected from the cluster (through user manual action, or because request failure above), that node's UI cab still be accessed. It will display the work "disconnected" on status bar, but will still allow a user who is connected directly to that node's UI to make changes. So if an attempt is made later (after making some change) to reconnect this node to the cluster, it will fail because flows do not match between cluster and this node anymore. User's who are connected to anyone of the other nodes still in the cluster will see a missing node in the status bar (for example: 1/2). From these node's UIs changes will not be allowed because node is missing. - It is best to look at nifi-app.log or user the cluster UI in NiFi to see why a node was disconnected in the first place. - Users should be educated on how NiFi works as described above and should avoid making changes to canvas when "disconnected" is displayed on NiFi UI status bar above canvas. - NiFi allows changes to be made on disconnected nodes by design. The intent here is to allow users to disconnect a node to perform troubleshooting of a misbehaving node or to perform some temporary one off testing that they do not want to perform across entire cluster. IN such cases, those changes must be backed out before being able to rejoin cluster. Another option is to rename/remove flow.xml.gz on that disconnected node. On restart, in the absence of a flow.xml.gz file, the connecting node will inherit the flow.xml.gz from the cluster. - Thanks, Matt ... View more

@Veerendra Nath Jasthi - Not sure I am following your question. The UI displays the user which is currently authenticated in to the UI. - Are you not expecting to see "CN=niifiadmin, OU=HORTONWORKS"? What are you expecting to see? - What forms of user authentication are you configured to use? User/client certificate? <-- User name displayed in upper right comes from DN in user/client certificate LDAP authentication? <-- User name can come from user DN in LDAP (USE_DN) or username entered in login window (USE_USERNAME) Kerberos authentication? <-- User name comes from user entered principal. <user>@<domain> (so pretty sure you are not using kerberos for authentication.) - Thanks, Matt ... View more