Andrey,
I see. So in a nutshell, you're saying that we want to return a future that
the user's code is not allowed to complete. In this case, I think it's
clear that CompletableFuture is not what we need. We actually need a
NonCompletableFuture :)
My vote is for the custom interface.
-Val
On
Igor Sapego created IGNITE-14432:
Summary: Python thin: Support "with" statement for connection
method
Key: IGNITE-14432
URL: https://issues.apache.org/jira/browse/IGNITE-14432
Project: Ignite
Hi Igniters,
I've detected some new issue on TeamCity to be handled. You are more than
welcomed to help.
*New test failure in master
CreateIndexOnInvalidDataTypeTest.testCreateIndexOnInvalidData
Hi Igniters,
I've detected some new issue on TeamCity to be handled. You are more than
welcomed to help.
*New test failure in master
ClientReconnectCompatibilityTest.TestReconnectToOldNodeDisablesPartitionAwareness
Hi Igniters,
I've detected some new issue on TeamCity to be handled. You are more than
welcomed to help.
*New test failure in master-nightly
0",1).TestServerSideExpiryPolicyWorksOnAllVersions
Hi Igniters,
I've detected some new issue on TeamCity to be handled. You are more than
welcomed to help.
*New test failure in master IgniteOptimizationSystemFuncSpec.Supported
optimized system functions NVL2
Igniters,
Seems that within Ignite-3 we have some mess in terms like manager, cpu,
service, module, etc. Let's clarify this point. Also It'll be great to
discuss the rules of dividing code into modules.
I'll use the context of Ignite cluster & node lifecycle
Alexey Scherbakov created IGNITE-14431:
--
Summary: Assertion error in GridDhtAtomicCache.unlockEntries
Key: IGNITE-14431
URL: https://issues.apache.org/jira/browse/IGNITE-14431
Project: Ignite
Hello Alexei,
It would be nice to add something like as follows:
boolean isInfoEnabled();
boolean isDebugEnabled();
or
boolean isLoggable(Level) - the same way which System.Logger suggests
Thanks,
S.
пт, 26 мар. 2021 г. в 17:41, Alexei Scherbakov :
> Andrey,
>
> I've introduced a
Andrey,
I've introduced a new class LogWrapper to fix usability issues [1]
The suggested usage is something like:
private static LogWrapper LOG = new LogWrapper(MyClass.class);
[1]
Forgot to attach a link to the PR with an example [1].
[1] https://github.com/apache/ignite-3/pull/59
On Fri, Mar 26, 2021 at 4:03 PM Andrey Mashenkov
wrote:
> Hi Igniters,
>
> In almost every new task we faced the problem of what logger has to be
> used: JUL. log4J or any else.
>
> Since JDK
Hi Igniters,
In almost every new task we faced the problem of what logger has to be
used: JUL. log4J or any else.
Since JDK 9 there is a System.Logger which interface looks acceptable for
use,
excepts maybe some usability issues like method signatures.
LogLevel is passed as a mandatory argument,
Andrey Mashenkov created IGNITE-14430:
-
Summary: Common logger interface.
Key: IGNITE-14430
URL: https://issues.apache.org/jira/browse/IGNITE-14430
Project: Ignite
Issue Type:
Ivan Daschinskiy created IGNITE-14429:
-
Summary: Python thin client cache.get_size works not as expected
and PeekModes are incorrect.
Key: IGNITE-14429
URL: https://issues.apache.org/jira/browse/IGNITE-14429
Pavel,
Dedicated pool looks safer and more manageable to me. Make sure the threads
in the pool are lazily started and stopped if not used for some time.
Because I have no more real arguments against the change, I suggest to
proceed with this approach.
чт, 25 мар. 2021 г. в 22:16, Pavel Tupitsyn
Mikhail Petrov created IGNITE-14428:
---
Summary: Formalize the names of the metrics included in the
metric registry.
Key: IGNITE-14428
URL: https://issues.apache.org/jira/browse/IGNITE-14428
Alessandro Pezze' created IGNITE-14427:
--
Summary: string setCipherSuites don't specify format
Key: IGNITE-14427
URL: https://issues.apache.org/jira/browse/IGNITE-14427
Project: Ignite
Alessandro Pezze' created IGNITE-14426:
--
Summary: string setCipherSuites don't specify format
Key: IGNITE-14426
URL: https://issues.apache.org/jira/browse/IGNITE-14426
Project: Ignite
Val,
The methods below shouldn't be accessible for user:
complete()
completeExceptionaly()
Returning CompletableFuture we must always make a copy to prevent the
original future from being completed by mistake.
I think it will NOT be enough to do that returing the future to the
end-user, but from
Denis Chudov created IGNITE-14425:
-
Summary: Hang transactions in FINISH [COMMIT] phase when
сommunication spi is blocked
Key: IGNITE-14425
URL: https://issues.apache.org/jira/browse/IGNITE-14425
Pavel Pereslegin created IGNITE-14424:
-
Summary: Cache group re-encryption does not start after cluster
secondary activation.
Key: IGNITE-14424
URL: https://issues.apache.org/jira/browse/IGNITE-14424
Folks,
I ran some tests and got a Segmentation Fault without pretty explanation.
It's not actually that user happy to get. Even if there was a warning in
the release notes.
So, I think we should follow the idea of a check for indexes (and cache) on
Ignite start. And looks like designing and
Denis Chudov created IGNITE-14423:
-
Summary: Node failure caused by AssertionError: Transaction does
not own lock for update
Key: IGNITE-14423
URL: https://issues.apache.org/jira/browse/IGNITE-14423
Ivan Daschinskiy created IGNITE-14422:
-
Summary: Version management for ducktape.
Key: IGNITE-14422
URL: https://issues.apache.org/jira/browse/IGNITE-14422
Project: Ignite
Issue Type:
CompletableFuture seems a better option to me.
--
Regards,
Konstantin Orlov
> On 26 Mar 2021, at 11:07, Pavel Tupitsyn wrote:
>
> On the one hand, I agree with Alexey.
> CompletableFuture has complete* methods which should not be available to
> the user code.
> This can be solved with a
Anton Vinogradov created IGNITE-14421:
-
Summary: Get rid of useless waiting on grep
Key: IGNITE-14421
URL: https://issues.apache.org/jira/browse/IGNITE-14421
Project: Ignite
Issue Type:
On the one hand, I agree with Alexey.
CompletableFuture has complete* methods which should not be available to
the user code.
This can be solved with a simple interface like we do in Thin Client:
IgniteClientFuture extends Future, CompletionStage
On the other hand:
- CompletionStage has
I do not like Java's CompletableFuture and prefer our own Future (revised
IgniteFuture).
My understanding of the Future (or Promise) pattern in general is having
two separate APIs:
1. Server-side: create, set result, raise error, cancel from server.
2. Client-side: get result, handle
28 matches
Mail list logo
