db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francois Orsini <francois.ors...@gmail.com>
Subject Re: is getAllStackTraces() something we are allowed to call from the server given the recent SecurityManager changes?
Date Tue, 01 Nov 2005 01:49:36 GMT
if permission is granted as part of the security policies I would think so -
it will call the appropriate permission check on the security manager
installed...

from the Javadoc:
-----------------------

If there is a security manager, then the security manager's checkPermission
method is called with a RuntimePermission("getStackTrace") permission as
well as RuntimePermission("modifyThreadGroup") permission to see if it is ok
to get the stack trace of all threads.

Throws:
SecurityException - if a security manager exists and its checkPermission
method doesn't allow getting the stack trace of thread.

On 10/31/05, Mike Matrigali <mikem_app@sbcglobal.net> wrote:
>
>
>
> Francois Orsini (JIRA) wrote:
> > [
> 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 <http://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.
> >
> >
>
>

Mime
View raw message