hey all, any thoughts on this problem?
the weird thing is, each of these 10 threads is
reading/writing different nodes with different parents, eg
/test1/testfile.txt
/test2/testfile.txt
...
/test10/testfile.txt
so it's baffling me why anything would be sharing locks for
operations on different nodes.
i notice in the javadocs for WriterPreferenceReadWriteLock
that a deadlock can occur if a thread tries to re-acquire a
read lock that it already holds, if there are also waiting
writers. i also see in the thread dump that multiple threads
are waiting to both read and write.
i wonder if maybe some thread called two read methods on a
node without the lock having been released after the first
one. is that possible?
or do the SISM locks apply to all operations in a workspace?
can somebody explain the locking behavior of SISM?
Brian Moseley wrote:
Brian Moseley wrote:
while running a very simple test against my caldav server (client
program spawns 10 threads, each of which does a single PUT request), i
ran into what looks like a deadlock issue. all of the requests time
out without receiving any bytes.
the thread dump is at <http://people.apache.org/~bcm/deadlock.txt>.
there are in fact 10 http threads waiting to lock or waiting on what
appear to be 3 different locks.
i have never had to debug a deadlock problem, so first i want to make
sure that i'm diagnosing it properly :) if so, what's the next step?
what's the best way to figure out what's going on?
thanks!
for what it's worth, i'm using DerbyPersistenceManager, as per
<http://svn.osafoundation.org/server/cosmo/branches/0.2/src/main/resources/server/repository.xml>.
