I just could reproduce the problem with the new test case testsuite/junit/xmltestcases/functional/extra/multi-user/getPut/getPutFolder.xml
and it also exists in the latest sources. It has got something to do with security and seems to be what Warwick already identified in http://issues.apache.org/bugzilla/show_bug.cgi?id=31907 which we thought was solved, but apparently is not. I will have a look at this ASAP. Oliver On Fri, 19 Nov 2004 15:59:22 -0800, Mirko Froehlich <[EMAIL PROTECTED]> wrote: > I did some basic JMeter concurrency testing to validate if Slide meets > our concurrency requirements. Unfortunately, the results were not very > promising. > > As I mentioned, we are planning on using Slide as a repository for > application data. We expect to have a few hundred concurrent users of > our application who would be reading from as well as (although less > frequently) writing to the repository. In case it matters, most of the > read and write access would be to a dedicated folder per user, rather > than a shared folder. I realize that this use case is probably very > different from the way most people use Slide, which I assume is mostly > for web publishing. > > My test mainly consists of a JSP page that uses the WebDAV client > library to access a folder, iterate over the 10 contained documents and > retrieve their contents (about 2k each), and create a new document, > retrieve it, and then delete it. I have 100 different folders, all > populated with the same 10 documents. My JMeter test consists of 5 > concurrent threads that each access a different one of the 100 folders, > with 800ms between requests. After only a few seconds, Slide completely > deadlocks with various exceptions to that effect in the Tomcat logs. > > I have tried increasing my JDBC store's MySQL connection pool from 10 to > 30, without any improvements. It seems like creating documents is > responsible for the deadlocks, as the test behaved fine when it was > limited to read-only access. > > Can anyone think of a way for me to tune the system in order to prevent > the deadlocks from occurring? > > -Mirko > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
