jackrabbit-oak-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Mueller (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (OAK-5978) Allow deployers to configure a query time limit
Date Fri, 24 Mar 2017 13:49:42 GMT

    [ https://issues.apache.org/jira/browse/OAK-5978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15940361#comment-15940361

Thomas Mueller commented on OAK-5978:

How is your request different from what we have already? As Davide wrote on the Oak list,
we cancel a query that iterated over a certain amount of nodes or as of 1.6 may hit the traversal
index (doesn't have an index). As for resource exhaustion: we have a limit on the number of
nodes read in memory. The number of traversed nodes is very similar to a time limit: the more
nodes are traversed, the slower a query is (it's basically a 1:1 relationship). Measuring
the time taken for a query is tricky, we would have to measure each individual "nextNode()"
call, and sum that. This would include time to load binaries from Lucene indexes (possibly
reads from the S3 datastore). This is highly dependant on caching, much more than a typical
query in a relational database with a local file system.

> 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
> At this stage, this is an idea. It may not be possible to implement.

This message was sent by Atlassian JIRA

View raw message