Agree, there is no need in an advanced syntax. The user just needs to know
how to find a query id. That's a documentation task.
-
Denis
On Wed, Jan 30, 2019 at 4:34 AM Vladimir Ozerov <voze...@gridgain.com>
wrote:
> Hi Yuriy,
>
> Agree that at the moment the simpler the better. Let's return to more
> complex syntax in future if needed. Regarding proposed syntax, please note
> that as query ID is not database object name but rather string literal,
> we'd better wrap it into quotes to keep syntax consistency across commands:
>
> KILL QUERY '8a55df83-2f41-4f81-8e11-ab0936d00000_6742';
>
> Vladimir.
>
> On Wed, Jan 30, 2019 at 3:09 PM Юрий <jury.gerzhedow...@gmail.com> wrote:
>
> > 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
> >
>
