Matt - Your right about just adding a "RouteOnAttribute" processor. I got so caught up in trying to understand why a retry wasn't getting fired I lost track of my original goal. I think I have a understanding of why the "retry" was not getting fired now and that makes perfect sense. I will just add the "RouteOnAttribute" processor now to check for a 200 or 502 code in the response.
Thanks On Fri, Oct 14, 2016 at 12:50 PM, Matt Burgess <mattyb...@apache.org> wrote: > 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. > > Thanks, > Matt > > On Fri, Oct 14, 2016 at 12:29 PM, Jeremy Dyer <jdy...@gmail.com> 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] > > https://github.com/apache/nifi/blob/master/nifi-nar- > bundles/nifi-standard-bundle/nifi-standard-processors/src/ > main/java/org/apache/nifi/processors/standard/InvokeHTTP.java#L596 > > [2] > > https://github.com/apache/nifi/blob/master/nifi-nar- > bundles/nifi-standard-bundle/nifi-standard-processors/src/ > main/java/org/apache/nifi/processors/standard/InvokeHTTP.java#L586 > > > > On Fri, Oct 14, 2016 at 12:11 PM, Matt Burgess <mattyb...@apache.org> > 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] > >> https://github.com/apache/nifi/blob/master/nifi-nar- > bundles/nifi-standard-bundle/nifi-standard-processors/src/ > main/java/org/apache/nifi/processors/standard/InvokeHTTP.java#L906 > >> > >> On Fri, Oct 14, 2016 at 11:59 AM, Jeremy Dyer <jdy...@gmail.com> 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 > > > > >
