> On Feb. 18, 2014, 6:41 p.m., Prasad Mujumdar wrote: > > @Vaibhav, thanks for the patch and following up on the overall async > > execution line items! > > > > The patch itself looks fine on the first pass. I do have a high level > > question on the approach. The patch enables async execution by defaults on > > client side and adds synchronous wait top of that. This IHMO defeats the > > purpose of the aysnc execution. From the application point of view, there's > > no difference in the behavior with or without this patch. The execution > > will block till the query execution is complete. > > The rationale of async execution is to return control back to client > > immediately so that the client has an option to perform alternate > > foreground work while the query is being processed. Have you considered > > blocking in fetch for queries with resultset ? That in would give more time > > for server to process the query in parallel while client examines the > > resultset description and possible interact with end user etc.
@Prasad: Thanks a lot for taking a look! I was basically going for a use case when an error can be detected sooner. For example consider the scenario when a stmt.cancel is called from a separate thread: Blocking calls: When stmt.execute is called, internally HiveStatement sets a variable stmtHandle, to refer to the Operation object that it created for the query execution. However, for a blocking call, the stmtHandle is set only when the call to Operation.run returns. If we call a stmt.cancel (in a different thread) during this, the internal code will check for the value of stmtHandle and return immediately if it is null, essentially doing a no-op. Async calls: Since an async call immediately returns from Operation.run, the stmtHandle is set in HiveStatement while the query is still executing. This means, that a stmt.cancel can actually cancel the underlying operation and the original stmt.execute will throw an error when we poll for the operation status (since the underlying operation handle is gone). This can return a useful response to the client sooner. However, I agree blocking on fetch would be more efficient. Do you think I can take that up in a follow up jira since I may not have a lot of time to work on it for Hive 13 release? Thanks again! - Vaibhav ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/14950/#review34728 ----------------------------------------------------------- On Feb. 18, 2014, 2:22 p.m., Vaibhav Gumashta wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/14950/ > ----------------------------------------------------------- > > (Updated Feb. 18, 2014, 2:22 p.m.) > > > Review request for hive and Thejas Nair. > > > Repository: hive-git > > > Description > ------- > > Should be applied on top of: > HIVE-5217 [Add long polling to asynchronous execution in HiveServer2] > HIVE-5229 [Better thread management for HiveServer2 async threads] > HIVE-5230 [Better error reporting by async threads in HiveServer2] > HIVE-5441 [Async query execution doesn't return resultset status] > > > Diffs > ----- > > jdbc/src/java/org/apache/hive/jdbc/HiveStatement.java f0d0c77 > > Diff: https://reviews.apache.org/r/14950/diff/ > > > Testing > ------- > > TestJdbcDriver2 > > > Thanks, > > Vaibhav Gumashta > >
