On Tue, 2014-10-07 at 13:52 +0400, Dmitry Potapov wrote: > On Tue, Oct 07, 2014 at 09:43:35AM +0200, Oleg Kalnichevski wrote: > > On Mon, 2014-10-06 at 19:42 +0400, Dmitry Potapov wrote: > > > On Mon, Oct 06, 2014 at 03:49:42PM +0200, Oleg Kalnichevski wrote: > > > > Could you please put together a test case demonstrating such execution > > > > path? > > > Here it is: https://gist.github.com/hirthwork/45a45702a112c14b041d > > > > > > I've modified NHttpFileServer example a bit, so it will throw > > > ProtocolException > > > if file not found. > > > At the start of execution I'm putting timestamp into context using > > > HttpRequestInterceptor and in ConnectionKeepAlive strategy tries to get > > > request > > > and timestamp from context. > > > Everything works fine if there was no exception (context is the same as > > > one > > > passed to http processor). > > > In case of exception original context is lost, so it will contain only > > > response > > > object. > > > > > > > I see the problem now. If we want to support propagation of the current > > context to the HttpAsyncService#exception method I do not see a way > > around storing it in the State object. > > > > Would you like to put together a patch? > For now, I don't see good place where state.setContext(null) should be called. > So, this solutions doesn't seems good to me. > > I have another suggestion: in case of exception in request handler, new > PipelineEntry with null result can be created and .responseReady(conn) can be > called again. This solution is not ideal, but it seems to be much better than > storing context somewhere else. Please, take a look at the attached patch. > >
Look pretty good to me. Please create a pull request at GitHub. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
