You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by "Joe Witt (Jira)" <ji...@apache.org> on 2022/04/11 14:36:00 UTC

[jira] [Resolved] (NIFI-9885) Content repository applies backpressure even when archiving disabled

     [ https://issues.apache.org/jira/browse/NIFI-9885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Joe Witt resolved NIFI-9885.
----------------------------
    Resolution: Fixed

> Content repository applies backpressure even when archiving disabled
> --------------------------------------------------------------------
>
>                 Key: NIFI-9885
>                 URL: https://issues.apache.org/jira/browse/NIFI-9885
>             Project: Apache NiFi
>          Issue Type: Bug
>          Components: Core Framework
>         Environment: 1.13.2 (this code part seems unmodified to latest master to date (and 1.16.0)
>            Reporter: Guillaume Lhermenier
>            Assignee: Mark Payne
>            Priority: Major
>              Labels: archive, backpressure, content-repo, content-repository
>             Fix For: 1.17.0, 1.16.1
>
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> When specifying `nifi.content.repository.archive.enabled` to false, I expect NiFi to not do any archiving activities, despite I would have some archiving related configurations set in my properties file.
> For example, for this configuration subset 
> {code:java}
> nifi.content.repository.archive.max.retention.period=1 hours
> nifi.content.repository.archive.max.usage.percentage=50%
> nifi.content.repository.archive.enabled=false {code}
> I would expect NiFi to just delete the claim and not doing any archiving activity.
> However, with that exact configuration, I can see in logs some stuffs like 
> {code:java}
> 2022-04-06 07:25:02,234 INFO [Timer-Driven Process Thread-54] o.a.n.c.repository.FileSystemRepository Unable to write to container default due to archive file size constraints; waiting for archive cleanup
> or 
> INFO [Cleanup Archive for default] o.a.n.c.repository.FileSystemRepository Successfully deleted 0 files (0 bytes) from archive {code}
> I ended up wondering why this could happen.
> So I dig a little bit in "FileSystemRepository" class and found the following
> [Here|https://github.com/apache/nifi/blob/b019a9191f1c83bc7f547dc02c1b679b8936acee/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/repository/FileSystemRepository.java#L193] We can see that the property "nifi.content.repository.archive.enabled" determines the variable "archiveData".
> But [here|https://github.com/apache/nifi/blob/b019a9191f1c83bc7f547dc02c1b679b8936acee/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/repository/FileSystemRepository.java#L238] we can see that the containerState created with "archiveEnabled = true" is only determined by maxArchiveRatio > 0D, no matter the value of archiveData. 
> So if we disabled the archiving but left the property "nifi.content.repository.archive.max.usage.percentage" set (which would lead to compute "maxArchiveRatio"), then the containerState will be started with archive enabled. 
> [This line |https://github.com/apache/nifi/blob/b019a9191f1c83bc7f547dc02c1b679b8936acee/nifi-nar-bundles/nifi-framework-bundle/nifi-framework/nifi-framework-core/src/main/java/org/apache/nifi/controller/repository/FileSystemRepository.java#L224]
> {code:java}
> if (maxArchiveRatio > 0D) { {code}
> should better be
> {code:java}
> if (archiveData && maxArchiveRatio > 0D) { {code}
>  



--
This message was sent by Atlassian Jira
(v8.20.1#820001)