We discovered what the issue was. In generating the certs using the nifi toolkit, we were not using the --nifiDnSuffix switch. So the zookeeper OU was defaulting to NIFI. As soon as I found that, it resolved the issue. ... View more

@LuxIsterica    "filename" is also another FlowFile attribute that is created by default on every FlowFile that is created in NiFi.  With some processors a filename can not be derived from or created based in the content that is received. ExecuteSQL (no inbound connection) and generateFlowFile processors are good examples here. In case like this, NiFi will just default to using the FlowFile's uuid as the filename also. Your statement "attribute "filename" that generated that executesql is "inherited" in all processors" is not accurate.  Processors do not inherit attributes.   A NiFi FlowFile exists of two parts: 1. FlowFile attributes/metadata -- These FlowFile attributes reside in heap memory and are also stored in the flowfile_repository.  It is these attributes which "flow" from one processor component to another in you dataflow you build on the canvas. Processors then have access to these FlowFile Attributes when they execute against a given FlowFile from the inbound connection.  Some processors as part of their execution will create additional attributes on a FlowFile before it is committed to the processor relationship that is assigned to a outbound connection. 2. FlowFile Content -- The actual content of a FlowFile is written to a claim in the content_repository.  It is only access as needed by a processor.  It does not reside in heap memory unless a processor needs to do so to perform its function. These FlowFile attributes can be changed as your FlowFile passes through different processors, but they belong to the FlowFile and not the processors at all.  So there is nothing you need to "preserve/save" in most cases. Hope this adds some clarity, Matt ... View more

@pxm    NiFi sets not restriction on the data size that can be processed.   Ingested data becomes the content portion of a NiFi FlowFile and is written to the content repository.  The data is not read again unless a processor needs to read the content; otherwise, only the FlowFile attributes/metadata is passed from processor component to another component.  So you need to make sure you have sufficient storage space for the NIFi content_repository.  It is also strongly recommended that this dedicated storage separate from any other NiFi repository. Beyond that, any limitation here will be on network and disk IO.   Thanks, Matt ... View more

@pauljoshiva    What this error is telling is that the flow.xml.gz on this node does not match the flow.xml.gz that is running on another node.  On startup of all your NiFi nodes an election takes place to determine which flow.xml.gz will be elected as the cluster flow.  So node 1 presents its flow (1 vote), then node 2 presents its flow (if it matches node 1's flow that flows vote increases to 2, if not it gets its own singular vote), this process repeats for all nodes joining the cluster until a flow.xml.gz is elected to be the cluster vote.  At that point in time, any nodes that have a flow.xml.gz that matched this elected cluster flow will throw the exception you  reported and shut back down. Since all nodes in your cluster must be running the exact same flow.xml.gz, you can copy the flow.xml.gz from one of the nodes that is up and joined in to the cluster to the node that threw the exception and restart it.  It should successfully join the cluster at on restart this time. Hope this helps, Matt ... View more

Hi @MattWho    I understand, but like i said was a fresh instalation and NiFi never works. I try to remove the file from the /run/cloudera-scm-agent/proccess/NIFI_FOLDER but not works and i can't find the file in other location on the node.   Maybe was my fault, i try to start directly with TLS and never works, maybe the first start can't create the cert from the NiFi CA (because i saw in the role log a message with missing keystore file) and is for that the NiFi can't start fine and then create the previous sensitive.key file.   Finally i remove the service, start un-secure, force to NiFi CA to recreate the certs and then, activate TLS/SSL and is when NiFi starts fine and is working.   Now i have another problem, i install NiFi in two workers nodes but only one web ui works, the other web ui shows this message:   Secure Connection Failed An error occurred during a connection to HOSTNAME:8443. Certificate key usage inadequate for attempted operation. Error code: SEC_ERROR_INADEQUATE_KEY_USAGE The page you are trying to view cannot be shown because the authenticity of the received data could not be verified. Please contact the website owners to inform them of this problem.     Any way @MattWho thanks for your help, i'll keep working on the NiFi web ui issue and try to configure ldap authentication, in this moment i only get the user name validation, i try to integrate the gruop validation.   Best Regards. ... View more