[
https://issues.apache.org/jira/browse/FLUME-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13881421#comment-13881421
]
Brock Noland commented on FLUME-2181:
-------------------------------------
Thank you very much of the new exception types! Can you make a RB item next
update?
I think this is wrong. I think we don't want to throw an IOException when
fsyncPerTransaction == true. We should also have a test for this particular
condition.
{noformat}
- open = false;
- throw new IOException("Corrupt event found. Please run File Channel " +
- "Integrity tool.", ex);
+ if (fsyncPerTransaction) {
+ open = false;
+ throw new IOException("Corrupt event found. Please run File Channel " +
+ "Integrity tool.", ex);
+ }
+ throw ex;
{noformat}
I think the below has to catch throwable because scheduled executor does and
then eats it.
{noformat}
+ try {
+ sync();
+ } catch (Exception ex) {
+ LOG.error("Data file, " + getFile().toString() + " could not " +
+ "be synced to disk due to an error.", ex);
+ }
{noformat}
if(LOG.isDebugEnabled()) can be added here:
{noformat}
+ LOG.debug("No events written to file, " + getFile().toString() +
+ " in last " + fsyncInterval + " or since last commit.");
{noformat}
Precondition.checkNotNull
{noformat}
+ syncExecutor.shutdown(); // No need to wait for it to shutdown.
{noformat}
is this really what we want? I think we want to throw an exception regardless
of fsyncPerTransaction.
{noformat}
+ if(operation != OP_RECORD) {
+ if (!fsyncPerTransaction) {
+ throw new CorruptEventException("Operation code is invalid. File "
+
+ "is corrupt. Please run File Channel Integrity tool.");
+ }
+ }
{noformat}
> Optionally disable File Channel fsyncs
> ---------------------------------------
>
> Key: FLUME-2181
> URL: https://issues.apache.org/jira/browse/FLUME-2181
> Project: Flume
> Issue Type: Improvement
> Reporter: Hari Shreedharan
> Assignee: Hari Shreedharan
> Attachments: FLUME-2181-1.patch, FLUME-2181.patch
>
>
> This will give File Channel performance a big boost, at the cost of possible
> data loss if a crash happens between checkpoints.
> Also we should make it configurable, with default to false. If the user does
> not mind slight inconsistencies, this feature can be explicitly enabled
> through configuration. So if it is not configured, then the behavior will be
> exactly as it is now.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
