Are you using the same user to do all tasks in the performance-test or do you have one user per performance-thread?
If you are using one and only one user that logs in from all performance-threads, then it would be like the same user had a lot of browser windows opened at the same time and clicking like crazy. It is not a likely scenario, but it could happen so the session handler guards some of the events in the session, such as save.
Hi Ove ,
We are not using one user for all tasks. There will different user per task. So we are using one user per performance-thread.
Good, that is the first thing to look at.
Do you know what you are trying to do?
When I handle sessions, I tend to guard the session as much as possible. If I need to send something from the session to another class/worker, I strive to only send the data needed. If I send the session, then I never manipulate on the session itself if I can avoid it and if I have a fork somewhere in the code, I collect all the data that is needed from the separare legs and then assemble, set and commit them at one point in the code. I don't think this is such a case, rather some sort of multiple calls that tries to do the same thing.
We are trying to achieve how many user can be served at peak time and how many open session CQ can support. We are also checking open session should not cross 100 after all request serverd. We have minimized to below 100 and still minimizing to make it 0. As you said we are handling session commit at the end of process and logout either in exception case and there is finally block call to close if any other session still alive. Will check are there any multiple calls for doing same thing.
1 person found this helpful
Which version of CQ5/CRX are you using? What hotfix level?
Anyway: This is a warning about a potential problem, which is avoided by delaying some other operations. So not an issue in the first place.
Secondly, for me it seems, that you import lot of users concurrently from the LDAP. This means, that you either have thousands of users, which just do a single request to CQ5, and are therefor for every request the respective user is imported. Or the lifetime of cached principals ("cache.expiration" in your JAAS config) is set to a very low value.
And as a last tip: Please report this to Daycare.
We are using CQ 5.4 and crx-hotfixpack-188.8.131.52-2.3.24 on our prod environment.
Could you please suggest what is standard value or proportion for cache.maxsize and cache.expiration in terms of number of hits?
1 person found this helpful
* cache.maxsize = 1000
* cache.expiration = 600 (= 10 minutes)
These values should be sufficient for 99% of all authoring usecases. Sadly there are no statistics available about the usage of this cache.
Your comments are much appreicated!
question about the statement "it seems, that you import lot of users concurrently from the LDAP". for us yes we are but the question is should that me problamatic? We do see that it is causing issues for us in CQ5.5 with CRX 2.3.15:
com.day.crx.security.ldap.LDAPLoginModule commit: could not commit: javax.jcr.InvalidItemStateException: property /some/LDAP/group/rep:lastsynced: the property cannot be saved because it has been modified externally.
However we had no such issue with CQ5.3 with CRX2.0