[
https://issues.apache.org/jira/browse/CALCITE-3965?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17097071#comment-17097071
]
Laurent Goujon commented on CALCITE-3965:
-----------------------------------------
This is somehow related to CALCITE-3517, but after a look at the code,
{{DiffRepository#expand}} do not do write to disk, and the main issue is really
contention around the instance lock. The method is synchronized, but most
operations look thread-safe. They are some calls to get and set (which are also
synchronized), but it doesn't look like they need to done "atomically".
Removing {{synchronized}} on the expand() method results in the build
completing in 2min30s with no test failures.
> Excessive time waiting on DiffRepository lock
> ---------------------------------------------
>
> Key: CALCITE-3965
> URL: https://issues.apache.org/jira/browse/CALCITE-3965
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: Laurent Goujon
> Assignee: Laurent Goujon
> Priority: Major
>
> When running the whole test suite from commandline, tests are parallelized
> and gradle/junit tries to use as many cores as possible (16 on my machine).
> But the tests take a very long time, approximatevely 90minutes on my machine,
> and several of them failed because they took too long to complete.
> Using jstack to look at the threads state while tests are running show that
> most of them are waiting on {{DiffRepository}} methods
> ({{DiffRepository#expand}} in most cases) while one of the thread obtained
> the lock (and is usually flushing data on disk).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
