@varun_rathinam    Observations from your configuration: 1. You are using "Defragment" merge strategy which tells me that somewhere upstream in your dataflow you are splitting some FlowFile in to fragments and then you are using this processor to merge those fragments back in to the original FlowFile.  Correct?  When using Defragment you can not use multiple MergeContent processors in series as i mentioned earlier because the defragment strategy is expecting to find all fragments from the fragment count before merging them. 2. When using the defragment strategy it is the fragment.count attribute on the FlowFiles that dictates when the bin should be merged and not the min number of entries.  3. Each FlowFile that has a unique value in the fragment.identifier will be allocated to a different bin. Setting the number of bins to "1" will never work no matter which merge strategy you choose to use.  When the MergeContent processor executes it first checks to see if a free bin is available (if not it merges oldest bin or routes oldest bins FlowFiles to failure in case of Defragment to free up a bin), then it looks at the current FlowFiles in the inbound connection at that exact moment in time and starts allocating them to existing bins or new bins.  So at a minimum you should always have at least "2" bins.  The default is "5" bins.  Having multiple bins does not mean that all those available bins will be used. 4. I see you changed Maximum Number of Entries from default 1000 to 100000.  Is this because you know each of the FlowFiles you split will produce up to 100,000 FlowFiles?  As i mentioned the  ALL FlowFiles allocated to bins have their attributes held in heap memory.  Adding to that... If you have multiple bins being filled because you have unique fragment.identifiers being defragmented, you could have even more than 100,000 FlowFiles worth of attributes in heap memory. So your NiFi JVM heap memory being set at only 2GB may lead you to hitting Out Of Memory (OOM) conditions with such a dataflow design.  Also want to add that where ever you are doing the original splitting of your FlowFile in your dataflow will also have an impact on heap memory because the FlowFile Attributes for every FlowFile being produced during the split process is held in heap memory until every new split FlowFile being produced is committed to a downstream connection.  NiFi connections between processors have swapping enabled by default to help reduce heap usage when queues get large, but same does not apply within the internals of a processors execution.   As i mentioned before, the MergeContent does not load FlowFile content in heap memory, so the size of your FlowFiles does not impact heap here. So you really want to step back and look at your use case again and ask yourself: "do I really need to split my source FlowFile and merge it back in to the original FlowFile to satisfy my use case?" NiFi has numerous record based processors for working with records avoiding the need to split them in many use cases. Hope this helps, Matt ... View more

@NickH    The FetchSFTP processor has multiple different relationships. For your use case of the file really not being there when the FetchSFTP tries to fetch the content, the expected outcome would be that the FlowFile is routed to the "not.found" relationship which you should auto-terminate, If you encountered some sort of communications failure (network issue during Fetch), the FlowFile should have been routed to the "comms.failure" relationship which should be looped back on processor to try again. The FetchSFTP also has a "permission.denied" relationship which you can perhaps handle via dataflow design as well. Perhaps sending an email alert? Hope this helps, Matt ... View more

@MahipalRathore    The bulletin is not going to include anything more than what would be found in the nifi-app.log.  The Bulletin if produced as a result of some failure while processing a FlowFile, will have details about the FlowFiles assigned UUID and filename as well as it size relative to content claim in which the FlowFiles content can be found.  You could the use NiFi data provenance to obtain details on the FlowFile including all its FlowFile attributes.  Some bulletins are for exceptions that occur unrelated to a FlowFile directly and thus will contain no FlowFile info.  But if a FlowFile is routed to failure as a result of for example an exception thrown by the putHDFS processor, details on that FlowFile record should be included in the bulletin. Note: If the bulletin is being produced by a processor that creates a FlowFile, no FlowFile will have been created, so there is no FlowFile created from which to get FlowFile details. Hope this helps, Matt ... View more

@asfou    NiFi does not contain any processors that support Hive version 2.x.  The latest versions of Apache NiFi offer Hive 1.x and Hive 3.x client based processor components.  To support Hive 2.x version, you may need to build your own custom processors built using the Hive 2.x client. Matt ... View more

@saivenkatg55    You need to literally use ./keystore.p12 in your command instead of just keystore.p12 curl --cert-type P12 --cert ./keystore.p12:password --cacert nifi-cert.pem -v https://w0lxqhdp04:9091/nifi-api/flow/search-results?q=     Hope this helps, Matt ... View more