[jira] [Comment Edited] (NIFI-7524) Add retry relationship to ExecuteSQL

["Dennis Jaheruddin (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/NIFI-7524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17141513#comment-17141513 ] 

Dennis Jaheruddin edited comment on NIFI-7524 at 6/21/20, 3:41 PM:
-------------------------------------------------------------------

In addition to the comment of Mark (it would indeed make sense to name a relationship based on what happened, and not on what you might want to do with it), the existing faillure relationship would also need to be renamed to ensure what the possible outcomes are. It should of course be crystal clear which relationship will be followed in what scenario.

I am not sure what the typical faillures would be, perhaps:
 # Invalid configuration (e.g. malformed URL)
 # Structural (e.g. schema or datatype or value mismatch, and invalid query syntax)
 # Timeout/server not found/connection refused.
 # Authentication/security error

If this is accurate, it may make sense to have a 'connection.faillure' and 'other.faillure'.

That being said, if you are in a situation where authentication may change or tokens are slow that kind of error may also be worth retrying. (Or in a situation where schema's are often updated, that kind of error may also be worth retrying). 

So it is important that if a split is defined, this is going to have to be a meaningful one. I am curious to see what others think. The alternative would perhaps be to create an attribute with the error code so the error may be routed as a retry or out of the system.


was (Author: dennisjaheruddin):
In addition to the comment of Mark (it would indeed make sense to name a relationship based on what happened, and not on what you might want to do with it), the existing faillure relationship would also need to be renamed to ensure what the possible outcomes are. It should of course be crystal clear which relationship will be followed in what scenario.

I am not sure what the typical faillures would be, perhaps:
 # Invalid configuration (e.g. malformed URL)
 # Structural (e.g. schema or datatype or value mismatch, and invalid query syntax)
 # Timeout/server not found/connection refused.
 # Authentication/security error

If this is accurate, it may make sense to have a 'connection.faillure' and 'other.faillure'.

That being said, if you are in a situation where authentication may change or tokens are slow that kind of error may also be worth retrying. (Or in a situation where schema's are often updated, that kind of error may also be worth retrying). 

So it is important that if a split is defined, this is going to be a meaningfull one. The alternative would perhaps be to create an attribute with the error code so the error may be routed as a retry or out of the system.

> Add retry relationship to ExecuteSQL
> ------------------------------------
>
>                 Key: NIFI-7524
>                 URL: https://issues.apache.org/jira/browse/NIFI-7524
>             Project: Apache NiFi
>          Issue Type: Improvement
>          Components: Extensions
>            Reporter: Matt Burgess
>            Priority: Major
>
> Currently ExecuteSQL has success and failure relationships, where all errors/failures are routed to failure. However for transient exceptions such as "Connection refused", it would be better to have a retry relationship to indicate that the flow file could be processed successfully in the future, rather than invalid SQL errors, e.g.  The retry relationship exists in other RDBMS processors such as PutSQL and PutDatabaseRecord, and would be helpful for ExecuteSQL as well.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)