Mailing List Archive

You can override the defaults using sysprops in your CI builds -

-Ptests.timeoutSuite=1000!

takes precedence over any annotations (1 second).

Dawid

On Mon, Feb 12, 2024 at 7:53?PM David Smiley <dsmiley@apache.org> wrote:

> Looking at LuceneTestCase, I see the annotation from RandomizedTesting:
> @TimeoutSuite(millis = 2 * TimeUnits.HOUR)
> This matches my observations of some builds that timed out, perhaps
> some flaky test hanging in Solr (that extends LuceneTestCase).
> Looking at this annotation, there is further documentation that the
> default can be set via sysprop tests.timeoutSuite. Wouldn't doing
> that make more sense than hard-coding this figure in LuceneTestCase?
> For example, I'd like to have a normal/default test run have a low
> timeout (10min?) but on a "nightly" run on CI, use much higher. Not 2
> hours though; individual tests needing so much should have a
> TimeoutSuite applied to them.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

Oh; I didn't know that took precedence -- makes sense. Hopefully a
test subclass (like SolrTestCase) could override it as well.

On Mon, Feb 12, 2024 at 2:09?PM Dawid Weiss <dawid.weiss@gmail.com> wrote:
>
>
> You can override the defaults using sysprops in your CI builds -
>
> -Ptests.timeoutSuite=1000!
>
> takes precedence over any annotations (1 second).
>
> Dawid
>
> On Mon, Feb 12, 2024 at 7:53?PM David Smiley <dsmiley@apache.org> wrote:
>>
>> Looking at LuceneTestCase, I see the annotation from RandomizedTesting:
>> @TimeoutSuite(millis = 2 * TimeUnits.HOUR)
>> This matches my observations of some builds that timed out, perhaps
>> some flaky test hanging in Solr (that extends LuceneTestCase).
>> Looking at this annotation, there is further documentation that the
>> default can be set via sysprop tests.timeoutSuite. Wouldn't doing
>> that make more sense than hard-coding this figure in LuceneTestCase?
>> For example, I'd like to have a normal/default test run have a low
>> timeout (10min?) but on a "nightly" run on CI, use much higher. Not 2
>> hours though; individual tests needing so much should have a
>> TimeoutSuite applied to them.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Sorry, the docs are not the best, I know.

It's documented here -
https://github.com/randomizedtesting/randomizedtesting/blob/master/randomized-runner/src/main/java/com/carrotsearch/randomizedtesting/SysGlobals.java#L186-L197

So:

1) if you pass tests.timeoutSuite=1000 this changes the default value for
all classes that don't define any explicit timeout using an annotation;
classes that do have an annotation,
use the annotation's value,
2) if you pass tests.timeoutSuite=1000! then this overrides everything -
the default value and all annotations.

I vaguely recall option (2) was added specifically for nightlies which
bumped the iteration multiplier - this affected tests that normally ran
fairly fast
but during nightly runs could run slower than anticipated.

D.


On Thu, Feb 15, 2024 at 3:18?PM David Smiley <dsmiley@apache.org> wrote:

> Oh; I didn't know that took precedence -- makes sense. Hopefully a
> test subclass (like SolrTestCase) could override it as well.
>
> On Mon, Feb 12, 2024 at 2:09?PM Dawid Weiss <dawid.weiss@gmail.com> wrote:
> >
> >
> > You can override the defaults using sysprops in your CI builds -
> >
> > -Ptests.timeoutSuite=1000!
> >
> > takes precedence over any annotations (1 second).
> >
> > Dawid
> >
> > On Mon, Feb 12, 2024 at 7:53?PM David Smiley <dsmiley@apache.org> wrote:
> >>
> >> Looking at LuceneTestCase, I see the annotation from RandomizedTesting:
> >> @TimeoutSuite(millis = 2 * TimeUnits.HOUR)
> >> This matches my observations of some builds that timed out, perhaps
> >> some flaky test hanging in Solr (that extends LuceneTestCase).
> >> Looking at this annotation, there is further documentation that the
> >> default can be set via sysprop tests.timeoutSuite. Wouldn't doing
> >> that make more sense than hard-coding this figure in LuceneTestCase?
> >> For example, I'd like to have a normal/default test run have a low
> >> timeout (10min?) but on a "nightly" run on CI, use much higher. Not 2
> >> hours though; individual tests needing so much should have a
> >> TimeoutSuite applied to them.
> >>
> >> ~ David Smiley
> >> Apache Lucene/Solr Search Developer
> >> http://www.linkedin.com/in/davidwsmiley
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

