Thank you Mark. I saw that config parm and have been running with "Request Expiration" set to 10 min. Based on the behavior I've observed, it buys me time plus a large margin before the request times out with a "500: Service Unavailable". It does not seem to restrict me to 10 minutes if I have a response to send sooner. I have several conditions where I handle an error by sending back a 400 series reply and those appear to go back instantly as I hoped in most cases*. They aren't waiting the full ten minutes. This is just what I want.
* there is a case that cause a workflow problem that I must figure out how to avoid, and I am about to submit a question to the group about that case. On Wed, Feb 15, 2017 at 10:00 AM, Mark Payne <marka...@hotmail.com> wrote: > 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. > >> > >> > >
