Looking for additional insight on Impala query states

[Phil Rhodes <ph...@distilnetworks.com>]

Hi all, I've looked at https://issues.cloudera.org/browse/IMPALA-2198
and read the linked page, but am still not totally clear on a couple
of things regarding Impala query states.  Could anyone here possibly
speak to these two things in particular:

1. Why does  a query go into "waiting to be closed" state?  I mean, I
get that it's "an exception or it's returned all it's rows", but I
don't get why such a query isn't closed immediately.

and perhaps more to the point:

2. Will all queries sitting in "waiting to be closed" state eventually
be closed by the Impala runtime? And, if so, are there any guarantees
about how long they may remain in this state before being closed?


Any insights you can share would be greatly appreciated.


Thanks,


Phil R.

Re: Looking for additional insight on Impala query states

[Phil Rhodes <ph...@distilnetworks.com>]

Thanks Matt, that helps a lot.


Phil


On Mon, Aug 22, 2016 at 3:57 PM, Matthew Jacobs <mj...@cloudera.com> wrote:
> Hi Phil,
>
> The main reason that queries remain registered in some form is to give
> clients the ability to query their final state. If the query were to
> disappear automatically, a client might try to fetch or get the status
> and Impala would indicate that no such query exists. Queries will not
> automatically be unregistered until they are explicitly closed by a
> client, the client closes the session, or the --idle_session_timeout
> (Impalad process argument) is set and the specified idle time elapses
> for the session, at which point every query in the session is
> unregistered.
>
> Thanks,
> Matt
>
> On Mon, Aug 22, 2016 at 11:12 AM, Phil Rhodes
> <ph...@distilnetworks.com> wrote:
>> Hi all, I've looked at https://issues.cloudera.org/browse/IMPALA-2198
>> and read the linked page, but am still not totally clear on a couple
>> of things regarding Impala query states.  Could anyone here possibly
>> speak to these two things in particular:
>>
>> 1. Why does  a query go into "waiting to be closed" state?  I mean, I
>> get that it's "an exception or it's returned all it's rows", but I
>> don't get why such a query isn't closed immediately.
>>
>> and perhaps more to the point:
>>
>> 2. Will all queries sitting in "waiting to be closed" state eventually
>> be closed by the Impala runtime? And, if so, are there any guarantees
>> about how long they may remain in this state before being closed?
>>
>>
>> Any insights you can share would be greatly appreciated.
>>
>>
>> Thanks,
>>
>>
>> Phil R.

Re: Looking for additional insight on Impala query states

[Matthew Jacobs <mj...@cloudera.com>]

Hi Phil,

The main reason that queries remain registered in some form is to give
clients the ability to query their final state. If the query were to
disappear automatically, a client might try to fetch or get the status
and Impala would indicate that no such query exists. Queries will not
automatically be unregistered until they are explicitly closed by a
client, the client closes the session, or the --idle_session_timeout
(Impalad process argument) is set and the specified idle time elapses
for the session, at which point every query in the session is
unregistered.

Thanks,
Matt

On Mon, Aug 22, 2016 at 11:12 AM, Phil Rhodes
<ph...@distilnetworks.com> wrote:
> Hi all, I've looked at https://issues.cloudera.org/browse/IMPALA-2198
> and read the linked page, but am still not totally clear on a couple
> of things regarding Impala query states.  Could anyone here possibly
> speak to these two things in particular:
>
> 1. Why does  a query go into "waiting to be closed" state?  I mean, I
> get that it's "an exception or it's returned all it's rows", but I
> don't get why such a query isn't closed immediately.
>
> and perhaps more to the point:
>
> 2. Will all queries sitting in "waiting to be closed" state eventually
> be closed by the Impala runtime? And, if so, are there any guarantees
> about how long they may remain in this state before being closed?
>
>
> Any insights you can share would be greatly appreciated.
>
>
> Thanks,
>
>
> Phil R.