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
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
+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
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
> 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
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
>
> 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
Ilya Kasnacheev created IGNITE-14445:
Summary: "Remote node does not observe current" after failure by
not receiving metrics from client
Key: IGNITE-14445
URL:
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
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
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
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
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,
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
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
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
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
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
18 matches
Mail list logo
