On 3 Oct 2010, at 13:16, Jukka Zitting wrote:
> Hi,
>
> On Sun, Oct 3, 2010 at 12:51 PM, Ian Boston <[email protected]> wrote:
>> Just in case it helps, I have commented and attached patches for the partial
>> solution that I am working on which eliminate blocking by simply not sharing
>> the SystemSession in the AccessControlProvider.
>
> Excellent, thanks!
>
> BR,
>
> Jukka Zitting
For posterity:
One other fix mentioned on the jira was to remove synchronisation from the
cache surrounding the LRUMap in the AbrstractPrincipalProvider, and protect the
operation from failure with try {} catch {} (LRUMap throws NPE on concurrent
access).
This has now freed our code base up to the extent that read concurrency is
being limited by the SharedItemManager, however we still are limited to around
1000 requests per second regardless of number of cores, indicating although
faster, its still single threaded. What I don't know is if being fast but
single threaded is good enough to support the number of users we have to
support per JVM.
Jukka,
Do you think your work on JCR-2699 will make reads truly concurrent with no
blocking or will there always be a part of the code base that is essentially
single threaded?
I ask because this might become a deal breaker for us, and I would rather not
raise expectations, or ask too for too much from the Jackrabbit community, if
our usage of Jackrabbit is not going to match the aims of Jackrabbit.
Thanks
Ian
