On 2 Oct 2010, at 10:20, Ian Boston wrote: > > On 2 Oct 2010, at 02:15, Ian Boston wrote: > >> Hi, >> I have been trying to work out why Sling is showing Single Threaded >> behaviour with authenticated users to areas of the JCR that are not read >> public. >> >> I think that this is because there are concurrent threads using the >> ACLProvider via the DefaultSecurityManager sharing single system session >> that is synchronised inside the ItemManager.getNode et al. method. >> >> This does not happen where the JCR is public read since resolution of the >> ACLs is bypassed and so no single threading is seen. >> >> So the question: >> Am I diagnosing the problem correctly ? >> What would be the impact of customising this area of the code base to use >> one systemSession per thread and avoid the single threadedness, which is >> having a big impact on the performance of our deployments ? >> >> TIA >> Ian > > > I have had a look at fixing this and its a major modification to all Access > Control Providers as the single systemSession per workspace is saved in the > abstract base class. It happens in all Jackrabbit instances since around 1.6 > when item tree is not 100% read granted. > > Any pointers on this would be really appreciated as its becoming a deal > breaker for our use of Sling and Jackrabbit. We cant use Jackrabbit if it is > a single threaded server for read access where some read is denied. > > Ian
Quick update, making the SystemSession a non singleton and binding AccessControl providers to threads as well as workspaces eliminates the blocking caused by shared use of the SystemSession, however the server is still behaving in a single threaded way with only minimal throughput increase between 1,2,3,4 concurrent requests. Progress, but still investigating. Is it safe to use a per AccessControlProvider System session (ie 1 per thread for the life of the thread)? Ian