I think this information could sit well within the dev-docs in lucene i.e.
"randomized testing in lucene". This would make it more discoverable as
well and there is already a lack of proper docs as Dawid pointed?. We could
add some references to docs like randomized testing core concepts
<https://github.com/randomizedtesting/randomizedtesting/wiki/Core-Concepts>.
If this idea makes sense I could try to write some doc around it and open a
PR. I would like to know your thoughts on this? Thanks!

- Shubham

On Thu, Feb 15, 2024 at 10:23?PM Dawid Weiss <dawid.weiss@gmail.com> wrote:

>
> Sorry, the docs are not the best, I know.
>
> It's documented here -
>
> https://github.com/randomizedtesting/randomizedtesting/blob/master/randomized-runner/src/main/java/com/carrotsearch/randomizedtesting/SysGlobals.java#L186-L197
>
> So:
>
> 1) if you pass tests.timeoutSuite=1000 this changes the default value for
> all classes that don't define any explicit timeout using an annotation;
> classes that do have an annotation,
> use the annotation's value,
> 2) if you pass tests.timeoutSuite=1000! then this overrides everything -
> the default value and all annotations.
>
> I vaguely recall option (2) was added specifically for nightlies which
> bumped the iteration multiplier - this affected tests that normally ran
> fairly fast
> but during nightly runs could run slower than anticipated.
>
> D.
>
>
> On Thu, Feb 15, 2024 at 3:18?PM David Smiley <dsmiley@apache.org> wrote:
>
>> Oh; I didn't know that took precedence -- makes sense. Hopefully a
>> test subclass (like SolrTestCase) could override it as well.
>>
>> On Mon, Feb 12, 2024 at 2:09?PM Dawid Weiss <dawid.weiss@gmail.com>
>> wrote:
>> >
>> >
>> > You can override the defaults using sysprops in your CI builds -
>> >
>> > -Ptests.timeoutSuite=1000!
>> >
>> > takes precedence over any annotations (1 second).
>> >
>> > Dawid
>> >
>> > On Mon, Feb 12, 2024 at 7:53?PM David Smiley <dsmiley@apache.org>
>> wrote:
>> >>
>> >> Looking at LuceneTestCase, I see the annotation from RandomizedTesting:
>> >> @TimeoutSuite(millis = 2 * TimeUnits.HOUR)
>> >> This matches my observations of some builds that timed out, perhaps
>> >> some flaky test hanging in Solr (that extends LuceneTestCase).
>> >> Looking at this annotation, there is further documentation that the
>> >> default can be set via sysprop tests.timeoutSuite. Wouldn't doing
>> >> that make more sense than hard-coding this figure in LuceneTestCase?
>> >> For example, I'd like to have a normal/default test run have a low
>> >> timeout (10min?) but on a "nightly" run on CI, use much higher. Not 2
>> >> hours though; individual tests needing so much should have a
>> >> TimeoutSuite applied to them.
>> >>
>> >> ~ David Smiley
>> >> Apache Lucene/Solr Search Developer
>> >> http://www.linkedin.com/in/davidwsmiley
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>

There's actually quite a lot of docs related to Lucene tests (my remark was
meant at the randomizedtesting package) - see here:
https://github.com/apache/lucene/blob/main/help/tests.txt

