Hi, On 11.01.2010 09:38, Ian Boston wrote: > > On 11 Jan 2010, at 07:52, Felix Meschberger wrote: > >> Hi, >> >> On 09.01.2010 11:48, Ian Boston wrote: >>> Ok, so I was slow on the uptake, as usual, I now see the problems and I >>> agree, the pooling should be removed. >> >> Ok, shall I move on then ? Or should I wait for the full consequences >> with respect to ACL caching (see below) are known ? > > > I am happy with that, you have tested in performance with no pooling, and I > think it will only become an issue with group deny, which is not a problem > for Sling or Jackrabbit at the moment.
Ok, thanks. Regards Felix > >> >>> >>> Just for the record, here is want I observed, only worth reading if you >>> like me haven't looked at the pool code. (Felix I think you said all of >>> this in shorthand form, sorry) >> >> Thanks for the flowser. Yet your description hits the nail right at the >> center and is also very concise! >> >>> >>> 1. The only sessions that can go into the pool are sessions authenticated >>> with a password, as the password is stored with the pool and used to check >>> if the login request can get the session out of the pool which btw is a >>> pool for the user in question. If you have any form of LoginModule >>> associated with an AuthenticationHandler (eg the OpenID or a container >>> auth, CAS, webAuth, ie anything where Sling does not see the password), >>> then the pool wont work. >>> >>> 2. There is one pool per user, and the "user pools" are never cleaned up. >>> Since sessions are only cleaned when taken out of the pool, if 1M users hit >>> your app server and then exited their browser there would be 1M pools and >>> 1-4M open JCR sessions (browsers have 1-4 http connections per window). The >>> current code does not clean user pools or defunct sessions. >>> >>> 3. The inactive session list is a linked list that needs to be tightly >>> synchronised. I think I am seeing the same session being taken out of the >>> pool and shared incorrectly, resulting in a release happening more than >>> once. Some of the time this results in a logout which shows up. Since >>> sessions are not thread safe, I think it might have been the cause of other >>> random problems. >>> >>> 4. slingRepository.loginAdministrative() uses SimpleCredentials and so is >>> pooled. Limiting the number of concurrent request that require an >>> administrative session to < 10 (the default per user pool size). > > actually this is wrong, there is no limit by default, but only the first 10 > get pooled. > > >>> >>> -------------------------------------------------------------------- >>> >>> Can you point me to where the compiled ACLs are cached, I cant find the >>> code, I need to check that my customisations haven't broken anything ? >> >> Oops, now you got me... >> >> According to my interpretation of the code, your are right in saying the >> compiled ACLs are cached per-Session and not globally... >> >> Unfortunately, I have to admit that this is an area of Jackrabbit code, >> I do not know in full detail. So it might be worth asking on the >> Jackrabbit list about this.... > > Ok, will do. > >> >> Regards >> Felix >> >>> >>> Thanks >>> Ian >>> >>> >>> >>> On 7 Jan 2010, at 09:22, Felix Meschberger wrote: >>> >>>> Hi, >>>> >>>> You are correctly noting these potential issues. >>>> >>>> But for a long time now, Jackrabbit has dramatically grown in this area: >>>> >>>> * The compiled ACLs are not cached within the session but in an >>>> ACL cache (where they IMHO belong) >>>> * Session setup once was a very heavy-weight operation (due to >>>> Principal lookup etc.). This has also been highly optimized by >>>> now. In fact Repository.login is even as fast as (if not faster >>>> than) retrieving and checking a Session from the session pool ! >>>> >>>> In fact, for our Communiqué 5 product we have switched off session >>>> pooling for a long time now -- interestingly for performance and >>>> stability reasons. >>>> >>>> What you might want to check with respect to performance, is temporarily >>>> switching off session pooling by setting the "Max Idle Session" >>>> configuration value to zero (0). >>>> >>>> Regards >>>> Felix >>>> >>>> On 07.01.2010 10:12, Ian Boston wrote: >>>>> >>>>> On 6 Jan 2010, at 22:11, Felix Meschberger wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> Today I stumbled upon a potential problem with the JCR Session Pooling >>>>>> we have in the JCR Base bundle. >>>>>> >>>>>> Some time ago, we disabled session pooling by default. Only today I >>>>>> actually set this default for the Embedded Jackrabbit bundle (see >>>>>> SLING-1272). >>>>>> >>>>>> The problems with session pooling are manyfold, some of the issues are: >>>>>> >>>>>> * Only works with SimpleCredentials authentication >>>>>> * Wrong level of abstraction: such optimizations are the task of the >>>>>> repository implementation and not of the user >>>>>> * Cleanup of the session for reuse is brittle and timeconsuming >>>>>> (due to a JCR search to ensure unlocking transient locks) >>>>>> * Little to no gain in performance (in fact performance is even >>>>>> lower than using plain Jackrabbit Sessions. >>>>>> >>>>>> The only real use of the current session pooling, we might discuss, is >>>>>> the optional limitation of concurrent requests per user. But even this >>>>>> feature is disabled by default. >>>>>> >>>>>> For these reasons, I think we should remove the Session Pooling support >>>>>> from the JCR base bundle. >>>>>> >>>>>> WDYT ? >>>>> >>>>> >>>>> What happens to compiled ACL's if there is no session pooling. IIRC where >>>>> the JCR is not in "everyone can read everything" mode, the Session is the >>>>> location where compiled ACL's are stored. If the session is not pooled >>>>> every request has to recompile the ACLs. >>>>> >>>>> This wont be noticed for situations where most reads dont need an ACL, >>>>> but where they do and there are a high number of ACL (or the cost of >>>>> resolving and compiling the ACLs is higher due to complex rules) then >>>>> removing session pooling is going to have an impact. >>>>> >>>>> The ACL resolution mechanism in DefaultAccessControlManager is highly >>>>> optimised and very fast once the ACL has been compiled, which is good >>>>> since its an extremely high traffic area of the Jackrabbit code base, but >>>>> compilation of the ACL is not fast particularly where there are many ACLs >>>>> effecting a single node. >>>>> >>>>> I suspect that if you are comparing performance in "everyone can read >>>>> everything" you wont see any impact, have you tried to see what happens >>>>> when there is a more complex ACL structure that is compiled ? >>>>> >>>>> Also, I was told once that JCR XASessions and the associated >>>>> SecurtiyManager, and all JCR core thing with an init() attached to the >>>>> session was a heavy and expensive object (relative term) that should be >>>>> re-used, has this changed ? >>>>> >>>>> I am not going to vote on this, but I do want to discuss it since when I >>>>> first looked at Sling I was relieved to see session pooling in place. >>>>> >>>>> I could also be that I am miss-understanding session pooling, but I >>>>> thought the key feature was that if a user came back, and there was a >>>>> session in the pool that they had used before, they got the same session >>>>> back and were able to re-use all the work of previous requests in the ACL >>>>> area. >>>>> >>>>> Ian >>>>> >>>>>> >>>>>> Regards >>>>>> Felix >>>>> >>>>> >>>> >>> >>> >> > >
