Re: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor lasts 5s?
On 07/11/2013 06:36, Konstantin Kolinko wrote: > SocketInputStream.read( ) used by BIO connector here ignores > Thread.interrupt(), > but if I understand it correctly it can be aborted by calling socket.close(). That should work but I'm not sure we have the necessary state information (I could be wrong) to work out which threads can be safely closed. > 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) Because the executor could be being used by other connectors that are not being stopped. > b) Whether there can be some useful activity besides keep-alives There were in some cases with WebSocket. Adding this wait reduced abnormal closes. I'm sure there are still some scenarios where errors can be generated but adding this wait was part of the fix for the ones that were being observed at the time. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor lasts 5s?
2013/11/7 Mark Thomas : >>> 2013/11/6 Mark Thomas : 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=0x7fc30c014000 nid=0x5bb2 > runnable [0x7fc31250f000] > 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 <0xd8247af8> (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. 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
Re: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor lasts 5s?
Great, thks Btw the tests are in sirona (incubator) in reporting module if you want to "play" Le 6 nov. 2013 21:34, "Mark Thomas" a écrit : > >> 2013/11/6 Mark Thomas : > >>> 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. > > Mark > > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > >
Re: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor lasts 5s?
>> 2013/11/6 Mark Thomas : >>> 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. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor lasts 5s?
Mark, On 11/6/13, 11:58 AM, 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. It could also be a server socket waiting for a read-timeout to occur on a keepalive request, right? Disabling keepalives in the "tests" could eliminate the problem (if that's what it is). -chris signature.asc Description: OpenPGP digital signature
Re: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor lasts 5s?
On 06/11/2013 17:25, Romain Manni-Bucau wrote: > BTW, why not using java.util.concurrent.ThreadPoolExecutor#awaitTermination? Didn't see the method in the API. I'll fix that shortly. 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 Romain Manni-Bucau : >> Well if the server does something I'll do. Here is my thread dump: >> https://gist.github.com/rmannibucau/156c39bed29270cd5e06 >> 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 : >>> 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
Re: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor lasts 5s?
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 : >> 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
RE: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor lasts 5s?
"http-bio-1234-exec-19" daemon prio=10 tid=0x7fc30c014000 nid=0x5bb2 runnable [0x7fc31250f000] 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) this is a connection kept alive from a client, and Tomcat is waiting for it to send the next request until it times out. Filip > -Original Message- > From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com] > Sent: Wednesday, November 06, 2013 10:04 AM > To: Tomcat Developers List > Subject: Re: > org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor lasts 5s? > > Well if the server does something I'll do. Here is my thread dump: > https://gist.github.com/rmannibucau/156c39bed29270cd5e06 > 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 : > > 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
Re: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor lasts 5s?
BTW, why not using java.util.concurrent.ThreadPoolExecutor#awaitTermination? 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 Romain Manni-Bucau : > Well if the server does something I'll do. Here is my thread dump: > https://gist.github.com/rmannibucau/156c39bed29270cd5e06 > 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 : >> 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
Re: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor lasts 5s?
Well if the server does something I'll do. Here is my thread dump: https://gist.github.com/rmannibucau/156c39bed29270cd5e06 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 : > 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
Re: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor lasts 5s?
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
Re: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor lasts 5s?
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. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor lasts 5s?
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 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). 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 : > On 06/11/2013 15:05, Romain Manni-Bucau wrote: >> Well, that's not blocking *me* that much, just I'm sure we'll get the >> feedback from users. So if it can be configured in next releases it >> would be awesome. > > It isn't clear to me what the problem is. Is the delay too short?, too > long? and what is the problem it causes? > > 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 Filip Hanik (mailing lists) : >>> Romain, what you could do for a work around right now, is to set an executor >>> yourself. >>> This way, Tomcat won't attempt to stop it, and there wont be a delay. >>> >>> http://tomcat.apache.org/tomcat-7.0-doc/config/executor.html >>> >>> the only time tomcat attempts to stop the executor, is if it created it, but >>> if you pass in an executor, tomcat wont stop it. >>> >>> Filip >>> >>> >>> -Original Message- From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com] Sent: Wednesday, November 06, 2013 7:12 AM To: Tomcat Developers List Subject: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor lasts 5s? Hi does org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor have to last 5s since something was done (request) on the instance? My issue is with arquillian (tomcat and tomee) we need to wait some seconds (engouh to be human visible). When running a single test (I'm not Linus Torvald so I need to debug sometimes ;) it is not that nice. Romain Manni-Bucau Twitter: @rmannibucau Blog: http://rmannibucau.wordpress.com/ LinkedIn: http://fr.linkedin.com/in/rmannibucau Github: https://github.com/rmannibucau - 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 >> > > > - > 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
Re: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor lasts 5s?
On 06/11/2013 15:05, Romain Manni-Bucau wrote: > Well, that's not blocking *me* that much, just I'm sure we'll get the > feedback from users. So if it can be configured in next releases it > would be awesome. It isn't clear to me what the problem is. Is the delay too short?, too long? and what is the problem it causes? 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 Filip Hanik (mailing lists) : >> Romain, what you could do for a work around right now, is to set an executor >> yourself. >> This way, Tomcat won't attempt to stop it, and there wont be a delay. >> >> http://tomcat.apache.org/tomcat-7.0-doc/config/executor.html >> >> the only time tomcat attempts to stop the executor, is if it created it, but >> if you pass in an executor, tomcat wont stop it. >> >> Filip >> >> >> >>> -Original Message- >>> From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com] >>> Sent: Wednesday, November 06, 2013 7:12 AM >>> To: Tomcat Developers List >>> Subject: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor >>> lasts 5s? >>> >>> Hi >>> >>> does org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor have >>> to last 5s since something was done (request) on the instance? >>> >>> My issue is with arquillian (tomcat and tomee) we need to wait some >>> seconds (engouh to be human visible). When running a single test (I'm >>> not Linus Torvald so I need to debug sometimes ;) it is not that nice. >>> >>> Romain Manni-Bucau >>> Twitter: @rmannibucau >>> Blog: http://rmannibucau.wordpress.com/ >>> LinkedIn: http://fr.linkedin.com/in/rmannibucau >>> Github: https://github.com/rmannibucau >>> >>> - >>> 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 > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor lasts 5s?
Well, that's not blocking *me* that much, just I'm sure we'll get the feedback from users. So if it can be configured in next releases it would be awesome. 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 Filip Hanik (mailing lists) : > Romain, what you could do for a work around right now, is to set an executor > yourself. > This way, Tomcat won't attempt to stop it, and there wont be a delay. > > http://tomcat.apache.org/tomcat-7.0-doc/config/executor.html > > the only time tomcat attempts to stop the executor, is if it created it, but > if you pass in an executor, tomcat wont stop it. > > Filip > > > >> -Original Message- >> From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com] >> Sent: Wednesday, November 06, 2013 7:12 AM >> To: Tomcat Developers List >> Subject: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor >> lasts 5s? >> >> Hi >> >> does org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor have >> to last 5s since something was done (request) on the instance? >> >> My issue is with arquillian (tomcat and tomee) we need to wait some >> seconds (engouh to be human visible). When running a single test (I'm >> not Linus Torvald so I need to debug sometimes ;) it is not that nice. >> >> Romain Manni-Bucau >> Twitter: @rmannibucau >> Blog: http://rmannibucau.wordpress.com/ >> LinkedIn: http://fr.linkedin.com/in/rmannibucau >> Github: https://github.com/rmannibucau >> >> - >> 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
RE: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor lasts 5s?
Romain, what you could do for a work around right now, is to set an executor yourself. This way, Tomcat won't attempt to stop it, and there wont be a delay. http://tomcat.apache.org/tomcat-7.0-doc/config/executor.html the only time tomcat attempts to stop the executor, is if it created it, but if you pass in an executor, tomcat wont stop it. Filip > -Original Message- > From: Romain Manni-Bucau [mailto:rmannibu...@gmail.com] > Sent: Wednesday, November 06, 2013 7:12 AM > To: Tomcat Developers List > Subject: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor > lasts 5s? > > Hi > > does org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor have > to last 5s since something was done (request) on the instance? > > My issue is with arquillian (tomcat and tomee) we need to wait some > seconds (engouh to be human visible). When running a single test (I'm > not Linus Torvald so I need to debug sometimes ;) it is not that nice. > > Romain Manni-Bucau > Twitter: @rmannibucau > Blog: http://rmannibucau.wordpress.com/ > LinkedIn: http://fr.linkedin.com/in/rmannibucau > Github: https://github.com/rmannibucau > > - > 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
