[
https://issues.apache.org/jira/browse/OAK-5978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15940424#comment-15940424
]
Ian Boston commented on OAK-5978:
---------------------------------
It's different for the reasons you stated.
When a query causes the working set of an active repository to increase beyond
the resources that are available, everything slows down. That shows up as page
faulting in TarMK, page faults with MongoMK on MMAPv1 and saturated IO in
MongoMK WT. Counting the number of results or looking for traversal is no
longer a good way of detecting a query that should be canceled. Starting a
timer at the start of the query and checking the time elapsed at convenient
points throughout the query execution would be a better way of protecting
normal operation from roque queries. That suggestion is based on my very
limited knowledge of how Oak works internally. There are probably much better
ways of doing it based on elapsed time.
Perhaps it can't be implemented in Oak. The current limits don't appear to
protect against outage.
> Allow deployers to configure a query time limit
> -----------------------------------------------
>
> Key: OAK-5978
> URL: https://issues.apache.org/jira/browse/OAK-5978
> Project: Jackrabbit Oak
> Issue Type: New Feature
> Components: query
> Affects Versions: 1.6.1
> Reporter: Ian Boston
>
> Currently when a query takes a long time to complete, Oak allows it to
> continue to completion, which can under certain circumstances result in
> resource exhaustion and slow performance for all operations depending on Oak.
> This feature request is to apply a deployer configurable time limit to all
> queries. If the query exceeds that time limit, it is canceled with a suitable
> exception, so that it consumes no more resources and the code or user that
> submitted the query is notified.
> Ideally this needs to work while the query is executing inside Oak rather
> than waiting to return via the Oak API before being canceled. Cancelation
> should result in minimal resource usage.
> At this stage, this is an idea. It may not be possible to implement.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
