Hi, Thanks a bunch for your reply. I learned yet another new thing :)
I think my problem lied in my program's usage of sessions accessing Jackrabbit. I had a single session processing all the requests, but after reading a lot online, special thanks to this page: http://n4.nabble.com/Threads-in-jackrabbit-application-td520034.html#a520034 I learned that each thread should have its own session. I made the changes and the performance shot up very significantly. I used to be able to add/update/query Jackrabbit with about 300-500 requests (over 5 minutes) and it would come to a halt. Now I was able to perform 7,200 operations (over about 40 minutes) and it was still up and running (no glitches felt). I still need to run longer and harsher tests on the application but I feel a lot more confident in its performance. Thanks again for your help, Rokham Marcel Reutegger wrote: > > Hi, > > On Thu, Nov 12, 2009 at 04:27, rokham <somebodyik...@gmail.com> wrote: >> Note that all these requests are WRITING to Jackrabbit. I also just >> came >> across this article, claiming that "Jackrabbit isn’t actually able to >> handle >> concurrent queries well". > > do you mean JCR queries or SQL queries to the underlying database? > > jackrabbit is able to handle and execute concurrent JCR queries. > > however, writes to the underlying database are currently serialized. > > regards > marcel > > -- View this message in context: http://n4.nabble.com/Tomcat-stops-responding-due-to-too-many-requests-using-Jackrabbit-tp605488p620747.html Sent from the Jackrabbit - Dev mailing list archive at Nabble.com.