db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-666) Enhance derby.locks.deadlockTrace to print stack traces for all threads involved in a deadlock
Date Tue, 01 Nov 2005 18:09:57 GMT
    [ http://issues.apache.org/jira/browse/DERBY-666?page=comments#action_12356519 ] 

Mike Matrigali commented on DERBY-666:
--------------------------------------

Here are some pointers for anyone interested in picking up this project.  It seems like a
good 1st project for someone interested in doing derby development:

1) use the interfaces as described by Francois's comments above.
2) The code must be within a securiity block,  I believe Dan will be providing some more info
on this area soon.
3) See posting by Dan on list under subject "Re: is getAllStackTraces() something we are allowed
to call from the server given the recent SecurityManager changes?"
4) I would sugest coding a try/catch block around the security exception and not fail the
operation if we get a security exception.
     In this case add the extra information to the lock error message if you can, otherwise
let the system continue.  You might
     print a message saying stack traces not available due to not enough permission granted
by security manager.
5) The code wants to go in opensource/java/engine/org/apache/derby/impl/services/locks/Deadlock.java,
in the buildException() routine.

Lars posted some code, it would need to get the traces into a string buffer:
The following ought to do it:    

public static void dumpTraces(PrintStream out) {
        Map<Thread,StackTraceElement[]> threadtraces = 
		Thread.getAllStackTraces();
        for (Map.Entry<Thread,StackTraceElement[]> threadtrace 
                : threadtraces.entrySet()) {
            out.println(threadtrace.getKey().getName());
            StackTraceElement[] traces = threadtrace.getValue();
            for (StackTraceElement trace : traces) {
                out.println(trace);
            }
        }
    }

The locktable could possibly remember which thread corresponds to each
transaction and just dump those.

Mapping threads to transactions is hard as it is possible for the thread of a transaction
to change with every
jdbc interaction if a connection pool is involved.  The interesting stack traces are the ones
that are waiting and those transactions could note their thread id before waiting.

> 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: 10.1.1.0
>     Reporter: Bryan Pendleton
>     Priority: Minor

>
> 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)
problems.
> >
> >      *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.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message