ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Denis Magda <dma...@apache.org>
Subject Re: proposed realization KILL QUERY command
Date Thu, 22 Nov 2018 00:22:55 GMT
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 <vozerov@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.gerzhedowich@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 <dmagda@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.gerzhedowich@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 <vozerov@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.gerzhedowich@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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message