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 identifiers.
Please, take a look, into `ScanQueryView` [1], `RunningQueryManager` [2]
> Right now different types of IDs (long, UUID, IgniteUuid) look confusing and
> messy.
Yes.
Let’s, fix it.
> Shouldn't we unify identifiers for all ongoing tasks in Ignite and move
> cancel to a single method in a single bean?
I think we should:
1. create separate beans for each API - TransactionMXBean, ComputeMXBean, etc.
* The single method will be very error-prone:
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?
* When the user wants to kill some task(from a script or by hand) he
knows the type of task for sure.
2. Implement IEP-39 with the current identifiers.
3. Improve our API with unified identifier types.
Bringing our API to the unified identifiers types approach is a very
hard task to do and it will take a long time to implement.
We shouldn’t leave our users without the proposed API until this moment.
[1]
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/spi/systemview/view/ScanQueryView.java
[2]
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/query/RunningQueryManager.java
> 5 февр. 2020 г., в 12:07, Alexey Goncharuk <alexey.goncha...@gmail.com>
> написал(а):
>
> 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 Ignite subsystems. However, given that lately we
> developed a unified approach to metrics and system views with Nikolay's
> help, shouldn't we take one more step forward and unify this part as well?
