Question about java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Question about java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync

Gang Yan

 

Hi all

 

I hava a bug about Managed servers are taking too long to come up, it took 2-3hrs to come up.is on JDK 1.7.131.

 

I check server log and thread dump.This thread is waiting for some one to release something:

 

"Policy scanning timer" daemon prio=10 tid=0x00007fa3e4a7f800 nid=0x3be0 waiting on condition [0x00007fa440e81000]

   java.lang.Thread.State: WAITING (parking)

    at sun.misc.Unsafe.park(Native Method)

    - parking to wait for  <0x00000007c3cb4dd8> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)

    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)

    at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)

    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)

    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)

    at java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:945)

    at oracle.security.jps.az.common.util.JpsLock.lock(JpsLock.java:90)

    at oracle.security.jps.az.internal.common.scanner.PolicyChangeScanner.scanApplicationPolicies(PolicyChangeScanner.java:439)

    at oracle.security.jps.az.internal.common.scanner.PolicyChangeScanner.scan(PolicyChangeScanner.java:273)

    at oracle.security.jps.az.internal.common.scanner.PolicyChangeScanner$ScanTask.run(PolicyChangeScanner.java:234)

    at oracle.security.jps.az.internal.common.scanner.PolicyChangeScannerExecutor$SchedulerTask.run(PolicyChangeScannerExecutor.java:69)

    at java.util.TimerThread.mainLoop(Timer.java:555)

    at java.util.TimerThread.run(Timer.java:505)

 

It is also waiting for the lock: java.lang.Thread.State: TIMED_WAITING

 

"Policy scanning timer" daemon prio=10 tid=0x00007fa3e4a7f800 nid=0x3be0 in Object.wait() [0x00007fa440e81000]

   java.lang.Thread.State: TIMED_WAITING (on object monitor)

    at java.lang.Object.wait(Native Method)

    at java.util.TimerThread.mainLoop(Timer.java:552)

    - locked <0x00000007c448e018> (a java.util.TaskQueue)

    at java.util.TimerThread.run(Timer.java:505)

 

how to find out who hold on this lock ?

 

Thanks!

 

 

 

 

 

 


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question about java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync

Josh Humphries-2
IIUC, the built in lock tracking only tracks exclusive holders of a ReadWriteLock (e.g. write lock), and not shared holders (e.g. read lock). So the issue here looks to be that the read lock was acquired (perhaps by multiple threads), and isn't being release. So the attempt to acquire a write lock is wedged. Unfortunately, the annotations in the stack trace won't show which threads have the read lock.

If you don't think there are any such tasks (e.g. threads acquiring the read lock and then never releasing it), the problem could be barging. The stack trace shows you are using an unfair lock (which is the default, for performance reasons). With an unfair read lock, an attempt to acquire a read lock will succeed if it is already read-locked -- even if there is a writer, waiting in line for the lock (in other words, the reader "barges" in front of the writer). So if the readers never "quiesce" (e.g. no point in time where the number of readers reaches zero), the writer will be starved. This could be solved by using a fair lock.



----
Josh Humphries
[hidden email]

On Fri, Mar 24, 2017 at 12:22 PM, Gang Yan <[hidden email]> wrote:

 

Hi all

 

I hava a bug about Managed servers are taking too long to come up, it took 2-3hrs to come up.is on JDK 1.7.131.

 

I check server log and thread dump.This thread is waiting for some one to release something:

 

"Policy scanning timer" daemon prio=10 tid=0x00007fa3e4a7f800 nid=0x3be0 waiting on condition [0x00007fa440e81000]

   java.lang.Thread.State: WAITING (parking)

    at sun.misc.Unsafe.park(Native Method)

    - parking to wait for  <0x00000007c3cb4dd8> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)

    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)

    at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)

    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)

    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)

    at java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:945)

    at oracle.security.jps.az.common.util.JpsLock.lock(JpsLock.java:90)

    at oracle.security.jps.az.internal.common.scanner.PolicyChangeScanner.scanApplicationPolicies(PolicyChangeScanner.java:439)

    at oracle.security.jps.az.internal.common.scanner.PolicyChangeScanner.scan(PolicyChangeScanner.java:273)

    at oracle.security.jps.az.internal.common.scanner.PolicyChangeScanner$ScanTask.run(PolicyChangeScanner.java:234)

    at oracle.security.jps.az.internal.common.scanner.PolicyChangeScannerExecutor$SchedulerTask.run(PolicyChangeScannerExecutor.java:69)

    at java.util.TimerThread.mainLoop(Timer.java:555)

    at java.util.TimerThread.run(Timer.java:505)

 

