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:
> 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.
> > 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>
> >> 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
> >> have the steps stopped. Routine administration, that sort of activity.
> >> 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
> >> Unavailable?
> >> The software engineers responsible for the POSTing applications are
> >> 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
> >>>> 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.