[jira] [Commented] (LUCENE-4360) Support running the same test suite multiple times in parallel
[
https://issues.apache.org/jira/browse/LUCENE-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13610915#comment-13610915
]
Commit Tag Bot commented on LUCENE-4360:
[branch_4x commit] Dawid Weiss
http://svn.apache.org/viewvc?view=revisionrevision=1381124
LUCENE-4360: Support running the same test suite multiple times in parallel.
Support running the same test suite multiple times in parallel
--
Key: LUCENE-4360
URL: https://issues.apache.org/jira/browse/LUCENE-4360
Project: Lucene - Core
Issue Type: New Feature
Components: general/test
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
Fix For: 4.0, 5.0
Attachments: quickhack.patch
The current test execution multiplier or:
{code}
-Dtests.iters=N
{code}
generates multiple tests (method executions) under a test class (suite). All
these tests, however, are bound to a single class so they must run
sequentially and on a single JVM (because of how JUnit works -- nesting of
rules, class hooks, etc.).
Mark pointed out that if somebody has a multi-core CPU then it'd be nice to
be able to run a single suite in parallel, possibly in combination with
tests.iters (so that a single test method is executed X times on Y parallel
JVMs).
This is surprisingly easy with the randomized runner because it currently
accepts duplicate suite names and will load-balance them in a normal way.
So, if one has Y cores (JVMs) then providing a suite name X times will result
in X executions, balanced across Y JVMs.
The only problem is how to multiply suite names. This can be done in a
number of ways, starting from a custom resource collection wrapper and ending
at a built-in code in the runner itself. I think the custom collection
wrapper approach would be interesting, I'll explore this direction.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4360) Support running the same test suite multiple times in parallel
[
https://issues.apache.org/jira/browse/LUCENE-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448571#comment-13448571
]
Dawid Weiss commented on LUCENE-4360:
-
Any ideas what to call this parameter? It's not the same as tests.iters because
it multiplies entire suites. I came up with:
{code}
-Dtests.multiply
-Dtests.duplicate
or the short equivalents:
-Dtests.mply
-Dtests.dups
{code}
Support running the same test suite multiple times in parallel
--
Key: LUCENE-4360
URL: https://issues.apache.org/jira/browse/LUCENE-4360
Project: Lucene - Core
Issue Type: New Feature
Components: general/test
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
Fix For: 5.0, 4.0
Attachments: quickhack.patch
The current test execution multiplier or:
{code}
-Dtests.iters=N
{code}
generates multiple tests (method executions) under a test class (suite). All
these tests, however, are bound to a single class so they must run
sequentially and on a single JVM (because of how JUnit works -- nesting of
rules, class hooks, etc.).
Mark pointed out that if somebody has a multi-core CPU then it'd be nice to
be able to run a single suite in parallel, possibly in combination with
tests.iters (so that a single test method is executed X times on Y parallel
JVMs).
This is surprisingly easy with the randomized runner because it currently
accepts duplicate suite names and will load-balance them in a normal way.
So, if one has Y cores (JVMs) then providing a suite name X times will result
in X executions, balanced across Y JVMs.
The only problem is how to multiply suite names. This can be done in a
number of ways, starting from a custom resource collection wrapper and ending
at a built-in code in the runner itself. I think the custom collection
wrapper approach would be interesting, I'll explore this direction.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4360) Support running the same test suite multiple times in parallel
[
https://issues.apache.org/jira/browse/LUCENE-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448606#comment-13448606
]
Dawid Weiss commented on LUCENE-4360:
-
Example of use:
{code}
ant test-core -Dtests.dups=3 -Dtestcase=TestCharFilter
JUnit4 says kaixo! Master seed: 4CE0022F3CDFF5D7
Your default console's encoding may not display certain unicode glyphs:
windows-1252
Executing 3 suites with 3 JVMs.
Suite: org.apache.lucene.analysis.TestCharFilter
OK 0.05s J1 | TestCharFilter.testCharFilter1
OK 0.01s J1 | TestCharFilter.testCharFilter11
OK 0.00s J1 | TestCharFilter.testCharFilter2
OK 0.00s J1 | TestCharFilter.testCharFilter12
Completed on J1 in 0.35s, 4 tests
Suite: org.apache.lucene.analysis.TestCharFilter
OK 0.04s J2 | TestCharFilter.testCharFilter1
OK 0.01s J2 | TestCharFilter.testCharFilter11
OK 0.00s J2 | TestCharFilter.testCharFilter2
OK 0.01s J2 | TestCharFilter.testCharFilter12
Completed on J2 in 0.35s, 4 tests
Suite: org.apache.lucene.analysis.TestCharFilter
OK 0.04s J0 | TestCharFilter.testCharFilter1
OK 0.02s J0 | TestCharFilter.testCharFilter11
OK 0.00s J0 | TestCharFilter.testCharFilter2
OK 0.00s J0 | TestCharFilter.testCharFilter12
Completed on J0 in 0.36s, 4 tests
JVM J0: 0.67 .. 1.56 = 0.89s
JVM J1: 0.67 .. 1.55 = 0.88s
JVM J2: 0.67 .. 1.57 = 0.90s
Execution time total: 1.58 sec.
Tests summary: 3 suites, 12 tests
{code}
In combination with tests.iters:
{code}
ant test-core -Dtests.dups=2 -Dtests.iters=2 -Dtestcase=TestCharFilter
JUnit4 says íHola! Master seed: 592442048D98540B
Your default console's encoding may not display certain unicode glyphs:
windows-1252
Executing 2 suites with 2 JVMs.
Suite: org.apache.lucene.analysis.TestCharFilter
OK 0.04s J1 | TestCharFilter.testCharFilter12 {#0
seed=[592442048D98540B:5E8780464DC70845]}
OK 0.00s J1 | TestCharFilter.testCharFilter12 {#1
seed=[592442048D98540B:EAD13CBA7905C369]}
OK 0.00s J1 | TestCharFilter.testCharFilter11 {#0
seed=[592442048D98540B:4AC9FEB2457325F4]}
OK 0.00s J1 | TestCharFilter.testCharFilter11 {#1
seed=[592442048D98540B:FE9F424E71B1EED8]}
OK 0.00s J1 | TestCharFilter.testCharFilter1 {#0
seed=[592442048D98540B:643276B2D133E783]}
OK 0.00s J1 | TestCharFilter.testCharFilter1 {#1
seed=[592442048D98540B:D064CA4EE5F12CAF]}
OK 0.00s J1 | TestCharFilter.testCharFilter2 {#0
seed=[592442048D98540B:D339FCA65F87D49C]}
OK 0.01s J1 | TestCharFilter.testCharFilter2 {#1
seed=[592442048D98540B:676F405A6B451FB0]}
Completed on J1 in 0.34s, 8 tests
Suite: org.apache.lucene.analysis.TestCharFilter
OK 0.05s J0 | TestCharFilter.testCharFilter12 {#0
seed=[592442048D98540B:5E8780464DC70845]}
OK 0.00s J0 | TestCharFilter.testCharFilter12 {#1
seed=[592442048D98540B:EAD13CBA7905C369]}
OK 0.00s J0 | TestCharFilter.testCharFilter11 {#0
seed=[592442048D98540B:4AC9FEB2457325F4]}
OK 0.00s J0 | TestCharFilter.testCharFilter11 {#1
seed=[592442048D98540B:FE9F424E71B1EED8]}
OK 0.00s J0 | TestCharFilter.testCharFilter1 {#0
seed=[592442048D98540B:643276B2D133E783]}
OK 0.00s J0 | TestCharFilter.testCharFilter1 {#1
seed=[592442048D98540B:D064CA4EE5F12CAF]}
OK 0.00s J0 | TestCharFilter.testCharFilter2 {#0
seed=[592442048D98540B:D339FCA65F87D49C]}
OK 0.00s J0 | TestCharFilter.testCharFilter2 {#1
seed=[592442048D98540B:676F405A6B451FB0]}
Completed on J0 in 0.35s, 8 tests
JVM J0: 0.66 .. 1.49 = 0.82s
JVM J1: 0.66 .. 1.28 = 0.62s
Execution time total: 1.49 sec.
Tests summary: 2 suites, 16 tests
{code}
Note each JVM will start from the same master seed. Each test will work in its
own working directory and JVM though so it can be useful for performing stress
testing of a single suite.
Support running the same test suite multiple times in parallel
--
Key: LUCENE-4360
URL: https://issues.apache.org/jira/browse/LUCENE-4360
Project: Lucene - Core
Issue Type: New Feature
Components: general/test
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
Fix For: 5.0, 4.0
Attachments: quickhack.patch
The current test execution multiplier or:
{code}
-Dtests.iters=N
{code}
generates multiple tests (method executions) under a test class (suite). All
these tests, however, are bound to a single class so they must run
sequentially and on a single JVM (because of how JUnit works -- nesting of
rules, class hooks, etc.).
Mark pointed out that if somebody has a multi-core CPU then it'd be nice to
be able to run a single suite in parallel, possibly in combination with
tests.iters (so that a single test method is executed X times on Y parallel
[jira] [Commented] (LUCENE-4360) Support running the same test suite multiple times in parallel
[
https://issues.apache.org/jira/browse/LUCENE-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448627#comment-13448627
]
Sami Siren commented on LUCENE-4360:
Cool! This is a really nice addition!
Support running the same test suite multiple times in parallel
--
Key: LUCENE-4360
URL: https://issues.apache.org/jira/browse/LUCENE-4360
Project: Lucene - Core
Issue Type: New Feature
Components: general/test
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
Fix For: 5.0, 4.0
Attachments: quickhack.patch
The current test execution multiplier or:
{code}
-Dtests.iters=N
{code}
generates multiple tests (method executions) under a test class (suite). All
these tests, however, are bound to a single class so they must run
sequentially and on a single JVM (because of how JUnit works -- nesting of
rules, class hooks, etc.).
Mark pointed out that if somebody has a multi-core CPU then it'd be nice to
be able to run a single suite in parallel, possibly in combination with
tests.iters (so that a single test method is executed X times on Y parallel
JVMs).
This is surprisingly easy with the randomized runner because it currently
accepts duplicate suite names and will load-balance them in a normal way.
So, if one has Y cores (JVMs) then providing a suite name X times will result
in X executions, balanced across Y JVMs.
The only problem is how to multiply suite names. This can be done in a
number of ways, starting from a custom resource collection wrapper and ending
at a built-in code in the runner itself. I think the custom collection
wrapper approach would be interesting, I'll explore this direction.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4360) Support running the same test suite multiple times in parallel
[
https://issues.apache.org/jira/browse/LUCENE-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448631#comment-13448631
]
Dawid Weiss commented on LUCENE-4360:
-
Thanks! It was Mark's request, actually. I had all the infrastructure ready, I
just needed that duplicating resource collection and this was trivial.
Support running the same test suite multiple times in parallel
--
Key: LUCENE-4360
URL: https://issues.apache.org/jira/browse/LUCENE-4360
Project: Lucene - Core
Issue Type: New Feature
Components: general/test
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
Fix For: 5.0, 4.0
Attachments: quickhack.patch
The current test execution multiplier or:
{code}
-Dtests.iters=N
{code}
generates multiple tests (method executions) under a test class (suite). All
these tests, however, are bound to a single class so they must run
sequentially and on a single JVM (because of how JUnit works -- nesting of
rules, class hooks, etc.).
Mark pointed out that if somebody has a multi-core CPU then it'd be nice to
be able to run a single suite in parallel, possibly in combination with
tests.iters (so that a single test method is executed X times on Y parallel
JVMs).
This is surprisingly easy with the randomized runner because it currently
accepts duplicate suite names and will load-balance them in a normal way.
So, if one has Y cores (JVMs) then providing a suite name X times will result
in X executions, balanced across Y JVMs.
The only problem is how to multiply suite names. This can be done in a
number of ways, starting from a custom resource collection wrapper and ending
at a built-in code in the runner itself. I think the custom collection
wrapper approach would be interesting, I'll explore this direction.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
