[
https://issues.apache.org/jira/browse/STORM-837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14640938#comment-14640938
]
ASF GitHub Bot commented on STORM-837:
--------------------------------------
Github user arunmahadevan commented on the pull request:
https://github.com/apache/storm/pull/644#issuecomment-124635613
@ptgoetz to address the concern of recovery times for large files, can we
recommend (or auto enforce) the max size in "size based rotation" to a
reasonable threshold (say 1GB). As long as the files get rotated at a
reasonable threshold which can be copied over quickly there wont be issues.
Regarding time based rotation: It may be possible to support by guarding
all the operations with locks and then have the new file path updated in the
index along with rotation. (there might be other corner cases which needs to be
thought through).
However the issue I see with time based rotation is we don't have a control
of the file size and if users configure a daily rotation policy and the data
rate is high, we wont be able to recover such huge files in case of failure.
> HdfsState ignores commits
> -------------------------
>
> Key: STORM-837
> URL: https://issues.apache.org/jira/browse/STORM-837
> Project: Apache Storm
> Issue Type: Bug
> Reporter: Robert Joseph Evans
> Assignee: Arun Mahadevan
> Priority: Critical
>
> HdfsState works with trident which is supposed to provide exactly once
> processing. It does this two ways, first by informing the state about
> commits so it can be sure the data is written out, and second by having a
> commit id, so that double commits can be handled.
> HdfsState ignores the beginCommit and commit calls, and with that ignores the
> ids. This means that if you use HdfsState and your worker crashes you may
> both lose data and get some data twice.
> At a minimum the flush and file rotation should be tied to the commit in some
> way. The commit ID should at a minimum be written out with the data so
> someone reading the data can have a hope of deduping it themselves.
> Also with the rotationActions it is possible for a file that was partially
> written is leaked, and never moved to the final location, because it is not
> rotated. I personally think the actions are too generic for this case and
> need to be deprecated.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
