[
https://issues.apache.org/jira/browse/NIFI-6613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16928952#comment-16928952
]
ASF subversion and git services commented on NIFI-6613:
-------------------------------------------------------
Commit 6b17c4b1347d91177bdece540b3485e962e30a2b in nifi's branch
refs/heads/master from Mark Payne
[ https://gitbox.apache.org/repos/asf?p=nifi.git;h=6b17c4b ]
NIFI-6613: If LengthDelimitedJournal gets poisoned, log the reason and hold
onto it so that it can be included as the cause of subsequent Exceptions that
are thrown
This closes #3704.
Signed-off-by: Koji Kawamura <[email protected]>
> When FlowFile Repository fails to update due to previous failure, it should
> log the root cause
> ----------------------------------------------------------------------------------------------
>
> Key: NIFI-6613
> URL: https://issues.apache.org/jira/browse/NIFI-6613
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
> Reporter: Mark Payne
> Assignee: Mark Payne
> Priority: Major
> Fix For: 1.10.0
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When the FlowFile Repository (more specifically, the LengthDelimitedJournal
> of the write-ahead log) fails to update, it logs the reason. However, all
> subsequent attempts to update the repo will first check if the repo is
> 'poisoned' and if so throw an Exception. This gets logged as something like:
> {code:java}
> Failed to process session due to
> org.apache.nifi.processor.exception.ProcessException: FlowFile Repository
> failed to update: org.apache.nifi.processor.exception.ProcessException:
> FlowFile Repository failed to
> updateorg.apache.nifi.processor.exception.ProcessException: FlowFile
> Repository failed to update at
> org.apache.nifi.controller.repository.StandardProcessSession.commit(StandardProcessSession.java:405)
> at
> org.apache.nifi.controller.repository.StandardProcessSession.commit(StandardProcessSession.java:336)
> at
> org.apache.nifi.processors.script.ExecuteScript.onTrigger(ExecuteScript.java:228)
> at
> org.apache.nifi.controller.StandardProcessorNode.onTrigger(StandardProcessorNode.java:1165)
> at
> org.apache.nifi.controller.tasks.ConnectableTask.invoke(ConnectableTask.java:203)
> at
> org.apache.nifi.controller.scheduling.TimerDrivenSchedulingAgent$1.run(TimerDrivenSchedulingAgent.java:117)
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at
> java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
> at
> java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)Caused by: java.io.IOException:
> Cannot update journal file /flowfile_repository/journals/4614619461.journal
> because this journal has already encountered a failure when attempting to
> write to the file. If the repository is able to checkpoint, then this problem
> will resolve itself. However, if the repository is unable to be checkpointed
> (for example, due to being out of storage space or having too many open
> files), then this issue may require manual intervention. {code}
> Because there may be many Processors attempting to update the repository,
> this causes a lot of errors in the logs and makes it difficult to understand
> the underlying cause. When the journal becomes "poisoned" we should hold onto
> the Throwable that caused it and log it in this error message so that each
> update indicates the root cause. This will make it much easier to track what
> happened.
>
>
--
This message was sent by Atlassian Jira
(v8.3.2#803003)
