tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Thomas <>
Subject Re: svn commit: r1198553 - in /tomcat/tc7.0.x/trunk: ./ java/org/apache/tomcat/util/net/ test/org/apache/catalina/startup/ webapps/docs/changelog.xml webapps/docs/config/ajp.xml webapps/docs/config/http.xml
Date Thu, 17 Nov 2011 09:06:44 GMT
On 17/11/2011 08:44, Konstantin Kolinko wrote:
> 2011/11/17 Mark Thomas <>:
>> On 06/11/2011 20:52, wrote:
>>> Author: kkolinko
>>> Date: Sun Nov  6 20:52:33 2011
>>> New Revision: 1198553
>>> URL:
>>> Log:
>>> Merged revisions r1197158, r1198552 from tomcat/trunk:
>>> Add new attribute to AbstractEndpoint and use it to speed up Tomcat tests.
>>> If the attribute "fastShutdown" is set on the endpoint,
>>> the usual wait of 1 sec during pause() is skipped.
>> Any thoughts welcome.
> "fastShutdown" disables 1sec wait in AbstractEndpoint.pause(). The
> idea behind it is that when test ends there are no open connections
> being processed by Tomcat (and so there is not much benefit in pausing
> endpoint before stopping it).
> It may be that for some tests that is not true.

Could be. I haven't looked that hard. It certainly wasn't deterministic.
I saw failures in completely different tests in two separate runs. Once
I turned this option off, it ran without issue. On Windows it was fine
with the option enabled.

> Before implementing it I pondered an idea of alternative
> implementation to minimize wait in endpoint.pause(). The idea was to
> iterate over endpoint threads and check whether pausing was successful
>  (I think that will be faster than this empirical 1 second wait).
> Though implementing that would require an insight in implementation of
> a specific endpoint.

I was thinking of re-factoring exactly along these lines. I'll have some
time later today so I'll give that a try before tagging 7.0.23.

> It should be possible to update TomcatBaseTest class to turn off this
> feature for some tests, or for Apr connector as a whole.
> That is just regarding this feature.
> There might be other questions like whether Apr shutdown can be made
> more robust and whether this crash is triggered by some other issue.

True. Lets see where the refactoring gets us. If that works, it will
address the testing issue as well as providing an improvement for
standard usages.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message