Yury,
Please give me a couple of days to read through the thread and respond.
Pretty busy these days, bare with me.
-
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
>