It is also waiting for the lock: java.lang.Thread.State: TIMED_WAITING

 

"Policy scanning timer" daemon prio=10 tid=0x00007fa3e4a7f800 nid=0x3be0 in Object.wait() [0x00007fa440e81000]

   java.lang.Thread.State: TIMED_WAITING (on object monitor)

    at java.lang.Object.wait(Native Method)

    at java.util.TimerThread.mainLoop(Timer.java:552)

    - locked <0x00000007c448e018> (a java.util.TaskQueue)

    at java.util.TimerThread.run(Timer.java:505)

 

how to find out who hold on this lock ?

 

Thanks!

 

 

 

 

 

 


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question about java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync

David Holmes-6
In reply to this post by Gang Yan

The TIMED_WAITING section is not a thread waiting for a “lock”. It is the TimerThread doing a timed Object.wait() to wait until the next task is scheduled to be released.

 

David

 

From: Concurrency-interest [mailto:[hidden email]] On Behalf Of Gang Yan
Sent: Saturday, March 25, 2017 2:22 AM
To: [hidden email]
Subject: [concurrency-interest] Question about java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync

 

 

Hi all

 

I hava a bug about Managed servers are taking too long to come up, it took 2-3hrs to come up.is on JDK 1.7.131.

 

I check server log and thread dump.This thread is waiting for some one to release something:

 

"Policy scanning timer" daemon prio=10 tid=0x00007fa3e4a7f800 nid=0x3be0 waiting on condition [0x00007fa440e81000]

   java.lang.Thread.State: WAITING (parking)

    at sun.misc.Unsafe.park(Native Method)

    - parking to wait for  <0x00000007c3cb4dd8> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)

    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)

    at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)

    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)

    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)

    at java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:945)

    at oracle.security.jps.az.common.util.JpsLock.lock(JpsLock.java:90)

    at oracle.security.jps.az.internal.common.scanner.PolicyChangeScanner.scanApplicationPolicies(PolicyChangeScanner.java:439)

    at oracle.security.jps.az.internal.common.scanner.PolicyChangeScanner.scan(PolicyChangeScanner.java:273)

    at oracle.security.jps.az.internal.common.scanner.PolicyChangeScanner$ScanTask.run(PolicyChangeScanner.java:234)

    at oracle.security.jps.az.internal.common.scanner.PolicyChangeScannerExecutor$SchedulerTask.run(PolicyChangeScannerExecutor.java:69)

    at java.util.TimerThread.mainLoop(Timer.java:555)

    at java.util.TimerThread.run(Timer.java:505)

 

It is also waiting for the lock: java.lang.Thread.State: TIMED_WAITING

 

"Policy scanning timer" daemon prio=10 tid=0x00007fa3e4a7f800 nid=0x3be0 in Object.wait() [0x00007fa440e81000]

   java.lang.Thread.State: TIMED_WAITING (on object monitor)

    at java.lang.Object.wait(Native Method)

    at java.util.TimerThread.mainLoop(Timer.java:552)

    - locked <0x00000007c448e018> (a java.util.TaskQueue)

    at java.util.TimerThread.run(Timer.java:505)

 

how to find out who hold on this lock ?

 

Thanks!

 

 

 

 

 

 


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question about java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync

Nathan & Ila Reynolds
In reply to this post by Josh Humphries-2

Along these lines, I recently discovered a situation where ThreadMXBean fails to detect ReentrantReadWriteLock deadlock.  It is very easy to reproduce.  I would assume that fixing this problem would make it easy to see your problem as well.

http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8176204

 

-Nathan

 

