db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: [jira] Assigned: (DERBY-666) Enhance derby.locks.deadlockTrace to print stack traces for all threads involved in a deadlock
Date Fri, 10 Mar 2006 18:31:01 GMT
I don't think there is any need to close as won't fix.  It is a 
reasonable feature if anyone ever gets the time or inclination to
fix.  I would reserve wont fix for issues we think actually are a bad idea.

I do think it is a good idea to release the assignment, it is more 
likely someone else might pick up.

Bryan Pendleton (JIRA) wrote:
>      [ http://issues.apache.org/jira/browse/DERBY-666?page=all ]
> Bryan Pendleton reassigned DERBY-666:
> -------------------------------------
>     Assign To:     (was: Bryan Pendleton)
> I'm not actively working on this. There were two problems with the solution I was pursuing:
> 1) It required JDK 1.5 features
> 2) It didn't work in the Network Server case, only in the embedded case
> Mike suggested some other implementations that might have resolved these problems, but
I'm not currently able to spend enough time to pursue these solutions, so I'm unassigning
myself from the issue in the hopes that somebody else might be interested.
> If, after a while, nobody else appears to be interested, I'll close this as Wont-Fix.
>>Enhance derby.locks.deadlockTrace to print stack traces for all threads involved in
a deadlock
>>         Key: DERBY-666
>>         URL: http://issues.apache.org/jira/browse/DERBY-666
>>     Project: Derby
>>        Type: Improvement
>>  Components: Store
>>    Versions:
>>    Reporter: Bryan Pendleton
>>    Priority: Minor
>> Attachments: repro.java
>>I was reading http://www.linux-mag.com/content/view/2134/ (good article, btw!), and
it says:
>>>  The next two properties are needed to diagnose concurrency (locking and deadlock)
>>>     *derby.locks.monitor=true logs all deadlocks that occur in the system.
>>>     *derby.locks.deadlockTrace=true log a stack trace of all threads involved
in lock-related rollbacks.
>>It seems, that, in my environment, the deadlockTrace property does not log a stack
trace of *all* threads involved in the deadlock.
>>Instead, it only logs a stack trace of the *victim* thread involved in the deadlock.
>>I think it would be very useful if the derby.locks.deadlockTrace setting could in
fact log a stack trace of all involved threads.
>>In a posting to derby-dev, Mike Matrigali noted that an earlier implementation of
a similar feature had to be removed because it was too expensive in both time and space, but
he suggested that there might be several possible ways to implement this in an acceptably
efficient manner:
>>>A long time ago there use to be room in each lock to point at a
>>>stack trace for each lock, but that was removed to optimize the size
>>>of the lock data structure which can have many objects outstanding.
>>>And creating and storing the stack for every lock was incredibly slow
>>>and just was not very useful for any very active application.  I think
>>>I was the only one who ever used it.
>>>The plan was sometime to add a per user data structure which could be
>>>filled in when it was about to wait on a lock, which would give most of what is
interesting in a deadlock.
>>>The current deadlockTrace is meant to dump the lock table out to derby.log when
a deadlock is encountered.
>>>I agree getting a dump of all stack traces would be very useful, and
>>>with the later jvm debug interfaces may now be possible - in earlier
>>>JVM's there weren't any java interfaces to do so.  Does anyone have
>>>the code to donate to dump all thread stacks to a buffer?
>>Mike also suggested a manual technique as a workaround; it would be useful to put
this into the documentation somewhere, perhaps on the page which documents derby.locks.deadlockTrace?
Here's Mike's suggestion:
>>>What I do if I can reproduce easily is set try to catch the wait by
>>>hand and then depending on the environment either send the magic
>>>signal or hit ctrl-break in the server window which will send the JVM
>>>specific thread dumps to derby.log.
>>The magic signal, btw, is 'kill -QUIT', at least with Sun JVMs in my experience.

View raw message