Taras Ledkov created IGNITE-14441:
-
Summary: Query plan printed for long running query must use
IGNITE_TO_STRING_INCLUDE_SENSITIVE policy
Key: IGNITE-14441
URL: https://issues.apache.org/jira/browse/IGNITE-14441
Ivan Bessonov created IGNITE-14442:
--
Summary: IgniteRunner fails with NPE after REST module was broken
by incompatible changes.
Key: IGNITE-14442
URL: https://issues.apache.org/jira/browse/IGNITE-14442
Hello Alexander, Igniters,
I support the suggestion, we need to work out some ground rules to have a
consistent naming convention. Agree with having at most one component per
project module - this requirement may turn out to be too strict in the
future, but now it seems reasonable and may help us
Agree with package and module naming.
I just thought that
Service is a self-suffucient component and provides high-level API to
user/other components/services (e.g. RaftService to TableService).
Manager is internal component - a logical brick of the Service (e.g.
RaftGroupManager or TableSchemaMan
Ivan,
My concern with the concept of a user completing the future returned from
Ignite public API is that it is unclear how to interpret this action (this
backs Val's message).
Let's say a user started a compute with fut = compute.runAsync(task); and
now calls fut.complete(someVal); Does this mean
Pavel Vinokurov created IGNITE-14443:
Summary: Calcite integration. SqlFirstLastValueAggFunction support
Key: IGNITE-14443
URL: https://issues.apache.org/jira/browse/IGNITE-14443
Project: Ignite
Ivan Daschinskiy created IGNITE-1:
-
Summary: Move affinity calculation and storage to client
Key: IGNITE-1
URL: https://issues.apache.org/jira/browse/IGNITE-1
Project: Ignite
Guys,
I want to remember there is one more point to pay attention to.
Extending Future and CompletableStage is more than just prevents unexpected
behavior if a user completed the future.
First of all, it helps us to write safer code as we won't a method contract
exposed such methods as to a user
Hello,
One more area where newcomers' contributions will be very helpful is MTCGA
activity (see [1], [2]). There are a lot of flaky tests in Ignite,
usually, the reason of flakiness is some concurrency issue in test code but
sometimes tests flaky due to some bugs in production code.
Why MTCGA is
Hello!
> Let's say a user started a compute with fut = compute.runAsync(task);
> and now calls fut.complete(someVal); Does this mean that Ignite no longer
needs to execute the task?
> If the task is currently running, does it need to be canceled?
Yes, this case looks like Ignite should cancel com
Ilya Kasnacheev created IGNITE-14445:
Summary: "Remote node does not observe current" after failure by
not receiving metrics from client
Key: IGNITE-14445
URL: https://issues.apache.org/jira/browse/IGNITE-1444
>
> Yes, this case looks like Ignite should cancel computations because a user
> wants to complete the future. Why not?
> If there will be an opportunity to cancel a future, why is it a bad option
> to finish a future through a complete() method?
Future has cancel() method for this.
Completing fut
IMO the only way Ignite should cancel computations is iff cancel method is
invoked, not implicitly if complete is invoked.
On Tue, 30 Mar 2021 at 4:58 PM, Denis Garus wrote:
> Hello!
>
> > Let's say a user started a compute with fut = compute.runAsync(task);
> > and now calls fut.complete(someVa
> Completing future from outside will never respect other subscribers that
> may expect other guatantees.
For example, if we talk about public API like IgniteCache, what subscribers
may expect other guatantees?
IMHO, the best solution is to get the well-known standard interface to a
user, and he w
Kirill Gusakov created IGNITE-14446:
---
Summary: Implement simple version of watching mechanism
Key: IGNITE-14446
URL: https://issues.apache.org/jira/browse/IGNITE-14446
Project: Ignite
Issue
+1 to package and module naming.
+1 to service definition as "component providing a high-level API to
user/other components/services"
I would avoid defining strict rules for Manager and Processor.
For me it just adds confusion without real value.
A component can be a Manager if it manages somethin
These are actually some interesting points. As I'm thinking more about
this, I'm leaning towards changing my opinion and voting for the
CompletableFuture. Here is my reasoning.
First, it's important to keep in mind that CompletableFuture is not an
interface that we will implement, it's an implemen
Thank you for the review.
I have updated the PR. Please see.
On Mon, Mar 29, 2021 at 8:27 PM Ilya Kasnacheev
wrote:
>
> Hello!
>
> I have left some more comments after trying this change on a real Azure
> cluster.
>
> Regards,
> --
> Ilya Kasnacheev
>
>
> вт, 23 мар. 2021 г. в 18:32, Atri Sharma
Val,
> we can have an IgniteFuture that extends CompletableFuture.
> This might be useful if want the cancel() operation to cancel the
> underlying operation
I think we can subscribe to the cancellation of the CompletableFuture
and cancel the underlying operation without an extra class,
something
Ivan Bessonov created IGNITE-14447:
--
Summary: Invalid meta page can be used after index re-creation
Key: IGNITE-14447
URL: https://issues.apache.org/jira/browse/IGNITE-14447
Project: Ignite
> Stripping them from such functionality, which they are used to, is most
likely a bad idea.
Completely agree with this point of view.
Moreover, a user can pass CompletableFuture to another library to do any
manipulations.
So if we want to introduce our class instead of the java class, we should
h
21 matches
Mail list logo
