@dupuy_gregory  Yes, a krb5.conf can contain multiple realms in it. The HDFS processor components offered through NiFi can each be configured with different hadoop configuration resources (core-site.xml, hdfs-site.xml, etc..) and different Kerberos credentials (keytab and principal). This will allow various NiFi dataflows to interact with different target Hadoop clusters. If you found this response addressd yoru query, please take a moment to login and click on "Accept as Solution" Thank you, Matt ... View more

@Noctix    Can you share nifi.properties file and authorizers.xml file and verbose output of the nifi-1 keystore and your shared truststore?   It may help ... View more

@sivag  Did you recently upgrade your browser? Have you tried using a different browser? ... View more

@zrbear  It would  be difficult to assist here without you sharing the following: - contents of nifi.properties file - verbose listing of yoru keystore and truststore using keytool  Also make sure if using Java JDK 8 that you have installed the unlimited strength JCE policies: https://www.oracle.com/java/technologies/javase-jce8-downloads.html Hope this helps, Matt ... View more

@HariAllstate  What is the use case for wanting these to be dynamic?   The MergeContent processor allocates FlowFiles located in the inbound connection(s) to bins based on the configuration of these properties: Merge Strategy - Bin-Packing Algorithm - Keeps allocating FlowFiles to bin until both configured mins (Minimum Number of Entries and Minimum Group Size) are met. Bins can also be restricted to FlowFiles all having same value set in that attribute specified in the Correlation Attribute Name property - Defragment - FlowFile are allocated to bins based on fragment Attributes set on the inbound queued FlowFiles. The purpose of the Max Bin Age is to prevent bins from getting stuck forever because they do not meet the criteria necessary to be merged.  Assume the scenario where the max num entries has been reached preventing any new FlowFiles from being allocated to a bin and those binned FlowFiles did not total enough size to meet the min group size.  Since both mons must be satisfied for a bin to be merged, that bin could potentially sit forever.  Max bin age when reached would force that bin to merge.  In the case of Defragment the FlowFiles would rout to failure if max bin age is reached before all fragments are allocated to a bin.  So Max Bin Age should be set to max latency you want to allow on a bin. Not clear on why you would want that to be dynamic and if it was, where would you pull that value from since many FlowFiles are allocated to a bin and they could end up having a variety of values. Since only the "mins" must be satisfied to merge a bin, not clear why you would want a dynamic capability here as well.  Plus same applies here in that many FlowFiles are allocated to bins and may have different values. Also note that the processor does not use Max when considering if a bin is ready to be merged.  When the MergeContent processor executes, it looks at only the FlowFiles queued on an inbound connection at that exact moment in time and allocates them to 1 or more bins. At the end of that allocation, each bin is evaluated to see if the mins were satisfied or all the fragments are in the bin and if so, it is merged. If you found this addressed your query, please take a moment to login and click "Accept as Solution" Thank you, Matt   ... View more

@jg6  There is no direct relationship between the DistributedMapCacheServer and the DistributedMapCacheClientService.  Meaning that the client is simply configured with a hostname and a port.  This hostname and port could be a DistributedMapCacheServer running on an entirely different NiFi cluster somewhere. Additionally there is no component that registers a dependency on the DistributedMapCacheServer controller service.  They only have a dependency on the DistributedMapCacheClientService.  So when constructing a template only the interconnected and dependent pieces are included. That being said, using the DistributedMapCache is not the cache I would recommend using anyway.  IT offers no high Availability (HA).  While a DistributedMapCacheServer is being started on every node in a NiFi cluster, they do not talk to one another and the DistributedMapCacheClientService can only be configured to point at one of them.  So if you lose the NiFi node were your clients point, you lost all your cache.  There are better options for external cache services that do offer HA. Hope this is helpful, Matt ... View more