[
https://issues.apache.org/jira/browse/NIFI-1636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15198236#comment-15198236
]
ASF GitHub Bot commented on NIFI-1636:
--------------------------------------
Github user joewitt commented on a diff in the pull request:
https://github.com/apache/nifi/pull/285#discussion_r56420228
--- Diff:
nifi-api/src/main/java/org/apache/nifi/processor/AbstractProcessor.java ---
@@ -27,7 +30,12 @@ public final void onTrigger(final ProcessContext
context, final ProcessSessionFa
onTrigger(context, session);
session.commit();
} catch (final Throwable t) {
- getLogger().error("{} failed to process due to {}; rolling
back session", new Object[]{this, t});
+ StringWriter stacktraceWriter = new StringWriter();
--- End diff --
that is actually the current behavior/intent. I think the change needed is
to simply get rid of the 'if debug enabled' stuff we did in the logger and
instead just always log the stacktrace when it is there. This is what Adam
Taft had advocated for previously as I recall. I now see why he was saying it.
So yeah in the UI it should be a short and ideally meaningful message (not
always possible) and if a throwable shows up we should put the whole stack
trace in the logs.
The current idea that a user will go in an do debug enabled....just has
proven to be a failed experiment in my view and as someone who advocated for
that I now think i was wrong.
> Print entire stacktrace when unexpected exception occurs during onTrigger
> -------------------------------------------------------------------------
>
> Key: NIFI-1636
> URL: https://issues.apache.org/jira/browse/NIFI-1636
> Project: Apache NiFi
> Issue Type: Improvement
> Reporter: Ricky Saltzer
> Assignee: Ricky Saltzer
>
> As of now the try/catch clause in the {{AbstractProcessor}} class doesn't
> print the entire stacktrace when a processor throws an unexpected exception.
> Printing the entire stacktrace comes especially in handy when users are
> creating custom processors for internal use.
> The difference in information can be seen below:
> *Before*
> {code}
> java.lang.NumberFormatException: For input string: "five"
> {code}
> *After*
> {code}
> java.lang.NumberFormatException: For input string: "five"
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65)
> at java.lang.Integer.parseInt(Integer.java:580)
> at java.lang.Integer.parseInt(Integer.java:615)
> at TestException.main(TestException.java:5)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