From: Concurrency-interest [mailto:[hidden email]] On Behalf Of Josh Humphries
Sent: Friday, March 24, 2017 5:21 PM
To: Gang Yan <[hidden email]>
Cc: concurrency-interest <[hidden email]>
Subject: Re: [concurrency-interest] Question about java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync

 

IIUC, the built in lock tracking only tracks exclusive holders of a ReadWriteLock (e.g. write lock), and not shared holders (e.g. read lock). So the issue here looks to be that the read lock was acquired (perhaps by multiple threads), and isn't being release. So the attempt to acquire a write lock is wedged. Unfortunately, the annotations in the stack trace won't show which threads have the read lock.

 

If you don't think there are any such tasks (e.g. threads acquiring the read lock and then never releasing it), the problem could be barging. The stack trace shows you are using an unfair lock (which is the default, for performance reasons). With an unfair read lock, an attempt to acquire a read lock will succeed if it is already read-locked -- even if there is a writer, waiting in line for the lock (in other words, the reader "barges" in front of the writer). So if the readers never "quiesce" (e.g. no point in time where the number of readers reaches zero), the writer will be starved. This could be solved by using a fair lock.

 

 


----
Josh Humphries
[hidden email]

 

On Fri, Mar 24, 2017 at 12:22 PM, Gang Yan <[hidden email]> wrote:

 

Hi all

 

I hava a bug about Managed servers are taking too long to come up, it took 2-3hrs to come up.is on JDK 1.7.131.

 

I check server log and thread dump.This thread is waiting for some one to release something:

 

"Policy scanning timer" daemon prio=10 tid=0x00007fa3e4a7f800 nid=0x3be0 waiting on condition [0x00007fa440e81000]

   java.lang.Thread.State: WAITING (parking)

    at sun.misc.Unsafe.park(Native Method)

    - parking to wait for  <0x00000007c3cb4dd8> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)

    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)

    at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)

    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)

    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)

    at java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:945)

    at oracle.security.jps.az.common.util.JpsLock.lock(JpsLock.java:90)

    at oracle.security.jps.az.internal.common.scanner.PolicyChangeScanner.scanApplicationPolicies(PolicyChangeScanner.java:439)

    at oracle.security.jps.az.internal.common.scanner.PolicyChangeScanner.scan(PolicyChangeScanner.java:273)

    at oracle.security.jps.az.internal.common.scanner.PolicyChangeScanner$ScanTask.run(PolicyChangeScanner.java:234)

    at oracle.security.jps.az.internal.common.scanner.PolicyChangeScannerExecutor$SchedulerTask.run(PolicyChangeScannerExecutor.java:69)

    at java.util.TimerThread.mainLoop(Timer.java:555)

    at java.util.TimerThread.run(Timer.java:505)

 

It is also waiting for the lock: java.lang.Thread.State: TIMED_WAITING

 

"Policy scanning timer" daemon prio=10 tid=0x00007fa3e4a7f800 nid=0x3be0 in Object.wait() [0x00007fa440e81000]

   java.lang.Thread.State: TIMED_WAITING (on object monitor)

    at java.lang.Object.wait(Native Method)

    at java.util.TimerThread.mainLoop(Timer.java:552)

    - locked <0x00000007c448e018> (a java.util.TaskQueue)

    at java.util.TimerThread.run(Timer.java:505)

 

how to find out who hold on this lock ?

 

Thanks!

 

 

 

 

 

 


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

 


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question about java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync

Josh Humphries-2
Yep, the fact that readers are not tracked is why it cannot find the deadlock.

I am pretty sure that readers are not tracked because it's not free to do so. With an exclusive lock, it's simpler because only a single thread can hold the lock (so a single field, atomically updated, is all that is needed to track the holder). Tracking a shared lock on the other hand, where many threads could hold it, would require introduction of a thread-safe data structure (which adds much more book-keeping overhead -- execution time and garbage overhead on every acquire and release, memory overhead per lock instance).


----
Josh Humphries
[hidden email]

On Fri, Mar 24, 2017 at 7:53 PM, Nathan & Ila Reynolds <[hidden email]> wrote:

