Slava, Not sure I've understand a question. JMX supports security via password protection and secure channel.
пт, 17 янв. 2020 г. в 14:30, Вячеслав Коптилин <slava.kopti...@gmail.com>: > Hello Nikolay, > > I'm not sure we need JMX API for this case. If I’m not mistaken, it’s about > the administrator’s ability to cancel any task/query in the cluster, and in > my opinion, such action must require administrator permission. > Could you please clarify how it can be done via JMX? I mean permission > check and etc. Perhaps, I'm missing something obvious... > > Thanks, > S. > > чт, 16 янв. 2020 г. в 15:46, Николай Ижиков <nizhi...@apache.org>: > > > Alexey. > > > > I think, yes. > > We certainly should be able to use system view data for the new KILL API. > > > > I think we should support both SQL and Java(JMX) API for this KILL > command. > > > > > > > 16 янв. 2020 г., в 15:28, Alexei Scherbakov < > > alexey.scherbak...@gmail.com> написал(а): > > > > > > Nikolaj, > > > > > > Can we use system views instead of implementing something new ? > > > > > > Each user operation has an unique ID. > > > > > > It's possible to introduce universal SQL kill something like: > > > > > > kill transaction ID > > > > > > where id is taken from system view. > > > > > > > > > чт, 16 янв. 2020 г. в 14:19, Николай Ижиков <nizhi...@apache.org>: > > > > > >> Hello, Alexey. > > >> > > >> I’m talking about *administrator* API. > > >> > > >> For example, the User has a cluster that is used by several > > applications. > > >> Some application starts buggy compute tasks that consume all CPU > > resources. > > >> Right now, administrator doesn’t have the ability to kill this task. > > >> > > >> This can lead to instability of the whole cluster. > > >> > > >> > > >>> 16 янв. 2020 г., в 13:42, Alexei Scherbakov < > > >> alexey.scherbak...@gmail.com> написал(а): > > >>> > > >>> Transactions can be also rolled back using tx.close where close is > > >>> java.lang.AutoCloseable#close > > >>> It looks for me to the definition of uniform cancel API. > > >>> > > >>> > > >>> > > >>> чт, 16 янв. 2020 г. в 13:37, Alexei Scherbakov < > > >> alexey.scherbak...@gmail.com > > >>>> : > > >>> > > >>>> Nikolaj, > > >>>> > > >>>> We already have cancellation possibilities for almost every user > > >>>> computation. > > >>>> Transactions are cancelled using tx.rollback() > > >>>> Queries are cancelled using query.close() > > >>>> Task is cancellable through ComputeTaskSession > > >>>> > > >>>> What is uniform cancel API ? Why do we need it ? > > >>>> > > >>>> > > >>>> > > >>>> ср, 15 янв. 2020 г. в 21:30, Николай Ижиков <nizhi...@apache.org>: > > >>>> > > >>>>> Hello, Igniters. > > >>>>> > > >>>>> As you may know, we put a lot of effort to improve Ignite metric > and > > >>>>> diagnostic API. > > >>>>> We have created the following API: > > >>>>> * Metric manager > > >>>>> * System view manager > > >>>>> As far as I know, we would have tracing capabilities soon. > > >>>>> > > >>>>> I think it's time to take the next step. > > >>>>> We should provide to the administrator the API to cancel(stop, > kill) > > >>>>> arbitrary user started computation. > > >>>>> > > >>>>> Right now we have API to do it for: > > >>>>> * transactions `TransactionsMXBean#getActiveTransactions`. > > >>>>> * SQL queries: `KILL QUERY` sql command and visor task - > > >>>>> `VisorQueryCancelTask` > > >>>>> > > >>>>> Please, note, these features are implemented via different API. > > >>>>> > > >>>>> I think we should introduce uniform Cancel API for the following > > >>>>> computations: > > >>>>> > > >>>>> * service. > > >>>>> * specific service method execution. > > >>>>> * compute job(compute task). > > >>>>> * query(scan, continuous, text). > > >>>>> > > >>>>> We should also rework kill transaction and kill SQL queries API to > > >> make > > >>>>> them similar to each other. > > >>>>> I have plans to write an IEP for it and implement it. > > >>>>> What do you think? > > >>>>> > > >>>>> > > >>>> > > >>>> -- > > >>>> > > >>>> Best regards, > > >>>> Alexei Scherbakov > > >>>> > > >>> > > >>> > > >>> -- > > >>> > > >>> Best regards, > > >>> Alexei Scherbakov > > >> > > >> > > > > > > -- > > > > > > Best regards, > > > Alexei Scherbakov > > > > > -- Best regards, Alexei Scherbakov
