Details
-
Bug
-
Status: Open
-
Major
-
Resolution: Unresolved
-
1.12.1, 1.14.0, 1.13.2
-
None
-
None
-
Default standard NiFi from official download without changes.
nifi.content.repository.archive.enabled=true
nifi.content.repository.archive.max.usage.percentage=50%
Specifically, I have a disk that is 80% full when NiFi starts. For the test I used a Mac Book Pro 13” i7, 2019 with SSD. The file limits (launchctl limit maxfiles) are: filemaxfiles 65536 65536.
openjdk 11.0.6Default standard NiFi from official download without changes. nifi.content.repository.archive.enabled=true nifi.content.repository.archive.max.usage.percentage=50% Specifically, I have a disk that is 80% full when NiFi starts. For the test I used a Mac Book Pro 13” i7, 2019 with SSD. The file limits (launchctl limit maxfiles) are: filemaxfiles 65536 65536. openjdk 11.0.6
Description
If content archiving is enabled when NiFi is started (nifi.content.repository.archive.enabled=true) and the threshold above which deletion occurs is less than the actual free space available on disk, unexpected behavior will occur.
I have attached a simple flow (content_archiving_bug.xml) that is accessed via a HandleHttpRequest. In one of the branches then very many FlowFiles are created (DuplicateFlowFile). (This is to simulate a complex flow in production to show the behavior there).
If you call this branch via the browser a few (5-10) times, this leads to the fact that either no more FlowFiles are processed in the flow or that this happens only extremely slowly.
In addition, the HandleHttpRequest then takes no more requests from the queue and reports queue full back (to show this better, the queue is configured smaller).