On 08/07/2011 09:59, Rainer Jung wrote: > On 08.07.2011 10:50, Mark Thomas wrote: >> On 08/07/2011 09:47, Rainer Jung wrote: >>> No without wild guessing: >>> >>> AjpProcessor.recycle() now nulls input. On the next loop through >>> processing the connection, trying to read from the nulled input will >>> lead to an NPE, producing the 400 log entry. >>> >>> In 7.0.16 recycle was implemented in AbstractAjpProcessor.java and did >>> not null input. >> >> Looks like another refactoring problem. I'll take a look. > > Index: java/org/apache/coyote/ajp/AjpProcessor.java > =================================================================== > @@ -242,13 +242,6 @@ > > } > > - @Override > - public void recycle() { > - super.recycle(); > - input = null; > - output = null; > - } > - > // ----------------------------------------------------- ActionHook > Methods > > might do it. recycle() is only called once and at that place we don't > want to null input (and output) except we break out from the loop.
We also set those to null if the socket is closed in asyncDispatch(). That is what triggered that code appearing in the recycle method. Removing those calls will fix the issue but I need to think about what it might do to asyncDispatch(). We don't null out the socket when it is closed so I wonder if we really need to null these out. Looking at this has raised some more subtle differences between the AJP implementations. I'll work on this today. Hopefully, I'll fix this and further reduce the duplicate code at the same time. Mark > Directly below the loop we null input and output, except when we still > need it. At least my interpretation of the code. > > The change fixes the issue, but I didn't extensively test it. > > Regards, > > Rainer > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org