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
>
