Folks,
Regarding Reactive abstractions. While it might look too complex for
simple KV cases it can be quite powerful for queries. Also there are
known solutions for cancellation, backpressure and flow control. It
can greatly simplify things for users familiar with Reactive
programming rather than
Hi Igniters,
I've detected some new issue on TeamCity to be handled. You are more than
welcomed to help.
*Test with high flaky rate in master
EncryptedCacheExampleSelfTest.testBinaryPutGetExample
Valentin Kulichenko created IGNITE-14457:
Summary: Update Ignite 3 binary build structure
Key: IGNITE-14457
URL: https://issues.apache.org/jira/browse/IGNITE-14457
Project: Ignite
Amelchev Nikita created IGNITE-14456:
Summary: Ignite Extensions: change copyrights to 2021
Key: IGNITE-14456
URL: https://issues.apache.org/jira/browse/IGNITE-14456
Project: Ignite
Sergei Ryzhov created IGNITE-14455:
--
Summary: The directory with logs must contain
IgniteConfiguration.xml for ducktests.
Key: IGNITE-14455
URL: https://issues.apache.org/jira/browse/IGNITE-14455
Hi Andrey,
Please see below.
-Val
On Wed, Mar 31, 2021 at 7:55 AM Andrey Mashenkov
wrote:
> CompletableFuture cancellation will not work as many users expected.
> Javadoc says:
> /* Since (unlike {@link FutureTask}) this class has no direct
> * control over the computation that causes it to
Alexey,
Can you provide us some details on jygsaw adoption to better understand
the benefits ?
"We should be free to change them without any compatibility contract" -
let's mark such classes with a special annotation like @Internal, will it
work for you ?
ср, 31 мар. 2021 г. в 15:10, Alexey
CompletableFuture cancellation will not work as many users expected.
Javadoc says:
/* Since (unlike {@link FutureTask}) this class has no direct
* control over the computation that causes it to be completed,
* cancellation is treated as just another form of exceptional
* completion.
*/
Completion
Kseniya Romanova created IGNITE-14454:
-
Summary: [Ignite Website] Update for events schedule
Key: IGNITE-14454
URL: https://issues.apache.org/jira/browse/IGNITE-14454
Project: Ignite
Emmanuel Wiesenfeld created IGNITE-14453:
Summary: Issue with persistence when using JDK15
Key: IGNITE-14453
URL: https://issues.apache.org/jira/browse/IGNITE-14453
Project: Ignite
Vladimir Steshin created IGNITE-14452:
-
Summary: Add cehcking of the iptables settings applied.
Key: IGNITE-14452
URL: https://issues.apache.org/jira/browse/IGNITE-14452
Project: Ignite
This won't work with the Java Jigsaw module system because it prohibits
having two identical packages in different modules. I really hope that we
will adopt Jigsaw in the near future. Unless you are suggesting moving all
utility classes under org.apache.ignite.api.util package, bit this looks
Taras Ledkov created IGNITE-14451:
-
Summary: PK becomes corrupted after node restart
Key: IGNITE-14451
URL: https://issues.apache.org/jira/browse/IGNITE-14451
Project: Ignite
Issue Type: Bug
Alexey,
I would instead suggest moving the public utility classes to
org.apache.ignite.api. package in the util module to separate them from
internal classes, if we really need this.
Actually, I don't think there is a point in separating public/internal
classes in the util module. What are the
Nikolay Izhikov created IGNITE-14450:
Summary: Add Maximum CDC directory size configuration parameter
Key: IGNITE-14450
URL: https://issues.apache.org/jira/browse/IGNITE-14450
Project: Ignite
Nikolay Izhikov created IGNITE-14449:
Summary: Add binary meta change event to CDCCosumer
Key: IGNITE-14449
URL: https://issues.apache.org/jira/browse/IGNITE-14449
Project: Ignite
Issue
Alexei,
I had the same opinion regarding the internal package, but we still need to
somehow distinguish between public and internal classes in the ignite-util
module. If we introduce the internal package in the util, we should follow
the same structure in other modules.
Thoughts?
вт, 30 мар.
Semyon Danilov created IGNITE-14448:
---
Summary: Failure to connect to node leads to hanging connection
future if paired connections are used
Key: IGNITE-14448
URL:
> 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
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
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,
21 matches
Mail list logo
