@Emery  Your first query: One thing I've noticed is that it's not possible to select the MapCacheClientService I created. Components added to the NiFi canvas only have access to the controller services created on Process Groups (PG) on the canvas.  Even when you are looking at the canvas presented when you first login, you are looking at the root PG.  From the root PG you can create many child PGs.   When you use the Global Menu in the UI to access the "Controller Settings", you have the ability to create "Management Controller services".  Controller services created here are for use by Reporting tasks and Registry Clients created from with the same "Controller Settings" UI.  They are not directly going to be referenced by the components on the dataflow canvas.   This is why the MapCacheClientService you created was not see by your PutMapCache and FetchMapCache processors.   From within the processor component, you have the option to select existing supported controller service that exist already within the current PG level or any parent level PG (assuming user has proper permissions at those parent levels).  It is important to understand the Child PGs inherit policies from parent PGs unless an explicit policy is defined on the child PG.  You also have the option to "Create New Service", which you can select even if an available controller service already exists.. If a supported controller service exists, it will be presented in a selectable list when you click on the processor field, so it is NOT necessary to create a separate controller service for each processor. To create a new service you must click on the three stacked dots instead of clicking on the field. Please help our community grow. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@shiva239  The Schemas are fetched when a FlowFile is processed by the PutDatabaseRecord processor.  There is no option to schedule a refresh of the existing cache. There is no rest-api endpoint or options available to flush the cache on demand aside from maybe stopping and starting the processor.  But doing so means every schema will be cached again as new FlowFiles are processed by the PutDatabaseRecord processor, so not an ideal solution/work-around. The issue you are having is related with an existing Apache NiFi NIFI-12027 PutDatabaseRecord  improvement jira.  I suggest you add a comment to this jira explaining your use case and impact this has.  Perhaps someone in the community or yourself can contribute to this improvement. Please help our community grow and thrive. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@0tto  Welcome to the community. NiFi backend does not provide the ability to configure the Provenance Repository to store provenance events in an external DB which can then be accessed via the Provenance UI integration.  However, there are couple provenance Reporting tasks available within NiFi that can be used to additionally send provenance event (local provenance still exists) to another destination.   AzureLogAnalyticsProvenanceReportingTask SiteToSiteProvenanceReportingTask For sending the provenance events to a DB, building a dataflow on a dedicated NiFi instance via the SiteToSiteProvenanceReportingTask is going to be the option for you. So you would add this reporting task to the NiFi instance/cluster generating the provenance events you want to keep for long term storage.  You would setup another NiFi instance/cluster for processing the large volume of provenance events.  The Reporting task would be configured to send the provenance events to a Remote Input Port the other NiFi via NiFi's Site-To-Site capability. Admin guide: Site to Site Properties User guide: Site-to-Site Once these provenance events are received by that other NiFi they will become content of FlowFile which you can route via a NiFi dataflow on the canvas and send them to whatever storage destination of your choice. Note: You typically do not want to use the same NiFi where you are using the reporting task to receive and process the provenance events because those received events also will produce provenance events as they are routed through the dataflow, so you would have endless provenance events being produced.  Sending to an dedicated provenance NiFi instance/cluster makes sure that your DB contains only the dataflow(s) provenance events of interest. Please help our community grow and thrive. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@jirungaray  Welcome to the community. The DetectDuplicate processor does not store anything in NiFi state providers (local state directory or cluster state in zookeeper).  The DetectDuplicate processor utilizes a DistributedMapCache Service to store cached items.  Depending on the cache service used, those cache service may offer retention configurations for number of cache entries and cache entry persistence. Any NiFi component that retains state will indicate such in its documentation under the "State Management" section. The "Age Off Duration" configuration will age off cache entries that may still exist when that duration is reached, but it can not control the number of cache entries the end service will retain.  So the cache service may still be evicting cache entries prior to that configured Age of Duration is reached. Since you mention that your Cache Entries are not being preserved on NiFi restart, I assume you have configured your DetectDuplicate to use the DistributedMapCacheClientService.    The DistributedMapCacheClientService is dependent on the existence of a running DistributedMapCacheServer.  This DistributedMapCacheServer does in fact hold cache entries within NiFi's Heap memory and unless you have configured a "Persistence Directory", will lose all cache entries on NiFi service stop.  The DistributedMapCacheServer also has configuration thresholds for the max number of cache entries it will hod before evicting cache entires based on the eviction strategy configured.  This configuration established an upper boundary.  Keep in mind the higher the Max Cache Entries setting, the more NiFi heap memory is used which could lead to NiFi experiencing OutOfMemory (OOM) exceptions.  Since it sounds like you want to retain a very large amount of cached entries, I'd recommend against using the NiFi internal DistributedMapCacheClientService considering the high heap memory usage it would require and the high likelihood that will impact your NiFi's stability and performance.   NOTE: The DistributedMapCacheClientService and DistributedMapCacheServer do NOT offer any form of High Availability. The DistributeMapCacheClientService can only be configured with a single server hostname. While the DistributedMapCacheServer when started does create a running Cache server on all hosts within the NiFi cluster, the cached entries are not shared or replicated across all of them. ONLY the cache server hostname configured in the DistributedMapCacheClientService is used. For HA, you should be using a more robust external to NiFi cache service like Redis.     Please help our community grow and thrive. If you found any of the suggestions/solutions provided helped you with solving your issue or answering your question, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more