Thank you Rob ... View more

Thanks @Matt Burgess ... View more

Hi guys, thanks so much for the fast support and thanks to the Matts Team @Matt Burgess and @Matt Clarke I finally understood how the processor works. He emits a flow file with no payload and in the meta attributes are the file details like path and filename. Those are used by the HDFSFetch to fetch the correspondent files. Kind regards, Paul ... View more

@Mike Wong Does the listFile exhibit the same behavior or does it list your file correctly? - The fact that the logs shows it the processor yielding tells me it found no work to do (meaning no files to list). It yields so that it does not consume not stop CPU looking for work that does not exist. - Did you check your properties for leading or trailing whitespace? Did you try removing the "\" from your file filter? - Thanks, Matt ... View more

@Srini K Managing TLS/SSL issued certificates is not a job for NiFi. The NIFi CA is not backed by any type of long time management capability. Is becomes complicated to deploy and manage across multiple NiFi deployments. You are experiencing some of that management difficulty here now. - 1. Every Ambari based NiFi installation sets up its own CA. So it becomes difficult to setup communication between systems where each has a different Unique CA signing their certificates. You are trying to get two NiFi's to talk to one another, but this difficulty would extend to any other external service that NiFi needs to communicate to or receive connections from over TLS/SSL. 2. There is no build in management process to handle certificate renews or notifications of expiration. Your NiFi system may be working fine one day in production and then stop working all together the next because your certs expired. - In a production managed environment, a corporately or external managed CA should be used to issue, sign, and manage all your certificate needs. - Yes, NiFi requires TLS/SSL certificates in order to secure NiFi, but SSL/TLS is not a product of NiFi. - As far as merging the content of your two truststore in to a new truststore... A truststore cannot contain multiple keys with the same alias. Each entry must have a unique alias. The trustedCertEntries in each of your existing truststores have the same alias, so you are going to need to change the alias of one of them. Following commands will extract the trustedCertEntry from each source truststore.jks and put tehem in a new-truststore.jks with new unique alias fro each of those entries: keytool -importkeystore -srckeystore truststore.jks -destkeystore new-truststore.jks -srcalias nifi-cert -destalias nifi-cert1 -srcstorepass ****-deststorepass **** keytool -importkeystore -srckeystore truststore.jks -destkeystore new-truststore.jks -srcalias nifi-cert -destalias nifi-cert2 -srcstorepass ****-deststorepass **** ... View more

Upgraded the Firefox to latest version using following command: yum update firefox ------------------ Another error came in the process i.e. Failed to start Flow Service due to: java.net.BindException: Address already in use (Bind failed) Fixed it by changing NiFi protocol port from 9988 to 9989 Issue closed. ... View more

@Mahmoud Shash Just wanted to follow-up to see how things are progressing. Still seeing issue? Did you try any of my suggestions above? I see no reason for having your invokeHTTP processor scheduled to execute on primary node only since it is being triggered by incoming FlowFiles. If you switch it to "all nodes", do you still see issue? What do you see when you perform a "List queue" action on the connection feeding your invokeHTTP processor? Within the "Cluster" UI found under the global menu, who is currently elected as the primary node? Does the data listed when you ran "List queue" belong to that same node? - Thank you, Matt ... View more

@Veerendra Nath Jasthi The DN there is coming from the keystore being used by your NiFi nodes. I have no idea why the certs created for your servers all have nifiadmin in them.... ... But just like your user DN, the node identities must match exactly with what is in those server certs in the keystore.. - <property name="Node Identity 1">CN=nifiadmin, OU=NIFIrsdevhdf1.medassurant.local, OU=NIFI</property> <property name="Node Identity 2">CN=nifiadmin, OU=NIFIrsdevhdf2.medassurant.local, OU=NIFI/</property> <property name="Node Identity 3">CN=nifiadmin, OU=NIFIrsdevhdf3.medassurant.local, OU=NIFI</property> - so you will need to edit your node identities so they match the above and once again stop NiFi, remove your users.xml and authorizations.xml files, and then start NiFi again via Ambari. - Thank you, Matt ... View more