@mayki wogno Are you issuing commands against the rest api or are you trying to make a change within the UI when this occurs? Sounds like multiple changes being made against the same component at the same time. Each component has a revision number so that two people can't make changes to the exact same component at the same time. So when the second change is applied using the same revision as the first request which was successful, you get these responses. Two ways this can occur... 1. Two authenticated users are making a change to the configuration of the same processor. User 1 hits apply and that change is applied. User 2 then hits apply and a conflict response occurs from the first node that receives the request. 2. Multiple rest api call are being made against the same component without updating the revision number in the subsequent rest api calls. As far as node going down.... Do you mean you lose the api and have to refresh the browser? or does the cluster completely go down forcing you to restart nodes to get nodes to rejoin cluster? Thanks, Matt ... View more

@Raj B Thank you... Sometimes the most important piece of information is in the fine details. Other give away that it was clustered was that both FlowFiles in that queue had same position "1". Two FlowFiles in the same queue on the same node cannot occupy the same position. ... View more

@Constantin Stanca @Mohammed El Moumni Queue thresholds are per node and will cause a queue to no longer accept additional FlowFiles, It will not prevent downstream processor from processing FlowFiles that are already in that queue. Had he received two 700MB CSV files on one node, then the 1GB threshold would have been exceeded thus preventing any additional FlowFiles from entering that queue (including the corresponding 70 byte header files). In that case you would be stuck, since merge would not have the files even on a single node needed to merge a bin. Thanks, Matt ... View more

@Christophe Vico Confirm the DN of the PrivateKeyEntry in the keystore of all you nodes. # keystore -v --list -keystore <keystorename> Also confirm the patterns have been set on all nodes in the nifi.properties file. All it takes is a slight difference (extra space, missing space, case sensitivity, etc...) Thanks, Matt ... View more

@matthew N Accessing the NiFi UI requires to things to be successful: 1. User Authentication: You appear to be using LDAP to handle this part. 2. User Authorization: By default NiFi uses its internal file based authorizer (Configured in authorizers.xml) If an authenticated user lacks sufficient authorization to access a NiFi resource, you will see the "Unable to perform the desired action due to insufficient permissions. Contact the system administrator." response from NiFi. In order for an authenticated user to see the NiFi UI, they must at a minimum be granted the "view the user interface" access policy. Whichever user was configured as your "Initial admin Identity" will need to access the UI and add additional users and access policies for those users. Also keep in mind that NiFi generates the users.xml and authorizations.xml files only once the first time your NiFi is started securely. If you update who your initial admin identity is later, it will not get updated if these files already exist. If this is the first time setting up a new system, simply delete the users.xml and authorizations.xml files and restart NiFi. They will then be created again based on the current configurations in the authorizers.xml. Before updating your initial admin identity in the authorizers.xml file, I suggest looking in your nifi-user.log to versify the exact string being passed to the authorizer. It must match exactly since it is case sensitive and spaces also count as valid characters. (for example: CN= is not the same as cn=) The string you see output in the nifi-user.log is what will be passed to the authorizer. Thanks, Matt ... View more

@matthew N Sharing the full stack trace that goes along with the above NPE will help identify where the issue is occurring. ... View more