Re: Returning Responses to Http Requests

[James McMahon]

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  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  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 
> 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  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 
> >>> 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.
> >>
> >>
>
>

Re: Returning Responses to Http Requests

[Mark Payne]

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  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  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  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 
>>> 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.
>> 
>> 

Re: Returning Responses to Http Requests

[Bryan Bende]

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  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  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 
>> 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.
>
>

Re: Returning Responses to Http Requests

[Bryan Bende]

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  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.