[
https://issues.apache.org/jira/browse/NIFI-15424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18051920#comment-18051920
]
David Handermann commented on NIFI-15424:
-----------------------------------------
[~yuanhao.zhu] I am not quite following what you are proposing. As far as
socket timeouts and end of stream exceptions, these will be routed to the
Failure relationship, where it is the responsibility of the flow designer to
decide whether to retry. The number of relationships in InvokeHTTP can make it
challenging at times, but the general approach is to provide a low-level set of
options and more control in the flow design.
> InvokeHTTPProcessor: Add dedicated relationship for Java exceptions
> (transport/runtime) instead of routing to failure
> ---------------------------------------------------------------------------------------------------------------------
>
> Key: NIFI-15424
> URL: https://issues.apache.org/jira/browse/NIFI-15424
> Project: Apache NiFi
> Issue Type: Improvement
> Components: Core Framework
> Reporter: Yuanhao Zhu
> Priority: Major
> Original Estimate: 20m
> Remaining Estimate: 20m
>
> *Problem*
> Today, if {{InvokeHTTP}} throws a Java exception during the HTTP call (e.g.
> network interruption, DNS failure, connect reset/timeout), it routes the
> FlowFile to the existing error/failure relationship and sets:
> * {{invokehttp.java.exception.class}}
> * {{invokehttp.java.exception.message}}
> This mixes “HTTP response failures” with “request didn’t complete due to
> Java/transport exception”, making downstream handling (retry/alerting) messy.
> *Proposal*
> Add a dedicated relationship, e.g. {{{}java_exception{}}}, and route
> FlowFiles there when the HTTP call fails due to a Java exception (no valid
> HTTP response obtained). Keep existing relationships unchanged for normal
> HTTP outcomes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
