[
https://issues.apache.org/jira/browse/OAK-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16933417#comment-16933417
]
Jörg Hoh commented on OAK-8626:
-------------------------------
Unfortunately I don't have these numbers, I only got a threaddump. And from
what I know right now, the situation was special in a way, that a lot of Full
GCs happened at that time, which could trigger a contention on repository login
(requests queuing up during FullGC, and then for all of these queued threads
the processing starts).
Therefor I don't think that it is a bottleneck per se; but reducing the
overhead of creating a JCR session is always a good thing (as the login always
triggers a JCR query). I understand that if it's not a critical issue and also
not easy to change, that it's unlikely to get implemented at all.
> Make query statistic handling faster (maybe asynchronous)
> ---------------------------------------------------------
>
> Key: OAK-8626
> URL: https://issues.apache.org/jira/browse/OAK-8626
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: query
> Affects Versions: 1.8.11
> Reporter: Jörg Hoh
> Priority: Major
>
> During performance analysis I found in a threaddump a number of threads in
> this state:
> {noformat}
> "qtp1082699324-121518" prio=5 tid=0x1daae nid=0xffffffff timed_waiting
> java.lang.Thread.State: TIMED_WAITING
> at
> java.util.concurrent.ConcurrentSkipListMap.size(ConcurrentSkipListMap.java:1639)
> at
> org.apache.jackrabbit.oak.query.stats.QueryStatsMBeanImpl.getQueryExecution(QueryStatsMBeanImpl.java:134)
> at
> org.apache.jackrabbit.oak.query.QueryEngineImpl.parseQuery(QueryEngineImpl.java:160)
> at
> org.apache.jackrabbit.oak.query.QueryEngineImpl.executeQuery(QueryEngineImpl.java:259)
> at
> org.apache.jackrabbit.oak.query.QueryEngineImpl.executeQuery(QueryEngineImpl.java:235)
> at
> org.apache.jackrabbit.oak.plugins.identifier.IdentifierManager.resolveUUID(IdentifierManager.java:351)
> at
> org.apache.jackrabbit.oak.plugins.identifier.IdentifierManager.resolveUUID(IdentifierManager.java:345)
> at
> org.apache.jackrabbit.oak.plugins.identifier.IdentifierManager.resolveUUID(IdentifierManager.java:341)
> at
> org.apache.jackrabbit.oak.plugins.identifier.IdentifierManager.getTree(IdentifierManager.java:136)
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenProviderImpl.getTokenInfo(TokenProviderImpl.java:269)
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenAuthentication.validateCredentials(TokenAuthentication.java:105)
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenAuthentication.authenticate(TokenAuthentication.java:58)
> at
> org.apache.jackrabbit.oak.security.authentication.token.TokenLoginModule.login(TokenLoginModule.java:136)
> at
> org.apache.felix.jaas.boot.ProxyLoginModule.login(ProxyLoginModule.java:52)
> at sun.reflect.GeneratedMethodAccessor39.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at javax.security.auth.login.LoginContext.invoke(LoginContext.java:755)
> at
> javax.security.auth.login.LoginContext.access$000(LoginContext.java:195)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:682)
> at javax.security.auth.login.LoginContext$4.run(LoginContext.java:680)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:680)
> at javax.security.auth.login.LoginContext.login(LoginContext.java:587)
> at
> org.apache.jackrabbit.oak.core.ContentRepositoryImpl.login(ContentRepositoryImpl.java:163)
> [...]
> {noformat}
> Is it required to do the cache statistic handling within a query itself? Or
> is it possible to perform it outside of it asynchronously in a dedicated
> thread?
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
