如何在nifi中控制调用HTTP处理器的重试 [英] how to control retries of invoke HTTP processor in nifi

问题描述

例如调用HTTP处理器，如果重试关系连接到自身，如果发生500个相关错误，如何控制重试次数?

For e.g. invoke HTTP processor, if the retry relationship is connected to itself, how to control the number of retries if 500 related error occurred?

我想控制重试次数，例如5，并且在某些时间会重试.像这样想在24小时后第一次重试1分钟后重试，然后第二次30分钟后重试.

I want to control the number of retries up to some count for e.g. 5 and it much retry at certain time. First retry after 1 min and second after 30 min third after 24 hrs like this I want to do.

推荐答案

有一个开放的Jira案例(

There is an open Jira case (NIFI-90) discussing automatic penalization and back-off. In the meantime, if you want to implement your own back-off, you would send your retry relationship to a flow that would eventually be routed back to the InvokeHttp processor (or dropped once the retry count reached the max). The back-off cycle could look like this:

InvokeHttp -[retry]-> UpdateAttribute -> RouteOnAttribute -[give up]-> (Drop)
 ^                                               |
 |                                               v
 |------------------------------------------  (Delay)

1. UpdateAttribute: Sets/increments a "counter/retry" attribute and/or a correlated "delay amount" attribute.
2. RouteOnAttribute: Checks the counter to see if the max number of retries (5, e.g.) has been reached, and sends the flow file to (Drop) if so, otherwise continue on. The (Drop) processor can be an UpdateAttribute or something that auto-terminates its outgoing relationship, or some error-handling/reporting logic.
3. (Delay): This could be an ExecuteScript processor that delays the transfer of a flow file based on either the current retry count and/or the delay amount. Alternatively you could use ControlRate, but you'd inverse the "delay amount" to set the attribute for ControlRate accordingly (using the previous UpdateAttribute to increase the Rate Controlled Attribute's value).

这篇关于如何在nifi中控制调用HTTP处理器的重试的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！