On 24 December 2013 07:58, Daniel Mikusa <dmik...@gopivotal.com> wrote: > On Dec 19, 2013, at 8:08 PM, David Bullock <david.bull...@machaira.com.au> > wrote: > >> On 20 December 2013 04:10, Daniel Mikusa <dmik...@gopivotal.com> wrote:
> Unfortunately, once this problem starts to occur onWritePossible doesn't get > called back. > When I take a thread dump of the code, it just shows all of the threads doing > nothing. > Increasing timeout doesn't seem to help. Failures still occur within the > same timeframe (i.e. same number requests to the server). The only affect is > to create a delay between when requests stop being processed and the stack > trace shows up. >> What happens if you instead pass the ServletOutputStream to the >> DataStreamWriteListener's constructor? > > Unfortunately nothing. I still see the issue. OK, new theory. At some point, something happens in your onWritePossible handler which throws an unchecked exception and crashes the Tomcat thread which is responsible for keeping track of which async servlets are still wanting to write data and doing appropriate cleanup of the NIO selectors/keys. My money would have been on calling getOutputStream() on the response a second time (it throws java.lang.IllegalStateException, which is unchecked), but you say you got rid of that. To eliminate other unchecked candidates, make your onWritePossible() catch java.lang.Throwable and emit appropriate log messages if it catches anything (or more usefully, point a debugger at the catch clause). If that doesn't yield success, then I would like to see 2 thread dumps - once when onWritePossible() has been called (maybe put in a Thread.sleep(5000) so you have time to tickle the JVM), and once when it is in the failure state. (one in the starting-to-fail state would be good too). cheers, David. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
