Inside security code I have found an additional request which was done outside of the transaction which explains why the locking in the WebDAV layer failed: different transactions inside the same requests where blocking each other. Now everything should be done in one and a single request.
The new testcase passes now, Mirko, would you do us all the favor and check out the latest sources either from release or head branch and see if your test case succeeds as well? If not please supply stack traces and hints how to use your JMeter tests. Thanks, Oliver On Wed, 24 Nov 2004 00:53:01 +0100, Oliver Zeigermann <[EMAIL PROTECTED]> wrote: > 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]
