You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2013/11/06 15:12:07 UTC
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor
lasts 5s?
Posted by Mark Thomas <ma...@apache.org>.
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 <rm...@gmail.com>:
>> 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 <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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor
lasts 5s?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <rm...@gmail.com>:
> 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 <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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor
lasts 5s?
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor
lasts 5s?
Posted by Konstantin Kolinko <kn...@gmail.com>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor
lasts 5s?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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" <ma...@apache.org> a écrit :
> >> 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.
>
> Mark
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor
lasts 5s?
Posted by 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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor
lasts 5s?
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor lasts 5s?
Posted by "Filip Hanik (mailing lists)" <de...@hanik.com>.
"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)
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:rmannibucau@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 <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-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor
lasts 5s?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor
lasts 5s?
Posted by 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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor
lasts 5s?
Posted by Christopher Schultz <ch...@christopherschultz.net>.
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
Re: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor
lasts 5s?
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor
lasts 5s?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <ma...@apache.org>:
> 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) <de...@hanik.com>:
>>> 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:rmannibucau@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-unsubscribe@tomcat.apache.org
>>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor
lasts 5s?
Posted by Mark Thomas <ma...@apache.org>.
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) <de...@hanik.com>:
>> 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:rmannibucau@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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor
lasts 5s?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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) <de...@hanik.com>:
> 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:rmannibucau@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: org.apache.tomcat.util.net.AbstractEndpoint#shutdownExecutor lasts 5s?
Posted by "Filip Hanik (mailing lists)" <de...@hanik.com>.
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:rmannibucau@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org