[
https://issues.apache.org/jira/browse/NIFI-5834?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16699516#comment-16699516
]
ASF GitHub Bot commented on NIFI-5834:
--------------------------------------
Github user mattyb149 commented on a diff in the pull request:
https://github.com/apache/nifi/pull/3179#discussion_r236410289
--- Diff:
nifi-nar-bundles/nifi-hive-bundle/nifi-hive3-processors/src/main/java/org/apache/nifi/processors/hive/PutHive3QL.java
---
@@ -148,7 +148,23 @@ public void constructProcess() {
if (e instanceof SQLNonTransientException) {
return ErrorTypes.InvalidInput;
} else if (e instanceof SQLException) {
- return ErrorTypes.TemporalFailure;
+ // Use the SQLException's vendor code for guidance -- see
Hive's ErrorMsg class for details on error codes
+ int errorCode = ((SQLException) e).getErrorCode();
--- End diff --
I'll add the debug logging for now, we can add errorCode possibly to an
attribute (as was just done for some SQL processor(s)) under a separate Jira?
> Restore default PutHiveQL error handling behavior
> -------------------------------------------------
>
> Key: NIFI-5834
> URL: https://issues.apache.org/jira/browse/NIFI-5834
> Project: Apache NiFi
> Issue Type: Bug
> Components: Extensions
> Reporter: Matt Burgess
> Assignee: Matt Burgess
> Priority: Major
>
> As part of adding Rollback On Failure to PutHiveQL (via NIFI-3415), the code
> was refactored to allow failures to be rolled back rather than transferred to
> the failure relationship (if Rollback On Failure is set). As part of that,
> all transient SQLExceptions were declared to be of type "Temporal Failure".
> This (along with the refactor) allowed the failures to be handled as
> rollbacks or transfers as specified.
> Hive returns all exceptions as transient SQLExceptions, with an error code
> that better infers the behavior of the operation. This, via the discovery of
> NIFI-5045, resulted in the handling of error codes within the Hive error code
> range. However the default behavior when the error code is not in the
> Hive-valid range is to rollback regardless of whether Rollback On Failure is
> true or not. This was done as a "better safe than sorry" approach, but it
> made the behavior inconsistent with earlier versions of the processor, where
> failures were simply routed to failure rather than rolling back.
> This case proposes to return the default behavior for unknown SQLExceptions
> to "TemporalFailure", which will make the behavior consistent with previous
> versions of the processor, where unknown errors will be transferred to
> failure unless Rollback on Failure is true.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
