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)
QueryMXBea
> 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 sh
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 :
> Hello, Vyacheslav.
>
> > It seems to
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
> написал(а):
>
> Alexei,
>
> I agree that there should be no principal difficulty with
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 s
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, Вячеслав Коп
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 :
> Ticket [1] created.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-12632
>
> > 5
Ticket [1] created.
[1] https://issues.apache.org/jira/browse/IGNITE-12632
> 5 февр. 2020 г., в 15:36, Nikolay Izhikov написал(а):
>
> Alexey.
>
> I’m talking the following scenario:
>
> 1. Consider we have unified bean to kill tasks:
>
> CancelMXBean {
> public void cancel(long id);
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
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
Igniters, thanks for the feedback.
> Can we retain only single cancel(long queryId) method in QueryMXBean ?
> I think query type can be determined by queryId.
It seems the answer is no we can’t do it for now.
Different types of queries are handled by different managers and have different
sets of
Folks,
Shouldn't we unify identifiers for all ongoing tasks in Ignite and move
cancel to a single method in a single bean?
Right now different types of IDs (long, UUID, IgniteUuid) look confusing
and messy. I understand that such API is enforced by the IDs implementation
in the corresponding Igni
Nick
Can we retain only single cancel(long queryId) method in QueryMXBean ?
I think query type can be determined by queryId.
I also think we need similar "cancellation" API without the need to use mx
beans.
вт, 4 февр. 2020 г. в 18:07, Nikolay Izhikov :
> Hello, Igniters.
>
> I propose to creat
13 matches
Mail list logo
