From dev-return-44422-archive-asf-public=cust-asf.ponee.io@ignite.apache.org Wed Jan 30 12:09:28 2019 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 8EEE3180677 for ; Wed, 30 Jan 2019 13:09:26 +0100 (CET) Received: (qmail 74054 invoked by uid 500); 30 Jan 2019 12:09:25 -0000 Mailing-List: contact dev-help@ignite.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@ignite.apache.org Delivered-To: mailing list dev@ignite.apache.org Received: (qmail 73572 invoked by uid 99); 30 Jan 2019 12:09:24 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd4-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 30 Jan 2019 12:09:24 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd4-us-west.apache.org (ASF Mail Server at spamd4-us-west.apache.org) with ESMTP id 743E5C25CF for ; Wed, 30 Jan 2019 12:09:24 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd4-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 4.216 X-Spam-Level: **** X-Spam-Status: No, score=4.216 tagged_above=-999 required=6.31 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_REPLY=1, FROM_EXCESS_BASE64=0.105, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URI_HEX=1.313] autolearn=disabled Authentication-Results: spamd4-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd4-us-west.apache.org [10.40.0.11]) (amavisd-new, port 10024) with ESMTP id wMmECoOU466y for ; Wed, 30 Jan 2019 12:09:20 +0000 (UTC) Received: from mail-vs1-f42.google.com (mail-vs1-f42.google.com [209.85.217.42]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id 894F05F16A for ; Wed, 30 Jan 2019 12:09:19 +0000 (UTC) Received: by mail-vs1-f42.google.com with SMTP id x1so14066848vsc.10 for ; Wed, 30 Jan 2019 04:09:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zFbyHQ/EdcDCUgzAtCj8DN+e2qQgczyrwzHSwzFeFqU=; b=WbtBbVwhARMnsjM/uCKVhl9JKcAhWpLKYVfqePJW2iu1Z5MvLlwFXroxRWdGsyoAvx kaF4E1442KjfkLNlbYRwQU4YJhAQnCMY+BGj+QHdip8nHeh886rxB3mnJcvFNiYtf19B mu6h3pocJUtWwGDs0sttlEWG1qJ43U4ExQDL8/P2CVCF0pkiNA9SKVAgmMVqNFcTSEIn bZotLl34gKZgGWAPggQRP3p9kc+/hnzcx8HZUBC/tgYUbgygI0zSZKeJnw+U6p2Kv1bk BuNHIqx7ss1GCcvnwEqS3Pi61ighMujlZrfLjDLoKra3CJl4apznpb/R3fA09ElDb0KU hIUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=zFbyHQ/EdcDCUgzAtCj8DN+e2qQgczyrwzHSwzFeFqU=; b=fenGDZ9B4dlYXeIFzcfpkxK2SeNlRlLekd30HfQ3KwvPBd77x3lvpicH0+4SrwQ8Sg P0HGVqgRJqrUI3bZ9uLpKMkOIEncuV9/rhUORCLWlPikiPBAydaAg83DgO6tG4ti/m9F rkMVdmyGNamPcYRz2YNSJ99Hb0CEzKniNA1T0KIQFW84oH+R1pe8ESMd3zJI4vNvVnDH +/DLUQ05bAMFdnZ86jURMa+nyW3uxozgYbjhMlYL2gB92V2GePvYytLitEUoq4V1puqP oWbXpGhiAaqj1gM5RUGd7cIacXlMXBesgDwHVhJu8f2vsxVXT5U3wW5GRNr5RXastRyR LLTw== X-Gm-Message-State: AJcUukc0hasid0jUxd4EW+uKDMz6P7Z6/IWJ54EMBqjogm5l4yy5SQuY WexK+1G/XDkcDJX/G1ejgHQykIHwmNVAD1CIraY= X-Google-Smtp-Source: ALg8bN4CIRu9wbM9s1IGkepDWq7UZPTQG55D/KI1wdldxWD1/Ms6DlZ+e0FZvZFFeZKR+UXgSP6V38CClZxjb1t1svo= X-Received: by 2002:a67:d609:: with SMTP id n9mr11310438vsj.74.1548850157912; Wed, 30 Jan 2019 04:09:17 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?B?0K7RgNC40Lk=?= Date: Wed, 30 Jan 2019 15:09:05 +0300 Message-ID: Subject: Re: proposed realization KILL QUERY command To: Denis Magda Cc: dev Content-Type: multipart/alternative; boundary="000000000000790b3f0580abc724" --000000000000790b3f0580abc724 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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() and SELECT pg_terminate_backend() - *MySQL*: KILL QUERY 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. =D1=81=D1=80, 16 =D1=8F=D0=BD=D0=B2. 2019 =D0=B3. =D0=B2 18:02, Denis Magda= : > Yury, > > I do support the latter concatenation approach. It's simple and correlate= s > 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 i= d > can halt it everywhere. If someone decided to shut all queries on the nod= e, > 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 =D0=AE=D1=80=D0=B8=D0=B9 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 he= x >> values (shorter id, but with letters)? >> >> As for me hex values preferable due to it shorter and looks more unique >> across a logs >> >> >> >> =D0=B2=D1=82, 15 =D1=8F=D0=BD=D0=B2. 2019 =D0=B3. =D0=B2 18:35, Vladimir= Ozerov : >> >>> 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 =D0=AE=D1=80=D0=B8=D0=B9 >>> 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 =3D 1234X8753 , where *1234* - node order, *8753* - local no= de >>> query >>> > counter. *X* - delimeter >>> > >>> > 2) Converting both node order id and query id to HEX. >>> > >>> > query_id =3D 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=3D7BX3C86 - for killing concrete query. >>> > >>> > KILL QUERY WHERE nodeId=3D37d7afd8-b87d-4aa1-b3d1-c1c033800000 - for >>> kill >>> > all running queries on a given node. >>> > >>> > >>> > >>> > What do you think? >>> > >>> > >>> > =D0=B2=D1=82, 15 =D1=8F=D0=BD=D0=B2. 2019 =D0=B3. =D0=B2 11:20, Vladi= mir Ozerov : >>> > >>> > > Hi Yuriy, >>> > > >>> > > I think all proposed approaches might work. The question is what is >>> the >>> > > most convenient from user perspective. Encoded values without speci= al >>> > > 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 l= og >>> > > messages. This will be very useful for debugging purposes, e.g. gre= p >>> over >>> > > logs. So ideally query ID should not have any symbols which interfe= re >>> > with >>> > > grep syntax. >>> > > >>> > > >>> > > On Mon, Jan 14, 2019 at 3:09 PM =D0=AE=D1=80=D0=B8=D0=B9 >>> > 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 f= or >>> > 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=3D >>> > > > 37d7afd8-b87d-4aa1-b3d1-c1c033800000 and queryId=3D67321 >>> > > > >>> > > > 3) Use base16String(concat(node,".",queryID) as query id, e.g. ' >>> > > > 3132332E393337'. Then we hide internal structure of id and such i= d >>> 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_i= d >>> > column >>> > > > for Ignite. Also confirm list of columns. >>> > > > >>> > > > =D0=B2=D1=82, 27 =D0=BD=D0=BE=D1=8F=D0=B1. 2018 =D0=B3. =D0=B2 11= :00, Vladimir Ozerov < >>> vozerov@gridgain.com>: >>> > > > >>> > > > > Yes ("=D0=BD=D1=83=D1=8B") >>> > > > > >>> > > > > On Tue, Nov 27, 2018 at 10:56 AM =D0=9F=D0=B0=D0=B2=D0=BB=D1=83= =D1=85=D0=B8=D0=BD =D0=98=D0=B2=D0=B0=D0=BD < >>> vololo100@gmail.com> >>> > > > > wrote: >>> > > > > >>> > > > > > I believe that the meaning was: >>> > > > > > >>> > > > > > > I propose to start with running queries VIEW first. >>> > > > > > =D0=B2=D1=82, 27 =D0=BD=D0=BE=D1=8F=D0=B1. 2018 =D0=B3. =D0= =B2 10:47, Vladimir Ozerov < >>> > vozerov@gridgain.com >>> > > >: >>> > > > > > > >>> > > > > > > I propose to start with running queries =D0=BC=D1=88=D1=83= =D1=86 first. Once we >>> have >>> > > it, >>> > > > it >>> > > > > > > will be easier to agree on final command syntax. >>> > > > > > > >>> > > > > > > On Fri, Nov 23, 2018 at 9:32 AM =D0=9F=D0=B0=D0=B2=D0=BB=D1= =83=D1=85=D0=B8=D0=BD =D0=98=D0=B2=D0=B0=D0=BD < >>> > vololo100@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 specif= ic >>> > 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 =3D '123' >>> > > > > > > > For killing all queries started by some node we need to u= se >>> > only >>> > > > node >>> > > > > > > > order (or id). It could be like KILL QUERY WHERE nodeOrde= r >>> =3D >>> > 34. >>> > > > > > > > =D1=87=D1=82, 22 =D0=BD=D0=BE=D1=8F=D0=B1. 2018 =D0=B3. = =D0=B2 12:56, Denis Mekhanikov < >>> > > > > dmekhanikov@gmail.com >>> > > > > > >: >>> > > > > > > > > >>> > > > > > > > > Actually, option with separate parameters was mentioned >>> in >>> > > > another >>> > > > > > thread >>> > > > > > > > > >>> > > > > > > > >>> > > > > > >>> > > > > >>> > > > >>> > > >>> > >>> http://apache-ignite-developers.2346864.n4.nabble.com/proposed-design-f= or-thin-client-SQL-management-and-monitoring-view-running-queries-and-kill-= it-tp37713p38056.html >>> > > > > > > > > >>> > > > > > > > > Denis >>> > > > > > > > > >>> > > > > > > > > =D1=87=D1=82, 22 =D0=BD=D0=BE=D1=8F=D0=B1. 2018 =D0=B3.= =D0=B2 08:51, Vladimir Ozerov < >>> > > > > vozerov@gridgain.com >>> > > > > > >: >>> > > > > > > > > >>> > > > > > > > > > Denis, >>> > > > > > > > > > >>> > > > > > > > > > Problems with separate parameters are explained above= . >>> > > > > > > > > > >>> > > > > > > > > > =D1=87=D1=82, 22 =D0=BD=D0=BE=D1=8F=D0=B1. 2018 =D0= =B3. =D0=B2 3:23, Denis Magda < >>> > dmagda@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=3D10 [AND node_id=3D5] >>> > > > > > > > > > > >>> > > > > > > > > > > -- >>> > > > > > > > > > > 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 =D0=AE=D1=80=D0= =B8=D0=B9 < >>> > > > > > 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 | 2345= 6 >>> > > > > > > > > > > > > 333.31 | aaa6acb8-a4a5-42f6-f842-ead111b000= 20 >>> > | >>> > > > > > > > UPDATE... | >>> > > > > > > > > > > ... >>> > > > > > > > > > > > > | 321 | 34677= 77 >>> > > > > > > > > > > > > 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. >>> > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > > =D1=81=D1=80, 21 =D0=BD=D0=BE=D1=8F=D0=B1. 2018= =D0=B3. =D0=B2 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 stil= l >>> > should >>> > > > > > consider >>> > > > > > > > > > > > > > [node_order/id] as an optional parameter. >>> > > > > > > > > > > > > > >>> > > > > > > > > > > > > > Probably, if you explain to me how an end use= r >>> 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 =D0=AE=D1=80= =D0=B8=D0=B9 < >>> > > > > > > > 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. >>> > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > =D0=BF=D0=BD, 19 =D0=BD=D0=BE=D1=8F=D0=B1. = 2018 =D0=B3. =D0=B2 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 no= t >>> > 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 =D0=AE=D1= =80=D0=B8=D0=B9 < >>> > > > > > > > > > > jury.gerzhedowich@gmail.com> >>> > > > > > > > > > > > > > > wrote: >>> > > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > Hi Igniters, >>> > > > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > Earlier we agreed about syntax KILL QUE= RY >>> > > > > > > > > > > > > > > '[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+manage= ment+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 th= at >>> > 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 t= he >>> > 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 o= f >>> > > > > > implementation? >>> > > > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > And please give comments about which of >>> > thread >>> > > > pool >>> > > > > > will >>> > > > > > > > be >>> > > > > > > > > > > > better >>> > > > > > > > > > > > > to >>> > > > > > > > > > > > > > > use >>> > > > > > > > > > > > > > > > > for kill query requests. It's small, bu= t >>> > really >>> > > > > > important >>> > > > > > > > > > part >>> > > > > > > > > > > of >>> > > > > > > > > > > > > the >>> > > > > > > > > > > > > > > > > realization. >>> > > > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > Thanks. >>> > > > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > > -- >>> > > > > > > > > > > > > > > > > =D0=96=D0=B8=D0=B2=D0=B8 =D1=81 =D1=83= =D0=BB=D1=8B=D0=B1=D0=BA=D0=BE=D0=B9! :D >>> > > > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > > -- >>> > > > > > > > > > > > > > > =D0=96=D0=B8=D0=B2=D0=B8 =D1=81 =D1=83=D0= =BB=D1=8B=D0=B1=D0=BA=D0=BE=D0=B9! :D >>> > > > > > > > > > > > > > > >>> > > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > > >>> > > > > > > > > > > > > -- >>> > > > > > > > > > > > > =D0=96=D0=B8=D0=B2=D0=B8 =D1=81 =D1=83=D0=BB=D1= =8B=D0=B1=D0=BA=D0=BE=D0=B9! :D >>> > > > > > > > > > > > > >>> > > > > > > > > > > > >>> > > > > > > > > > > >>> > > > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> > > > > > > > >>> > > > > > > > -- >>> > > > > > > > Best regards, >>> > > > > > > > Ivan Pavlukhin >>> > > > > > > > >>> > > > > > >>> > > > > > >>> > > > > > >>> > > > > > -- >>> > > > > > Best regards, >>> > > > > > Ivan Pavlukhin >>> > > > > > >>> > > > > >>> > > > >>> > > > >>> > > > -- >>> > > > =D0=96=D0=B8=D0=B2=D0=B8 =D1=81 =D1=83=D0=BB=D1=8B=D0=B1=D0=BA=D0= =BE=D0=B9! :D >>> > > > >>> > > >>> > >>> > >>> > -- >>> > =D0=96=D0=B8=D0=B2=D0=B8 =D1=81 =D1=83=D0=BB=D1=8B=D0=B1=D0=BA=D0=BE= =D0=B9! :D >>> > >>> >> >> >> -- >> =D0=96=D0=B8=D0=B2=D0=B8 =D1=81 =D1=83=D0=BB=D1=8B=D0=B1=D0=BA=D0=BE=D0= =B9! :D >> > --=20 =D0=96=D0=B8=D0=B2=D0=B8 =D1=81 =D1=83=D0=BB=D1=8B=D0=B1=D0=BA=D0=BE=D0=B9!= :D --000000000000790b3f0580abc724--