Hi Gregg,
I've got an implementation of ConcurrentPermissions that allows for 16
concurrent writes by default, without writes the concurrent reads are
uncontended. Even with writes you'll still have a significant number of
concurrent reads, this can even be increased, I don't think you'll need
to though.
I've also got a wrapper class for the PermissionCollection classes that
locks on write, allow as many reads as you want and provides a default
PermissionCollection instance, or for Permission's that return a null
PermissionCollection from the factory method
Permission.getPermissionCollection().
You instantiate it by providing a Permission object in its constructor.
This is highly concurrent. I've corrected corrected a few concurrency
bugs in River I'm running through the tests at the moment. Note that
other classes in River that utilise this will now be the bottleneck so
will probably require some further revision.
If you want this committed, it will mean AR2 or Apache River 2.2.0 will
require Java 5, for now at least. I'm happy to do so if there are no
objections.
Regards,
Peter.
Gregg Wonderly wrote:
I have been looking into some seemingly slow responses in several
clients running simultaneously, and I see in some stack traces that
there are synchronization points in DynamicPolicyProvider.implies()
that seem to be heavily contended. We probably need to revisit this
class and rewrite it to use copy on write mutation so that reads (the
majority of activity) are completely uncontended.
Any thoughts or experience with this issue?
Gregg Wonderly
