This might be intended behavior, it appears that only request
(incoming) flow files get routed to relationships like "retry", but
you have no incoming request flow file so there is technically nothing
to retry (the processor will "retry" the next time it runs). In your
case it sounds like you'd need a RouteOnAttribute for the "response"
relationship in order to handle responses when there was no request
flow file.

Alternatively, what would you expect the behavior to be? Would
responses and requests (if present) be routed to "retry", or would a
"fake" request be generated for a GET with no incoming flow file? In
the former case you'd have two types of flow files to deal with (is it
request or response?), in the latter case the flow file would likely
only be an indication that a GET occurred, as it would have no
content, and if the retry route were connected back to InvokeHttp, it
seems functionally the same as the InvokeHttp running on its own
schedule (it would try the GET again later when scheduled).  Not
saying either is necessarily bad, just wanted to get your thoughts.


On Fri, Oct 14, 2016 at 12:29 PM, Jeremy Dyer <> wrote:
> Matt - No, I am not seeing this expected behavior. Nothing is being routed
> to "retry" as expected. IF I set "Always Output Response" = true the
> "Response" relationship is triggered and even in there you can see the
> "invoke.http.statuscode=502" I have attached a screenshot to show you what I
> mean. Looking at the code the only possible explanation for this would be
> that the incoming flowfile == null. Since my "InvokeHTTP" is a simple "GET"
> with no incoming flowfile I believe that the line at [1] is not being
> invoked as expected because the property at [2] is not set. However I do not
> want to set that property.
> [1]
> [2]
> On Fri, Oct 14, 2016 at 12:11 PM, Matt Burgess <> wrote:
>> Jeremy,
>> The code implies that 502 responses (actually all 5xx responses) are
>> routed to "retry" [1]. Are you not seeing that?
>> Regards,
>> Matt
>> [1]
>> On Fri, Oct 14, 2016 at 11:59 AM, Jeremy Dyer <> wrote:
>> > I'm monitoring some micro services that sit behind an Nginx reverse
>> > proxy.
>> > The idea is simple I want to fire off an alert if I get a "502 - Bad
>> > Gateway" response from Nginx which would mean that something has caused
>> > the
>> > micro service to crash and then have NiFi attempt to restart the micro
>> > service.
>> >
>> > However no relationship is being invoked when a 502 response code is
>> > returned? Works great for 200 or even 500 but not getting any output
>> > what
>> > so ever for a 502? Any ideas?
>> >
>> > Thanks,
>> > Jeremy Dyer

Reply via email to