You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-dev@jackrabbit.apache.org by Davide Giannella <gi...@gmail.com> on 2014/04/10 20:06:44 UTC
OAK-1717 reproducing the issue
Hello team,
working on OAK-1717[0] and trying to reproduce the issue in a systematic
way for the fix to come. So far I was not able to reproduce it. See [1]
for the initial code.
[0] https://issues.apache.org/jira/browse/OAK-1717
[1] http://goo.gl/Pt5lfN
By looking at log statements printed during the tests I can see the JVM
is executing a quite bunch of commits per thread reducing the
concurrency. Or it could be SLF4J playing tricks.
I have the following ideas around it
A) you identify something wrong in the code. Hooray! :)
B) Try using a fixed ThreadPool[2] hoping it will increase the
concurrency level
C) go into a complex implementation where using wait() and notify() I
control the concurrency forcing a "swap" of threads every X nodes.
D) Increase the number of nodes/threads and see if it does the trick.
E) reducing the `COUNT` part committing more frequently (currently 10).
WDYT?
D.
(2)
http://docs.oracle.com/javase/6/docs/api/java/util/concurrent/Executors.html#newFixedThreadPool%28int%29
Re: OAK-1717 reproducing the issue
Posted by Davide Giannella <gi...@gmail.com>.
On 10/04/2014 19:06, Davide Giannella wrote:
> Hello team,
>
> working on OAK-1717[0] and trying to reproduce the issue in a systematic
> way for the fix to come. So far I was not able to reproduce it...
for the sake of records I managed to reproduce it 3 times in a raw with
the following settings
10:05:47.207 [main] DEBUG
o.a.j.o.j.OrderedIndexConcurrentAddNodesClusterIT - Adding a total of
70000 nodes evenly spread across cluster. Loop: 2800, Count: 5, Cluster
nodes: 5
D.