jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexandru Popescu" <the.mindstorm.mailingl...@gmail.com>
Subject Re: Working with JCR in highly concurrent applications
Date Wed, 20 Sep 2006 18:31:01 GMT
On 9/20/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com> wrote:
> 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)
>

I think this was caused by an OutOfMemory exception. By configuring
the JVM to use 256M it seems I am getting some similar results.

But my question is: why is this happening (and why would it be normal)?

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


> ./alex
> --
> .w( the_mindstorm )p.
>
> > BR,
> >
> > Jukka Zitting
> >
> > --
> > Yukatan - http://yukatan.fi/ - info@yukatan.fi
> > Software craftsmanship, JCR consulting, and Java development
> >
>

Mime
View raw message