[ http://issues.apache.org/jira/browse/DERBY-666?page=comments#action_12356460 ]
Francois Orsini commented on DERBY-666: --------------------------------------- The new J2SE 5.0 has some new API to dump individual or all threads' stracktrace running in a JVM - There is a new notion of StackTraceElement object which represent a stack frame and can be output'ed as a String.... So you can get all frames of a particular thread's stack dump as well as for all threads in the JVM. http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#getStackTrace() http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Thread.html#getAllStackTraces() http://java.sun.com/j2se/1.5.0/docs/api/java/lang/StackTraceElement.html Thread(s) stack dumps can also be performed on the command line using 'jstack' (1.5) utility to dump all the JVM's thread stack traces given a JVM pid. http://java.sun.com/j2se/1.5.0/docs/tooldocs/share/jstack.html fyi. > 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