@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

@Aiiyer  What ERROR?  All I see are a bunch of normal INFO log lines form the nifi-app.log snippet you shared. Please share the ERROR log line and stack trace if present.   Or share screenshots of what you are doing and observing. Thank you, Matt ... View more

@midee    You are using an InvokeHTTP processor to hit the rest-api endpoint of some authentication service to obtain a JWT Token, correct? The invokeHTTP processor gives you only two options for handling the response from the endpoint.  Placed it in the content of the FlowFile or in to an attribute of the FlowFile.  This means that any user who has been granted authorization to view the data of any component that this FlowFile will traverse can see the attributes and content of this FlowFile. There is no capability for the invokeHTTP to encrypt/mask the endpoint response in either options.  Even if there was, this now masked/encrypted data would no longer be usable by downstream components.  I suspect your plan is to then use this token to make additional requests to other endpoints later in your flow?  Also keep in mind that a token generally has a limited lifespan.  You should also have the ability to invalidate the token via another endpoint when you are done with it.    So your options here are: 1. Limit user's access so they can not view the data in the dataflows that utilize this token so that they can't see the token in the content or attributes.  If you are building the flow, then you know how to get the token so does not matter that you can see the token via the attributes or content. 2. Invalidate the token once done with it. Token can't be used anymore even if a user gained access to it later via looking at the content or attributes of a FlowFile.  So you may consider building yoru flow to get a token --> use that token for other actions --> invalidate token (Using NiFi login authentication as a JWT token example, you hit the logout endpoint to invalidate the token on the server side. This means the client token will no longer work even if you have it still).  Of course this means you flow needs to obtain a new token every time it runs.  Issue here is if your flow utilizes same token for multiple FlowFiles.  First FlowFile that hist logout will invalidate token other FlowFiles may try to still use.   Note that the default life of a token issued by NiFi is 12 hours.  After that the client token can't be used anymore and a new token would need to be obtained anyway (of course this age can be adjusted via the NiFi login provider configuration) If you found this answered your query, please take a moment to login and click "Accept" on the solutions that assisted you. Thank you, Matt ... View more