Jim, In the case that the client closes the connection or times out, you will indeed not be able to respond to the request. A quick look at the code shows that if an Exception is caught when trying to respond, the FlowFile is routed to 'failure' but the entry is not removed from the context map. If an IOException is caught, then it probably makes sense to go ahead and remove the entry from the map and consider the request complete. I just filed a JIRA for this [1].
If you delete the StandardHttpContextMap and create a new one, then you will indeed have a fresh map, which would help until it fills up again. If you are constantly having clients timing out though, then you may want to consider reducing the Request Expiration to whatever value the clients are using for their timeout. Thanks -Mark [1] https://issues.apache.org/jira/browse/NIFI-3517 On Feb 22, 2017, at 10:13 AM, James McMahon <[email protected]<mailto:[email protected]>> wrote: I may well have that Mark. I have a number of paths where I have HandleHttpResponse that auto terminates Failures. That would cause such a problem, wouldn't it? How do people handle this situation: app does a POST, and so we handle the request. App closes or timesout for whatever the reason may be. The HanldeHttpResponse is unable to reply. Should those not be auto terminated? In a situation like this then Mark, are these the steps to recover? 1. HanldeHttpResponse at end of all paths 2. do not autoterminate failure conditions 3. DELETE the StandardHttpContextMap (to clear the log jam) 4. Recreate it fresh, which I presume creates it empty (I hope) What else must I do to recover? And how do I properly handle those "broken connection" situations? On Wed, Feb 22, 2017 at 10:06 AM, Mark Payne <[email protected]<mailto:[email protected]>> wrote: Jim, You likely have a path through your flow where you are receiving an HTTP Request via HandleHttpRequest but you never respond via a HandleHttpResponse. When using these processors, it's important that every incoming FlowFile go to a HandleHttpResponse processor. Do you have some path in your flow where you are not responding to the request? Thanks -Mark > On Feb 22, 2017, at 9:58 AM, James McMahon > <[email protected]<mailto:[email protected]>> wrote: > > I am getting the following errors when my users attempt to use curl or python > to post to my HandleHttpRequest processor (cannot export actual messages, > must select pieces and retype here): > WARNING > Received request from [IP address is here] but could not process it because > too many requests are already outstaning; responding with SERVICE_UNAVAILABLE > ERROR > ...claim=StandardContentClaim.... > transfer relationship not specified > > None of my apps can post to NiFi. > > I have a StandradSSLContextService and a standradHttpContextMap, both of > which are enabled. I suspect I may have inadvertently caused this problem by > setting my ContextMap parameters badly. Here are those params: > Maximum Outstanding Requests: 10000 > Request Expiration 10 min > > I've looked across my workflow and no flowfiles are queued up. So my > expectation is that there should be ample space in my ContextMap. But these > errors indicate otherwise. How do I fix this? > Thanks very much in advance for your help. > Jim
