On 19.09.2011, at 09:36, Ralph Goers wrote: > > On Sep 18, 2011, at 4:56 PM, Joern Huxhorn wrote: > >> >> On 19.09.2011, at 01:29, Ralph Goers wrote: >> >>> >>> On Sep 18, 2011, at 3:01 PM, Joern Huxhorn wrote: >>> >>>> Sorry, I was confused and mixed something up... >>>> >>>> I *planned* to implement a thread-specific sequence number but never did >>>> so. I also considered logging the ThreadGroup-hierarchy but didn't do so, >>>> yet, because of the expected performance impact. >>>> >>>> Which reminds me, completely off-topic, of another idea concerning a >>>> custom Message implementation: >>>> A ThreadDumpMessage that would not get any parameter at all and would >>>> consist of a ThreadDump if it is actually logged, including the >>>> ThreadGroup info etc.. >>>> This would have helped me immensely in the past. Instead, I had to trigger >>>> thread dumps via SIG_QUIT at a random points of execution. >>>> >>>> Such a Message wouldn't be used in production under normal circumstances >>>> but could be enabled in case of strange concurrency issues... >>> >>> I added it, but as I said, I wish I knew how to include the locks. >>> >>> FWIW, I could have used this 2 days ago when we were trying to debug just >>> such a concurrency issue. >>> >> >> I think >> http://download.oracle.com/javase/6/docs/api/java/lang/management/ThreadMXBean.html >> could be what you are looking for. >> Haven't given it a try, yet. > > Unfortunately, all the good lock information was added in 1.6. >
Yes, it is calling for some reflection magic. You'd have to reimplement LockInfo and MonitorInfo, though... Joern. --------------------------------------------------------------------- To unsubscribe, e-mail: log4j-dev-unsubscr...@logging.apache.org For additional commands, e-mail: log4j-dev-h...@logging.apache.org
