[jira] [Commented] (OAK-8626) Make query statistic handling faster (maybe asynchronous)
[
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=0x 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)
[jira] [Commented] (OAK-8626) Make query statistic handling faster (maybe asynchronous)
[
https://issues.apache.org/jira/browse/OAK-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16933408#comment-16933408
]
Thomas Mueller commented on OAK-8626:
-
Do you know how often this was called? It might be called millions of times, in
which case this could potentially be the hotspot for this query. There are
usually tools that allow you to find out how often a query is executed
(analytics tools to analyze query performance / list popular queries).
I wouldn't make it asynchronous unless really, really needed - this is
complicated.
> 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=0x 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)
