Thanks Mr @MattWho . In addition to your solution, i looked into Network Attached Storage & NFS. So i configured nfs server on the source, then configured nfs client on the destination. And lastly mount the source folder to the destination folder on restart. Thank you all. ... View more

Marfill, If backpressure is applied when the total number of flowfiles in a given queue has reached (#nodes * the limit per node) for example if you have a cluster of 3 nodes and the threshold is set to 10,000 then the backpressure will be applied when total # of flow files = 30,000 and so on. Regarding the Control Rate I believe its done per node statistics, for example if you have a control rate that allows 1 flow file per hour and the control rate processor is set part of load balancing on 3 nodes cluster, let say you receive total of 3 files for the first time  one on each node then the 3 will be get processed immediately. ... View more

Hi @SAMSAL ,   thank you for your help, but you're absoluty right in your second post - the first one seems very "uncomfortable".   @MattWho: I really don't care about the content, i've created backup-files in the stages before mailing and only the consumed filenames are relevant for mail. Last time there was 350 files and 35MB for backup 😉 ... View more

I know.Need FQDN likes testhost.magg.com,Thanks   ... View more

@Luwi  An "active content claim" would be any content claim where a FlowFile exist still referencing bytes of content in that claim.  A NiFi content claim file can contain the content for 1 too many FlowFiles.  So all it takes is one small FlowFile still queued in some connection anywhere on your NiFi canvas to prevent a content claim from being eligible to be moved to archive.  This is why the total reported content queued on yoru canvas will never match the disk usage in your content_repository. This article is useful in understanding this process more: https://community.cloudera.com/t5/Community-Articles/Understanding-how-NiFi-s-Content-Repository-Archiving-works/ta-p/249418 Thank you, Matt ... View more

@Gogineni  had you solved this problem? if yes, would you like to share us. thanks! ... View more

@sayak17  If you are simply looking to GET from a REST API endpoint and take the response and write to a local file on the server where your NiFi service is running, you'll want to use the InvokeHTTP processor and feed that to your putFile processor.   If you found this response assisted with your query, please take a moment to login and click on "Accept as Solution" below this post. Thank you, Matt ... View more

@Reddy3  There is not enough history or detail to understand what lead to the corruption of your NiFi HD DBs. However, the NiFi H2 DBs are used to hold flow configuration history (what user did what on the canvas) and authenticated user server side tokens. These DBs can be removed/renamed and on startup NiFi will created new DBs.  Removing these will have no impact on your flow.xml, content, etc... You will simply lose your flow configuration history (will start over from this point forward tracking changes) and your users will be forced to login again. Hope this helps, Matt ... View more

@pk87  Also consider that using timer driven may not always give you 60 minute scheduling.  When using timer driven the component will get scheduled upon start and then again x configured amount of time later.  A NiFi restart or stopping and starting the processor will reset this.  If you need to make sure that a component is only scheduled every x amount of time consistently, you should be using cron driven scheduling strategy which will allow you to set specific time of schedule. Thanks, Matt ... View more

@shuhaib3 Has the reply helped resolve your issue? If so, please mark the appropriate reply as the solution, as it will make it easier for others to find the answer in the future. Thanks! ... View more