Jim, When you configure your HandleHttpRequest processor, there is a property for the HttpContextMap to use. Within the Standard Http Context Map you can configure a property named "Request Expiration". By default, it is set to 1 minute. If any request is not handled within that time limit, it will automatically be responded to with a "500: Service Unavailable" response. If you expect your service to return a response more quickly than 1 minute it may make sense to change that to a smaller value so that they receive the response more quickly. Of course, if your dataflow is pretty expensive to operate and takes longer than that, you may be rejecting requests that are still processing.
If your engineers are not getting a response back, then perhaps there's a bug somewhere. However, if they are simply timing out, then it may be that they are not waiting long enough. They could either extend their timeouts, or you can reduce the Request Expiration to a shorter period. Thanks -Mark > On Feb 15, 2017, at 9:51 AM, Bryan Bende <bbe...@gmail.com> wrote: > > During this time when some of the steps are stopped, could just > connect your HandleHttpRequest to a different path through the flow > that returns an unavailable, and then when everything is back to > normal connect it back to the regular path? > > > > On Mon, Feb 13, 2017 at 8:15 AM, James McMahon <jsmcmah...@gmail.com> wrote: >> Thank you for replying Bryan. Yes sir, I can elaborate. Applications are >> trying to post content to my NiFi instance to have it processed to >> downstream systems. Occasionally there are legitimate reasons why we might >> have the steps stopped. Routine administration, that sort of activity. In >> such cases - NiFi is up, we still have jetty running, but a processor or the >> processors in a workflow are stopped, isn't there a way to intercept the >> Http POST request at the jetty server level to send a clean reply, such as >> Unavailable? >> >> The software engineers responsible for the POSTing applications are asking >> for this. Apparently it is cleaner and preferred to have their software >> field a standard Http Reply to their POST than to wait for an indefinite >> period of time for the equivalent of a timeout error. >> >> Thanks again for your help. -Jim >> >> On Thu, Feb 9, 2017 at 10:34 AM, Bryan Bende <bbe...@gmail.com> wrote: >>> >>> Hello, >>> >>> I'm not sure I fully understand the question... >>> >>> You would need HandletHttpRequest -> some processors -> >>> HandleHttpResponse all in a running state in order for someone to >>> receive a response. >>> >>> Can you elaborate on what you are trying to do? >>> >>> Thanks, >>> >>> Bryan >>> >>> On Thu, Feb 9, 2017 at 4:32 AM, James McMahon <jsmcmah...@gmail.com> >>> wrote: >>>> Good morning. The first processor in my workflow is a HandleHttpRequest. >>>> How >>>> do we set up to send a HandleHttpResponse if that processor is stopped >>>> and >>>> so not in a running state? >>>> >>>> Thank you. -Jim Mc. >> >>
