Just realized that in the case above, I couldn't have hit the quoted code, since neither call to AuthFilter.doFilter() had returned.
I can build and debug Tomcat, so any advice would be very welcome. Matt On Tue, Dec 6, 2016 at 2:20 PM, Matthew Bellew <[email protected]> wrote: > I have an intermittent bug that I've been trying to trying to track down > for a long time. The symptom is that the same tomcat request object is > being processed by two different threads. The symptom is a random crash > when one thread returns and recycles the request, and the other thread > access the request object, usually causing an NPE. > > Note, there are no background threads going on here. I see my top-most > filter AuthFilter.doFilter() is being called once with a Tomcat > RequestFacade object, and before that thread returns, AuthFilter.doFilter() > is called again on another thread with the exact == RequestFacade object. > > Google hasn't given me any leads (beyond "don't pass a request do another > thread". I'm not). > > My suspicion at this point centers around this code, though I have not > spent a much time in Tomcat internals. In Tomcat 8.5.8 > AbstractProtocol.ConnectionHandler.process() > around line 889. > > wrapper.registerReadInterest(); > } else if (state == SocketState.SENDFILE) { > // Sendfile in progress. If it fails, the socket will be > // closed. If it works, the socket will be re-added to the > // poller > connections.remove(socket); > Thread t = threads.remove(socket); assert t == Thread.currentThread(); > release(processor); > } else if (state == SocketState.UPGRADED) { > // Don't add sockets back to the poller if this was a > > My reading of this is that when state == SENDFILE, the request is not > complete in some sense. However, the processor is being released to be > recycled. Is this OK for the processor to be picked up by another thread > at this point? > > Thanks for any help, > Matt >
