This is certainly expected to work, and I'm reasonably sure that we've seen it working in the past. The expected behaviour of ASYNC is that you immediately get a response from the server, and as Till said, that is the reason that the flush() is there.
My understanding is that we should definitely NOT remove the waitForCompletion() call, or else the job will never actually execute. The naming of these methods and the structure of QueryTranslator is a little bit weird. Do you have an example of some client code that shows that you do not immediately get a response from the server (containing a result handle) when using ASYNC? If so, it's definitely a bug. Ceej aka Chris Hillery On Tue, Dec 29, 2015 at 10:07 PM, Wail Alkowaileet <[email protected]> wrote: > Dears, > > First, sorry for the many emails ... > > I have a question about the RESTAPI. I see that Async query get blocked > until the job is completed ... is that intentional ? > > if so ... this can fail a job if it takes too long (> HTTP timeout). > > in QueryTranslator: > switch (resultDelivery) { > case ASYNC: > JSONArray handle = new JSONArray(); > handle.put(jobId.getId()); > > handle.put(metadataProvider.getResultSetId().getId()); > response.put("handle", handle); > sessionConfig.out().print(response); > sessionConfig.out().flush(); > hcc.waitForCompletion(jobId); *<-- should we remove > this one ?* > break; > > As a result, I've never seen the status as RUNNING. it's always SUCCESS or > some sort of runtime exception payload. Even for query takes multiple > seconds. > > Removing waitForCompletion will need some modifications on the Result > framework interfaces to report the exceptions when query status = FAILURE > instead of throwing it to a finished HTTP session. > > Before reporting a JIRA issue, is there any "internal consequences" if the > client didn't wait? I didn't see any issue from my brief testings ... > -- > > *Regards,* > Wail Alkowaileet >
