@Vincent van Oudenhoven A Jira was raised in Apache Jira (https://issues.apache.org/jira/browse/NIFI-4761) to add a whitelist capability so that users could create a list of hostnames that would be allowed. This Whitelist feature is already part of the HDF 3.1 release from Hortonworks and will be part of the Apache NiFi 1.6 release at a later time. I am sorry to report there is no way around this host name check in Apache NIFi 1.5. Thanks, Matt ... View more

@Abdou B. The NiFi SSLContextService does not allow you to define a specific key alias to use from a keystore that contains multiple PrivateKeyEntries. So it is important that your keystore contains only a single PrivateKeyEntry that identifies the entity (user or server) that you want to use in the connection configured to use that specific keystore file. You can create as many unique SSLContextServices as you like in NiFi. I suggest creating and naming a unique one for each different keystore you will be using. If you plan on just using the NiFi server's keystore, I would create a SSLContextService that uses the same keystore and truststore that your NiFi is using in the nifi.properties file. Things to remember about NiFi and keystores.... 1. Keystore must contain only one "PrivateKeyEntry". 2. If certificate in keystore is being used by a listening type processor (ListenTCP, ListenHTTP, etc...), it will need to support "serverAuth". If it is being used in any processor where it is connecting to an external service (consumeKafka, publishKafka, etc...) it must support "clientAuth". Your Nifi.properties keystore must support both "clientAuth" and "serverAuth" 3. In a NiFi cluster, the keystore must exist on every node in the cluster. While the certificate in each keystore can be unique, the name of the keystore file and the passwords used to access the keystore must be identical on every node. 4. A commonly used truststore file is a good practice. I makes managing you r NiFi much easier only having one truststore file to update. The Truststore can contain one to many "TrustedCertEntries". These trustedCertEntries can be the public cert for each of your identities (user or server) and/or the public cert for the various Certificate Authorities (CA) that signed those private certs (more common). *** Keeping backup of your keystore and truststore files is always a good idea, NiFi does not write to these files and only reads them when accessed by a SSLContextService, but it is possible for a user in NiFi setup a flow that could consume these files (if local file permissions allow for it). Thank you, Matt ... View more

@Richard Corfield The queue stats on a connection will reflect the number of FlowFiles and cumulative size of those queued FlowFile's content. It does not include any archived content. I am not aware of your throughput rates or the variations in FlowFile Content sizes in your dataflow that may explain what you are seeing. A NiFi Content claim cannot be archived until there are no active FlowFiles anywhere in your dataflow pointing to that claim. Perhaps some screenshots will help make sure we are talking about the same thing when you say "queue". Thank you, Matt ... View more

@Rahul Soni Event Driven Scheduling strategy is considered experimental. It was developed long ago as an alternative to Timer Driven scheduling strategy. With enhancements to the Timer Driven strategy since then, The event Driven strategy has pretty much been abandoned. It only still exists for now to avoid breaking any backwards capability for NiFi users. Timer Driven strategy: Processors have a configured schedule they run at. The 0 sec default means that the processor will attempt to run as often as possible. This works in conjunction with the concurrent task property. When the processor runs it use the concurrent task. The processor will be unable to execute again until that thread completes unless their are additional free threads available via additional configured concurrent tasks. Back when the event driven strategy was developed the timer driven strategy was not a s mature as it is now. With a run schedule of 0 secs and no work to do, the processor would end up consuming 100% of a cpu all the time constantly checking for work. The Timer Driven strategy has since had several improvements including yielding when there is no work to do to prevent excessive CPU usage. Event Driven Strategy: Rather then the processor deciding when to run, The NiFi controller would hand out threads based on work needing to be done. Essentially if an incoming connection to a processor using Event Driven strategy contained FlowFiles, the core would schedule that processor to execute. The concurrent tasks setting takes on a different meaning here. It is the ceiling more the maximum number of event driven threads that can be assigned concurrently to this processor. 0 would be very dangerous as it remove the ceiling al together. The strategy in the long run ended up being less performant then the Timer Driven strategy. Thanks, Matt ... View more

@Mahendra Hegde One possible solution may be to feed the "Success" relationship from the putFTP processor to a MergeContent processor. The MergeContent processor could be configured to merge once it receives all 10 FlowFiles. The single resulting FlowFile from that merge could be used as your trigger file. UpdateAttribute processor could be used to change it name and ReplaceText could be used to replace its content post merge if your trigger files has a specific requirements. Then use another PutFTP processor to send this trigger file to your FTP server. Thanks, Matt ... View more

@Mark Lin Make sure you added your custom nar to every node in the cluster and that the ownership and permissions on the nar on each Nifi cluster node is correct. It sounds like at least one of the nodes is missing the nar or was unable to read/unpack it to the work directory. Also make sure that every node sis running the same version of your nar. You could also try stopping NiFi on all you nodes and removing the entire "work" directory and restarting. Thanks, Matt ... View more