Hi Gregg,
The contention appears to be around the use of the existing single
thread synchronized Policy implementations like DynamicPolicyProvider.
There are numerous places where Thread is checked (not just subclasses)
by the SecurityManager using the checkAccess(Thread) method, this is
delegated to AccessController.checkPermission(perm)
checkPermission(perm) gets the AccessControlContext of the currently
executing stack, AccessControlContext.optimize() is called to remove
duplicate PermissionDomain's
then AccessControlContext.checkPermission(perm) is called to check the
permission's of all the ProtectionDomain's on the current stack, the
ProtectionDomain's on the stack are iterated through, the first
ProtectionDomain.implies(Permission) that returns false returns causes
the AccessControlContext to return false.
This means that if your thread is executing with several CodeSource's it
will have to check several ProtectionDomains.
Each ProtectionDomain will check the policy, if the ProtectionDomain was
created with the dynamic policy domain constructor:
public ProtectionDomain(CodeSource codesource,
PermissionCollection permissions,
ClassLoader classloader,
Principal[] principals)
The ProtectionDomain first check's the Policy for the permission, then
it checks it's own private PermissionCollection permissions passed in
via the constructor, or that which has been merged with the permissions
from the Policy.
Policy.getPermissions(ProtectionDomain)
In my RevokeablePolicy implementation, getPermissions doesn't return any
dynamic Permission grant's, if it did, they could never be revoked as
they would become merged with the ProtectionDomains private
PermissionCollection.
So to sum up, you should get much better mileage if you try out my new
ConcurrentDynamicPolicy implementation.
I know you've got a privately forked copy of River, but if you simply
copy concurrent_policy_utils.jar and jsk-policy.jar from River's Hudson
build, to your jre/lib/ext directory, you should be able to utilise it.
The ConcurrentDynanicPolicyProvider has passed all qa tests and jtreg
tests, I'm just waiting for someone like yourself to report back
concurrency improvements.
Cheers,
Peter.
Gregg Wonderly wrote:
The TaskManager class has a subclass of Thread that it uses to run
tasks. The problem with subclassing Thread, is that there is a lock
that is used in Thread to see if some methods are overridden so that
security can be maintained. So, in an environment where Thread is
used with a SecurityManager, it is better to use a Runnable to
encapsulate the custom code, instead of a Thread.
The TaskThread class should be a Runnable instead of a Thread, and
then there are just 3 other places where it is referenced that need
some adjustment. The thread that is running inside of the runnable
needs to be put into a per instance variable for one place where
interrupt processing is handled.
Gregg Wonderly
