On 06/11/2013 17:03, Romain Manni-Bucau wrote: > Well if the server does something I'll do. Here is my thread dump: > https://gist.github.com/rmannibucau/156c39bed29270cd5e06
Looks like the HTTP keep-alive in BIO is blocked (as expected) on a socket read. I thought that that was interruptible - obviously not. That certainly explains the delay you see. Need to think about how to best work-around that without loosing the benefits for things like WebSocket. Using NIO should also avoid the issue. Mark > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > > > 2013/11/6 Mark Thomas <ma...@apache.org>: >> On 06/11/2013 16:58, Mark Thomas wrote: >>> On 06/11/2013 16:49, Romain Manni-Bucau wrote: >>>> it is too long. >>>> >>>> If I try to summarize the execution of tests here what the user feel: >>>> >>>> 1) tomcat starts (ok a bit "long") -> understandable so OK >>>> 2) tests are executed (~ fast if you don't abuse of shrinkwrap things) -> >>>> OK >>>> 3) tomcat shutdown (after tests) -> KO: the server doesn't anything >>>> more (no more requests to process) but is waiting for its executor to >>>> shutdown >>> >>> Thanks, I think I understand now. >>> >>> There should only be a delay at point 3 if the server is still doing >>> something otherwise the executor shut down should be pretty much >>> immediate. If the executor is taking a noticeable time to shut down then >>> it would be worth looking at what the threads are doing. >>> >>> If memory serves me correctly, this was added to enable a more graceful >>> shutdown of WebSocket connections when the server and/or connector were >>> stopped. >>> >>>> This is not blocking at all, I just wanted to report this is not as >>>> nice as before when it was synchronous and that a little config would >>>> help a lot (or maybe another algo). >>> >>> It could be made configurable but in the case you describe above it >>> looks like there might be some other issue at play here. >> >> Oh, and open an enhancement request so this doesn't get lost. >> >> Mark >> >> >> --------------------------------------------------------------------- >> 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 > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
