The 0x040ebee8 monitor is most likely being held by native code.
Regards,
Peter Firmstone.
On 7/02/2016 4:27 AM, Peter Levart wrote:
On 02/06/2016 01:17 PM, Peter Firmstone wrote:
The security manager is non blocking, unfortunately java system
classes aren't.
It doesn't seem so. At least
Thanks Peter & David,
That's good to know.
I've altered the SecurityManager to perform a permission check prior to
becoming the security manager, this ensures the cache has been created,
to avoid any recursive deadlock prone calls.
The class that both threads are attempting to load and init
Out of curiousity, what class loader is using to define
org.apache.river.api.security.CombinerSecurityManager?
Mandy
> On Feb 7, 2016, at 1:54 AM, Peter wrote:
>
> Thanks Peter & David,
>
> That's good to know.
>
> I've altered the SecurityManager to perform a permission check prior to
> be
Thanks Peter & David,
That's good to know.
I've altered the SecurityManager to perform a permission check prior to
becoming the security manager, this ensures the cache has been created,
to avoid any recursive deadlock prone calls.
The class that both threads are attempting to load and init is
On 02/06/2016 10:32 PM, Peter wrote:
The 0x040ebee8 monitor is most likely being held by native code.
Regards,
Peter Firmstone.
Ok, but where? The deadlock report says it is held by main thread.
Somewhere between the following two java frames?
"main" #1 prio=5 os_prio=0 tid=0x017cf400 ni
