[DISCUSSION] API to KILL any user started computation

[Alexei Scherbakov]

Nick

I see no difficulty in assinging each cancellable object an IgniteUuid
(which is actually java UUID and is guaranteed to be unique per node).
We can have registry of running queries and just poking to what registry is
enough to understand query type.

чт, 6 февр. 2020 г. в 17:17, Вячеслав Коптилин <[hidden email]>:

> Hello,
>
> It seems to me we missed API that should be introduced into control
> utility.
> Nikolay, could you please note this requirement on the IEP page?
>
> Thanks,
> S.
>
> чт, 6 февр. 2020 г. в 15:29, Nikolay Izhikov <[hidden email]>:
>
> > Ticket [1] created.
> >
> > [1] https://issues.apache.org/jira/browse/IGNITE-12632
> >
> > > 5 февр. 2020 г., в 15:36, Nikolay Izhikov <[hidden email]>
> > написал(а):
> > >
> > > Alexey.
> > >
> > > I’m talking the following scenario:
> > >
> > > 1. Consider we have unified bean to kill tasks:
> > >
> > > CancelMXBean {
> > >       public void cancel(long id);
> > > }
> > >
> > > 2. And we have the following log:
> > >
> > > ```
> > > Transaction with ID=42 started.
> > > Compute task with ID=43 started.
> > > ```
> > >
> > > 3. We want to kill compute task and by mistake executing:
> > >
> > > cancelMxBean.cancel(42); //This will kill transaction not compute task.
> > >
> > > The user doesn’t have a chance to know, what type of object he is
> > killing.
> > > I think we should prevent this type of error by the API design.
> > >
> > >
> > >> 5 февр. 2020 г., в 14:43, Alexey Goncharuk <
> [hidden email]>
> > написал(а):
> > >>
> > >> Nikolay,
> > >>
> > >>
> > >>>               Consider copy-pasting wrong id from log to its
> > >>> parameters(killing not the buggy compute task, but *VERY* important
> > >>> transaction.
> > >>>               How users even know about this type of error with the
> > >>> single method approach?
> > >>>
> > >>> I thought that the identifiers would never intersect (meaning that a
> > >> transaction and a task would never share the same ID)
> > >>
> > >> I agree that change ID types for all objects would be a hard task, so
> > >> probably it's worth discussing a single cancel entry on phase 3.
> > >
> >
> >
>

--

Best regards,
Alexei Scherbakov

[Alexey Goncharuk]

Alexei,

I agree that there should be no principal difficulty with the unique ID for
each cancellable object, but I also see Nikolay's point about the wrong
copy-paste.

I like minimalistic APIs, but in this case the price of a mistake may be
high. Let's let a wider circle of community members to speak out.

[Nikolay Izhikov-2]

Hello, Vyacheslav.

> It seems to me we missed API that should be introduced into control utility.

Do you think we should support control.sh for cancel tasks?

> 7 февр. 2020 г., в 11:04, Alexey Goncharuk <[hidden email]> написал(а):
>
> Alexei,
>
> I agree that there should be no principal difficulty with the unique ID for
> each cancellable object, but I also see Nikolay's point about the wrong
> copy-paste.
>
> I like minimalistic APIs, but in this case the price of a mistake may be
> high. Let's let a wider circle of community members to speak out.

[slava.koptilin]

Hi Nikolay,

Yes, I think we should add this API to the control utility as well.
IMHO, the control utility is a more natural way of administration/control
of the cluster instead of JMX, for example.

Thanks,
S.

пт, 7 февр. 2020 г. в 11:38, Nikolay Izhikov <[hidden email]>:

> Hello, Vyacheslav.
>
> > It seems to me we missed API that should be introduced into control
> utility.
>
> Do you think we should support control.sh for cancel tasks?
>
>
> > 7 февр. 2020 г., в 11:04, Alexey Goncharuk <[hidden email]>
> написал(а):
> >
> > Alexei,
> >
> > I agree that there should be no principal difficulty with the unique ID
> for
> > each cancellable object, but I also see Nikolay's point about the wrong
> > copy-paste.
> >
> > I like minimalistic APIs, but in this case the price of a mistake may be
> > high. Let's let a wider circle of community members to speak out.
>
>

[Nikolay Izhikov-2]

> IMHO, the control utility is a more natural way of administration/control
of the cluster instead of JMX, for example.

It’s questionable.

I don’t mind to improve control.sh in this IEP.

But, we should discuss to topic - what management utilities we are providing *AND* supporting and how the should work.
As far as I know we have some REST API, but it seems abandoned and not supported.

> 7 февр. 2020 г., в 14:45, Вячеслав Коптилин <[hidden email]> написал(а):
>
> Hi Nikolay,
>
> Yes, I think we should add this API to the control utility as well.
> IMHO, the control utility is a more natural way of administration/control
> of the cluster instead of JMX, for example.
>
> Thanks,
> S.
>
> пт, 7 февр. 2020 г. в 11:38, Nikolay Izhikov <[hidden email]>:
>
>> Hello, Vyacheslav.
>>
>>> It seems to me we missed API that should be introduced into control
>> utility.
>>
>> Do you think we should support control.sh for cancel tasks?
>>
>>
>>> 7 февр. 2020 г., в 11:04, Alexey Goncharuk <[hidden email]>
>> написал(а):
>>>
>>> Alexei,
>>>
>>> I agree that there should be no principal difficulty with the unique ID
>> for
>>> each cancellable object, but I also see Nikolay's point about the wrong
>>> copy-paste.
>>>
>>> I like minimalistic APIs, but in this case the price of a mistake may be
>>> high. Let's let a wider circle of community members to speak out.
>>
>>

[Nikolay Izhikov-2]

Hello, Igniters.

PR [1] for the IEP-39 [2] are ready to be reviewed.
Ticket [3].

Can someone, please, review my changes

I propose to introduce the following features to Ignite management APIs.

1. JMX beans

```
ComputeMXBean#cancel(String sessionId);
QueryMXBean#cacncelSQL(String id)
QueryMXBean#cacncelScan(String originNodeId, String cacheName, Long id)
QueryMXBean#cacncelContinuous(String routineId)
TransactionMXBean#cancel(String xid)
ServiceMXBean#cancel(String name)
```

2. control.sh

```
> ./control.sh --kill scan b2d221ca-ab08-4544-b8dc-8475538ed42f default 63
> ./control.sh --kill compute 58b48c3e071-b2d221ca-ab08-4544-b8dc-8475538ed42f
> ./control.sh --kill tx 30058c3e071-00000000-0bac-6d33-0000-000000000003
> ./control.sh --kill sql b2d221ca-ab08-4544-b8dc-8475538ed42f_7
> ./control.sh --kill service my-svc
> ./control.sh --kill continuous bfca668d-5df8-4879-b97f-bd1712ad01c9
```

3. SQL(KILL QUERY for SQL queries already implemented):
```
KILL SCAN_QUERY 'b2d221ca-ab08-4544-b8dc-8475538ed42f' 'default' 63
KILL TX '30058c3e071-00000000-0bac-6d33-0000-000000000003'
KILL CONTINUOUS_QUERY 'bfca668d-5df8-4879-b97f-bd1712ad01c9'
KILL COMPUTE_TASK '58b48c3e071-b2d221ca-ab08-4544-b8dc-8475538ed42f'
KILL SERVICE 'my-svc'
```

[1] https://github.com/apache/ignite/pull/7520
[2] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=145724615
[3] https://issues.apache.org/jira/browse/IGNITE-12632

> 7 февр. 2020 г., в 14:53, Nikolay Izhikov <[hidden email]> написал(а):
>
>> IMHO, the control utility is a more natural way of administration/control
> of the cluster instead of JMX, for example.
>
> It’s questionable.
>
> I don’t mind to improve control.sh in this IEP.
>
> But, we should discuss to topic - what management utilities we are providing *AND* supporting and how the should work.
> As far as I know we have some REST API, but it seems abandoned and not supported.
>
>
>
>> 7 февр. 2020 г., в 14:45, Вячеслав Коптилин <[hidden email]> написал(а):
>>
>> Hi Nikolay,
>>
>> Yes, I think we should add this API to the control utility as well.
>> IMHO, the control utility is a more natural way of administration/control
>> of the cluster instead of JMX, for example.
>>
>> Thanks,
>> S.
>>
>> пт, 7 февр. 2020 г. в 11:38, Nikolay Izhikov <[hidden email]>:
>>
>>> Hello, Vyacheslav.
>>>
>>>> It seems to me we missed API that should be introduced into control
>>> utility.
>>>
>>> Do you think we should support control.sh for cancel tasks?
>>>
>>>
>>>> 7 февр. 2020 г., в 11:04, Alexey Goncharuk <[hidden email]>
>>> написал(а):
>>>>
>>>> Alexei,
>>>>
>>>> I agree that there should be no principal difficulty with the unique ID
>>> for
>>>> each cancellable object, but I also see Nikolay's point about the wrong
>>>> copy-paste.
>>>>
>>>> I like minimalistic APIs, but in this case the price of a mistake may be
>>>> high. Let's let a wider circle of community members to speak out.
>>>
>>>
>