From dev-return-44030-archive-asf-public=cust-asf.ponee.io@ignite.apache.org Tue Jan 15 09:21:00 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 6BB65180609 for ; Tue, 15 Jan 2019 09:20:59 +0100 (CET) Received: (qmail 91925 invoked by uid 500); 15 Jan 2019 08:20:58 -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 91913 invoked by uid 99); 15 Jan 2019 08:20:57 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd1-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 15 Jan 2019 08:20:57 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd1-us-west.apache.org (ASF Mail Server at spamd1-us-west.apache.org) with ESMTP id 97A0DC0650 for ; Tue, 15 Jan 2019 08:20:56 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd1-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: 3.311 X-Spam-Level: *** X-Spam-Status: No, score=3.311 tagged_above=-999 required=6.31 tests=[DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_LOW_CONTRAST=0.001, HTML_MESSAGE=2, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URI_HEX=1.313] autolearn=disabled Authentication-Results: spamd1-us-west.apache.org (amavisd-new); dkim=pass (2048-bit key) header.d=gridgain-com.20150623.gappssmtp.com Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd1-us-west.apache.org [10.40.0.7]) (amavisd-new, port 10024) with ESMTP id OrP2g0124sTj for ; Tue, 15 Jan 2019 08:20:52 +0000 (UTC) Received: from mail-vs1-f53.google.com (mail-vs1-f53.google.com [209.85.217.53]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTPS id D42D55F501 for ; Tue, 15 Jan 2019 08:20:51 +0000 (UTC) Received: by mail-vs1-f53.google.com with SMTP id e7so1143965vsc.2 for ; Tue, 15 Jan 2019 00:20:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gridgain-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=uQ+Mp1lIWC5rBGo1cM+6LgMeICx56RfXay/qJ926DKs=; b=IdlItnqrmP8xfxwY1sKsk9R5OoEThWDTTUIeDrI8YGj+TWSXK4tB/IFqAnBWxaSi40 XrGp44JY8JIVlWunDKMmZ4/avkuwriiaqBxi+EXXfzEEAkQJHi75KF9sXohRYCxZ6Y2r rXEjCnw1ZCefoIHfPeUZkMd4YQnp5zFr1T2rdKmtUlMzq7EMUU+wVknk6m7AgVyFFyUQ P7jXUGyd58EEnxco8Qx7qufRD4aKqLGDU5hXLGVA03jSIVeyTQo+78O2nH1GODXRiU2I aA1lohvk35VZvG7s8Ca/2qKEisujL2zXiyNq+C9Aq2hS28ANewBAzuzNV3L+PvCxJYcv oPsg== 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; bh=uQ+Mp1lIWC5rBGo1cM+6LgMeICx56RfXay/qJ926DKs=; b=WplZ44RMvw+7xgtgpVYRV/sUSIkNmS3WUcaHH+3qByhvn+Ri3ikH3UXM8SIgWbBMob 9IA00HBgLil9PUoTY7/I90PUBpDI6xdvfPEhm2dlCmmBxGawokhz4JrtUE43hA7kB9/r NmFKddvxEoU1rOLWjJvTpsT2atV1JVmjcPqexiqHdBj4bDL+FOIkNb9JF88ooS++kQp/ npePw626UObkX7Ad4CLANCtQ73ExUvAI5v0WVH12cp/ZRIRljos2q2c1h0a20LAT1XD8 DSOHt6eJIcZ3tvTC2euh+goOnQFu1JD5WUw+odrvnbz2K3RalmcGiDob5MvP1YQDENUh Fa+g== X-Gm-Message-State: AJcUukda8eebIv1NDg47mFD2THxs7NJ6ECv2u+BXYqBgyyepbrRvKVYG wR+JJO0yuR4RrxaKONBEZJm5FX9LKAiE7LknJs9L+AMPErQ= X-Google-Smtp-Source: ALg8bN7wxVoeRnrXcfOxtMWeSt01ZBcRPH0Kj7eQtTxDSu7sPtMKwjSt2bB3nPOW2AFEeFjWoZbXAXU2O5VeX2wNQtQ= X-Received: by 2002:a67:1346:: with SMTP id 67mr1014460vst.31.1547540445234; Tue, 15 Jan 2019 00:20:45 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Vladimir Ozerov Date: Tue, 15 Jan 2019 11:20:33 +0300 Message-ID: Subject: Re: proposed realization KILL QUERY command To: dev Content-Type: multipart/alternative; boundary="00000000000083a3b4057f7ad621" --00000000000083a3b4057f7ad621 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 =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 othe= r > 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 acro= ss > 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 fir= st > 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 lea= d > 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 id will b= e > 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 cluste= r. > 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. > > =D0=B2=D1=82, 27 =D0=BD=D0=BE=D1=8F=D0=B1. 2018 =D0=B3. =D0=B2 11:00, Vla= dimir Ozerov : > > > 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 > > 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 : > > > > > > > > I propose to start with running queries =D0=BC=D1=88=D1=83=D1=86 fi= rst. 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 > > > 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' o= r > > > > > KILL QUERY WHERE queryId =3D '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 =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-for= -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 : > > > > > > > > > > > > > > > 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. Withou= t > > > > > 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 wi= th > > > 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 fr= om > > > user > > > > > > > > > perspective > > > > > > > > > > and will killed on all nodes. User just need to known o= ne > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > =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 still should > > > consider > > > > > > > > > > > [node_order/id] as an optional parameter. > > > > > > > > > > > > > > > > > > > > > > Probably, if you explain to me how an end user will u= se > > > 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 f= or > > > > > 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 mos= t > 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. Als= o > > > 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 i= s > > > already > > > > > used > > > > > > > > for > > > > > > > > > > > some > > > > > > > > > > > > > internal Ignite tasks, and it appears to be a goo= d > > > > > 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 =D0=AE=D1=80=D0= =B8=D0=B9 < > > > > > > > > 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+manageme= nt+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 nati= ve > > > > > command. > > > > > > > > > > > > > > By nodeOrderId we find node which initial for t= he > > > 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 u= se > > to > > > > > process > > > > > > > > > > > > > > GridQueryKillRequest. > > > > > > > > > > > > > > My opinion it shouldn't be QUERY pool, due to t= he > > > 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. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > =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 > --00000000000083a3b4057f7ad621--