Along these lines, I recently discovered a situation where ThreadMXBean fails to detect ReentrantReadWriteLock deadlock.  It is very easy to reproduce.  I would assume that fixing this problem would make it easy to see your problem as well.

http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8176204

 

-Nathan

 

From: Concurrency-interest [mailto:[hidden email]] On Behalf Of Josh Humphries
Sent: Friday, March 24, 2017 5:21 PM
To: Gang Yan <[hidden email]>
Cc: concurrency-interest <[hidden email]>
Subject: Re: [concurrency-interest] Question about java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync

 

IIUC, the built in lock tracking only tracks exclusive holders of a ReadWriteLock (e.g. write lock), and not shared holders (e.g. read lock). So the issue here looks to be that the read lock was acquired (perhaps by multiple threads), and isn't being release. So the attempt to acquire a write lock is wedged. Unfortunately, the annotations in the stack trace won't show which threads have the read lock.

 

If you don't think there are any such tasks (e.g. threads acquiring the read lock and then never releasing it), the problem could be barging. The stack trace shows you are using an unfair lock (which is the default, for performance reasons). With an unfair read lock, an attempt to acquire a read lock will succeed if it is already read-locked -- even if there is a writer, waiting in line for the lock (in other words, the reader "barges" in front of the writer). So if the readers never "quiesce" (e.g. no point in time where the number of readers reaches zero), the writer will be starved. This could be solved by using a fair lock.

 

 


----
Josh Humphries
[hidden email]

 

On Fri, Mar 24, 2017 at 12:22 PM, Gang Yan <[hidden email]> wrote:

 

Hi all

 

I hava a bug about Managed servers are taking too long to come up, it took 2-3hrs to come up.is on JDK 1.7.131.

 

I check server log and thread dump.This thread is waiting for some one to release something:

 

"Policy scanning timer" daemon prio=10 tid=0x00007fa3e4a7f800 nid=0x3be0 waiting on condition [0x00007fa440e81000]

   java.lang.Thread.State: WAITING (parking)

    at sun.misc.Unsafe.park(Native Method)

    - parking to wait for  <0x00000007c3cb4dd8> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)

    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)

    at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)

    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)

    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)

    at java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:945)

    at oracle.security.jps.az.common.util.JpsLock.lock(JpsLock.java:90)

    at oracle.security.jps.az.internal.common.scanner.PolicyChangeScanner.scanApplicationPolicies(PolicyChangeScanner.java:439)

    at oracle.security.jps.az.internal.common.scanner.PolicyChangeScanner.scan(PolicyChangeScanner.java:273)

    at oracle.security.jps.az.internal.common.scanner.PolicyChangeScanner$ScanTask.run(PolicyChangeScanner.java:234)

    at oracle.security.jps.az.internal.common.scanner.PolicyChangeScannerExecutor$SchedulerTask.run(PolicyChangeScannerExecutor.java:69)

    at java.util.TimerThread.mainLoop(Timer.java:555)

    at java.util.TimerThread.run(Timer.java:505)

 

It is also waiting for the lock: java.lang.Thread.State: TIMED_WAITING

 

"Policy scanning timer" daemon prio=10 tid=0x00007fa3e4a7f800 nid=0x3be0 in Object.wait() [0x00007fa440e81000]

   java.lang.Thread.State: TIMED_WAITING (on object monitor)

    at java.lang.Object.wait(Native Method)

    at java.util.TimerThread.mainLoop(Timer.java:552)

    - locked <0x00000007c448e018> (a java.util.TaskQueue)

    at java.util.TimerThread.run(Timer.java:505)

 

how to find out who hold on this lock ?

 

Thanks!

 

 

 

 

 

 


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

 



_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Question about java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync

David Holmes-6
In reply to this post by Nathan & Ila Reynolds

Not likely to happen Nathan. Besides in the current case there is no evidence of any deadlock – it doesn’t hang.

 

David

 

