Issue was browser version related. Switching to a newer version of the browser resolved this issue. ... View more

@Kiem Nguyen I highly recommend starting a new question in Hortonworks community connection for this. Diagnosing what caused your node to disconnect and how to resolve is a different topic from how to stop a processor with a disconnected node. It would also be helpful to explain what you mean by "overloaded queue" and what makes you feel the size of your queue triggered your node to disconnect. What error did you see in the nifi-app.log on the node that disconnected. Thanks, Matt ... View more

@sally sally The user who is logged in and building out dataflow, has no correlation to who that dataflow is running as. All the processors on the canvas are being executed by the user who owns the Nifi process itself. So when you setup a SSL Context Service to use a specific keystore and truststore, it is the PrivateKeyEntry in that keystore that will be used as the user for authentication and authorization during any established connection. The TrustedCertEntry(s) in the truststore provided in the SSL Context Service will be used to establish trust of the Server certificates passed by the endpoint (in your case the certs being passed from your NiFi nodes) during the two-way TLS handshake. Now this is a little different then when you log in via the browser to the UI. Two-way TLS is not enforced by your browser like it is by NiFi's processors. Your browser likely did not trust the cert presented by your NiFI nodes, and you added an exception the first time you connected saying that you would like to trust that unknown cert coming from the nifi node. Within NiFi and the SSL Context Service, there is no way to add such an exception. So trust must work in both directions. This means the truststore you use in your ssl Context Service must be able to trust the certificates being passed by each of your Nifi nodes. Thanks, Matt ... View more

@sally sally What user own the running NiFi process? You need to make sure that user can read those keystore files. I suggest becoming that user on the NiFi server and making sure you can change directories to the location of cacerts.jks file. Also as that user run the keytool list command. keytool -v --list -keystore <path to keystore>/cacerts.jks The keystore file must contain a "PrivateKeyEntry" for your user. (The issuer will be the user if it is self-signed or it will be a CA if it was signed by a CA.) The truststore file must contain a "trustedCertEntry" for your user (self-signed) or the CA that signed the cert for you user. Also make sure that these files exist in the same location on every node if you are running a NiFi cluster. Thanks, Matt ... View more

@Wesley Bohannon Glad you came up with a solution. Sorry I did not get back to you sooner. Vacation got in the way. 🙂 ... View more

@sally sally Many processors in NiFi support using a the NiFi "SSL Context Service". Looking at InvokeHTTP processor as an example: You can create as many SSL context service as you want. Each can be configured to use its own keystore and truststore files. There are plenty of resources on-line for taking your pem file and loading it into a PKCS12 (.p12 or .pfx file) keystore. For the truststore, I would suggest using the JKS truststore already in use by your secured NiFi. Thanks, Matt ... View more

@Wesley Bohannon I setup a similar dataflow that is working as expected. The only difference is you made your fragment.index values 0-3 and I made mine 1-4. Is the FlowFile Attribute "table_name" set on all four FlowFiles? Is the value associated to the FlowFile Attribute "table_name" on all 4 FlowFiles exactly the same? Below is my test flow that worked: As you can see one 4 FlowFile merge was successful and a second is waiting for that 4th file before being merged. Thanks, Matt ... View more

@nesrine salmene The Database repository consists of two H@ databases: nifi-user-keys.h2.db nifi-flow-audit.h2.db When NiFi is running you will see two additional lock files that correspond to these databases. The nifi-user-keys.h2.db is only used when NiFi has been secured and it contains information about who has logged in to NiFi. The same information here is also output to the nifi-user.log. You can parse the nifi-user.log to audit who has logged in to a particular NiFi instance. The nifi-flow-audit.h2.db is used by NiFi to keep track of all configuration changes made within the NiFi UI. The information contained in this DB is viewable via the "Flow Configuration History" embedded UI found under the Upper right corner hamburger menu in NiFi's UI: You can use NiFi's rest API to query the Flow Configuration History. Thanks, Matt ... View more