The tests.timeoutSuite parameter could be added/ explained there too. I'm
not sure how much it's needed though - it's the first time anybody ever
mentioned it. :)

D.

On Thu, Feb 15, 2024 at 8:55?PM Shubham Chaudhary <shubhmasand@gmail.com>
wrote:

> I think this information could sit well within the dev-docs in lucene i.e.
> "randomized testing in lucene". This would make it more discoverable as
> well and there is already a lack of proper docs as Dawid pointed?. We could
> add some references to docs like randomized testing core concepts
> <https://github.com/randomizedtesting/randomizedtesting/wiki/Core-Concepts>.
> If this idea makes sense I could try to write some doc around it and open a
> PR. I would like to know your thoughts on this? Thanks!
>
> - Shubham
>
> On Thu, Feb 15, 2024 at 10:23?PM Dawid Weiss <dawid.weiss@gmail.com>
> wrote:
>
>>
>> Sorry, the docs are not the best, I know.
>>
>> It's documented here -
>>
>> https://github.com/randomizedtesting/randomizedtesting/blob/master/randomized-runner/src/main/java/com/carrotsearch/randomizedtesting/SysGlobals.java#L186-L197
>>
>> So:
>>
>> 1) if you pass tests.timeoutSuite=1000 this changes the default value for
>> all classes that don't define any explicit timeout using an annotation;
>> classes that do have an annotation,
>> use the annotation's value,
>> 2) if you pass tests.timeoutSuite=1000! then this overrides everything -
>> the default value and all annotations.
>>
>> I vaguely recall option (2) was added specifically for nightlies which
>> bumped the iteration multiplier - this affected tests that normally ran
>> fairly fast
>> but during nightly runs could run slower than anticipated.
>>
>> D.
>>
>>
>> On Thu, Feb 15, 2024 at 3:18?PM David Smiley <dsmiley@apache.org> wrote:
>>
>>> Oh; I didn't know that took precedence -- makes sense. Hopefully a
>>> test subclass (like SolrTestCase) could override it as well.
>>>
>>> On Mon, Feb 12, 2024 at 2:09?PM Dawid Weiss <dawid.weiss@gmail.com>
>>> wrote:
>>> >
>>> >
>>> > You can override the defaults using sysprops in your CI builds -
>>> >
>>> > -Ptests.timeoutSuite=1000!
>>> >
>>> > takes precedence over any annotations (1 second).
>>> >
>>> > Dawid
>>> >
>>> > On Mon, Feb 12, 2024 at 7:53?PM David Smiley <dsmiley@apache.org>
>>> wrote:
>>> >>
>>> >> Looking at LuceneTestCase, I see the annotation from
>>> RandomizedTesting:
>>> >> @TimeoutSuite(millis = 2 * TimeUnits.HOUR)
>>> >> This matches my observations of some builds that timed out, perhaps
>>> >> some flaky test hanging in Solr (that extends LuceneTestCase).
>>> >> Looking at this annotation, there is further documentation that the
>>> >> default can be set via sysprop tests.timeoutSuite. Wouldn't doing
>>> >> that make more sense than hard-coding this figure in LuceneTestCase?
>>> >> For example, I'd like to have a normal/default test run have a low
>>> >> timeout (10min?) but on a "nightly" run on CI, use much higher. Not 2
>>> >> hours though; individual tests needing so much should have a
>>> >> TimeoutSuite applied to them.
>>> >>
>>> >> ~ David Smiley
>>> >> Apache Lucene/Solr Search Developer
>>> >> http://www.linkedin.com/in/davidwsmiley
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>

I see. This makes more sense; it looks to me like it's fine to add this
info here in case anyone else ever requires it.

One observation though: there are some docs under the help folder (that too
as text files) and some under dev-docs. I personally feel all these should
be organized into the dev-docs folder (as .md files for readability on
github and IDEs), since that was the first place I went to look for any
docs.

- Shubham

