[
https://issues.apache.org/jira/browse/JENA-2328?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17551430#comment-17551430
]
ASF subversion and git services commented on JENA-2328:
-------------------------------------------------------
Commit cfc30a97cdcdec8e01cc6ff5bdcb75c422b7b4f5 in jena's branch
refs/heads/main from Andy Seaborne
[ https://gitbox.apache.org/repos/asf?p=jena.git;h=cfc30a97cd ]
JENA-2328: Shared async flag signalling from timeouts
> Query timeouts failing when plan phase is long
> ----------------------------------------------
>
> Key: JENA-2328
> URL: https://issues.apache.org/jira/browse/JENA-2328
> Project: Apache Jena
> Issue Type: Bug
> Components: ARQ
> Reporter: Dave Reynolds
> Assignee: Andy Seaborne
> Priority: Major
> Attachments: TestQueryExecutionTimeout3.java
>
>
> In a production service with a large TDB store (around 500MT) we find that
> some complex queries evade the query timeouts (set to 90s first result, 120s
> total) and then run for hours soaking up all available CPU cores. While the
> queries show no clear pattern, and it has been hard replicate in a controlled
> setting, we do now have one example which is expressible as a test case. See
> attached.
> The behaviour is that the abort() call from the alarm timeout is received by
> QueryExecDataset before there is an iterator to cancel - the QueryExecDataset
> instance is deep in getPlan() which itself executes part of the query. In the
> specific example it's OpSlice which is iterating through the offset while
> still in the planning phase. Though not queries which cause this sort of
> behaviour use offsets.
> Sorry but have no PR to offer at this stage. Have looked at whether it's
> possible to have getPlan() return some future or deferrable plan so that the
> top level exec has a handle on something that it can abort. However, the
> changes looks far reaching and I don't yet have a satisfactory approach to
> offer.
>
>
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]