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, Вячеслав Коптилин <slava.kopti...@gmail.com>: > 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 <nizhi...@apache.org>: > > > Ticket [1] created. > > > > [1] https://issues.apache.org/jira/browse/IGNITE-12632 > > > > > 5 февр. 2020 г., в 15:36, Nikolay Izhikov <nizhikov....@gmail.com> > > написал(а): > > > > > > 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 < > alexey.goncha...@gmail.com> > > написал(а): > > >> > > >> 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
