[
https://issues.apache.org/jira/browse/PHOENIX-1463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219834#comment-14219834
]
James Taylor commented on PHOENIX-1463:
---------------------------------------
Thanks for the updated patch, [~samarthjain]. Let's catch the TimeOutException
that would occur if the thread times out and wrap it in this one, like this
(where the e is the TimeOutException):
{code}
throw new
SQLExceptionInfo.Builder(SQLExceptionCode.OPERATION_TIMED_OUT).setMessage("Query
couldn't be completed in the alloted time: " + queryTimeOut + "
ms").setRootCause(e).build().buildException();
{code}
> phoenix.query.timeoutMs doesn't work as expected
> ------------------------------------------------
>
> Key: PHOENIX-1463
> URL: https://issues.apache.org/jira/browse/PHOENIX-1463
> Project: Phoenix
> Issue Type: Bug
> Affects Versions: 4.2
> Reporter: Jan Fernando
> Assignee: Samarth Jain
> Priority: Minor
> Fix For: 5.0.0, 4.2, 4.3
>
> Attachments: PHOENIX-1463.patch, PHOENIX-1463_v2.patch,
> PHOENIX-1463_v3.patch, PHOENIX-1463_v4.patch
>
>
> In doing performance testing with Phoenix I noticed that under heavy load we
> saw queries taking as long as 300 secs even though we had set
> phoenix.query.timeoutMs to 120 secs. It looks like the timeout is applied
> when the parent thread waits for all the parallel scans to complete. Each
> time we call rs.next() and need a to load a new chunk of data from HBase we
> again run parallel scans with a new 120 sec timeout. Therefore total query
> time could be timeout * # chunks scanned. I think it would be more intuitive
> if the query timeout applied to the query as a whole versus resetting for
> each chunk.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
