[
https://issues.apache.org/jira/browse/NIFI-731?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14608776#comment-14608776
]
ASF subversion and git services commented on NIFI-731:
------------------------------------------------------
Commit b3eb4a1a0f29d0f94639174dfbd7ea05307cb99a in incubator-nifi's branch
refs/heads/NIFI-731 from [~markap14]
[ https://git-wip-us.apache.org/repos/asf?p=incubator-nifi.git;h=b3eb4a1 ]
Revert "NIFI-731: Try using a Stack to hold FLowFIle Repo partitions so that we
tend to use the same partition to avoid disk seeks/thrashing"
This reverts commit 4b5ba3c4e9bbb2be5bd3f9bdf40159179a3b30e2.
> If content repo is unable to destroy content as fast as it is generated, nifi
> performance becomes very sporadic
> ---------------------------------------------------------------------------------------------------------------
>
> Key: NIFI-731
> URL: https://issues.apache.org/jira/browse/NIFI-731
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
> Reporter: Mark Payne
> Assignee: Mark Payne
> Fix For: 0.2.0
>
> Attachments:
> 0001-NIFI-731-Refactored-how-Content-and-FlowFile-Repos-i.patch
>
>
> When the FlowFile Repository marks claims as destructable, it puts the
> notification on a queue that the content repo pulls from. If the content repo
> cannot keep up, the queue will fill, resulting in backpressure, that prevents
> the FlowFile repository from being updated. This, in turn, causes Processors
> to block, waiting on space to become available. This is by design.
> However, the capacity of this queue is quite large, and the content repo
> drains the entire queue, then destroys all content claims that are on it. As
> a result, this act of destroying claims can be quite long, and Processors can
> block for quite a period of time, leading to very sporadic performance.
> Instead, the content repo should pull from the queue and destroy the claims
> one at a time or in small batches, instead of draining the entire queue each
> time. This should result in much less sporadic behavior.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
