asterixdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hillery <chill...@hillery.land>
Subject Re: Async query waits for job completion
Date Wed, 30 Dec 2015 08:20:18 GMT
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 <wael.y.k@gmail.com>
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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message