Hi, On 01.10.2010 08:51, Ian Boston wrote: > > 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)
Wow! I know see ... They have the javax.servlet.HttpServlet.class mechanism --- and we have it, too, in the SlingAllMethodsServlet .... Should we (for the SlingAllMethodsServlet) do something about it ? Regards Felix > > > >> >> 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 >>>> >>>> >>> >>> > >
