[
https://issues.apache.org/jira/browse/NIFI-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14720442#comment-14720442
]
Bryan Bende commented on NIFI-905:
----------------------------------
Ah I see what you are saying now, so my scenario will never trigger the
archiving because the partition is too small. I think your idea of how to
calculate the point of moving to another file makes sense, but probably not
required to address the intent of this ticket. I'll let that be your call, but
we could create another ticket "Adjust max append claim length based on max
partition size" if that makes sense.
In any case, given the above I was able to test a new scenario which is filling
up the content partition. Verified that processing resumed when I removed other
miscellaneous files to free up space.
> Clean up not occurring when content repository reaches max usage percentage
> ---------------------------------------------------------------------------
>
> Key: NIFI-905
> URL: https://issues.apache.org/jira/browse/NIFI-905
> Project: Apache NiFi
> Issue Type: Bug
> Affects Versions: 0.3.0
> Reporter: Bryan Bende
> Assignee: Mark Payne
> Fix For: 0.3.0
>
> Attachments:
> 0001-NIFI-905-Ensure-that-when-archive-threshold-is-hit-a.patch, nifi.dump
>
>
> Created a 500MB partition and set the content repository to use that
> partition, then created a simple Flow with GenerateFlowFile ->
> UpdateAttribute, using 10kb FlowFiles.
> When the content repository reached approx 224MB it started logging:
> "Unable to write to container default to archive file size constraints;
> waiting for archive cleanup"
> It appears that the clean up was never occurring and a thread dump shows a
> blocked thread:
> {code}
> "FileSystemRepository Workers Thread-2" daemon prio=10 tid=0x00007f78c2660000
> nid=0x2ae7 waiting for monitor entry [0x00007f78a907d000]
> java.lang.Thread.State: BLOCKED (on object monitor)
> at
> org.apache.nifi.controller.repository.FileSystemRepository.archive(FileSystemRepository.java:1095)
> - waiting to lock <0x00000000e193ae00> (a
> java.util.concurrent.LinkedBlockingQueue)
> at
> org.apache.nifi.controller.repository.FileSystemRepository.access$1200(FileSystemRepository.java:83)
> at
> org.apache.nifi.controller.repository.FileSystemRepository$ArchiveOrDestroyDestructableClaims.run(FileSystemRepository.java:1357)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:304)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:178)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
