serviceability-dev is the mailing list for discussing
java.lang.management APIs.
Getting the stack trace is expensive. ThreadMXBean.getThreadInfos(ids)
does not get the stack trace and locks information and is less expensive.
A typical lightweight monitoring application does BCI and call
Thr
Hi,
(A bit too quick on the send button; need to reallocate if the array is
not big enough).
I was just pointing out there already is access to the information you
are requesting
without adding a new API.
ThreadGroup.activeCount() provides the number of active threads.
Of course, threads co
Hi,
I was just pointing out there already is access to the information you
are requesting
without adding a new API.
ThreadGroup.activeCount() provides the number of active threads.
Of course, threads come and go asynchronously.
Yes, the Thread array has to be allocated by the caller and may b
Hi Roger,
> You might use ThreadGroup.enumerate(Thread[], recurse) after walking up
> the parents to the root ThreadGroup.
Thanks. Isn't this method silently dropping threads in case it can't hold what
you specified upfront as an array? Apart from that: Would it be a candidate for
live-monitori
Hi Christoph,
You might use ThreadGroup.enumerate(Thread[], recurse) after walking up
the parents to the root ThreadGroup.
$.02, Roger
On 10/27/2017 11:23 AM, Christoph Dreis wrote:
Hey,
I don't know if this is the correct mailing list for this specific topic.
Please let me know in case it
Hey,
I don't know if this is the correct mailing list for this specific topic.
Please let me know in case it isn't.
I'm currently trying to improve the live-monitoring of an application and
would like to get a simple overview of how many threads are in state
RUNNABLE, BLOCKED and so on.
For this