From: Concurrency-interest [mailto:[hidden email]] On Behalf Of Nathan & Ila Reynolds
Sent: Saturday, March 25, 2017 9:54 AM
To: 'Josh Humphries' <[hidden email]>; 'Gang Yan' <[hidden email]>
Cc: 'concurrency-interest' <[hidden email]>
Subject: Re: [concurrency-interest] Question about java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync

 

Along these lines, I recently discovered a situation where ThreadMXBean fails to detect ReentrantReadWriteLock deadlock.  It is very easy to reproduce.  I would assume that fixing this problem would make it easy to see your problem as well.

 

http://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8176204

 

-Nathan

 

From: Concurrency-interest [[hidden email]] On Behalf Of Josh Humphries
Sent: Friday, March 24, 2017 5:21 PM
To: Gang Yan <[hidden email]>
Cc: concurrency-interest <[hidden email]>
Subject: Re: [concurrency-interest] Question about java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync

 

IIUC, the built in lock tracking only tracks exclusive holders of a ReadWriteLock (e.g. write lock), and not shared holders (e.g. read lock). So the issue here looks to be that the read lock was acquired (perhaps by multiple threads), and isn't being release. So the attempt to acquire a write lock is wedged. Unfortunately, the annotations in the stack trace won't show which threads have the read lock.

 

If you don't think there are any such tasks (e.g. threads acquiring the read lock and then never releasing it), the problem could be barging. The stack trace shows you are using an unfair lock (which is the default, for performance reasons). With an unfair read lock, an attempt to acquire a read lock will succeed if it is already read-locked -- even if there is a writer, waiting in line for the lock (in other words, the reader "barges" in front of the writer). So if the readers never "quiesce" (e.g. no point in time where the number of readers reaches zero), the writer will be starved. This could be solved by using a fair lock.

 

 


----
Josh Humphries
[hidden email]

 

On Fri, Mar 24, 2017 at 12:22 PM, Gang Yan <[hidden email]> wrote:

 

Hi all

 

I hava a bug about Managed servers are taking too long to come up, it took 2-3hrs to come up.is on JDK 1.7.131.

 

I check server log and thread dump.This thread is waiting for some one to release something:

 

"Policy scanning timer" daemon prio=10 tid=0x00007fa3e4a7f800 nid=0x3be0 waiting on condition [0x00007fa440e81000]

   java.lang.Thread.State: WAITING (parking)

    at sun.misc.Unsafe.park(Native Method)

    - parking to wait for  <0x00000007c3cb4dd8> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)

    at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)

    at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)

    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)

    at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)

    at java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(ReentrantReadWriteLock.java:945)

    at oracle.security.jps.az.common.util.JpsLock.lock(JpsLock.java:90)

    at oracle.security.jps.az.internal.common.scanner.PolicyChangeScanner.scanApplicationPolicies(PolicyChangeScanner.java:439)

    at oracle.security.jps.az.internal.common.scanner.PolicyChangeScanner.scan(PolicyChangeScanner.java:273)

    at oracle.security.jps.az.internal.common.scanner.PolicyChangeScanner$ScanTask.run(PolicyChangeScanner.java:234)

    at oracle.security.jps.az.internal.common.scanner.PolicyChangeScannerExecutor$SchedulerTask.run(PolicyChangeScannerExecutor.java:69)

    at java.util.TimerThread.mainLoop(Timer.java:555)

    at java.util.TimerThread.run(Timer.java:505)

 

It is also waiting for the lock: java.lang.Thread.State: TIMED_WAITING

 

"Policy scanning timer" daemon prio=10 tid=0x00007fa3e4a7f800 nid=0x3be0 in Object.wait() [0x00007fa440e81000]

   java.lang.Thread.State: TIMED_WAITING (on object monitor)

    at java.lang.Object.wait(Native Method)

    at java.util.TimerThread.mainLoop(Timer.java:552)

    - locked <0x00000007c448e018> (a java.util.TaskQueue)

    at java.util.TimerThread.run(Timer.java:505)

 

how to find out who hold on this lock ?

 

Thanks!

 

 

 

 

 

 


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest

 


_______________________________________________
Concurrency-interest mailing list
[hidden email]
http://cs.oswego.edu/mailman/listinfo/concurrency-interest
Loading...