[
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
