Denis,
Let's consider parameter of KILL QUERY just a string with some query id,
without any meaning for user. User just need to get the id and pass as
parameter to KILL QUERY command.
Even if query is distributed it have single query id from user perspective
and will killed on all nodes. User just need to known one global query id.
How it can works.
1)SELECT * from running_queries
result is
query_id | node_id
| sql | schema_name | connection_id | duration
123.33 | e0a69cb8-a1a8-45f6-b84d-ead367a00000 | SELECT ... | ...
| 22 | 23456
333.31 | aaa6acb8-a4a5-42f6-f842-ead111b00020 | UPDATE... | ...
| 321 | 3467777
2) KILL QUERY '123.33'
So, user need select query_id from running_queries view and use it for KILL
QUERY command.
I hope it became clearer.
ср, 21 нояб. 2018 г. в 02:11, Denis Magda <dma...@apache.org>:
> Folks,
>
> The decimal syntax is really odd - KILL QUERY
> '[node_order].[query_counter]'
>
> Confusing, let's use a space to separate parameters.
>
> Also, what if I want to halt a specific query with certain ID? Don't know
> the node number, just know that the query is distributed and runs across
> several machines. Sounds like the syntax still should consider
> [node_order/id] as an optional parameter.
>
> Probably, if you explain to me how an end user will use this command from
> the very beginning (how do I look for a query id and node id, etc) then the
> things get clearer.
>
> --
> Denis
>
> On Tue, Nov 20, 2018 at 1:03 AM Юрий <jury.gerzhedow...@gmail.com> wrote:
>
> > Hi Vladimir,
> >
> > Thanks for your suggestion to use MANAGEMENT_POOL for processing
> > cancellation requests.
> >
> > About your questions.
> > 1) I'm going to implements SQL view to provide list of running queries.
> The
> > SQL VIEW has been a little bit discussed earlier. Proposed name is
> > *running_queries* with following columns: query_id, node_id, sql,
> > schema_name, connection_id, duration. Currently most of the information
> can
> > be retrieved through cache API, however it doesn't matter, any case we
> > need to expose SQL VIEW. Seem's you are right - the part should be
> > implemented firstly.
> > 2) Fully agree that we need to support all kind of SQL queries
> > (SLECT/DML/DDL, transactional, non transnational, local, distributed). I
> > definitely sure that it will possible for all of above, however I'm not
> > sure about DDL - need to investigate it deeper. Also need to understand
> > that canceled DML operation can lead to partially updated data for non
> > transational caches.
> >
> >
> >
> > пн, 19 нояб. 2018 г. в 19:17, Vladimir Ozerov <voze...@gridgain.com>:
> >
> > > Hi Yuriy,
> > >
> > > I think we can use MANAGEMENT_POOL for this. It is already used for
> some
> > > internal Ignite tasks, and it appears to be a good candidate to process
> > > cancel requests.
> > >
> > > But there are several things which are not clear enough for me at the
> > > moment:
> > > 1) How user is going to get the list of running queries in the first
> > place?
> > > Do we already have any SQL commands/views to get this information?
> > > 2) We need to ensure that KILL command will be processed properly by
> all
> > > kinds of SQL queries - SELECT/DML/DDL, non-transactional or
> > transactional,
> > > local queries and distributed queries. Will we be able to support all
> > these
> > > modes?
> > >
> > > Vladimir.
> > >
> > > On Mon, Nov 19, 2018 at 6:37 PM Юрий <jury.gerzhedow...@gmail.com>
> > wrote:
> > >
> > > > Hi Igniters,
> > > >
> > > > Earlier we agreed about syntax KILL QUERY
> > '[node_order].[query_counter]',
> > > > e.g. KILL QUERY '25.123' for single query or KILL QUERY '25.*' for
> all
> > > > queries on the node. Which is part of IEP-29
> > > > <
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-29%3A+SQL+management+and+monitoring
> > > > >
> > > > .
> > > >
> > > > Now I want to discuss internal realization of KILL query feature.
> > > >
> > > > My current vision is following:
> > > > After parsing, Ignite create KILL query command with two parameters:
> > > > nodeOrderId, nodeQryId. To determine that need to kill all queries
> on a
> > > > node we can use negative value of query id, due to qry id always have
> > > > positive values.
> > > > The command process at IgniteH2Indexing as native command.
> > > > By nodeOrderId we find node which initial for the query and send to
> the
> > > > node new GridQueryKillRequest with nodeQryId to TOPIC_QUERY with not
> > > QUERY
> > > > POOL executor.
> > > > At GridReduceQueryExecutor we add support of processing new
> > > > GridQueryKillRequest
> > > > which just run already exists cancelQueries method with given qryId
> or
> > > with
> > > > all qryIds which currently running at the node in case at initial
> KILL
> > > > QUERY parameters used star symbol.
> > > >
> > > > I have a doubt which of thread pool we should use to process
> > > > GridQueryKillRequest.
> > > > My opinion it shouldn't be QUERY pool, due to the pool can be fully
> > used
> > > by
> > > > executing queries, it such case we can't cancel query immediately.
> May
> > we
> > > > use one of already existed pool or create new one? Or may be I'm
> > mistaken
> > > > and it should use QUERY pool.
> > > >
> > > > What do you think about proposed plan of implementation?
> > > >
> > > > And please give comments about which of thread pool will be better to
> > use
> > > > for kill query requests. It's small, but really important part of the
> > > > realization.
> > > >
> > > >
> > > > Thanks.
> > > >
> > > >
> > > > --
> > > > Живи с улыбкой! :D
> > > >
> > >
> >
> >
> > --
> > Живи с улыбкой! :D
> >
>
--
Живи с улыбкой! :D
