Sure. val httpGet: HttpGet = new HttpGet(url+"query/status?handle=" + handle) val response: CloseableHttpResponse = httpclient.execute(httpGet)
val responseEntity: HttpEntity = response.getEntity val status = scala.io.Source.fromInputStream(responseEntity.getContent).mkString that's my code ... probably I should use different response method ? On Wed, Dec 30, 2015 at 11:20 AM, Chris Hillery <[email protected]> wrote: > 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 > > > -- *Regards,* Wail Alkowaileet
