Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
DomainKey-Status: good
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=UI8/rtBsOKzO7Dqmy5GvJXq6iekdVanD/x/kxWn4pl/91jEbzkZPh14XHj8vaKyqbY+HcjfR3DN8jhEvKLANinzYn/bAIitBtQa0JzVG5vLV9p4eTaubJm2FX4/h4RSsLhTWKp800YPeQWZlQtyc8FwYPhFK6U5Z5P6YJomxeU8=
Message-ID: <c6f400460609201107y6f0429c0if198ac6a661fd815@mail.gmail.com>
Date: Wed, 20 Sep 2006 21:07:39 +0300
From: "Alexandru Popescu" <the.mindstorm.mailinglist@gmail.com>
To: users@jackrabbit.apache.org
Subject: Re: Working with JCR in highly concurrent applications
In-Reply-To: <510143ac0609201036l1293d5c1w4ad4608e3232804d@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <c6f400460609200245u511e55b8he7e4edf04620367c@mail.gmail.com>
	 <510143ac0609200912m4e5dddcbm423a22e272b2e227@mail.gmail.com>
	 <c6f400460609200920i60b8f21fjd67f229ad27d0d16@mail.gmail.com>
	 <510143ac0609201036l1293d5c1w4ad4608e3232804d@mail.gmail.com>

On 9/20/06, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> Hi,
>
> On 9/20/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com> wrote:
> > I will try to trim down my functional test. Still, I am missing the
> > repository creation/load fixture, so I will highly appreciate if you
> > can share this one (and I don't have to write it my own :-( ).
>
> You can check my simple test case at
> http://people.apache.org/~jukka/2006/ConcurrentTest.java. You can
> compile and run it as follows if you have Jackrabbit core and all the
> dependencies in your classpath.
>
>     $ javac ConcurrentTest.java
>     $ java ConcurrentTest
>
> The test sets up a simple content structure of about 10k nodes, each
> containing a single "test" property. The test threads count the wall
> clock time it takes the "test" property of a thousand randomly
> selected nodes. Special staging is used to ensure that the test
> results are not affected by the startup or shutdown periods of the
> threads. I figure a test framework like TestNG would take care of all
> that automatically...
>
> Below is a verbatim copy of the output of a representative test run on
> my laptop (Windows XP, Java 1.4, Pentium M 750, 1,86 GHz, 1GB DDR2
> 533MHz RAM, 2x100GB SATA 5400rpm HDD):
>
> Threads,Count,Min,Sum,Max
> 10,235,765,294828,3984
> 20,218,2109,619515,4765
> 30,185,3750,848800,6000
> 40,200,5015,1251299,7500
> 50,199,5969,1658329,10296
> 60,182,5828,1826373,11234
> 70,158,7782,1810896,12468
> 80,160,9015,2185606,14469
> 90,179,8563,2766261,16594
> 100,105,10672,1891184,18750
>
> See http://people.apache.org/~jukka/2006/concurrent.png for a graph on
> how the minimum, average, and maximum wall clock time for reading 1000
> properties grows by the number of concurrent threads. At least these
> results are very linear as expected.
>

Weird, but after everything here is what I am seeing (with jackrabbit 1.0):

Exception in thread "main" javax.jcr.ItemNotFoundException:
cafebabe-cafe-babe-cafe-babecafebabe
	at org.apache.jackrabbit.core.ItemManager.createItemInstance(ItemManager.java:464)
	at org.apache.jackrabbit.core.ItemManager.getItem(ItemManager.java:320)
	at org.apache.jackrabbit.core.ItemImpl.restoreTransientItems(ItemImpl.java:708)
	at org.apache.jackrabbit.core.ItemImpl.save(ItemImpl.java:1208)
	at org.apache.jackrabbit.core.SessionImpl.save(SessionImpl.java:805)
	at org.noco.jackrabbit.perf.ConcurrentTest.main(ConcurrentTest.java:125)

./alex
--
.w( the_mindstorm )p.

> BR,
>
> Jukka Zitting
>
> --
> Yukatan - http://yukatan.fi/ - info@yukatan.fi
> Software craftsmanship, JCR consulting, and Java development
>