Actually I haven't committed the latest transaction deadlock fixes I made to
get the enlistment of slide server transactions into the client's
transaction working. If Mirko is using client side transactions then this
may fix it. And even if he's not it still may fix it :-) But I'm still
waiting on a comitter account from Apache to commit this fix. What I found
particularly interesting about the exception stack that accompanies the
deadlock is that it is in the thread of execution for a commit which is
exactly where this latest problem was. The defect for this problem is:
http://issues.apache.org/bugzilla/show_bug.cgi?id=32250
If you think the problem may be security related then this is the defect I
opened for some other potentially problematic areas in the security impl
that could suffer the same problem that I fixed in 31907. eg.
http://issues.apache.org/bugzilla/show_bug.cgi?id=31908
Though the fact that the stack indicates its occurring during the commit
would make me think it is defect 32250.
Warwick
> -----Original Message-----
> From: Oliver Zeigermann [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, November 23, 2004 5:53 PM
> To: Slide Users Mailing List
> Subject: Re: major deadlock issues (JDBC store with MySQL)
>
>
> I just could reproduce the problem with the new test case
>
> testsuite/junit/xmltestcases/functional/extra/multi-user/getPu
> t/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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
