[
https://issues.apache.org/jira/browse/NIFI-744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14704158#comment-14704158
]
Joseph Witt commented on NIFI-744:
----------------------------------
Tests we must do:
- What happens where there is a single partition for content and it gets full
while the flow is on? What happens on restart?
- What happens if there is multiple partitions and one of them gets full? What
happens on restart?
- What happens if upgrading from an older content repo that had data in it?
Will it seamlessly work?
- What happens if upgrading from an older flow that had flowfiles swapped out?
Will they swap in properly? What if we have both old format swap files
(because that part of the flow is disabled) and then we create new formatted
swap files? Will it work?
- What happens if data is flowing at very high rates and the system is killed?
Is the behavior consistent with expectation?
> Allow FileSystemRepository to write to the same file for multiple
> (non-parallel) sessions
> -----------------------------------------------------------------------------------------
>
> Key: NIFI-744
> URL: https://issues.apache.org/jira/browse/NIFI-744
> Project: Apache NiFi
> Issue Type: Bug
> Components: Core Framework
> Reporter: Mark Payne
> Assignee: Mark Payne
> Fix For: 0.3.0
>
> Attachments:
> 0001-NIFI-744-Refactored-ContentClaim-into-ContentClaim-a.patch
>
>
> Currently, when a ProcessSession is committed, the Content Claim that was
> being written to is now "finished" and will never be written to again.
> When a flow has processors that generate many, many FlowFiles, each in their
> own session, this means that we have many, many files on disk on the Content
> Repository, as well. Generally, this hasn't been a problem to write to these
> files. However, when the files are to be archived or destroyed, this is very
> taxing and can cause erratic performance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
