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.