[
https://issues.apache.org/jira/browse/OAK-3765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Reschke updated OAK-3765:
--------------------------------
Fix Version/s: 1.0.26
> Parallelized test runner does not wait for test completion
> ----------------------------------------------------------
>
> Key: OAK-3765
> URL: https://issues.apache.org/jira/browse/OAK-3765
> Project: Jackrabbit Oak
> Issue Type: Bug
> Components: jcr
> Affects Versions: 1.2.9, 1.0.25, 1.3.12
> Reporter: Julian Reschke
> Assignee: Julian Reschke
> Priority: Minor
> Fix For: 1.3.13, 1.0.26, 1.2.10
>
>
> As analyzed by [~tomek.rekawek] in OAK-3743:
> Quote from the mailing list:
> {quote}
> On a “slow” machine, in the surefire logs for the AtomicCounterTest (which
> takes 63 sec while it should 3 sec), following test case appears:
> {noformat}
> <testcase time="2.261"
> classname="org.apache.jackrabbit.oak.jcr.RepositoryTest"
> name="importWithRegisteredType[RDBDocumentStore on
> jdbc:derby:oaktest\;create=true]"/>
> {noformat}
> It’s a test case from a completely different class. I downloaded all the
> surefire reports and it seems that the test cases from the RepositoryTest
> class are spread across CRUDTest, ConflictResolutionTest, ObservationTest and
> others. On the “fast” machines the problem doesn’t exist and all
> RepositoryTest methods are invoked within their own test case.
> {quote}
> It seems that this behaviour is caused by the
> {{org.apache.jackrabbit.oak.jcr.Parallelized}} runner, used in the
> {{AbstractRepositoryTest}}. JUnit submits a {{Runnable}} wrapping all the
> test cases from a single class to the {{ThreadPoolScheduler#schedule()}}
> method and then invokes {{#finished()}}. The latter waits for 10 minutes
> until the submitted {{Runnable}} is done. However, in case of the
> {{RepositoryTest}}, all tests takes more than 10 minutes. The {{finished()}}
> method simply returns, JUnit invokes another test class, while the
> {{RepositoryTest}} is still running in the background.
> In the attached patch, the {{finished()}} method waits indefinitely until all
> tests are done. It may seem a bit radical, but after all it's the same
> behaviour as in single-thread JUnit runner, which doesn't have internal
> timeout as well.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