On Fri, Feb 16, 2024 at 1:32?AM Dawid Weiss <dawid.weiss@gmail.com> wrote:

>
> There's actually quite a lot of docs related to Lucene tests (my remark
> was meant at the randomizedtesting package) - see here:
> https://github.com/apache/lucene/blob/main/help/tests.txt
>
> The tests.timeoutSuite parameter could be added/ explained there too. I'm
> not sure how much it's needed though - it's the first time anybody ever
> mentioned it. :)
>
> D.
>
> On Thu, Feb 15, 2024 at 8:55?PM Shubham Chaudhary <shubhmasand@gmail.com>
> wrote:
>
>> I think this information could sit well within the dev-docs in lucene
>> i.e. "randomized testing in lucene". This would make it more discoverable
>> as well and there is already a lack of proper docs as Dawid pointed?. We
>> could add some references to docs like randomized testing core concepts
>> <https://github.com/randomizedtesting/randomizedtesting/wiki/Core-Concepts>.
>> If this idea makes sense I could try to write some doc around it and open a
>> PR. I would like to know your thoughts on this? Thanks!
>>
>> - Shubham
>>
>> On Thu, Feb 15, 2024 at 10:23?PM Dawid Weiss <dawid.weiss@gmail.com>
>> wrote:
>>
>>>
>>> Sorry, the docs are not the best, I know.
>>>
>>> It's documented here -
>>>
>>> https://github.com/randomizedtesting/randomizedtesting/blob/master/randomized-runner/src/main/java/com/carrotsearch/randomizedtesting/SysGlobals.java#L186-L197
>>>
>>> So:
>>>
>>> 1) if you pass tests.timeoutSuite=1000 this changes the default value
>>> for all classes that don't define any explicit timeout using an annotation;
>>> classes that do have an annotation,
>>> use the annotation's value,
>>> 2) if you pass tests.timeoutSuite=1000! then this overrides everything -
>>> the default value and all annotations.
>>>
>>> I vaguely recall option (2) was added specifically for nightlies which
>>> bumped the iteration multiplier - this affected tests that normally ran
>>> fairly fast
>>> but during nightly runs could run slower than anticipated.
>>>
>>> D.
>>>
>>>
>>> On Thu, Feb 15, 2024 at 3:18?PM David Smiley <dsmiley@apache.org> wrote:
>>>
>>>> Oh; I didn't know that took precedence -- makes sense. Hopefully a
>>>> test subclass (like SolrTestCase) could override it as well.
>>>>
>>>> On Mon, Feb 12, 2024 at 2:09?PM Dawid Weiss <dawid.weiss@gmail.com>
>>>> wrote:
>>>> >
>>>> >
>>>> > You can override the defaults using sysprops in your CI builds -
>>>> >
>>>> > -Ptests.timeoutSuite=1000!
>>>> >
>>>> > takes precedence over any annotations (1 second).
>>>> >
>>>> > Dawid
>>>> >
>>>> > On Mon, Feb 12, 2024 at 7:53?PM David Smiley <dsmiley@apache.org>
>>>> wrote:
>>>> >>
>>>> >> Looking at LuceneTestCase, I see the annotation from
>>>> RandomizedTesting:
>>>> >> @TimeoutSuite(millis = 2 * TimeUnits.HOUR)
>>>> >> This matches my observations of some builds that timed out, perhaps
>>>> >> some flaky test hanging in Solr (that extends LuceneTestCase).
>>>> >> Looking at this annotation, there is further documentation that the
>>>> >> default can be set via sysprop tests.timeoutSuite. Wouldn't doing
>>>> >> that make more sense than hard-coding this figure in LuceneTestCase?
>>>> >> For example, I'd like to have a normal/default test run have a low
>>>> >> timeout (10min?) but on a "nightly" run on CI, use much higher. Not
>>>> 2
>>>> >> hours though; individual tests needing so much should have a
>>>> >> TimeoutSuite applied to them.
>>>> >>
>>>> >> ~ David Smiley
>>>> >> Apache Lucene/Solr Search Developer
>>>> >> http://www.linkedin.com/in/davidwsmiley
>>>> >>
>>>> >> ---------------------------------------------------------------------
>>>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>>>> >>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>>

