2013/11/7 Mark Thomas <ma...@apache.org>: >>> 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. > > No need. Already implemented in 7.0.x and trunk. >
[https://gist.github.com/rmannibucau/156c39bed29270cd5e06] > > "http-bio-1234-exec-19" daemon prio=10 tid=0x00007fc30c014000 nid=0x5bb2 > runnable [0x00007fc31250f000] > java.lang.Thread.State: RUNNABLE > at java.net.SocketInputStream.socketRead0(Native Method) > at java.net.SocketInputStream.read(SocketInputStream.java:152) > at java.net.SocketInputStream.read(SocketInputStream.java:122) > at > org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:516) > at > org.apache.coyote.http11.InternalInputBuffer.fill(InternalInputBuffer.java:501) > at > org.apache.coyote.http11.Http11Processor.setRequestLineReadTimeout(Http11Processor.java:173) > at > org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:947) > at > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603) > at > org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312) > - locked <0x00000000d8247af8> (a org.apache.tomcat.util.net.SocketWrapper) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) > at java.lang.Thread.run(Thread.java:724) > > this is a connection kept alive from a client, and Tomcat is waiting for it > to send the next request until it times out. SocketInputStream.read( ) used by BIO connector here ignores Thread.interrupt(), but if I understand it correctly it can be aborted by calling socket.close(). Reviewing r1539446 and r1539453... http://svn.apache.org/r1539446 http://svn.apache.org/r1539453 The old waiting code was added in r1523967 http://svn.apache.org/r1523967 I was wondering, why r1539453 introduces executorTerminationTimeoutMillis as equal to zero for BIO: a) Why there is no such option for an external Executor (owned by Service) b) Whether there can be some useful activity besides keep-alives The answers are as following: Looking at an external executor, StandardThreadExecutor.stopInternal() does not wait after a call to 'executor.shutdownNow()'. Thus it effectively has its "executorTerminationTimeoutMillis" always equal to zero. Looking at a StandardService.stopInternal(), the call to connector.stop() is near the end of that method. At this point all hosts and web applications and their class loaders have already been stopped. Thus there should be no useful activities on those threads. Thus I am OK with zero timeout for BIO. I am questioning the usefulness of that wait. If it is for asynchronous reads/writes, an application may fail to process those, because its classloader have already been stopped. I am also noting that we ignore the return value of executor.shutdownNow() which is a List<Runnable>. Those runnables are discarded without ever starting them. Best regards, Konstantin Kolinko --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
