[
https://issues.apache.org/jira/browse/NIFI-1754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15283091#comment-15283091
]
Joseph Witt commented on NIFI-1754:
-----------------------------------
[~jskora] I commented on the pira itself with a few more specific things but
general thoughts:
# I think this should be simplified to just the basic original intent. The
intent of the JIRA, as i understood it, was to provide additional details about
impacted flow files in the case of a session rollback and specifically in the
'log message' of a rollback. So that is why I suggested there be a toString or
similar method which was presuming it would be a private/internally called
thing by the 'rollback' method to ensure that a nicely logged output occurred.
That should not require API changes.
# The additional/new nifi properties should be avoided unless it became clear
at some point user configuration of something like this was necessary.
# Avoid changing flow file attributes. They do not get persisted when a flow is
restarted nor do they appear to get reset once the condition causing them to
rollback is cleared and thus it gets committed. So it could be misleading down
on later in the flow. Instead, another mechanism of storing this information
for internal or user experience purposes should be pursued such as the
FlowFileRecord itself which does not get exposed to the public API portions -
is just an internal thing which could be wired up with queue
management/visualization/REST responses. But I'd recommend deferring this part
until later and if it was clear that it was worth it. With already done queue
management work and with your first initial idea further changes here may be
not necessary. Rollback is intended to 'get back to the state we were in with
the flowfile before we called this clearly broken processor code'. Therefore
we don't want to be changing the nature of the flow file in such a way that
could be used to alter the flow itself - as in - these attributes changing
should not then be used to route the flow files elsewhere and so on. These are
not persistent, outside the tracking of provenance, etc.. so not a good track.
But your original intent/idea I am totally behind which is to help provide more
tooling - initially in the form of logs - to understand flowfiles impacted by a
rollback. I see that as valuable personally because that can at times help
inform one trying to figure out what the bug was in the processor. Because
again rollback should only ever occur due to a bug in the processor calling the
session commit OR due to a failure of the framework itself while trying to
commit.
# Consider applying to 1.x line only but if needing to be in both there would
likely need to be a PR for each to accommodate the differences.
# FlowDebugger is a cool concept. It should be named 'DebugFlow' to follow the
VerbSubject naming construct and it should not be in this PR/JIRA. It should be
its own. And it can be applied to both 1.x and 0.x.
> Rollback log messages should include the flowfile filename and UUID to assist
> in flow management.
> -------------------------------------------------------------------------------------------------
>
> Key: NIFI-1754
> URL: https://issues.apache.org/jira/browse/NIFI-1754
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
> Affects Versions: 1.0.0, 0.7.0
> Reporter: Joe Skora
> Assignee: Joe Skora
>
> When a processor calls rollback on a flowfile, the filename and UUID of the
> flowfile should be included in log entry to make it easier for the offending
> files to be found and fixed or removed from the flow by the dataflow managers.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
