Hi Igniters,
Let's return to KILL QUERY command. Previously we mostly discussed about
two variants of format:
1) simple - KILL QUERY {running_query_id}
2) advanced syntax - KILL QUERY WHERE {parameters}. Parameters seems can be
any columns from running queries view or just part of them.
I've checked approaches used by Industrial RDBMS vendors :
-
- *ORACLE*: ALTER SYSTEM CANCEL SQL 'SID, SERIAL, SQL_ID'
-
- *Postgres*: SELECT pg_cancel_backend(<pid of the process>) and
SELECT pg_terminate_backend(<pid of the process>)
- *MySQL*: KILL QUERY <qry_Id>
As we see all of them use simple syntax to cancel a query and can't do some
filters.
IMHO simple *KILL QUERY qry_id* better for the few reasons.
User can kill just single query belong (started) to single node and it will
be exactly that query which was passed as parameter - predictable results.
For advance syntax it could lead send kill request to all nodes in a
cluster and potentially user can kill unpredictable queries depend on
passed parameters.
Other vendors use simple syntax
How it could be used
1)SELECT * from sql_running_queries
result is
query_id
| sql | schema_name | duration | ....
8a55df83-2f41-4f81-8e11-ab0936d00000_6742 | SELECT ... | ...
| .... | ....
8a55df83-2f41-4f81-8e11-ab0936d00000_1234 | UPDATE... | ...
| ...... | ....
2) KILL QUERY 8a55df83-2f41-4f81-8e11-ab0936d00000_6742
Do you have another opinion? Let's decide which of variant will be prefer.
ср, 16 янв. 2019 г. в 18:02, Denis Magda <dma...@apache.org>:
> Yury,
>
> I do support the latter concatenation approach. It's simple and correlates
> with what other DBs do. Plus, it can be passed to KILL command without
> complications. Thanks for thinking this through!
>
> As for the killing of all queries on a particular node, not sure that's a
> relevant use case. I would put this off. Usually, you want to stop a
> specific query (it's slow or resources consuming) and have to know its id,
> the query runs across multiple nodes and a single KILL command with the id
> can halt it everywhere. If someone decided to shut all queries on the node,
> then it sounds like the node is experiencing big troubles and it might be
> better just to shut it down completely.
>
> -
> Denis
>
>
> On Tue, Jan 15, 2019 at 8:00 AM Юрий <jury.gerzhedow...@gmail.com> wrote:
>
>> Denis and other Igniters, do you have any comments for proposed approach?
>> Which of these ones will be better to use for us - simple numeric or hex
>> values (shorter id, but with letters)?
>>
>> As for me hex values preferable due to it shorter and looks more unique
>> across a logs
>>
>>
>>
>> вт, 15 янв. 2019 г. в 18:35, Vladimir Ozerov <voze...@gridgain.com>:
>>
>>> Hi,
>>>
>>> Concatenation through a letter looks like a good approach to me. As far
>>> as
>>> killing all queries on a specific node, I would put it aside for now -
>>> this
>>> looks like a separate command with possibly different parameters.
>>>
>>> On Tue, Jan 15, 2019 at 1:30 PM Юрий <jury.gerzhedow...@gmail.com>
>>> wrote:
>>>
>>> > Thanks Vladimir for your thoughts.
>>> >
>>> > Based on it most convenient ways are first and third.
>>> > But with some modifications:
>>> > For first variant delimiter should be a letter, e.g. 123X15494, then it
>>> > could be simple copy by user.
>>> > For 3rd variant can be used convert both numeric to HEX and use a
>>> letter
>>> > delimiter not included to HEX symbols (ABCDEF), in this case query id
>>> will
>>> > be shorter and also can be simple copy by user. e.g. 7BX3C86 ( it the
>>> same
>>> > value as used for first variant), instead of convert all value as
>>> string to
>>> > base16 due to it will be really long value.
>>> >
>>> > Possible realization for the cases:
>>> > 1) Concatenation node order id with query id with a letter delimiter.
>>> >
>>> > query_id = 1234X8753 , where *1234* - node order, *8753* - local node
>>> query
>>> > counter. *X* - delimeter
>>> >
>>> > 2) Converting both node order id and query id to HEX.
>>> >
>>> > query_id = 7BX3C86, value is concat(hex(node),"X",hex(queryID))
>>> >
>>> > For both variants we can use either simple or copmlex KILL QUERY
>>> syntax.
>>> > Simple:
>>> >
>>> > KILL QUERY 7BX3C86 - for kill concrete query
>>> > KILL QUERY 7B - for killing all queries on a node. May be need extra
>>> > symbols for such queries to avoid fault of user and kill all queries by
>>> > mistake, like KILL QUERY 7B*
>>> >
>>> > Complex:
>>> >
>>> > KILL QUERY WHERE queryId=7BX3C86 - for killing concrete query.
>>> >
>>> > KILL QUERY WHERE nodeId=37d7afd8-b87d-4aa1-b3d1-c1c033800000 - for
>>> kill
>>> > all running queries on a given node.
>>> >
>>> >
>>> >
>>> > What do you think?
>>> >
>>> >
>>> > вт, 15 янв. 2019 г. в 11:20, Vladimir Ozerov <voze...@gridgain.com>:
>>> >
>>> > > Hi Yuriy,
>>> > >
>>> > > I think all proposed approaches might work. The question is what is
>>> the
>>> > > most convenient from user perspective. Encoded values without special
>>> > > characters are good because they are easy to copy with mouse
>>> > (double-click)
>>> > > or keyboard (Ctrl+Shift+arrow). On the other hand, ability to
>>> identify
>>> > > ID/name of suspicious node from query ID is also a good thing.
>>> Several
>>> > > examples of query ID:
>>> > >
>>> > > CockroachDB: 14dacc1f9a781e3d0000000000000001
>>> > > MongoDB: shardB:79014
>>> > >
>>> > > Also it is important that the same query ID is printed in various log
>>> > > messages. This will be very useful for debugging purposes, e.g. grep
>>> over
>>> > > logs. So ideally query ID should not have any symbols which interfere
>>> > with
>>> > > grep syntax.
>>> > >
>>> > >
>>> > > On Mon, Jan 14, 2019 at 3:09 PM Юрий <jury.gerzhedow...@gmail.com>
>>> > wrote:
>>> > >
>>> > > > Hi Igniters,
>>> > > >
>>> > > > Earlier we discuss about columns for running queries. Let's
>>> summarize
>>> > it
>>> > > > and continue discussion for not closed questions.
>>> > > >
>>> > > > What we had:
>>> > > > *name of view**: *running_queries
>>> > > > *columns and meaning*:
>>> > > > query_id - unique id of query on node
>>> > > > node_id - initial node of request.
>>> > > > sql - text of query
>>> > > > schema_name - name of sql schema
>>> > > > duration - duration in milliseconds from
>>> start
>>> > of
>>> > > > execution.
>>> > > >
>>> > > > All of this columns are clear, except query_id.
>>> > > > Let's keep in mind that the query_id column of the view coupled
>>> with
>>> > KILL
>>> > > > QUERY command.
>>> > > >
>>> > > > We have the following variants what is query_id:
>>> > > > 1) It's string, internally with two parts separated by '.'(it can
>>> be
>>> > > other
>>> > > > separator): numeric node order and numeric query counter unique for
>>> > local
>>> > > > node, e.g. '172.67321'. For this case query id will be really
>>> unique
>>> > > across
>>> > > > a cluster, but can be looks a strange for a user, especially in
>>> case we
>>> > > > will have ability to kill all queries on a node, when user should
>>> get
>>> > > first
>>> > > > part before separator to use it, e.g. KILL QUERY '172.*'.
>>> > > >
>>> > > > 2) Just single numeric id, unique for local node, e.g '127'. In
>>> this
>>> > case
>>> > > > we need more complicated syntax for further KILL QUERY command,
>>> which
>>> > > lead
>>> > > > to use two columns from the view, e.g. KILL QUERY WHERE nodeId=
>>> > > > 37d7afd8-b87d-4aa1-b3d1-c1c033800000 and queryId=67321
>>> > > >
>>> > > > 3) Use base16String(concat(node,".",queryID) as query id, e.g. '
>>> > > > 3132332E393337'. Then we hide internal structure of id and such id
>>> will
>>> > > be
>>> > > > unique across a cluster. However we will need use complicated
>>> syntax
>>> > for
>>> > > > KILL QUERY command as for 2nd case.
>>> > > >
>>> > > > 4) Just single numeric id, unique for local node, e.g '127'. But
>>> user
>>> > > > should use two columns to merge it and create query id unique in a
>>> > > cluster.
>>> > > > Such approach use by Oracle:ALTER SYSTEM CANCEL SQL 'SID, SERIAL,
>>> > > SQL_ID'.
>>> > > > In this case user will know real meaning of each part of passed
>>> > parameter
>>> > > > for KILL QUERY command. But it hard to use.
>>> > > >
>>> > > > 5) Any other approach you can think of....
>>> > > >
>>> > > > If be honestly I prefer first variant, it looks simple to use by
>>> user
>>> > (it
>>> > > > require read a docs, but any case it required for any use cases).
>>> > > >
>>> > > > Lets discuss it again and chose better approach to expose query_id
>>> > column
>>> > > > for Ignite. Also confirm list of columns.
>>> > > >
>>> > > > вт, 27 нояб. 2018 г. в 11:00, Vladimir Ozerov <
>>> voze...@gridgain.com>:
>>> > > >
>>> > > > > Yes ("нуы")
>>> > > > >
>>> > > > > On Tue, Nov 27, 2018 at 10:56 AM Павлухин Иван <
>>> vololo...@gmail.com>
>>> > > > > wrote:
>>> > > > >
>>> > > > > > I believe that the meaning was:
>>> > > > > >
>>> > > > > > > I propose to start with running queries VIEW first.
>>> > > > > > вт, 27 нояб. 2018 г. в 10:47, Vladimir Ozerov <
>>> > voze...@gridgain.com
>>> > > >:
>>> > > > > > >
>>> > > > > > > I propose to start with running queries мшуц first. Once we
>>> have
>>> > > it,
>>> > > > it
>>> > > > > > > will be easier to agree on final command syntax.
>>> > > > > > >
>>> > > > > > > On Fri, Nov 23, 2018 at 9:32 AM Павлухин Иван <
>>> > vololo...@gmail.com
>>> > > >
>>> > > > > > wrote:
>>> > > > > > >
>>> > > > > > > > Hi,
>>> > > > > > > >
>>> > > > > > > > May be I am a little bit late with my thoughts about a
>>> command
>>> > > > > syntax.
>>> > > > > > > > How do I see it is going to be used:
>>> > > > > > > > 1. A user is able to kill a query by unique id belonging
>>> only
>>> > to
>>> > > > this
>>> > > > > > > > query.
>>> > > > > > > > 2. A user is able to kill all queries started by a specific
>>> > node.
>>> > > > > > > > For killing a single query we must identify it by unique id
>>> > which
>>> > > > is
>>> > > > > > > > going to be received directly from Ignite (e.g. running
>>> queries
>>> > > > view)
>>> > > > > > > > and not calculated by user. Internally the id is compound
>>> but
>>> > why
>>> > > > > > > > cannot we convert it to opaque integer or string which
>>> hides
>>> > real
>>> > > > > > > > structure? E.g. base16String(concat(nodeOrder.toString(),
>>> ".",
>>> > > > > > > > queryIdOnNode.toString())) The syntax could be KILL QUERY
>>> '123'
>>> > > or
>>> > > > > > > > KILL QUERY WHERE queryId = '123'
>>> > > > > > > > For killing all queries started by some node we need to use
>>> > only
>>> > > > node
>>> > > > > > > > order (or id). It could be like KILL QUERY WHERE nodeOrder
>>> =
>>> > 34.
>>> > > > > > > > чт, 22 нояб. 2018 г. в 12:56, Denis Mekhanikov <
>>> > > > > dmekhani...@gmail.com
>>> > > > > > >:
>>> > > > > > > > >
>>> > > > > > > > > Actually, option with separate parameters was mentioned
>>> in
>>> > > > another
>>> > > > > > thread
>>> > > > > > > > >
>>> > > > > > > >
>>> > > > > >
>>> > > > >
>>> > > >
>>> > >
>>> >
>>> http://apache-ignite-developers.2346864.n4.nabble.com/proposed-design-for-thin-client-SQL-management-and-monitoring-view-running-queries-and-kill-it-tp37713p38056.html
>>> > > > > > > > >
>>> > > > > > > > > Denis
>>> > > > > > > > >
>>> > > > > > > > > чт, 22 нояб. 2018 г. в 08:51, Vladimir Ozerov <
>>> > > > > voze...@gridgain.com
>>> > > > > > >:
>>> > > > > > > > >
>>> > > > > > > > > > Denis,
>>> > > > > > > > > >
>>> > > > > > > > > > Problems with separate parameters are explained above.
>>> > > > > > > > > >
>>> > > > > > > > > > чт, 22 нояб. 2018 г. в 3:23, Denis Magda <
>>> > dma...@apache.org
>>> > > >:
>>> > > > > > > > > >
>>> > > > > > > > > > > Vladimir,
>>> > > > > > > > > > >
>>> > > > > > > > > > > All of the alternatives are reminiscent of
>>> mathematical
>>> > > > > > operations.
>>> > > > > > > > Don't
>>> > > > > > > > > > > look like a SQL command. What if we use a SQL
>>> approach
>>> > > > > > introducing
>>> > > > > > > > named
>>> > > > > > > > > > > parameters:
>>> > > > > > > > > > >
>>> > > > > > > > > > > KILL QUERY query_id=10 [AND node_id=5]
>>> > > > > > > > > > >
>>> > > > > > > > > > > --
>>> > > > > > > > > > > Denis
>>> > > > > > > > > > >
>>> > > > > > > > > > > On Wed, Nov 21, 2018 at 4:11 AM Vladimir Ozerov <
>>> > > > > > > > voze...@gridgain.com>
>>> > > > > > > > > > > wrote:
>>> > > > > > > > > > >
>>> > > > > > > > > > > > Denis,
>>> > > > > > > > > > > >
>>> > > > > > > > > > > > Space is bad candidate because it is a whitespace.
>>> > > Without
>>> > > > > > > > whitespaces
>>> > > > > > > > > > we
>>> > > > > > > > > > > > can have syntax without quotes at all. Any
>>> > non-whitespace
>>> > > > > > delimiter
>>> > > > > > > > > > will
>>> > > > > > > > > > > > work, though:
>>> > > > > > > > > > > >
>>> > > > > > > > > > > > KILL QUERY 45.1
>>> > > > > > > > > > > > KILL QUERY 45-1
>>> > > > > > > > > > > > KILL QUERY 45:1
>>> > > > > > > > > > > >
>>> > > > > > > > > > > > On Wed, Nov 21, 2018 at 3:06 PM Юрий <
>>> > > > > > jury.gerzhedow...@gmail.com>
>>> > > > > > > > > > > wrote:
>>> > > > > > > > > > > >
>>> > > > > > > > > > > > > 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
>>> > > > > > > > > > > > >
>>> > > > > > > > > > > >
>>> > > > > > > > > > >
>>> > > > > > > > > >
>>> > > > > > > >
>>> > > > > > > >
>>> > > > > > > >
>>> > > > > > > > --
>>> > > > > > > > Best regards,
>>> > > > > > > > Ivan Pavlukhin
>>> > > > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > >
>>> > > > > > --
>>> > > > > > Best regards,
>>> > > > > > Ivan Pavlukhin
>>> > > > > >
>>> > > > >
>>> > > >
>>> > > >
>>> > > > --
>>> > > > Живи с улыбкой! :D
>>> > > >
>>> > >
>>> >
>>> >
>>> > --
>>> > Живи с улыбкой! :D
>>> >
>>>
>>
>>
>> --
>> Живи с улыбкой! :D
>>
>
--
Живи с улыбкой! :D
