You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Igal Sapir <is...@apache.org> on 2019/03/14 19:26:44 UTC
Default Number of Test Threads
Does test.threads default to 1 for a reason?
If there is no objection, I would like to set the default to the number
of available CPU Threads. It looks like that can be done with a custom
Ant task which should be fairly simple to implement.
Best,
Igal
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Default Number of Test Threads
Posted by Igal Sapir <ig...@lucee.org>.
Chris,
On Fri, Mar 15, 2019 at 4:53 PM Christopher Schultz <
chris@christopherschultz.net> wrote:
> <snip/>
>
> I think you are on Windows (?),. but maybe you could use this script:
>
> https://github.com/ChristopherSchultz/apache-tomcat-stuff/tree/master/bi
> n
>
> (look for test-tomcat-release.sh)
>
> That script builds a custom build.properties and then runs everything.
> It could trivially add a threads setting to build.properties.
>
Thanks! I use both Windows and Linux, but I can see some gems in that
script that I can adopt.
Best,
Igal
Re: Default Number of Test Threads
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Igal,
On 3/14/19 16:29, Igal Sapir wrote:
> On 3/14/2019 12:51 PM, Mark Thomas wrote:
>> On 14/03/2019 19:26, Igal Sapir wrote:
>>> Does test.threads default to 1 for a reason?
>> Mostly historical. The tests weren't originally designed to run
>> in parallel.
>>
>>> If there is no objection, I would like to set the default to
>>> the number of available CPU Threads. It looks like that can be
>>> done with a custom Ant task which should be fairly simple to
>>> implement.
>> I over-ride it locally so I'm not going to be directly affected.
>>
>> A custom Ant task seems a little over-engineered compared to
>> setting a property in build.properties.
>
> I override it in build.properties as well, but I find myself doing
> it each time I download the sources for testing a tagged version,
> or at least copy the file from one version to another. If you're
> doing it in your dev directory and simply added "build.properties"
> to .gitignore then you are not affected by this.
I think you are on Windows (?),. but maybe you could use this script:
https://github.com/ChristopherSchultz/apache-tomcat-stuff/tree/master/bi
n
(look for test-tomcat-release.sh)
That script builds a custom build.properties and then runs everything.
It could trivially add a threads setting to build.properties.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlyMOxQACgkQHPApP6U8
pFjofBAAy1UKpHmO8eWUUrkvWpcQR0na3b9skAjrQjIe1kOojTvjuDfESxQtkXRJ
CRgwOl7ztpmxveStBErW8+OFLgovh/ilrL9Yxc3RNelJ7Z3Pmv87DevEJDt9VmNR
3q5JL6yx7EOLLTkXA+Z/PfbHmOXA6BN/wwI4d60x89tRqpSuWhE6BxFvRHxCfFOV
hUeMlAfeWZwXcCsoXwaj9CwMb16X3GbSPMvj+3EcFM51GV5gnJHwVsyA9PFTRIZR
2WPOM9As8Lms3fayiFR8K3DlA3N1H94fA9oyGlQUXeq6qXBxYjLTh8ayUSEJFpkx
N0P+DzqU0ydMAgHMeP1sumf85T7FZ3BNSTBUONgGYgUoIThi+RXy6/6OoUi2xgR2
ZdkdQBX7i1KqNIk3aua7zke58g9oDCVV/T/6k7CamhiGR13fDZAZ3SBZiDdReLxm
/OTp0YoNG+jOhiQ8yOL2aVBCvQdvJW4i8f5agYnfciL+S8z9xgUuvRvsHoVBHhgg
2kifiDJ30MN4SE0iQDGZUDdSD3RZu0GMCP0Zp6nXRioIDo94285a94/qUgm+Vjdm
ZfbghLrNtziXqBiUZoD1qkVVFygJnO2uM1Yl9Bnl2WdcmGLE+ukMeMqzGYk8ScM6
/y36CnkCjtULfm7TcVkSaNUU/EzjUKljwdvp0FVAN9mrYdA2JEw=
=iiK4
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Default Number of Test Threads
Posted by Igal Sapir <is...@apache.org>.
On 3/14/2019 12:51 PM, Mark Thomas wrote:
> On 14/03/2019 19:26, Igal Sapir wrote:
>> Does test.threads default to 1 for a reason?
> Mostly historical. The tests weren't originally designed to run in parallel.
>
>> If there is no objection, I would like to set the default to the number
>> of available CPU Threads. It looks like that can be done with a custom
>> Ant task which should be fairly simple to implement.
> I over-ride it locally so I'm not going to be directly affected.
>
> A custom Ant task seems a little over-engineered compared to setting a
> property in build.properties.
I override it in build.properties as well, but I find myself doing it
each time I download the sources for testing a tagged version, or at
least copy the file from one version to another. If you're doing it in
your dev directory and simply added "build.properties" to .gitignore
then you are not affected by this.
> I do wonder about CI systems. It is potentially a big change that might
> take someone by surprise. We'll need to update some buildbot
> configuration for example. I have visions of a CI system with lots of
> cores running lots of builds in parallel suddenly grinding to a halt
> because a Tomcat build suddenly tries to use every CPU. But I don't know
> now likely that is.
I doubt that CI systems are that fragile/vulnerable. AFAIK they launch
a new VM to ensure isolation and a clean environment, or else they would
fall apart any time someone pushes a build without considering the CI
environment.
> I guess I'm -0.
If it's just me then I can add a custom ENV variable to my profile, e.g.
$ export ANT_OPTS=-Dtest.threads=8
but I thought that others are annoyed by this as well.
Best,
Igal
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Default Number of Test Threads
Posted by Mark Thomas <ma...@apache.org>.
On 14/03/2019 19:26, Igal Sapir wrote:
> Does test.threads default to 1 for a reason?
Mostly historical. The tests weren't originally designed to run in parallel.
> If there is no objection, I would like to set the default to the number
> of available CPU Threads. It looks like that can be done with a custom
> Ant task which should be fairly simple to implement.
I over-ride it locally so I'm not going to be directly affected.
A custom Ant task seems a little over-engineered compared to setting a
property in build.properties.
I do wonder about CI systems. It is potentially a big change that might
take someone by surprise. We'll need to update some buildbot
configuration for example. I have visions of a CI system with lots of
cores running lots of builds in parallel suddenly grinding to a halt
because a Tomcat build suddenly tries to use every CPU. But I don't know
now likely that is.
I guess I'm -0.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Default Number of Test Threads
Posted by Igal Sapir <ig...@lucee.org>.
Chris,
On Sat, Mar 16, 2019 at 8:22 AM Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Igal,
>
> On 3/15/19 22:38, Igal Sapir wrote:
> > Chris,
> >
> > On Fri, Mar 15, 2019 at 4:56 PM Christopher Schultz <
> > chris@christopherschultz.net> wrote:
> >
> >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
> >>
> >> Igal,
> >>
> >> On 3/15/19 16:45, Igal Sapir wrote:
> >>> <snip/> I looked deeper into build.xml and I found some
> >>> interesting information and a simple solution for my issue. In
> >>> build.xml we have the following:
> >>>
> >>> <property file="${user.home}/build.properties"/> <property
> >>> file="build.properties"/> <property
> >>> file="build.properties.default"/>
> >>>
> >>> So I can place my settings for test.threads in
> >>> ~/build.properties.
> >>>
> >>> The current order of precedence, however, gives
> >>> ${user.home}/build.properties a higher priority than the one
> >>> at {tomcat}/build.properties.
> >>>
> >>> That is wrong IMHO and should be the other way around, i.e.
> >>> {tomcat}/build.properties should
> >>> override${user.home}/build.properties . I would like to
> >>> change that order if everyone agrees.
> >>
> >> I do not agree. The local configuration (~/build.properties)
> >> should override the default configuration (build.properties).
> >> That's why it's called "local configuration".
> >>
> >> Besides, if you implement your proposed switch, then you will be
> >> UNABLE to use ~/build.properties to customize this configuration
> >> that you don't like.
> >>
> >
> > Perhaps I'm missing something, but I think that the term "Local"
> > is ambiguous here, so I will avoid using it to prevent confusion.
> > We have (applied in order):
> >
> > 1) Project Default Config.: {tomcat}/build.properties.default 2)
> > Instance Config........: {tomcat}/build.properties 3) System
> > Config..........: {user.home}/build.properties
> >
> > Tomcat only ships with the Project Default Config file. The other
> > two are optional and can be created by the user.
> >
> > Suppose that I usually want to run tests with 8 threads. I can
> > set `test.threads=8` in the System Config file and each time I
> > download a new version of Tomcat I simply run `ant test` in the
> > directory of that instance. It will run with 8 threads, resolving
> > my original issue here.
> >
> > But, if now I download a version and want to run only that one with
> > 4 threads (a more likely scenario would be to set different
> > versions or paths for OpenSSL), I can not simply set the new value
> > for the Instance Configuration, {tomcat}/build.properties, to
> > affect only that instance -- I have to modify the System Config,
> > which will change the settings for all other instances.
> >
> > The way I see it, the System Config is Default for the system, and
> > each instance should be able to specify its own Instance
> > Configuration which will override both the Project's Defaults and
> > the System Defaults. My proposal is therefore that the order of
> > applying the settings will be:
> >
> > 1) Project Default Config.: {tomcat}/build.properties.default 2)
> > System Config..........: {user.home}/build.properties 3) Instance
> > Config........: {tomcat}/build.properties
> >
> > That way I do not need to add an Instance Config anywhere unless a
> > specific instance requires unique settings. I can set my System
> > Config (~/build.properties) with the values that I normally use,
> > and only override them with an Instance Config, i.e.
> > {tomcat}/build.properties where needed.
> >
> > What am I missing?
>
> Just remember that ant properties are write-once, so all your orders
> above are backward. If you want the instance config to override all
> others, you'll have to load it first.
>
You are right. I tried to simplify my example with pseudo-config that has
a "last value wins", but that probably caused more confusion, so I'll try
to avoid that in the future.
>
> Nobody is going to agree on this, so maybe:
>
> {tomcat}/build.first.properties
> {user.home}/build.properties (which is a really weird default, IMO)
> {tomcat}/build.properties
> {tomcat}/build.default.properties
>
> This preserves the current behavior in all environments and allows you
> to have your new type of overriding configuration.
>
I don't think that I would use `build.first.properties` if I have to create
or copy it to the {tomcat} directory each time.
If anything, I would prefer to specify a path to a properties file, e.g.
`build.properties.file` or something like that, which will be read first.
That will allow me to have multiple properties file at the home directory,
and specify them as needed. For example, I could then add a file named
`{user.home}/build.properties.tomcat7` with Tomcat 7-specific settings in
it, and then point to it in ANT_OPTS for Tomcat 7 tests.
If I'm the only one who thinks that that would be useful then there's no
need to change anything. I can set a few properties that I usually use,
e.g. `test.threads` and `java.7.home`, in {user.home}/build.properties for
system-wide configuration, and modify or disable (by renaming) it seldomly
when needed.
Thanks,
Igal
>
> Making a change to the current behavior runs the risk of breaking all
> downstream projects, so let's not do that.
>
> - -chris
> -----BEGIN PGP SIGNATURE-----
> Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
>
> iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlyNFLUACgkQHPApP6U8
> pFgByQ//S9oHh5vA2clnJw07M0LyDOu9MYh7i3N2Yiz0KneHwD1zN6K6IxmAk3Vl
> utyXEjJcJ8cZQ1dsgppUCKqDhqvXe+Ke+ySQ5es63mGY6CNlPMQnifca+CSEeJxA
> 9vLotQSeknnzOCR+h0xc0ICJAVUIhWDbc/YRdZV4iOf3/7oZ+N94QZz+1gKc6MVL
> 6yip6IVLs+3qgpemEDnGZS3NT9iSTlP4YsJ7DzhTkUqUkfPwEPJBkc8F+lywCAY/
> 47CGDL7mPulUQi1EJvG/N9KCNBWUjBQe+DX9gb2AQzPhysPwPjavNBoEXFNEBhM6
> 3nr1DlZaf91bNaW0EnVvaOxACAiIYvgDXnBLNISoRQURyvB4srH7Idmjp93vF+el
> 2N6/f8AUSAKODWyjWRVGf3fTJzoYejDgkDV8q3Ia23gTTLn8nZdohTTg1t59wpjH
> E6j0e0/z/CwHv/5Z+cj955MZzMoX8YNeH9540SZoIFADYTmSftugwvK6Itj1MHcF
> KGE0QjdBihJOvIBLB323mayCK03OufKgzFs03oA5OxZi8rYBZ9kz3Jv9EKcYHOLT
> qBNWM0INzwrUHFfhmXBo+Kdg4/DnHdszI2uResaqaOcUOzKMfdvOn+q4aMmnC4q5
> 6gmoa+hb+JnLYGdgxMtZ4Gzt5UWqLTHDYcghKT7wdZZ+v4Zj7nE=
> =qOG1
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Default Number of Test Threads
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Igal,
On 3/15/19 22:38, Igal Sapir wrote:
> Chris,
>
> On Fri, Mar 15, 2019 at 4:56 PM Christopher Schultz <
> chris@christopherschultz.net> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
>>
>> Igal,
>>
>> On 3/15/19 16:45, Igal Sapir wrote:
>>> <snip/> I looked deeper into build.xml and I found some
>>> interesting information and a simple solution for my issue. In
>>> build.xml we have the following:
>>>
>>> <property file="${user.home}/build.properties"/> <property
>>> file="build.properties"/> <property
>>> file="build.properties.default"/>
>>>
>>> So I can place my settings for test.threads in
>>> ~/build.properties.
>>>
>>> The current order of precedence, however, gives
>>> ${user.home}/build.properties a higher priority than the one
>>> at {tomcat}/build.properties.
>>>
>>> That is wrong IMHO and should be the other way around, i.e.
>>> {tomcat}/build.properties should
>>> override${user.home}/build.properties . I would like to
>>> change that order if everyone agrees.
>>
>> I do not agree. The local configuration (~/build.properties)
>> should override the default configuration (build.properties).
>> That's why it's called "local configuration".
>>
>> Besides, if you implement your proposed switch, then you will be
>> UNABLE to use ~/build.properties to customize this configuration
>> that you don't like.
>>
>
> Perhaps I'm missing something, but I think that the term "Local"
> is ambiguous here, so I will avoid using it to prevent confusion.
> We have (applied in order):
>
> 1) Project Default Config.: {tomcat}/build.properties.default 2)
> Instance Config........: {tomcat}/build.properties 3) System
> Config..........: {user.home}/build.properties
>
> Tomcat only ships with the Project Default Config file. The other
> two are optional and can be created by the user.
>
> Suppose that I usually want to run tests with 8 threads. I can
> set `test.threads=8` in the System Config file and each time I
> download a new version of Tomcat I simply run `ant test` in the
> directory of that instance. It will run with 8 threads, resolving
> my original issue here.
>
> But, if now I download a version and want to run only that one with
> 4 threads (a more likely scenario would be to set different
> versions or paths for OpenSSL), I can not simply set the new value
> for the Instance Configuration, {tomcat}/build.properties, to
> affect only that instance -- I have to modify the System Config,
> which will change the settings for all other instances.
>
> The way I see it, the System Config is Default for the system, and
> each instance should be able to specify its own Instance
> Configuration which will override both the Project's Defaults and
> the System Defaults. My proposal is therefore that the order of
> applying the settings will be:
>
> 1) Project Default Config.: {tomcat}/build.properties.default 2)
> System Config..........: {user.home}/build.properties 3) Instance
> Config........: {tomcat}/build.properties
>
> That way I do not need to add an Instance Config anywhere unless a
> specific instance requires unique settings. I can set my System
> Config (~/build.properties) with the values that I normally use,
> and only override them with an Instance Config, i.e.
> {tomcat}/build.properties where needed.
>
> What am I missing?
Just remember that ant properties are write-once, so all your orders
above are backward. If you want the instance config to override all
others, you'll have to load it first.
Nobody is going to agree on this, so maybe:
{tomcat}/build.first.properties
{user.home}/build.properties (which is a really weird default, IMO)
{tomcat}/build.properties
{tomcat}/build.default.properties
This preserves the current behavior in all environments and allows you
to have your new type of overriding configuration.
Making a change to the current behavior runs the risk of breaking all
downstream projects, so let's not do that.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlyNFLUACgkQHPApP6U8
pFgByQ//S9oHh5vA2clnJw07M0LyDOu9MYh7i3N2Yiz0KneHwD1zN6K6IxmAk3Vl
utyXEjJcJ8cZQ1dsgppUCKqDhqvXe+Ke+ySQ5es63mGY6CNlPMQnifca+CSEeJxA
9vLotQSeknnzOCR+h0xc0ICJAVUIhWDbc/YRdZV4iOf3/7oZ+N94QZz+1gKc6MVL
6yip6IVLs+3qgpemEDnGZS3NT9iSTlP4YsJ7DzhTkUqUkfPwEPJBkc8F+lywCAY/
47CGDL7mPulUQi1EJvG/N9KCNBWUjBQe+DX9gb2AQzPhysPwPjavNBoEXFNEBhM6
3nr1DlZaf91bNaW0EnVvaOxACAiIYvgDXnBLNISoRQURyvB4srH7Idmjp93vF+el
2N6/f8AUSAKODWyjWRVGf3fTJzoYejDgkDV8q3Ia23gTTLn8nZdohTTg1t59wpjH
E6j0e0/z/CwHv/5Z+cj955MZzMoX8YNeH9540SZoIFADYTmSftugwvK6Itj1MHcF
KGE0QjdBihJOvIBLB323mayCK03OufKgzFs03oA5OxZi8rYBZ9kz3Jv9EKcYHOLT
qBNWM0INzwrUHFfhmXBo+Kdg4/DnHdszI2uResaqaOcUOzKMfdvOn+q4aMmnC4q5
6gmoa+hb+JnLYGdgxMtZ4Gzt5UWqLTHDYcghKT7wdZZ+v4Zj7nE=
=qOG1
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Default Number of Test Threads
Posted by Igal Sapir <ig...@lucee.org>.
Chris,
On Fri, Mar 15, 2019 at 4:56 PM Christopher Schultz <
chris@christopherschultz.net> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA256
>
> Igal,
>
> On 3/15/19 16:45, Igal Sapir wrote:
> > <snip/>
> > I looked deeper into build.xml and I found some interesting
> > information and a simple solution for my issue. In build.xml we
> > have the following:
> >
> > <property file="${user.home}/build.properties"/> <property
> > file="build.properties"/> <property
> > file="build.properties.default"/>
> >
> > So I can place my settings for test.threads in ~/build.properties.
> >
> > The current order of precedence, however, gives
> > ${user.home}/build.properties a higher priority than the one at
> > {tomcat}/build.properties.
> >
> > That is wrong IMHO and should be the other way around, i.e.
> > {tomcat}/build.properties should
> > override${user.home}/build.properties . I would like to change
> > that order if everyone agrees.
>
> I do not agree. The local configuration (~/build.properties) should
> override the default configuration (build.properties). That's why it's
> called "local configuration".
>
> Besides, if you implement your proposed switch, then you will be
> UNABLE to use ~/build.properties to customize this configuration that
> you don't like.
>
Perhaps I'm missing something, but I think that the term "Local" is
ambiguous here, so I will avoid using it to prevent confusion. We have
(applied in order):
1) Project Default Config.: {tomcat}/build.properties.default
2) Instance Config........: {tomcat}/build.properties
3) System Config..........: {user.home}/build.properties
Tomcat only ships with the Project Default Config file. The other two are
optional and can be created by the user.
Suppose that I usually want to run tests with 8 threads. I can set
`test.threads=8` in the System Config file and each time I download a new
version of Tomcat I simply run `ant test` in the directory of that
instance. It will run with 8 threads, resolving my original issue here.
But, if now I download a version and want to run only that one with 4
threads (a more likely scenario would be to set different versions or paths
for OpenSSL), I can not simply set the new value for the Instance
Configuration, {tomcat}/build.properties, to affect only that instance -- I
have to modify the System Config, which will change the settings for all
other instances.
The way I see it, the System Config is Default for the system, and each
instance should be able to specify its own Instance Configuration which
will override both the Project's Defaults and the System Defaults. My
proposal is therefore that the order of applying the settings will be:
1) Project Default Config.: {tomcat}/build.properties.default
2) System Config..........: {user.home}/build.properties
3) Instance Config........: {tomcat}/build.properties
That way I do not need to add an Instance Config anywhere unless a specific
instance requires unique settings. I can set my System Config
(~/build.properties) with the values that I normally use, and only override
them with an Instance Config, i.e. {tomcat}/build.properties where needed.
What am I missing?
Thanks,
Igal
Re: Default Number of Test Threads
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Igal,
On 3/15/19 16:45, Igal Sapir wrote:
> On Fri, Mar 15, 2019 at 9:45 AM Konstantin Kolinko
> <kn...@gmail.com> wrote:
>
>> чт, 14 мар. 2019 г. в 22:26, Igal Sapir <is...@apache.org>:
>> <snip/> What is the use case? People verifying a release? CI
>> servers that may have different hardware?
>>
>
> The idea was more for testing new releases. On my laptop setting
> test.threads to 8 completes in about 10 minutes, while the default
> 1 thread takes more than 1 hour.
>
> I looked deeper into build.xml and I found some interesting
> information and a simple solution for my issue. In build.xml we
> have the following:
>
> <property file="${user.home}/build.properties"/> <property
> file="build.properties"/> <property
> file="build.properties.default"/>
>
> So I can place my settings for test.threads in ~/build.properties.
>
> The current order of precedence, however, gives
> ${user.home}/build.properties a higher priority than the one at
> {tomcat}/build.properties.
>
> That is wrong IMHO and should be the other way around, i.e.
> {tomcat}/build.properties should
> override${user.home}/build.properties . I would like to change
> that order if everyone agrees.
I do not agree. The local configuration (~/build.properties) should
override the default configuration (build.properties). That's why it's
called "local configuration".
Besides, if you implement your proposed switch, then you will be
UNABLE to use ~/build.properties to customize this configuration that
you don't like.
> I added an ant target, echoproperties [1], which outputs the
> merged properties so it's easy to see the final values.
You can also add -debug to the command-line and get the properties.
- -chris
-----BEGIN PGP SIGNATURE-----
Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/
iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAlyMO7QACgkQHPApP6U8
pFiElQ//YAxkI061TxrzcCb+Mht4/qJ7xMUQ4uVOY4/BGMehHqMjwudlOEB0jtjl
1HaDVjyiMiIgKq8Ss1y1g5I9aNzxA8+Uq+Efj82GmT4UVloSHpClhJAiO3+BUM2w
HsWdpwFyNFjjy0e/nt01yoCIl4NumKCFZ+AM6sSt/PVhI9gJ0JOx64PZeyZyjHjU
1X7oo4brjUgrw9ulzPfEHByjpHAfxD8SinGV1QKVToggVrDR3mrUrUtlkVDWOsj4
S6vJyM2W5tz4+AP+hi/EG0ck+ZlMwpw2x6K6i38CglaoFeKPQeQJWdPk+wPpJl4t
ZkmdnxFlDFRvIlir/Xn5zswkURZFMjGqJhfplqhN/dQ4B2ICuYth/wnX/HBXBjkd
NEHNtnLgtKMVobu8u1Hd76S/EhfDuVOlA3FaAp0n+67a90Pnboo0Ih5/fKl8ADXI
+yR7Dc8ZumhNfAZFSi3QNeasP3zXNYHVRNOSKEMtxhWyaVODB/EkMdDo3c6Lxh23
BzBJ6gI0Hzx/n5dos35QKGHZlZCE2yng4VFJ6rBWRG529nq0QL9npvkEWWciKn6d
GaLEJ1nsfZfui1jGBeYWBtQV33qEpTBxDu9tGXt8cD1ECtT7IgzmmmWCcE8VqGTE
z5Twj3PS+AYW98aHfKmItwI5mUTgib6Cwjb4k88JxwRQY2+9JEQ=
=hZhA
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Default Number of Test Threads
Posted by Igal Sapir <ig...@lucee.org>.
On Fri, Mar 15, 2019 at 9:45 AM Konstantin Kolinko <kn...@gmail.com>
wrote:
> чт, 14 мар. 2019 г. в 22:26, Igal Sapir <is...@apache.org>:
> <snip/>
> What is the use case? People verifying a release? CI servers that may
> have different hardware?
>
The idea was more for testing new releases. On my laptop setting
test.threads to 8 completes in about 10 minutes, while the default 1 thread
takes more than 1 hour.
I looked deeper into build.xml and I found some interesting information and
a simple solution for my issue. In build.xml we have the following:
<property file="${user.home}/build.properties"/>
<property file="build.properties"/>
<property file="build.properties.default"/>
So I can place my settings for test.threads in ~/build.properties.
The current order of precedence, however, gives
${user.home}/build.properties a higher priority than the one at
{tomcat}/build.properties.
That is wrong IMHO and should be the other way around, i.e.
{tomcat}/build.properties should override${user.home}/build.properties . I
would like to change that order if everyone agrees.
I added an ant target, echoproperties [1], which outputs the merged
properties so it's easy to see the final values.
Best,
Igal
[1] https://github.com/apache/tomcat/commit/8a2f41bed80a
Re: Default Number of Test Threads
Posted by Konstantin Kolinko <kn...@gmail.com>.
чт, 14 мар. 2019 г. в 22:26, Igal Sapir <is...@apache.org>:
>
> Does test.threads default to 1 for a reason?
>
> If there is no objection, I would like to set the default to the number
> of available CPU Threads. It looks like that can be done with a custom
> Ant task which should be fairly simple to implement.
It depends on the actual implementation,
and do not forget to document the setting in RUNNING.txt.
What is the use case? People verifying a release? CI servers that may
have different hardware?
1) Personally, I'll be bothered by this, as I do other things on my PC
while the tests are running.
It is not much, as I always have a custom build.properties file with a
"base.path" setting,
but it has to be documented properly.
2) If additional logging is enabled (e.g. access logs),
things will be messy if several tests run in parallel.
3) If someone explicitly runs a specific test,
things will be messy if several tests run in parallel.
I think that JUnit runs several test classes in parallel, but not
different tests from the same test class. (Maybe it is configurable).
4) IIRC, coverage tests need to run in single thread.
We have a separate configuration at Buildbot to run the coverage tests
once a day (scheduled by time).
I do not remember whether that configuration is explicitly configured
with thread count of 1.
It may be that the other configurations a configured with an explicit
count of threads, but this one has not been configured.
Best regards,
Konstantin Kolinko
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org