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 ? 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 >> >> > >
