[ 
https://issues.apache.org/jira/browse/NIFI-905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14720411#comment-14720411
 ] 

Mark Payne commented on NIFI-905:
---------------------------------

[~bende]: The reason that you are hitting the 100% full now is because we write 
up to a MB of content to a single file before we move on. The repo has 1024 
partitions. So you'll get to 1024 MB before it actually starts archiving. We 
may want to rethink the idea of using 1 MB as the point at which we move to 
another file. Perhaps we should write up to (max size of partition) / 1024 * 
50%? So that way we don't fill up the partition without archiving what is 
available?

> 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)

Reply via email to