On 1 Oct 2010, at 07:23, Felix Meschberger wrote: > Hi, > > On 30.09.2010 19:10, Ian Boston wrote: >> >> On 30 Sep 2010, at 17:16, Ian Boston wrote: >> >>> >>> On 30 Sep 2010, at 16:50, Ian Boston wrote: >>> >>>> Looking in the code most of those methods are synchronised, which feels >>>> wrong as it will make the server single threaded to read, write I can >>>> understand, but not read. I thought Jackrabbit was multithreaded on read? >>>> Do you know the reasoning behind this ? >>> >>> Hang on, isn't the ItemManagerImpl bound to session ? (there is a session >>> property there) >> >> Wearing sack cloth and ashes at the moment, if I take Sling OOTB with no >> modifications YourKit reports no thread synchronization issues associated >> with request processing. >> >> The largest cause of blocking on a monitor is in the classloader itself, >> with 50 threads running for the past 20 minutes flat out I am seeing 76K >> instances of a block in the classloader all from a Class.forName(...) inside >> the HttpServlet presumably syncing on the classloader. > > Class.forName() should probably not be used. This is known for behaving > badly in OSGi context. See BJ Hargrave's blog searching for > "classloading" entries, particularly probably > http://blog.bjhargrave.com/2007/09/classforname-caches-defined-class-in.html. > > Is this in your code or Sling ?
Inside the javax.servlet.HttpServlet code, probably part of Jetty/PAX, AFAICT, I am not certain I believe the stack trace is complete from YourKit (might have holes in it) > > Regards > Felix > >> >> ItemManager has blocked, but only 161 times, >> >> So my problems are caused by something I have done outside Sling in my own >> code, almost certainly related to sharing a Session between threads. >> Sorry for causing alarm (if I did). >> >> Ian >> >>> >>> Which means that a session is being shared between threads, making it block >>> threads ? >>> Does that make sense ? >>> Ian >>> >>> >> >>
