Gregg Wonderly wrote:
Peter Firmstone wrote:
I don't want to be calling DNS!
This is the most significant reason why I hate resource based policy
implementation. I've spent countless hours trying to figure out why
something was so horribly slow, only to find that the primary DNS
server as not functioning, and the default 10 sec cache of failure was
too short, and so every DNS action timed out to the first host, and
then failed over and worked.
By setting the failure cache to 1min, my application was suddenly much
more responsive.
Gregg Wonderly
I've been running some tests on my ExecutionContextManager implementation.
I think I can eliminate the need for this additional interface and
implementation, by implementing a non blocking PermissionCollection for
a new Permission class called ProxyPermission.
Current Performance tests indicate that my ECM performs around 1.2 to
2.5 times the speed of AccessController.checkPermission(Permission).
When I run 5 concurrent threads looping constantly performing
checkPermission on 4 different Permission's for 100000 loops, the
performance per thread degrades from 11 seconds to 30 seconds for the
total test duration, due to internal synchronization in
RuntimePermission's PermissionCollection. (BasicPermissionCollection),
this is performed with the mostly non blocking
DynamicConcurrentPolicyProvider.
In comparison a comparative test on the ECM is about 7.5 seconds with
the same number of AccessController.getContext calls, the ECM reduces
these calls down to 4.2 seconds by testing 4 different Permission's per
getContext call (x 100000 loops). However this last test is atypical,
since checkPermission calls will normally only be made once, rather than
several in a row.
Because the ECM also uses a Synchronized Set, containing
AccessControlContext's there is potential for blocking under different
conditions in the ECM. Instead of having one ECM per policy, I could
have multiple, I can however create a non blocking
ProxyPermissionCollection for ProxyPermission's that behave similarly to
BasicPermission's, but are instead intended to support revocation with
Security Delegates and perform almost as well as the ECM.
This makes for a much simpler outcome and keeps the policy
implementation tighter. No ExecutionContextManager.
ProxyPermission's will be created for network addresses (without DNS
resolution), although considering that we want to be able to get through
firewalls and the like, I'm going to have to be careful, about exactly
what permission names are used. Since a service may be found, not
through DNS, but via a Registrar and a listening post, as per Sim's
Meekong Jeri Endpoint's.
These ProxyPermission's will be usable whether people want to revoke
them or not, and should be much faster than SocketPermission's, anyone
with any ideas, please assist.
Cheers,
Peter.