>
> One observation though: there are some docs under the help folder (that
> too as text files) and some under dev-docs. I personally feel all these
> should be organized into the dev-docs folder (as .md files for readability
> on github and IDEs), since that was the first place I went to look for any
> docs.
>

Expectations are different depending on whom you ask. I prefer those txt
files over md files, actually - they're easier to cat to terminal/grep,
etc. And there is a gradle task that shows them - type:

gradlew help

and you'll see what I mean:

This is Lucene's gradle build. See some
guidelines, ant-equivalent commands etc. under help/*; or type:

gradlew :helpWorkflow # Typical workflow commands.
gradlew :helpTests # Tests, filtering, beasting, etc.
gradlew :helpFormatting # Code formatting conventions.
gradlew :helpJvms # Using alternative or EA JVM toolchains.
gradlew :helpDeps # Declaring, inspecting and excluding
dependencies.
gradlew :helpForbiddenApis # How to add/apply rules for forbidden APIs.
gradlew :helpLocalSettings # Local settings, overrides and build
performance tweaks.
gradlew :helpRegeneration # How to refresh generated and derived
resources.
gradlew :helpJmh # JMH micro-benchmarks.
gradlew :helpGit # Git assistance and guides.
gradlew :helpIDEs # IDE support.
gradlew :helpPublishing # Maven and other artifact publishing,
signing, etc.

The "dev-docs" are mostly concerned with processes and procedures; the
help/ is, I think, more focused on development/code. But you're entitled
to your own opinion, of course. ;)

Dawid

Good to know the gradle task is using these files for help and keeping as
.txt too has its own benefits here.

- Shubham

On Fri, Feb 16, 2024 at 2:03?AM Dawid Weiss <dawid.weiss@gmail.com> wrote:

> One observation though: there are some docs under the help folder (that
>> too as text files) and some under dev-docs. I personally feel all these
>> should be organized into the dev-docs folder (as .md files for readability
>> on github and IDEs), since that was the first place I went to look for any
>> docs.
>>
>
> Expectations are different depending on whom you ask. I prefer those txt
> files over md files, actually - they're easier to cat to terminal/grep,
> etc. And there is a gradle task that shows them - type:
>
> gradlew help
>
> and you'll see what I mean:
>
> This is Lucene's gradle build. See some
> guidelines, ant-equivalent commands etc. under help/*; or type:
>
> gradlew :helpWorkflow # Typical workflow commands.
> gradlew :helpTests # Tests, filtering, beasting, etc.
> gradlew :helpFormatting # Code formatting conventions.
> gradlew :helpJvms # Using alternative or EA JVM toolchains.
> gradlew :helpDeps # Declaring, inspecting and excluding
> dependencies.
> gradlew :helpForbiddenApis # How to add/apply rules for forbidden
> APIs.
> gradlew :helpLocalSettings # Local settings, overrides and build
> performance tweaks.
> gradlew :helpRegeneration # How to refresh generated and derived
> resources.
> gradlew :helpJmh # JMH micro-benchmarks.
> gradlew :helpGit # Git assistance and guides.
> gradlew :helpIDEs # IDE support.
> gradlew :helpPublishing # Maven and other artifact publishing,
> signing, etc.
>
> The "dev-docs" are mostly concerned with processes and procedures; the
> help/ is, I think, more focused on development/code. But you're entitled
> to your own opinion, of course. ;)
>
> Dawid
>

I found that passing -Ptests.timeoutSuite=500 doesn't have any effect
that I can see; it didn't interrupt the tests. I needed that trailing
exclamation mark for it to do the interrupt. Thanks for that tip. I
don't so much mind this for specific tests that might want to pick
their own timeout (rather rare), but it's troublesome for the vast
majority. IMO LuceneTestCase shouldn't be declaring a default; it
should be done in a gradle build file instead. Then, configuration
for a build server (I'm thinking of Crave.io used by Solr PRs) can
specify like 10 minutes because otherwise an unlucky build hogs that
96 core server for hours. Until then, I'll use an exclamation mark
for that server's config which isn't quite ideal but it's adequate.

On Thu, Feb 15, 2024 at 11:53?AM Dawid Weiss <dawid.weiss@gmail.com> wrote:
>
>
> Sorry, the docs are not the best, I know.
>
> It's documented here -
> https://github.com/randomizedtesting/randomizedtesting/blob/master/randomized-runner/src/main/java/com/carrotsearch/randomizedtesting/SysGlobals.java#L186-L197
>
> So:
>
> 1) if you pass tests.timeoutSuite=1000 this changes the default value for all classes that don't define any explicit timeout using an annotation; classes that do have an annotation,
> use the annotation's value,
> 2) if you pass tests.timeoutSuite=1000! then this overrides everything - the default value and all annotations.
>
> I vaguely recall option (2) was added specifically for nightlies which bumped the iteration multiplier - this affected tests that normally ran fairly fast
> but during nightly runs could run slower than anticipated.
>
> D.
>
>
> On Thu, Feb 15, 2024 at 3:18?PM David Smiley <dsmiley@apache.org> wrote:
>>
>> Oh; I didn't know that took precedence -- makes sense. Hopefully a
>> test subclass (like SolrTestCase) could override it as well.
>>
>> On Mon, Feb 12, 2024 at 2:09?PM Dawid Weiss <dawid.weiss@gmail.com> wrote:
>> >
>> >
>> > You can override the defaults using sysprops in your CI builds -
>> >
>> > -Ptests.timeoutSuite=1000!
>> >
>> > takes precedence over any annotations (1 second).
>> >
>> > Dawid
>> >
>> > On Mon, Feb 12, 2024 at 7:53?PM David Smiley <dsmiley@apache.org> wrote:
>> >>
>> >> Looking at LuceneTestCase, I see the annotation from RandomizedTesting:
>> >> @TimeoutSuite(millis = 2 * TimeUnits.HOUR)
>> >> This matches my observations of some builds that timed out, perhaps
>> >> some flaky test hanging in Solr (that extends LuceneTestCase).
>> >> Looking at this annotation, there is further documentation that the
>> >> default can be set via sysprop tests.timeoutSuite. Wouldn't doing
>> >> that make more sense than hard-coding this figure in LuceneTestCase?
>> >> For example, I'd like to have a normal/default test run have a low
>> >> timeout (10min?) but on a "nightly" run on CI, use much higher. Not 2
>> >> hours though; individual tests needing so much should have a
>> >> TimeoutSuite applied to them.
>> >>
>> >> ~ David Smiley
>> >> Apache Lucene/Solr Search Developer
>> >> http://www.linkedin.com/in/davidwsmiley
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

> I found that passing -Ptests.timeoutSuite=500 doesn't have any effect
> that I can see; it didn't interrupt the tests.


It's exactly what I said - without the exclamation mark, this is the
default value of the timeout unless a class has an annotation specifying
other value (which all of Lucene tests do because they inherit from
LuceneTestCase).


> I needed that trailing
> exclamation mark for it to do the interrupt.


Yep, it's an override that takes precedence over annotations.


> majority. IMO LuceneTestCase shouldn't be declaring a default; it
> should be done in a gradle build file instead.


We could, sure. Or it could be shorter too. I don't have an opinion on this.


> Then, configuration
> for a build server (I'm thinking of Crave.io used by Solr PRs) can
> specify like 10 minutes because otherwise an unlucky build hogs that
> 96 core server for hours. Until then, I'll use an exclamation mark
> for that server's config which isn't quite ideal but it's adequate.
>

+1.