@PriyankaMondal  What is being logged in the nifi-user.log when the issue happens? Have you tried using your browser's developer tools to look at the data being exchanged in the request with the NiFi cluster? Feels like maybe the site cookies are not being sent to the NiFi node after successful authentication resulting in the exception being seen. Thanks, Matt ... View more

@arutkwccu  The release notes for minor releases typically include highlights covering any "deprecated" components (This is documented for Apache NiFi 2.0.0-M1 Deprecated Components and Features ) or components moved to "optional build profiles" (such as this specific parquet bundle).  This is done help make minor upgrades as seamless and painless as possible. Apache NIFi 2.0.0 is a Major release and as such will have many significant changes including breaking changes as well.  As such, it should not be treated the same as minor version upgrade and extra care and evaluation taken during migration from a previous major release version.   I agree that is would have been nice if the Apache Community included another confluence page documenting all components to the "Optional Build Profile" with instructions like i added above on how to add them. Glad you are good to go now. Thank you, Matt ... View more

@elemenop  Not all local changes result in a change to the version controlled flow.   It is typical for a single NiFi-Registry to be used by multiple NiFi deployments (example would be dev and prod deployments). A flow built in the dev environment may be have different configuration based on that dev environment versus what is used in the same dataflow deployed in the prod environment. The following actions are not considered local changes: stopping/starting processors modifying sensitive property values modifying remote process group URLs updating a processor that was referencing a non-existent controller service to reference an externally available controller service assigning, creating, modifying or deleting parameter contexts creating, modifying or deleting variables Sharing the exact Apache NiFi or Cloudera Flow Management (CFM) version along with the reproduction steps executed in yoru environment would be helpful. If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more

@pratschavan  This sound like a configuration issue with your GetFile processor.  Sounds like you may have it configured so that you are consuming the same file over and over again. GetFile processor was deprecated in favor of the newer listFie and FetchFile processors.   Are you running a single standalone instance of NiFi or running a multi-node NiFi cluster? How is your GetFile processor configured? Thanks, Matt ... View more

@Alexy  The answer to your question is neither... The following property is relative to the configuration of the "fileNamingPattern" property. <maxHistory>60</maxHistory>   Let's say we have the following  fileNamingPattern property: <fileNamePattern>logs/archived/app.%d{yyyy-MM-dd}.log.gz</fileNamePattern> This pattern would create one log file per day and then maxHistory would would dictate number of days to retain as 60.    In this specific example the number of days retained and number of files and number of days both equal 60. and another example: <fileNamePattern>${org.apache.nifi.bootstrap.config.log.dir}/nifi-app_%d{yyyy-MM-dd_HH}.log</fileNamePattern> Here you will notice the date pattern is based on hourly logs.  So the "maxHistory" property in this example would dictate the number of hours worth of logs to retain (not days). Now lets look at a slightly different example: <fileNamePattern>logs/archived/app.%d{yyyy-MM-dd}.%i.log.gz</fileNamePattern> <maxFileSize>10MB</maxFileSize> In this example you'll notice "%i" has been added to pattern.  "%i" works in conjunction with the "maxFileSize" property.  throughout a single day any time the log file sizes reaches 10MB, an incremental number log for the same day is created.  app.2024-01-02.1.log.gz app.2024-01-02.2.log.gz app.2024-01-02.3.log.gz ... The MaxHistory does not take into consideration the "%i" incremental logs.  It is still based on the %d pattern to retain 60 days of logs.  So in this case you would have any number of files potentially created across those 60 days. The same applies to the hours based example if "%i" is added to the fileNamingPattern. in order to protect disk usage you will often see the following used: <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy"> <fileNamePattern>${org.apache.nifi.bootstrap.config.log.dir}/nifi-app_%d{yyyy-MM-dd_HH}.%i.log</fileNamePattern> <maxFileSize>100MB</maxFileSize> <maxHistory>30</maxHistory> <totalSizeCap>10GB</totalSizeCap> </rollingPolicy> What this does is create hourly logs that will incrementally role during each hour if the log file reaches 100MB in size. Then to prevent excessive disk usage should logging unexpectedly increase in log generation, the "TotalSizeCap" will start deleting the oldest rolled logs until max usage is below 10GB.  This may mean that 30 hours of logs are no longer retained, but you avoid disk usage issues when the unexpected happens. Hopefully this clears this up for you. NOTE: Above is based on the "SizeAndTimeBasedRollingPolicy".  LogBack as other rolling Policy providers. If you found any of the suggestions/solutions provided helped you with your issue, please take a moment to login and click "Accept as Solution" on one or more of them that helped. Thank you, Matt ... View more