jmx-dev RFR: 8020875 java/lang/management/ThreadMXBean/ResetPeakThreadCount.java fails intermittently

[shanliang]

Just to be a test, after terminated 8 threads and checked their states 
by calling Thread.join() (must be same to Thread.getState()), DO sleep 
sometime and then call mbean.getThreadCount(), if it reports a right 
number, then we may need to verify mbean.getThreadCount() method.

Shanliang

Jaroslav Bachorik wrote:
> On Wed 24 Jul 2013 08:20:56 AM CEST, Mandy Chung wrote:
>   
>> On 7/24/2013 2:09 PM, Daniel Fuchs wrote:
>>     
>>> On 7/24/13 8:01 AM, Mandy Chung wrote:
>>>       
>>>> I am catching up on this thread....
>>>>
>>>> The thread count counts Java threads that are not hidden.  I believe
>>>> all VM internal threads are hidden from external API. This test runs
>>>> in othervm mode and AFAICT the thread count is expected to be
>>>> deterministic.  I don't expect the VM will start and terminate any
>>>> thread any time.
>>>>
>>>> I agree with David that we should diagnose why there is one
>>>> additional thread started before the reset.  If it is the
>>>> LogManager$Cleaner thread, like David said, the VM is shutting down
>>>> while the test is still running which doesn't quite make sense.
>>>>         
>>> I think that Shanliang's suspicion that a thread might be still alive
>>> if unscheduled just after having
>>> called its barrier.signal() is a very good suggestion. I would advise
>>> calling thread.join() on all threads in
>>> terminateThreads, just to make sure they are all really dead and not
>>> in some comatose state...
>>> If Shanliang is right then the test would be failing because some of
>>> the threads we think are dead are
>>> not actually dead yet - and not because of some new VM thread that
>>> nobody can see :-)
>>>       
>> Thanks for pointing that out.
>>
>> I agree that the test should be changed to call Thread.join(). There
>> may be other java.lang.management tests that should also be fixed to
>> call Thread.join.
>>     
>
> I've tried using Thread.join() but I am still getting the thread count 
> discrepancy.
>
> Specifically:
> 1. 10 worker threads have been successfully started - 
> mben.getThreadCount() reports 14 and Thread.getAllStackTraces() returns 
> 14 items
> ---
> Thread: Thread[Signal Dispatcher,9,system]
> Thread: Thread[worker-5,5,main]
> Thread: Thread[worker-7,5,main]
> Thread: Thread[worker-9,5,main]
> Thread: Thread[worker-12,5,main]
> Thread: Thread[worker-11,5,main]
> Thread: Thread[Reference Handler,10,system]
> Thread: Thread[main,5,main]
> Thread: Thread[worker-10,5,main]
> Thread: Thread[worker-8,5,main]
> Thread: Thread[Finalizer,8,system]
> Thread: Thread[worker-6,5,main]
> Thread: Thread[worker-13,5,main]
> Thread: Thread[worker-4,5,main]
> ---
> 2. Terminating 8 threads
> 3. After the threads have been terminated (waiting on Thread.join() for 
> them to die) - mbean.getThreadCount() reports 7 while 
> Thread.getAllStackTraces() returns only 6 items
> ---
> Thread: Thread[Signal Dispatcher,9,system]
> Thread: Thread[Finalizer,8,system]
> Thread: Thread[worker-12,5,main]
> Thread: Thread[Reference Handler,10,system]
> Thread: Thread[main,5,main]
> Thread: Thread[worker-13,5,main]
> ---
>
> This would almost point to mbean.getThreadCount() reporting a stale 
> value. Is that possible?
>
> -JB-
>
>   
>> Mandy
>>     
>
>
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/jmx-dev/attachments/20130724/6c50234a/attachment.html