[
https://issues.apache.org/jira/browse/IMPALA-8962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16934809#comment-16934809
]
Tim Armstrong commented on IMPALA-8962:
---------------------------------------
I think it's unlikely that it's safe to remove BlockOnWait() - I think we need
that currently to get to the point where the Coordinator is instantiated. I'm
not sure if the HS2 protocol is clear on *when* in the query state machine it
is valid to call fetch, but there's potentially a long time that elapses
between the Exec() call and when the Coordinator and PlanRootSink are
instantiated. E.g. this includes time in admission control.
> FETCH_ROWS_TIMEOUT_MS should apply before rows are available
> ------------------------------------------------------------
>
> Key: IMPALA-8962
> URL: https://issues.apache.org/jira/browse/IMPALA-8962
> Project: IMPALA
> Issue Type: Bug
> Components: Clients
> Reporter: Sahil Takiar
> Assignee: Sahil Takiar
> Priority: Major
>
> IMPALA-7312 added a fetch timeout controlled by the query option
> {{FETCH_ROWS_TIMEOUT_MS}}. The issue is that the timeout only applies after
> the *first* batch of rows are available. The issue is that both Beeswax and
> HS2 clients call {{request_state->BlockOnWait}} inside
> {{ImpalaServer::FetchInternal}}. The call to {{BlockOnWait}} blocks until
> rows are ready to be consumed via {{ClientRequestState::FetchRows}}.
> So clients can still end up blocking indefinitely waiting for the first row
> batch to appear.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscr...@impala.apache.org
For additional commands, e-mail: issues-all-h...@impala.apache.org
