From: Nate M. <na...@ve...> - 2006-11-24 15:08:40
|
I like the idea of having a back ground listener of some sort to catch in-process information on other (potentially stuck or bogged down) threads. Should this be made generic though to have a common background thread as a "catcher's mitt" for information generated by any reporter? -N Serge Knystautas wrote: > I've written docs for: > 1. testing a webapp for concurrency issues > 2. diagnosing a webapp that is slow only in production > 3. diagnosing a webapp that gets intermittently briefly freezes > 4. seeing what requests are stuck in my webapp > > Writing up the last one got me thinking about an alternate approach to > that problem, especially if the issues are intermittent. > > The active connection filter is very good to help you see what is going > on mid-request. The profiling filter is very good to help you log > relevant information on an intermittent problem. > > I was thinking of writing a mixture of the two... a profiling filter > that would log information mid-request if it exceeded a threshold. Each > request would start a timer and if after (for example) 5 seconds the > request is still going, a separate thread would log the information you > want. > > The advantage of this is that you get complete information of what the > request is doing at the time, rather than just knowing a request was slow. > |