Chris, you seem to have shown only the first couple of lines of each stack trace. Was it that that was all there was? (I’d think not, but if so, where did you get them from, in FR?)
If there was more, please do share it. You often need to see down 10-15 lines of a stack trace to really see what “line of code” (if any) that the stack trace indicates the request was running.
Also, is this in fact the stack traces from running requests (shown in the request activity page)? Or was it something from the resources>thread dump? That’s not as useful, as it’s ALL threads in the JVM, not only those really running requests.
Hope that helps.
/charlie
--
You received this message because you are subscribed to the Google Groups "FusionReactor" group.
To unsubscribe from this group and stop receiving emails from it, send an email to fusionreacto...@googlegroups.com.
To post to this group, send email to fusion...@googlegroups.com.
Visit this group at http://groups.google.com/group/fusionreactor.
For more options, visit https://groups.google.com/d/optout.
Let me add to David’s great reply by adding a more generic point on all this: it’s not generally as valuable to do that “strack trace all” on that page if you want to know why certain threads are slow.
Instead, you’d generally be better off stack tracing them individually, so you can know what stack trace goes with what request.
With the below, you (and we) have no idea which requests are slow or may be fast—remember: a stack trace if just a point in time display of what the JVM says a given thread is doing at that moment. It conveys no info on how long it had been doing that one thing, let alone the duration of the request itself.
So from the FR running requests interface, you can easily see the duration of each request, and even sort them by longest-running, and then then pick a slow one to stack trace it, and see what it says it’s doing (and refresh it, to see if it’s still doing that seconds later). Then you can compare other long-running requests. That is more effective than trying to make sense of just a thread dump of all running request threads (or worse, the dump of all threads in the resource>all threads page, though there are indeed times when you may want to use that to see what threads OTHER than those for CF requests are doing, including cfthread threads.)
Finally, if one gets the FR CP alert email, that gives the dual benefit of a) providing this stack trace of request threads by email (when you’re not looking at FR, and when there’s some problem state like too many requests running) and b) it lists at the top of the email the running requests and their duration, so you can easily do the same sort of process above (find a long running request, find its request id on the left of the running request list, go to the request details at the bottom of the email to find that request, get its thread id, and find its one stack trace in the email.)
Of course, again, it’s far easier just to stack trace a single long-running request in the FR interface, if you can be (or get) online when there is one to investigate.
Hope that helps (you or others reading along).
/charlie
--