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
