[jira] [Commented] (IGNITE-20780) Sql. Move session expiration to IgniteSqlImpl
[ https://issues.apache.org/jira/browse/IGNITE-20780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782636#comment-17782636 ] Yury Gerzhedovich commented on IGNITE-20780: [~korlov] LGTM! > Sql. Move session expiration to IgniteSqlImpl > - > > Key: IGNITE-20780 > URL: https://issues.apache.org/jira/browse/IGNITE-20780 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > As for now, session management is split between two components: IgniteSql is > responsible for creating new sessions, and sql engine is responsible for > sessions' idle expiration. Let's keep all session management in a single > place: for this we need to move expiration logic to IgniteSqlImpl. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-18536) Schema synchronization feature and Catalog feature integration
[ https://issues.apache.org/jira/browse/IGNITE-18536?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy resolved IGNITE-18536. Fix Version/s: 3.0.0-beta2 Resolution: Fixed > Schema synchronization feature and Catalog feature integration > -- > > Key: IGNITE-18536 > URL: https://issues.apache.org/jira/browse/IGNITE-18536 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Priority: Blocker > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Metadata synchronization should be used, implemented (most likely) on top of > "transactions in the past", defined in the transactions IEP (see "Lock-free > RW Transactions" in > https://cwiki.apache.org/confluence/display/IGNITE/IEP-91:+Transaction+protocol). > Let's plug SchemaSychronizationManager into Ignite node and use it for > waiting actual metadata before resolve actual Catalog version for a > transaction. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-18536) Schema synchronization feature and Catalog feature integration
[
https://issues.apache.org/jira/browse/IGNITE-18536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17756000#comment-17756000
]
Roman Puchkovskiy edited comment on IGNITE-18536 at 11/3/23 3:08 PM:
-
To do schema sync, we don't need a transaction, a timestamp is enough. For the
APIs where a timestamp is not available (like in the example of table("name")),
the implementation should take ts=HLC.now() and then await for the schemas to
be complete wrt this timestamp before proceeding.
was (Author: rpuch):
Make do schema sync, we don't need a transaction, a timestamp is enough. For
the APIs where a timestamp is not available (like in the example of
table("name")), the implementation should take ts=HLC.now() and then await for
the schemas to be complete wrt this timestamp before proceeding.
> Schema synchronization feature and Catalog feature integration
> --
>
> Key: IGNITE-18536
> URL: https://issues.apache.org/jira/browse/IGNITE-18536
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Priority: Blocker
> Labels: ignite-3
>
> Metadata synchronization should be used, implemented (most likely) on top of
> "transactions in the past", defined in the transactions IEP (see "Lock-free
> RW Transactions" in
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-91:+Transaction+protocol).
> Let's plug SchemaSychronizationManager into Ignite node and use it for
> waiting actual metadata before resolve actual Catalog version for a
> transaction.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20794) Fix build
Vadim Pakhnushev created IGNITE-20794: - Summary: Fix build Key: IGNITE-20794 URL: https://issues.apache.org/jira/browse/IGNITE-20794 Project: Ignite Issue Type: Bug Components: sql Reporter: Vadim Pakhnushev Assignee: Vadim Pakhnushev Integration tests build fails after merging IGNITE-20544 on top of IGNITE-20787 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20511) Thin 3.0: Track and log connection ID on the server
[ https://issues.apache.org/jira/browse/IGNITE-20511?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782601#comment-17782601 ] Pavel Tupitsyn commented on IGNITE-20511: - Merged to main: bdbf79d408459500fcdc7c060e410ad2dbd0eda3 > Thin 3.0: Track and log connection ID on the server > --- > > Key: IGNITE-20511 > URL: https://issues.apache.org/jira/browse/IGNITE-20511 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > * Assign a unique ID to every client connection in > *ClientInboundMessageHandler* > * Include it into all log messages to correlate them easier -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20793) ItConnectionManagerTest#testShutdown is flaky
[
https://issues.apache.org/jira/browse/IGNITE-20793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-20793:
-
Description:
Sometimes this test fails with the following exception:
{code:java}
java.util.concurrent.ExecutionException:
org.apache.ignite.internal.network.handshake.ChannelAlreadyExistsException
at
org.apache.ignite.internal.future.OrderingFuture.exceptionForThrowingFromGet(OrderingFuture.java:450)
at
org.apache.ignite.internal.future.OrderingFuture.get(OrderingFuture.java:437)
at
org.apache.ignite.internal.network.netty.ItConnectionManagerTest.testShutdown(ItConnectionManagerTest.java:190)
at jdk.internal.reflect.GeneratedMethodAccessor14.invoke(Unknown Source)
at
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
at
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at
org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
at
org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at
org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
at
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138)
at
org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:151)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at
org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1511)
at
org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:41)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:155)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at
org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at
[jira] [Created] (IGNITE-20793) ItConnectionManagerTest#testShutdown is flaky
Aleksandr Polovtcev created IGNITE-20793: Summary: ItConnectionManagerTest#testShutdown is flaky Key: IGNITE-20793 URL: https://issues.apache.org/jira/browse/IGNITE-20793 Project: Ignite Issue Type: Bug Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20793) ItConnectionManagerTest#testShutdown is flaky
[ https://issues.apache.org/jira/browse/IGNITE-20793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-20793: - Labels: ignite-3 (was: ) > ItConnectionManagerTest#testShutdown is flaky > - > > Key: IGNITE-20793 > URL: https://issues.apache.org/jira/browse/IGNITE-20793 > Project: Ignite > Issue Type: Bug >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Blocker > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20793) ItConnectionManagerTest#testShutdown is flaky
[ https://issues.apache.org/jira/browse/IGNITE-20793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-20793: - Ignite Flags: (was: Docs Required,Release Notes Required) > ItConnectionManagerTest#testShutdown is flaky > - > > Key: IGNITE-20793 > URL: https://issues.apache.org/jira/browse/IGNITE-20793 > Project: Ignite > Issue Type: Bug >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Blocker > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20789) Remove outdated schemas stored in SchemaManager
[ https://issues.apache.org/jira/browse/IGNITE-20789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-20789: --- Ignite Flags: (was: Docs Required,Release Notes Required) > Remove outdated schemas stored in SchemaManager > --- > > Key: IGNITE-20789 > URL: https://issues.apache.org/jira/browse/IGNITE-20789 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > When a schema version is not needed (that is, no tuple can be written in this > schema AND no tuple exists in the storage (that is written in this schema) > that can be read), it should be removed. > Only whole prefixes might be removed (so, if we must keep version N, then we > cannot remove versions N+). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-14578) Bootstrap configuation manager with distributed configuration
[ https://issues.apache.org/jira/browse/IGNITE-14578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-14578: Assignee: Alexander Lapin (was: Kirill Gusakov) > Bootstrap configuation manager with distributed configuration > - > > Key: IGNITE-14578 > URL: https://issues.apache.org/jira/browse/IGNITE-14578 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: iep-73, ignite-3 > > Update IgntionImpl with code that will > * Add distributed root keys. > * Bootstrap distributed configuration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-20787) Extract interface from TableImpl
[
https://issues.apache.org/jira/browse/IGNITE-20787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr resolved IGNITE-20787.
Resolution: Fixed
Thanks for the refactoring, merged into main:
f6c60f533d908ecf53c4df24238a26b31039f35d
> Extract interface from TableImpl
>
>
> Key: IGNITE-20787
> URL: https://issues.apache.org/jira/browse/IGNITE-20787
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Time Spent: 40m
> Remaining Estimate: 0h
>
> There's a public API {{Table}} and {{IgniteTables}} and corresponding
> internal {{TableImpl}} {{IgniteTablesInternal}} but the {{TableImpl}} is not
> an interface which leaks to other modules and complicates further
> refactorings. We should extract an interface from it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20792) ItRebalanceDistributedTest.testRaftClientsUpdatesAfterRebalance rare fails with "No such partition 0 in table TBL1"
[
https://issues.apache.org/jira/browse/IGNITE-20792?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Gusakov updated IGNITE-20792:
Description:
>From time to time test
>ItRebalanceDistributedTest.testRaftClientsUpdatesAfterRebalance fails with:
{code}
3:29:03
org.apache.ignite.internal.lang.IgniteInternalException: IGN-CMN-65535
TraceId:969a42d9-18ee-4dc9-a18b-d275f893b6b1 No such partition 0 in table TBL1
13:29:03
org.apache.ignite.internal.lang.IgniteInternalException: IGN-CMN-65535
TraceId:969a42d9-18ee-4dc9-a18b-d275f893b6b1 No such partition 0 in table TBL1
at
app//org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.partitionRaftGroupService(InternalTableImpl.java:1535)
at
app//org.apache.ignite.internal.rebalance.ItRebalanceDistributedTest.lambda$testRaftClientsUpdatesAfterRebalance$23(ItRebalanceDistributedTest.java:637)
at
java.base@11.0.17/java.util.stream.MatchOps$1MatchSink.accept(MatchOps.java:90)
at
java.base@11.0.17/java.util.ArrayList$ArrayListSpliterator.tryAdvance(ArrayList.java:1632)
at
java.base@11.0.17/java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:127)
at
java.base@11.0.17/java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:502)
at
java.base@11.0.17/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:488)
at
java.base@11.0.17/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
at
java.base@11.0.17/java.util.stream.MatchOps$MatchOp.evaluateSequential(MatchOps.java:230)
at
java.base@11.0.17/java.util.stream.MatchOps$MatchOp.evaluateSequential(MatchOps.java:196)
at
java.base@11.0.17/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.base@11.0.17/java.util.stream.ReferencePipeline.allMatch(ReferencePipeline.java:533)
at
app//org.apache.ignite.internal.rebalance.ItRebalanceDistributedTest.lambda$testRaftClientsUpdatesAfterRebalance$24(ItRebalanceDistributedTest.java:632)
at
app//org.apache.ignite.internal.testframework.IgniteTestUtils.waitForCondition(IgniteTestUtils.java:613)
at
app//org.apache.ignite.internal.testframework.IgniteTestUtils.waitForCondition(IgniteTestUtils.java:596)
at
app//org.apache.ignite.internal.rebalance.ItRebalanceDistributedTest.testRaftClientsUpdatesAfterRebalance(ItRebalanceDistributedTest.java:631)
at
java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base@11.0.17/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566)
at
app//org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
at
app//org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at
app//org.junit.jupiter.engine.extension.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
at
app//org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
at
app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
at
app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
at
app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
at
app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
at
app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at
app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at
app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at
app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at
app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
at
app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
at
[jira] [Created] (IGNITE-20792) ItRebalanceDistributedTest.testRaftClientsUpdatesAfterRebalance rare fails with "No such partition 0 in table TBL1"
Kirill Gusakov created IGNITE-20792:
---
Summary:
ItRebalanceDistributedTest.testRaftClientsUpdatesAfterRebalance rare fails with
"No such partition 0 in table TBL1"
Key: IGNITE-20792
URL: https://issues.apache.org/jira/browse/IGNITE-20792
Project: Ignite
Issue Type: Bug
Reporter: Kirill Gusakov
>From time to time test
>ItRebalanceDistributedTest.testRaftClientsUpdatesAfterRebalance fails with:
{code}
3:29:03
org.apache.ignite.internal.lang.IgniteInternalException: IGN-CMN-65535
TraceId:969a42d9-18ee-4dc9-a18b-d275f893b6b1 No such partition 0 in table TBL1
13:29:03
org.apache.ignite.internal.lang.IgniteInternalException: IGN-CMN-65535
TraceId:969a42d9-18ee-4dc9-a18b-d275f893b6b1 No such partition 0 in table TBL1
at
app//org.apache.ignite.internal.table.distributed.storage.InternalTableImpl.partitionRaftGroupService(InternalTableImpl.java:1535)
at
app//org.apache.ignite.internal.rebalance.ItRebalanceDistributedTest.lambda$testRaftClientsUpdatesAfterRebalance$23(ItRebalanceDistributedTest.java:637)
at
java.base@11.0.17/java.util.stream.MatchOps$1MatchSink.accept(MatchOps.java:90)
at
java.base@11.0.17/java.util.ArrayList$ArrayListSpliterator.tryAdvance(ArrayList.java:1632)
at
java.base@11.0.17/java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:127)
at
java.base@11.0.17/java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:502)
at
java.base@11.0.17/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:488)
at
java.base@11.0.17/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
at
java.base@11.0.17/java.util.stream.MatchOps$MatchOp.evaluateSequential(MatchOps.java:230)
at
java.base@11.0.17/java.util.stream.MatchOps$MatchOp.evaluateSequential(MatchOps.java:196)
at
java.base@11.0.17/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.base@11.0.17/java.util.stream.ReferencePipeline.allMatch(ReferencePipeline.java:533)
at
app//org.apache.ignite.internal.rebalance.ItRebalanceDistributedTest.lambda$testRaftClientsUpdatesAfterRebalance$24(ItRebalanceDistributedTest.java:632)
at
app//org.apache.ignite.internal.testframework.IgniteTestUtils.waitForCondition(IgniteTestUtils.java:613)
at
app//org.apache.ignite.internal.testframework.IgniteTestUtils.waitForCondition(IgniteTestUtils.java:596)
at
app//org.apache.ignite.internal.rebalance.ItRebalanceDistributedTest.testRaftClientsUpdatesAfterRebalance(ItRebalanceDistributedTest.java:631)
at
java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base@11.0.17/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566)
at
app//org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
at
app//org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at
app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at
app//org.junit.jupiter.engine.extension.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
at
app//org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
at
app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
at
app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
at
app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
at
app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
at
app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
at
app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
at
app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
at
app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
at
app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
at
[jira] [Updated] (IGNITE-20766) Deal with the primary replica provider in integration tests
[ https://issues.apache.org/jira/browse/IGNITE-20766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-20766: --- Description: In the process of implementing IGNITE-20678, it turned out that using *TestPlacementDriver* in tests *ItRebalanceDistributedTest* and *ItIgniteNodeRestartTest* does not look correct, since for each node the primary replica will be defined as the node (primary replica) itself, which can lead to unpredictable behavior, we need to figure this out. Definition of done Both thests have an integration nature; the cluster contains more than one node, and the nodes use the network. In these circumstances, the primary replica can be changed during an integration test and is not predetermined. # I believe the test implementation of the placement drive is not applicable here; this is a better way to instance the production implementation. Look at the PR attached. # Or it would be better to rewrite the test to use the original Ignite node instead of the particular instantiated nodes. was: In the process of implementing IGNITE-20678, it turned out that using *TestPlacementDriver* in tests *ItRebalanceDistributedTest* and *ItIgniteNodeRestartTest* does not look correct, since for each node the primary replica will be defined as the node (primary replica) itself, which can lead to unpredictable behavior, we need to figure this out. Definition of done Both thests have an integration nature; the cluster contains more than one node, and the nodes use the network. In these circumstances, the primary replica can be changed during an integration test and is not predetermined. # I believe the test implementation of the placement drive is not applicable here; this is a better way to instance the production implementation. Look at the PR attached. # Or it would be better to rewrite the test to use the original Ignite node instead of the particular instantiated nodes. > Deal with the primary replica provider in integration tests > --- > > Key: IGNITE-20766 > URL: https://issues.apache.org/jira/browse/IGNITE-20766 > Project: Ignite > Issue Type: Bug >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > In the process of implementing IGNITE-20678, it turned out that using > *TestPlacementDriver* in tests *ItRebalanceDistributedTest* and > *ItIgniteNodeRestartTest* does not look correct, since for each node the > primary replica will be defined as the node (primary replica) itself, which > can lead to unpredictable behavior, we need to figure this out. > Definition of done > Both thests have an integration nature; the cluster contains more than one > node, and the nodes use the network. In these circumstances, the primary > replica can be changed during an integration test and is not predetermined. > # I believe the test implementation of the placement drive is not applicable > here; this is a better way to instance the production implementation. Look at > the PR attached. > # Or it would be better to rewrite the test to use the original Ignite node > instead of the particular instantiated nodes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20766) Deal with the primary replica provider in integration tests
[ https://issues.apache.org/jira/browse/IGNITE-20766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-20766: --- Description: In the process of implementing IGNITE-20678, it turned out that using *TestPlacementDriver* in tests *ItRebalanceDistributedTest* and *ItIgniteNodeRestartTest* does not look correct, since for each node the primary replica will be defined as the node (primary replica) itself, which can lead to unpredictable behavior, we need to figure this out. Definition of done Both thests have an integration nature; the cluster contains more than one node, and the nodes use the network. In these circumstances, the primary replica can be changed during an integration test and is not predetermined. # I believe the test implementation of the placement drive is not applicable here; this is a better way to instance the production implementation. Look at the PR attached. # Or it would be better to rewrite the test to use the original Ignite node instead of the particular instantiated nodes. was:In the process of implementing IGNITE-20678, it turned out that using *TestPlacementDriver* in tests *ItRebalanceDistributedTest* and *ItIgniteNodeRestartTest* does not look correct, since for each node the primary replica will be defined as the node (primary replica) itself, which can lead to unpredictable behavior, we need to figure this out. > Deal with the primary replica provider in integration tests > --- > > Key: IGNITE-20766 > URL: https://issues.apache.org/jira/browse/IGNITE-20766 > Project: Ignite > Issue Type: Bug >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > In the process of implementing IGNITE-20678, it turned out that using > *TestPlacementDriver* in tests *ItRebalanceDistributedTest* and > *ItIgniteNodeRestartTest* does not look correct, since for each node the > primary replica will be defined as the node (primary replica) itself, which > can lead to unpredictable behavior, we need to figure this out. > Definition of done > Both thests have an integration nature; the cluster contains more than one > node, and the nodes use the network. In these circumstances, the primary > replica can be changed during an integration test and is not predetermined. > # I believe the test implementation of the placement drive is not applicable > here; this is a better way to instance the production implementation. Look at > the PR attached. > # Or it would be better to rewrite the test to use the original Ignite node > instead of the particular instantiated nodes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20779) Transaction operation might throw no exception on enlisting attempt, while transaction is in FINISHING state
[
https://issues.apache.org/jira/browse/IGNITE-20779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-20779:
--
Description:
h3. Motivation
Read-write lock is used in ReadWriteTransactionImpl to _enlist_ a partition and
to _finish_ the transaction ({_}read{_} and _write_ locks are acquired
respectively). But only final state is checked inside the lock (COMMITTED or
ABORTED), while this state is set asynchronously when the transaction is
finished *and* the response is received from the commit partition.
ReadWriteTransactionImpl#finish sets FINISHING state synchronously, so this
state must also be checked within the locks.
h3. Implementation notes
# Add checking the FINISHING state to the method
ReadWriteTransactionImpl#checkEnlistReady
# add checking the FINISHING state to the method
ReadWriteTransactionImpl#finish
# rename checkEnlistReady to checkEnlistPossible (optional)
# add assertion that ReadWriteTransactionImpl#finishFuture is null before
assigning a value to it.
was:
h3. Motivation
Read-write lock is used in ReadWriteTransactionImpl to _enlist_ a partition and
to _finish_ the transaction ({_}read{_} and _write_ locks are acquired
respectively). But inside the lock only final state is checked (COMMITTED or
ABORTED), while this state is set asynchronously when transaction is finished
*and* response received from the commit partition.
ReadWriteTransactionImpl#finish sets FINISHING state synchronously, so this
state must also be checked within the locks.
h3. Implementation note
# Add checking the FINISHING state to the method
ReadWriteTransactionImpl#checkEnlistReady
# add checking the FINISHING state to the method
ReadWriteTransactionImpl#finish
# rename checkEnlistReady to checkEnlistPossible (optional)
# add assertion that ReadWriteTransactionImpl#finishFuture is null before
assigning a value to it.
> Transaction operation might throw no exception on enlisting attempt, while
> transaction is in FINISHING state
>
>
> Key: IGNITE-20779
> URL: https://issues.apache.org/jira/browse/IGNITE-20779
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> Read-write lock is used in ReadWriteTransactionImpl to _enlist_ a partition
> and to _finish_ the transaction ({_}read{_} and _write_ locks are acquired
> respectively). But only final state is checked inside the lock (COMMITTED or
> ABORTED), while this state is set asynchronously when the transaction is
> finished *and* the response is received from the commit partition.
> ReadWriteTransactionImpl#finish sets FINISHING state synchronously, so this
> state must also be checked within the locks.
> h3. Implementation notes
> # Add checking the FINISHING state to the method
> ReadWriteTransactionImpl#checkEnlistReady
> # add checking the FINISHING state to the method
> ReadWriteTransactionImpl#finish
> # rename checkEnlistReady to checkEnlistPossible (optional)
> # add assertion that ReadWriteTransactionImpl#finishFuture is null before
> assigning a value to it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20779) Transaction operation might throw no exception on enlisting attempt, while transaction is in FINISHING state
[
https://issues.apache.org/jira/browse/IGNITE-20779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-20779:
--
Description:
h3. Motivation
Read-write lock is used in ReadWriteTransactionImpl to _enlist_ a partition and
to _finish_ the transaction ({_}read{_} and _write_ locks are acquired
respectively). But inside the lock only final state is checked (COMMITTED or
ABORTED), while this state is set asynchronously when transaction is finished
*and* response received from the commit partition.
ReadWriteTransactionImpl#finish sets FINISHING state synchronously, so this
state must also be checked within the locks.
h3. Implementation note
# Add checking the FINISHING state to the method
ReadWriteTransactionImpl#checkEnlistReady
# add checking the FINISHING state to the method
ReadWriteTransactionImpl#finish
# rename checkEnlistReady to checkEnlistPossible (optional)
# add assertion that ReadWriteTransactionImpl#finishFuture is null before
assigning a value to it.
was:
h3. Motivation
Read-write lock is used in ReadWriteTransactionImpl to enlist a partition and
to finish the transaction (read and write locks are acquired respectively). But
inside the lock only final state is checked (COMMITTED or ABORTED), while this
state is set asynchronously when transaction is finished *and* response
received from the commit partition. ReadWriteTransactionImpl#finish sets
FINISHING state synchronously, so this state must also be checked within the
locks.
h3. Implementation note
# Add checking the FINISHING state to the method
ReadWriteTransactionImpl#checkEnlistReady
# add checking the FINISHING state to the method
ReadWriteTransactionImpl#finish
# rename checkEnlistReady to checkEnlistPossible (optional)
# add assertion that ReadWriteTransactionImpl#finishFuture is null before
assigning a value to it.
> Transaction operation might throw no exception on enlisting attempt, while
> transaction is in FINISHING state
>
>
> Key: IGNITE-20779
> URL: https://issues.apache.org/jira/browse/IGNITE-20779
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> Read-write lock is used in ReadWriteTransactionImpl to _enlist_ a partition
> and to _finish_ the transaction ({_}read{_} and _write_ locks are acquired
> respectively). But inside the lock only final state is checked (COMMITTED or
> ABORTED), while this state is set asynchronously when transaction is finished
> *and* response received from the commit partition.
> ReadWriteTransactionImpl#finish sets FINISHING state synchronously, so this
> state must also be checked within the locks.
> h3. Implementation note
> # Add checking the FINISHING state to the method
> ReadWriteTransactionImpl#checkEnlistReady
> # add checking the FINISHING state to the method
> ReadWriteTransactionImpl#finish
> # rename checkEnlistReady to checkEnlistPossible (optional)
> # add assertion that ReadWriteTransactionImpl#finishFuture is null before
> assigning a value to it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20779) Transaction operation might throw no exception on enlisting attempt, while transaction is in FINISHING state
[ https://issues.apache.org/jira/browse/IGNITE-20779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-20779: -- Description: h3. Motivation Read-write lock is used in ReadWriteTransactionImpl to enlist a partition and to finish the transaction (read and write locks are acquired respectively). But inside the lock only final state is checked (COMMITTED or ABORTED), while this state is set asynchronously when transaction is finished *and* response received from the commit partition. ReadWriteTransactionImpl#finish sets FINISHING state synchronously, so this state must also be checked within the locks. h3. Implementation note # Add checking the FINISHING state to the method ReadWriteTransactionImpl#checkEnlistReady # add checking the FINISHING state to the method ReadWriteTransactionImpl#finish # rename checkEnlistReady to checkEnlistPossible (optional) # add assertion that ReadWriteTransactionImpl#finishFuture is null before assigning a value to it. was: h3. Motivation The well-known pattern is used in ReadWriteTransactionImpl#finish and ReadWriteTransactionImpl#enlist, but it is violated. The code checks the transaction state, but it does not always change under the write lock to the final state (COMMITED, ABORTED). In general, we can change the transaction state to final or FINISHING. h3. Implementation note # Add checking the FINISHING state to the method ReadWriteTransactionImpl#checkEnlistReady # Add checking the FINISHING state to the method ReadWriteTransactionImpl#finish > Transaction operation might throw no exception on enlisting attempt, while > transaction is in FINISHING state > > > Key: IGNITE-20779 > URL: https://issues.apache.org/jira/browse/IGNITE-20779 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > h3. Motivation > Read-write lock is used in ReadWriteTransactionImpl to enlist a partition and > to finish the transaction (read and write locks are acquired respectively). > But inside the lock only final state is checked (COMMITTED or ABORTED), while > this state is set asynchronously when transaction is finished *and* response > received from the commit partition. ReadWriteTransactionImpl#finish sets > FINISHING state synchronously, so this state must also be checked within the > locks. > h3. Implementation note > # Add checking the FINISHING state to the method > ReadWriteTransactionImpl#checkEnlistReady > # add checking the FINISHING state to the method > ReadWriteTransactionImpl#finish > # rename checkEnlistReady to checkEnlistPossible (optional) > # add assertion that ReadWriteTransactionImpl#finishFuture is null before > assigning a value to it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20779) Transaction operation might throw no exception on enlisting attempt, while transaction is in FINISHING state
[ https://issues.apache.org/jira/browse/IGNITE-20779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-20779: -- Description: h3. Motivation Read-write lock is used in ReadWriteTransactionImpl to enlist a partition and to finish the transaction (read and write locks are acquired respectively). But inside the lock only final state is checked (COMMITTED or ABORTED), while this state is set asynchronously when transaction is finished *and* response received from the commit partition. ReadWriteTransactionImpl#finish sets FINISHING state synchronously, so this state must also be checked within the locks. h3. Implementation note # Add checking the FINISHING state to the method ReadWriteTransactionImpl#checkEnlistReady # add checking the FINISHING state to the method ReadWriteTransactionImpl#finish # rename checkEnlistReady to checkEnlistPossible (optional) # add assertion that ReadWriteTransactionImpl#finishFuture is null before assigning a value to it. was: h3. Motivation Read-write lock is used in ReadWriteTransactionImpl to enlist a partition and to finish the transaction (read and write locks are acquired respectively). But inside the lock only final state is checked (COMMITTED or ABORTED), while this state is set asynchronously when transaction is finished *and* response received from the commit partition. ReadWriteTransactionImpl#finish sets FINISHING state synchronously, so this state must also be checked within the locks. h3. Implementation note # Add checking the FINISHING state to the method ReadWriteTransactionImpl#checkEnlistReady # add checking the FINISHING state to the method ReadWriteTransactionImpl#finish # rename checkEnlistReady to checkEnlistPossible (optional) # add assertion that ReadWriteTransactionImpl#finishFuture is null before assigning a value to it. > Transaction operation might throw no exception on enlisting attempt, while > transaction is in FINISHING state > > > Key: IGNITE-20779 > URL: https://issues.apache.org/jira/browse/IGNITE-20779 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > h3. Motivation > Read-write lock is used in ReadWriteTransactionImpl to enlist a partition and > to finish the transaction (read and write locks are acquired respectively). > But inside the lock only final state is checked (COMMITTED or ABORTED), while > this state is set asynchronously when transaction is finished *and* response > received from the commit partition. ReadWriteTransactionImpl#finish sets > FINISHING state synchronously, so this state must also be checked within the > locks. > h3. Implementation note > # Add checking the FINISHING state to the method > ReadWriteTransactionImpl#checkEnlistReady > # add checking the FINISHING state to the method > ReadWriteTransactionImpl#finish > # rename checkEnlistReady to checkEnlistPossible (optional) > # add assertion that ReadWriteTransactionImpl#finishFuture is null before > assigning a value to it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20779) Transaction operation might throw no exception on enlisting attempt, while transaction is in FINISHING state
[ https://issues.apache.org/jira/browse/IGNITE-20779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-20779: -- Summary: Transaction operation might throw no exception on enlisting attempt, while transaction is in FINISHING state (was: Transaction operation might throw no exception, but is not be considered) > Transaction operation might throw no exception on enlisting attempt, while > transaction is in FINISHING state > > > Key: IGNITE-20779 > URL: https://issues.apache.org/jira/browse/IGNITE-20779 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > h3. Motivation > The well-known pattern is used in ReadWriteTransactionImpl#finish and > ReadWriteTransactionImpl#enlist, but it is violated. The code checks the > transaction state, but it does not always change under the write lock to the > final state (COMMITED, ABORTED). In general, we can change the transaction > state to final or FINISHING. > h3. Implementation note > # Add checking the FINISHING state to the method > ReadWriteTransactionImpl#checkEnlistReady > # Add checking the FINISHING state to the method > ReadWriteTransactionImpl#finish -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20791) Tets does not work through Idea due to the versions of snakeyaml conflict
[
https://issues.apache.org/jira/browse/IGNITE-20791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Sizov reassigned IGNITE-20791:
--
Assignee: Kirill Sizov
> Tets does not work through Idea due to the versions of snakeyaml conflict
> -
>
> Key: IGNITE-20791
> URL: https://issues.apache.org/jira/browse/IGNITE-20791
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Kirill Sizov
>Priority: Major
> Labels: ignite-3
>
> That is the exception:
> {noformat}
> java.lang.NoSuchMethodError: org.yaml.snakeyaml.constructor.SafeConstructor:
> method ()V not found
> at
> io.micronaut.context.env.yaml.CustomSafeConstructor.(CustomSafeConstructor.java:36)
> at
> io.micronaut.context.env.yaml.YamlPropertySourceLoader.processInput(YamlPropertySourceLoader.java:56)
> at
> io.micronaut.context.env.AbstractPropertySourceLoader.read(AbstractPropertySourceLoader.java:117)
> at
> io.micronaut.context.env.AbstractPropertySourceLoader.loadProperties(AbstractPropertySourceLoader.java:102)
> at
> io.micronaut.context.env.AbstractPropertySourceLoader.load(AbstractPropertySourceLoader.java:68)
> at
> io.micronaut.context.env.AbstractPropertySourceLoader.load(AbstractPropertySourceLoader.java:55)
> at
> io.micronaut.context.env.DefaultEnvironment.loadPropertySourceFromLoader(DefaultEnvironment.java:607)
> at
> io.micronaut.context.env.DefaultEnvironment.readPropertySourceList(DefaultEnvironment.java:541)
> at
> io.micronaut.context.env.DefaultEnvironment.readPropertySourceList(DefaultEnvironment.java:527)
> at
> io.micronaut.context.DefaultApplicationContext$RuntimeConfiguredEnvironment.readPropertySourceList(DefaultApplicationContext.java:794)
> at
> io.micronaut.context.env.DefaultEnvironment.readPropertySources(DefaultEnvironment.java:412)
> at
> io.micronaut.context.env.DefaultEnvironment.start(DefaultEnvironment.java:270)
> at
> io.micronaut.context.DefaultApplicationContext$RuntimeConfiguredEnvironment.start(DefaultApplicationContext.java:769)
> at
> io.micronaut.context.DefaultApplicationContext$RuntimeConfiguredEnvironment.start(DefaultApplicationContext.java:738)
> at
> io.micronaut.context.DefaultApplicationContext.startEnvironment(DefaultApplicationContext.java:242)
> at
> io.micronaut.context.DefaultApplicationContext.start(DefaultApplicationContext.java:193)
> at
> io.micronaut.test.extensions.AbstractMicronautExtension.startApplicationContext(AbstractMicronautExtension.java:433)
> at
> io.micronaut.test.extensions.AbstractMicronautExtension.beforeClass(AbstractMicronautExtension.java:314)
> at
> io.micronaut.test.extensions.junit5.MicronautJunit5Extension.beforeAll(MicronautJunit5Extension.java:84)
> at
> org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.lambda$invokeBeforeAllCallbacks$12(ClassBasedTestDescriptor.java:395)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.invokeBeforeAllCallbacks(ClassBasedTestDescriptor.java:395)
> at
> org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.before(ClassBasedTestDescriptor.java:211)
> at
> org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.before(ClassBasedTestDescriptor.java:84)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:148)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
> at
> org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
> at
> org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
> at
> org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:41)
> at
> org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:155)
> at
>
[jira] [Updated] (IGNITE-20791) Tets does not work through Idea due to the versions of snakeyaml conflict
[
https://issues.apache.org/jira/browse/IGNITE-20791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-20791:
---
Description:
That is the exception:
{noformat}
java.lang.NoSuchMethodError: org.yaml.snakeyaml.constructor.SafeConstructor:
method ()V not found
at
io.micronaut.context.env.yaml.CustomSafeConstructor.(CustomSafeConstructor.java:36)
at
io.micronaut.context.env.yaml.YamlPropertySourceLoader.processInput(YamlPropertySourceLoader.java:56)
at
io.micronaut.context.env.AbstractPropertySourceLoader.read(AbstractPropertySourceLoader.java:117)
at
io.micronaut.context.env.AbstractPropertySourceLoader.loadProperties(AbstractPropertySourceLoader.java:102)
at
io.micronaut.context.env.AbstractPropertySourceLoader.load(AbstractPropertySourceLoader.java:68)
at
io.micronaut.context.env.AbstractPropertySourceLoader.load(AbstractPropertySourceLoader.java:55)
at
io.micronaut.context.env.DefaultEnvironment.loadPropertySourceFromLoader(DefaultEnvironment.java:607)
at
io.micronaut.context.env.DefaultEnvironment.readPropertySourceList(DefaultEnvironment.java:541)
at
io.micronaut.context.env.DefaultEnvironment.readPropertySourceList(DefaultEnvironment.java:527)
at
io.micronaut.context.DefaultApplicationContext$RuntimeConfiguredEnvironment.readPropertySourceList(DefaultApplicationContext.java:794)
at
io.micronaut.context.env.DefaultEnvironment.readPropertySources(DefaultEnvironment.java:412)
at
io.micronaut.context.env.DefaultEnvironment.start(DefaultEnvironment.java:270)
at
io.micronaut.context.DefaultApplicationContext$RuntimeConfiguredEnvironment.start(DefaultApplicationContext.java:769)
at
io.micronaut.context.DefaultApplicationContext$RuntimeConfiguredEnvironment.start(DefaultApplicationContext.java:738)
at
io.micronaut.context.DefaultApplicationContext.startEnvironment(DefaultApplicationContext.java:242)
at
io.micronaut.context.DefaultApplicationContext.start(DefaultApplicationContext.java:193)
at
io.micronaut.test.extensions.AbstractMicronautExtension.startApplicationContext(AbstractMicronautExtension.java:433)
at
io.micronaut.test.extensions.AbstractMicronautExtension.beforeClass(AbstractMicronautExtension.java:314)
at
io.micronaut.test.extensions.junit5.MicronautJunit5Extension.beforeAll(MicronautJunit5Extension.java:84)
at
org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.lambda$invokeBeforeAllCallbacks$12(ClassBasedTestDescriptor.java:395)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.invokeBeforeAllCallbacks(ClassBasedTestDescriptor.java:395)
at
org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.before(ClassBasedTestDescriptor.java:211)
at
org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.before(ClassBasedTestDescriptor.java:84)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:148)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at
org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
at
org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:41)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:155)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at
org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
[jira] [Updated] (IGNITE-20791) Tets does not work through Idea due to the versions of snakeyaml conflict
[
https://issues.apache.org/jira/browse/IGNITE-20791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-20791:
---
Description:
That is the exception:
{noformat}
java.lang.NoSuchMethodError: org.yaml.snakeyaml.constructor.SafeConstructor:
method ()V not found
at
io.micronaut.context.env.yaml.CustomSafeConstructor.(CustomSafeConstructor.java:36)
at
io.micronaut.context.env.yaml.YamlPropertySourceLoader.processInput(YamlPropertySourceLoader.java:56)
at
io.micronaut.context.env.AbstractPropertySourceLoader.read(AbstractPropertySourceLoader.java:117)
at
io.micronaut.context.env.AbstractPropertySourceLoader.loadProperties(AbstractPropertySourceLoader.java:102)
at
io.micronaut.context.env.AbstractPropertySourceLoader.load(AbstractPropertySourceLoader.java:68)
at
io.micronaut.context.env.AbstractPropertySourceLoader.load(AbstractPropertySourceLoader.java:55)
at
io.micronaut.context.env.DefaultEnvironment.loadPropertySourceFromLoader(DefaultEnvironment.java:607)
at
io.micronaut.context.env.DefaultEnvironment.readPropertySourceList(DefaultEnvironment.java:541)
at
io.micronaut.context.env.DefaultEnvironment.readPropertySourceList(DefaultEnvironment.java:527)
at
io.micronaut.context.DefaultApplicationContext$RuntimeConfiguredEnvironment.readPropertySourceList(DefaultApplicationContext.java:794)
at
io.micronaut.context.env.DefaultEnvironment.readPropertySources(DefaultEnvironment.java:412)
at
io.micronaut.context.env.DefaultEnvironment.start(DefaultEnvironment.java:270)
at
io.micronaut.context.DefaultApplicationContext$RuntimeConfiguredEnvironment.start(DefaultApplicationContext.java:769)
at
io.micronaut.context.DefaultApplicationContext$RuntimeConfiguredEnvironment.start(DefaultApplicationContext.java:738)
at
io.micronaut.context.DefaultApplicationContext.startEnvironment(DefaultApplicationContext.java:242)
at
io.micronaut.context.DefaultApplicationContext.start(DefaultApplicationContext.java:193)
at
io.micronaut.test.extensions.AbstractMicronautExtension.startApplicationContext(AbstractMicronautExtension.java:433)
at
io.micronaut.test.extensions.AbstractMicronautExtension.beforeClass(AbstractMicronautExtension.java:314)
at
io.micronaut.test.extensions.junit5.MicronautJunit5Extension.beforeAll(MicronautJunit5Extension.java:84)
at
org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.lambda$invokeBeforeAllCallbacks$12(ClassBasedTestDescriptor.java:395)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.invokeBeforeAllCallbacks(ClassBasedTestDescriptor.java:395)
at
org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.before(ClassBasedTestDescriptor.java:211)
at
org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.before(ClassBasedTestDescriptor.java:84)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:148)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at
org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
at
org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:41)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:155)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at
org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
[jira] [Created] (IGNITE-20791) Tets does not work through Idea due to the versions of snakeyaml conflict
Vladislav Pyatkov created IGNITE-20791:
--
Summary: Tets does not work through Idea due to the versions of
snakeyaml conflict
Key: IGNITE-20791
URL: https://issues.apache.org/jira/browse/IGNITE-20791
Project: Ignite
Issue Type: Bug
Reporter: Vladislav Pyatkov
That is the exception:
{noformat}
java.lang.NoSuchMethodError: org.yaml.snakeyaml.constructor.SafeConstructor:
method ()V not found
at
io.micronaut.context.env.yaml.CustomSafeConstructor.(CustomSafeConstructor.java:36)
at
io.micronaut.context.env.yaml.YamlPropertySourceLoader.processInput(YamlPropertySourceLoader.java:56)
at
io.micronaut.context.env.AbstractPropertySourceLoader.read(AbstractPropertySourceLoader.java:117)
at
io.micronaut.context.env.AbstractPropertySourceLoader.loadProperties(AbstractPropertySourceLoader.java:102)
at
io.micronaut.context.env.AbstractPropertySourceLoader.load(AbstractPropertySourceLoader.java:68)
at
io.micronaut.context.env.AbstractPropertySourceLoader.load(AbstractPropertySourceLoader.java:55)
at
io.micronaut.context.env.DefaultEnvironment.loadPropertySourceFromLoader(DefaultEnvironment.java:607)
at
io.micronaut.context.env.DefaultEnvironment.readPropertySourceList(DefaultEnvironment.java:541)
at
io.micronaut.context.env.DefaultEnvironment.readPropertySourceList(DefaultEnvironment.java:527)
at
io.micronaut.context.DefaultApplicationContext$RuntimeConfiguredEnvironment.readPropertySourceList(DefaultApplicationContext.java:794)
at
io.micronaut.context.env.DefaultEnvironment.readPropertySources(DefaultEnvironment.java:412)
at
io.micronaut.context.env.DefaultEnvironment.start(DefaultEnvironment.java:270)
at
io.micronaut.context.DefaultApplicationContext$RuntimeConfiguredEnvironment.start(DefaultApplicationContext.java:769)
at
io.micronaut.context.DefaultApplicationContext$RuntimeConfiguredEnvironment.start(DefaultApplicationContext.java:738)
at
io.micronaut.context.DefaultApplicationContext.startEnvironment(DefaultApplicationContext.java:242)
at
io.micronaut.context.DefaultApplicationContext.start(DefaultApplicationContext.java:193)
at
io.micronaut.test.extensions.AbstractMicronautExtension.startApplicationContext(AbstractMicronautExtension.java:433)
at
io.micronaut.test.extensions.AbstractMicronautExtension.beforeClass(AbstractMicronautExtension.java:314)
at
io.micronaut.test.extensions.junit5.MicronautJunit5Extension.beforeAll(MicronautJunit5Extension.java:84)
at
org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.lambda$invokeBeforeAllCallbacks$12(ClassBasedTestDescriptor.java:395)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.invokeBeforeAllCallbacks(ClassBasedTestDescriptor.java:395)
at
org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.before(ClassBasedTestDescriptor.java:211)
at
org.junit.jupiter.engine.descriptor.ClassBasedTestDescriptor.before(ClassBasedTestDescriptor.java:84)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:148)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at
org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$9(NodeTestTask.java:139)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.executeRecursively(NodeTestTask.java:138)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.execute(NodeTestTask.java:95)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
at
org.junit.platform.engine.support.hierarchical.SameThreadHierarchicalTestExecutorService.invokeAll(SameThreadHierarchicalTestExecutorService.java:41)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$6(NodeTestTask.java:155)
at
org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
at
org.junit.platform.engine.support.hierarchical.NodeTestTask.lambda$executeRecursively$8(NodeTestTask.java:141)
at
org.junit.platform.engine.support.hierarchical.Node.around(Node.java:137)
at
[jira] [Created] (IGNITE-20790) Implement Catalog compaction
Roman Puchkovskiy created IGNITE-20790: -- Summary: Implement Catalog compaction Key: IGNITE-20790 URL: https://issues.apache.org/jira/browse/IGNITE-20790 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy When a Catalog version is not needed anymore (this has to be defined), we should remove it. Only the full prefixes can be removed. This means that if version N is still needed, we cannot remove versions M>N. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20789) Remove outdated schemas stored in SchemaManager
Roman Puchkovskiy created IGNITE-20789: -- Summary: Remove outdated schemas stored in SchemaManager Key: IGNITE-20789 URL: https://issues.apache.org/jira/browse/IGNITE-20789 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy When a schema version is not needed (that is, no tuple can be written in this schema AND no tuple exists in the storage (that is written in this schema) that can be read), it should be removed. Only whole prefixes might be removed (so, if we must keep version N, then we cannot remove versions N+). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20788) Make primary key indexes immediately available
Kirill Tkalenko created IGNITE-20788: Summary: Make primary key indexes immediately available Key: IGNITE-20788 URL: https://issues.apache.org/jira/browse/IGNITE-20788 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko Fix For: 3.0.0-beta2 It is necessary to make sure that the created primary key indexes immediately become available upon table creation and are not built, since this is not necessary. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18660) Sql. Decimal out of range error does not occur
[
https://issues.apache.org/jira/browse/IGNITE-18660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782527#comment-17782527
]
Evgeny Stanilovsky commented on IGNITE-18660:
-
analogous query not fail on PG and returns the same result, can we close it ?
> Sql. Decimal out of range error does not occur
> --
>
> Key: IGNITE-18660
> URL: https://issues.apache.org/jira/browse/IGNITE-18660
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
>
> The following query is expected to fail but it does not.
> {code:java}
> statement error
> SELECT ('0.54321543215432154321543215432154321'::DECIMAL(35,35) +
> 1)::VARCHAR
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18662) Sql. Numeric to/from decimal cast with overflow does not produce an error
[
https://issues.apache.org/jira/browse/IGNITE-18662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-18662:
Ignite Flags: (was: Docs Required,Release Notes Required)
> Sql. Numeric to/from decimal cast with overflow does not produce an error
> --
>
> Key: IGNITE-18662
> URL: https://issues.apache.org/jira/browse/IGNITE-18662
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: calcite2-required, calcite3-required, ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Casts from numeric type to decimal with overflow must fail but they return a
> result:
> {code:java}
> SELECT 1000::BIGINT::DECIMAL(3,1)
> {code}
> Returns
> {code:java}
>
> 100
> {code}
> And the following query:
> {code:java}
> SELECT 2147483648::DECIMAL(18,0)::INTEGER
>
> -2147483648
> # Integer.MIN_VALUE
> {code}
> {code:java}
> query I
> SELECT 128::DECIMAL(3,0)::TINYINT
>
> -128
> # Byte.MIN_VALUE
> {code}
> See skipif-ed examples in cast_to_decimal.test and cast_from_decimal.test
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20773) Adjust lock resolution procedure in order to have an ability to do tx coordinator liveness check
[ https://issues.apache.org/jira/browse/IGNITE-20773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-20773: -- Summary: Adjust lock resolution procedure in order to have an ability to do tx coordinator liveness check (was: Adjust log resolution procedure in order to have an ability to do tx coordinator liveness check) > Adjust lock resolution procedure in order to have an ability to do tx > coordinator liveness check > > > Key: IGNITE-20773 > URL: https://issues.apache.org/jira/browse/IGNITE-20773 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Denis Chudov >Priority: Major > > h3. Motivation > In order to implemented liveness check and thus initiate transaction recovery > if the corresponding coordinator is dead, it's required to adjust lock > resolution procedure. > h3. Definition of done > Liveness check described in IGNITE-20771 is triggered, meaning that txId of > first lock is available. > h3. Implementation Notes > Given ticket finishes the chain of lock triggered tx recovery (coordinator > aspect) thus it's required also to add some integration tests here for the > whole chain. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20719) [ducktests] CDC ducktests do not work if HTTP metrics export is enabled
[ https://issues.apache.org/jira/browse/IGNITE-20719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-20719: - Ignite Flags: (was: Docs Required,Release Notes Required) > [ducktests] CDC ducktests do not work if HTTP metrics export is enabled > --- > > Key: IGNITE-20719 > URL: https://issues.apache.org/jira/browse/IGNITE-20719 > Project: Ignite > Issue Type: Task >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > There are several problems preventing the CDC ducktests to work correctly if > HTTP metrics exporter (opencensus prometheus) is enabled: > # Prometheus metrics HTTP port conflict between ignite.sh and ignite-cdc.sh > processes. > # StandaloneGridKernalContext used in ignite-cdc.sh returns null as ignite > instance name but it's needed by the opencensus metrics exporter with the > sendInstanceName=True (which in turn is needed for ducktests to bound metrics > to particular test instance). > # Current ignite_spec overrides the ignite_instance_name if metrics were > enabled preventing using of different custom names. Which is needed for CDC > tests there two ignite configurations are specified in the same XML config > file on the same node (one for source and another for the target cluster). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20719) [ducktests] CDC ducktests do not work if HTTP metrics export is enabled
[ https://issues.apache.org/jira/browse/IGNITE-20719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-20719: - Fix Version/s: 2.16 > [ducktests] CDC ducktests do not work if HTTP metrics export is enabled > --- > > Key: IGNITE-20719 > URL: https://issues.apache.org/jira/browse/IGNITE-20719 > Project: Ignite > Issue Type: Task >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > Fix For: 2.16 > > Time Spent: 20m > Remaining Estimate: 0h > > There are several problems preventing the CDC ducktests to work correctly if > HTTP metrics exporter (opencensus prometheus) is enabled: > # Prometheus metrics HTTP port conflict between ignite.sh and ignite-cdc.sh > processes. > # StandaloneGridKernalContext used in ignite-cdc.sh returns null as ignite > instance name but it's needed by the opencensus metrics exporter with the > sendInstanceName=True (which in turn is needed for ducktests to bound metrics > to particular test instance). > # Current ignite_spec overrides the ignite_instance_name if metrics were > enabled preventing using of different custom names. Which is needed for CDC > tests there two ignite configurations are specified in the same XML config > file on the same node (one for source and another for the target cluster). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-20719) [ducktests] CDC ducktests do not work if HTTP metrics export is enabled
[ https://issues.apache.org/jira/browse/IGNITE-20719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky resolved IGNITE-20719. -- Resolution: Fixed [~serge.korotkov] Thanks for your contribution, merged > [ducktests] CDC ducktests do not work if HTTP metrics export is enabled > --- > > Key: IGNITE-20719 > URL: https://issues.apache.org/jira/browse/IGNITE-20719 > Project: Ignite > Issue Type: Task >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > There are several problems preventing the CDC ducktests to work correctly if > HTTP metrics exporter (opencensus prometheus) is enabled: > # Prometheus metrics HTTP port conflict between ignite.sh and ignite-cdc.sh > processes. > # StandaloneGridKernalContext used in ignite-cdc.sh returns null as ignite > instance name but it's needed by the opencensus metrics exporter with the > sendInstanceName=True (which in turn is needed for ducktests to bound metrics > to particular test instance). > # Current ignite_spec overrides the ignite_instance_name if metrics were > enabled preventing using of different custom names. Which is needed for CDC > tests there two ignite configurations are specified in the same XML config > file on the same node (one for source and another for the target cluster). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20608) ItIgniteNodeRestartTest#nodeWithDataTest is flaky on TC
[
https://issues.apache.org/jira/browse/IGNITE-20608?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin reassigned IGNITE-20608:
Assignee: Alexander Lapin
> ItIgniteNodeRestartTest#nodeWithDataTest is flaky on TC
> ---
>
> Key: IGNITE-20608
> URL: https://issues.apache.org/jira/browse/IGNITE-20608
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Alexander Lapin
>Priority: Major
> Labels: ignite-3
>
> Test fails in different branches with timeout in test logic, stack trace:
> {code:java}
> org.awaitility.core.ConditionTimeoutException: Condition with lambda
> expression in org.apache.ignite.internal.runner.app.ItIgniteNodeRestartTest
> that uses org.apache.ignite.table.Table, org.apache.ignite.table.Tableint was
> not fulfilled within 30 seconds.
> at
> app//org.awaitility.core.ConditionAwaiter.await(ConditionAwaiter.java:167)
> at
> app//org.awaitility.core.CallableCondition.await(CallableCondition.java:78)
> at
> app//org.awaitility.core.CallableCondition.await(CallableCondition.java:26)
> at
> app//org.awaitility.core.ConditionFactory.until(ConditionFactory.java:985)
> at
> app//org.awaitility.core.ConditionFactory.until(ConditionFactory.java:954)
> at
> app//org.apache.ignite.internal.runner.app.ItIgniteNodeRestartTest.checkTableWithData(ItIgniteNodeRestartTest.java:1182)
> at
> app//org.apache.ignite.internal.runner.app.ItIgniteNodeRestartTest.nodeWithDataTest(ItIgniteNodeRestartTest.java:751)
> at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> //... not so important stack trace lines {code}
> Its history is available
> [here|https://ci.ignite.apache.org/project.html?projectId=ApacheIgnite3xGradle_Test_IntegrationTests=7638414685760227643=testDetails],
> it is not clear what commit introduced this flakiness.
> Some other tests from the same class fail as well, they may share the same
> root cause so worth investigating them in the single ticket:
> *
> [ItIgniteNodeRestartTest.testTwoNodesRestartReverse|https://ci.ignite.apache.org/project.html?projectId=ApacheIgnite3xGradle_Test_IntegrationTests=-6899510263921361541=testDetails_ApacheIgnite3xGradle_Test_IntegrationTests=%3Cdefault%3E]
> *
> [ItIgniteNodeRestartTest.nodeWithDataAndIndexRebuildTest|https://ci.ignite.apache.org/project.html?projectId=ApacheIgnite3xGradle_Test_IntegrationTests=6204054563732065266=testDetails_ApacheIgnite3xGradle_Test_IntegrationTests=%3Cdefault%3E]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20356) Sql. Rework RowHandler "set" operation.
[
https://issues.apache.org/jira/browse/IGNITE-20356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov reassigned IGNITE-20356:
-
Assignee: Maksim Zhuravkov
> Sql. Rework RowHandler "set" operation.
> ---
>
> Key: IGNITE-20356
> URL: https://issues.apache.org/jira/browse/IGNITE-20356
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In IGNITE-19791, a wrapper over {{BinaryTuple}} was added.
> This wrapper ({{BinaryTupleRowWrapper}}) does not support the "{{set()}}"
> method
> Instead of using {{set(int, RowT, Object)}} method, we can use the
> {{append(RowT, Object)}} method to add field values sequentially.
> We need:
> * Add a new RowFactory method that will return a builder that allows you to
> append values to row and build the row.
> * Remove the {{RowHandler#set()}} method and rework all related code/tests
> to use the builder.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20787) Extract interface from TableImpl
Vadim Pakhnushev created IGNITE-20787:
-
Summary: Extract interface from TableImpl
Key: IGNITE-20787
URL: https://issues.apache.org/jira/browse/IGNITE-20787
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Vadim Pakhnushev
Assignee: Vadim Pakhnushev
There's a public API {{Table}} and {{IgniteTables}} and corresponding internal
{{TableImpl}} {{IgniteTablesInternal}} but the {{TableImpl}} is not an
interface which leaks to other modules and complicates further refactorings. We
should extract an interface from it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20786) Disable logit log storage by default
[ https://issues.apache.org/jira/browse/IGNITE-20786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782467#comment-17782467 ] Kirill Tkalenko commented on IGNITE-20786: -- Looks good! > Disable logit log storage by default > > > Key: IGNITE-20786 > URL: https://issues.apache.org/jira/browse/IGNITE-20786 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently, new log storage allocates too much space in tests. If I reduce > segment file size to reasonably small value (say, 128Kb), it starts failing > due to bugs in implementation (in jraft itself, not in our code). > Let's roll it back and then fix without rushing -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20786) Disable logit log storage by default
[ https://issues.apache.org/jira/browse/IGNITE-20786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-20786: --- Fix Version/s: 3.0.0-beta2 > Disable logit log storage by default > > > Key: IGNITE-20786 > URL: https://issues.apache.org/jira/browse/IGNITE-20786 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Currently, new log storage allocates too much space in tests. If I reduce > segment file size to reasonably small value (say, 128Kb), it starts failing > due to bugs in implementation (in jraft itself, not in our code). > Let's roll it back and then fix without rushing -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20786) Disable logit log storage by default
Ivan Bessonov created IGNITE-20786: -- Summary: Disable logit log storage by default Key: IGNITE-20786 URL: https://issues.apache.org/jira/browse/IGNITE-20786 Project: Ignite Issue Type: Improvement Reporter: Ivan Bessonov Assignee: Ivan Bessonov Currently, new log storage allocates too much space in tests. If I reduce segment file size to reasonably small value (say, 128Kb), it starts failing due to bugs in implementation (in jraft itself, not in our code). Let's roll it back and then fix without rushing -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20785) .NET: Thin 3.0: TestAuthnOnServerNoAuthnOnClient is flaky
[
https://issues.apache.org/jira/browse/IGNITE-20785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-20785:
Description:
https://ci.ignite.apache.org/test/8027961041270686932?currentProjectId=ApacheIgnite3xGradle_Test=true=
{code}
Expected: No Exception to be thrown
But was: Apache.Ignite.Security.Exception.InvalidCredentialsException:
Authentication failed
---> Apache.Ignite.IgniteException:
org.apache.ignite.security.exception.InvalidCredentialsException:
IGN-AUTHENTICATION-2 TraceId:0ea2bf31-ef59-42c3-b5f5-e8369d2ac082
Authentication failed
at
org.apache.ignite.internal.security.authentication.AuthenticationManagerImpl.lambda$authenticate$1(AuthenticationManagerImpl.java:72)
...
at Apache.Ignite.Tests.BasicAuthenticatorTests.DisableAuthenticationAfterTest()
in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/BasicAuthenticatorTests.cs:line
39
{code}
> .NET: Thin 3.0: TestAuthnOnServerNoAuthnOnClient is flaky
> -
>
> Key: IGNITE-20785
> URL: https://issues.apache.org/jira/browse/IGNITE-20785
> Project: Ignite
> Issue Type: Improvement
> Components: platforms, thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>
> https://ci.ignite.apache.org/test/8027961041270686932?currentProjectId=ApacheIgnite3xGradle_Test=true=
> {code}
> Expected: No Exception to be thrown
> But was: to endpoint: 127.0.0.1:10942
> ---> Apache.Ignite.Security.Exception.InvalidCredentialsException:
> Authentication failed
> ---> Apache.Ignite.IgniteException:
> org.apache.ignite.security.exception.InvalidCredentialsException:
> IGN-AUTHENTICATION-2 TraceId:0ea2bf31-ef59-42c3-b5f5-e8369d2ac082
> Authentication failed
> at
> org.apache.ignite.internal.security.authentication.AuthenticationManagerImpl.lambda$authenticate$1(AuthenticationManagerImpl.java:72)
> ...
> at
> Apache.Ignite.Tests.BasicAuthenticatorTests.DisableAuthenticationAfterTest()
> in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/BasicAuthenticatorTests.cs:line
> 39
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20785) .NET: Thin 3.0: TestAuthnOnServerNoAuthnOnClient is flaky
Pavel Tupitsyn created IGNITE-20785: --- Summary: .NET: Thin 3.0: TestAuthnOnServerNoAuthnOnClient is flaky Key: IGNITE-20785 URL: https://issues.apache.org/jira/browse/IGNITE-20785 Project: Ignite Issue Type: Improvement Components: platforms, thin client Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20774) ItRebalanceDistributedTest#testRebalanceRetryWhenCatchupFailed is flaky on TC
[
https://issues.apache.org/jira/browse/IGNITE-20774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko reassigned IGNITE-20774:
Assignee: Kirill Tkalenko
> ItRebalanceDistributedTest#testRebalanceRetryWhenCatchupFailed is flaky on TC
> -
>
> Key: IGNITE-20774
> URL: https://issues.apache.org/jira/browse/IGNITE-20774
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Chugunov
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Attachments: _Integration_Tests_Module_Runner_18723.log.zip
>
>
> Test fails with timeout in different branches including main:
> {code:java}
> java.util.concurrent.TimeoutException: after() timed out after 60 seconds
> at
> org.junit.jupiter.engine.extension.TimeoutExceptionFactory.create(TimeoutExceptionFactory.java:29)
> at
> org.junit.jupiter.engine.extension.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:58)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptLifecycleMethod(TimeoutExtension.java:128)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptAfterEachMethod(TimeoutExtension.java:110)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> ...
> {code}
> From stack trace it is not clear where test timed out.
> TC run with failed test in main is available
> [here|https://ci.ignite.apache.org/viewLog.html?buildId=7593604=buildResultsDiv=ApacheIgnite3xGradle_Test_IntegrationTests_ModuleRunner]
> test logs are attached.
> Also TC reports NullPointerException in logs, it is not clear whether timeout
> is caused but this NPE:
> {code:java}
> [2023-10-29T00:37:45,888][ERROR][%irdt_trrwcf_2%JRaft-FSMCaller-Disruptor-_stripe_4-0][StripedDisruptor]
> Handle disruptor event error
> [name=%irdt_trrwcf_2%JRaft-FSMCaller-Disruptor-,
> event=org.apache.ignite.raft.jraft.core.FSMCallerImpl$ApplyTask@55293f4b,
> hasHandler=false]
> java.lang.NullPointerException: null
> at
> org.apache.ignite.raft.jraft.core.FSMCallerImpl.doCommitted(FSMCallerImpl.java:492)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.core.FSMCallerImpl.runApplyTask(FSMCallerImpl.java:382)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.core.FSMCallerImpl$ApplyTaskHandler.onEvent(FSMCallerImpl.java:136)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.core.FSMCallerImpl$ApplyTaskHandler.onEvent(FSMCallerImpl.java:130)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:226)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:191)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:137)
> [disruptor-3.3.7.jar:?]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20775) Create configuration and reasonable test defaults for logit storage
[ https://issues.apache.org/jira/browse/IGNITE-20775?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-20775: --- Fix Version/s: 3.0.0-beta2 > Create configuration and reasonable test defaults for logit storage > --- > > Key: IGNITE-20775 > URL: https://issues.apache.org/jira/browse/IGNITE-20775 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Right now, tests allocate too much disk space during runs. Literally > gigabytes. > We must provide better defaults for tests (in TestIgnitionManager, for > example). > We should also check that restart with updated configuration doesn't break > anything. > Other minor fixes are welcomed here as well. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20301) ItIgniteInMemoryNodeRestartTest tests are flaky
[
https://issues.apache.org/jira/browse/IGNITE-20301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17782439#comment-17782439
]
Roman Puchkovskiy commented on IGNITE-20301:
Thanks
> ItIgniteInMemoryNodeRestartTest tests are flaky
> ---
>
> Key: IGNITE-20301
> URL: https://issues.apache.org/jira/browse/IGNITE-20301
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3, tech-debt
> Fix For: 3.0.0-beta2
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> inMemoryNodeRestartNotLeader and inMemoryNodeFullPartitionRestart fail 50/50
> on my machine.
> For both tests, the following is seen in the console when they fail:
> [2023-08-29T11:20:35,053][ERROR][%iiimnrt_imnfpr_3344%JRaft-Common-Executor-0][LogThreadPoolExecutor]
> Uncaught exception in pool: %iiimnrt_imnfpr_3344%JRaft-Common-Executor-,
> org.apache.ignite.raft.jraft.util.MetricThreadPoolExecutor@76504d30[Running,
> pool size = 4, active threads = 2, queued tasks = 0, completed tasks = 1601].
> java.lang.IllegalArgumentException: null
> at
> org.apache.ignite.raft.jraft.util.Requires.requireTrue(Requires.java:64)
> ~[main/:?]
> at
> org.apache.ignite.raft.jraft.core.Replicator.fillCommonFields(Replicator.java:1553)
> ~[main/:?]
> at
> org.apache.ignite.raft.jraft.core.Replicator.sendEntries(Replicator.java:1631)
> ~[main/:?]
> at
> org.apache.ignite.raft.jraft.core.Replicator.sendEntries(Replicator.java:1601)
> ~[main/:?]
> at
> org.apache.ignite.raft.jraft.core.Replicator.continueSending(Replicator.java:983)
> ~[main/:?]
> at
> org.apache.ignite.raft.jraft.core.Replicator.lambda$waitMoreEntries$9(Replicator.java:1583)
> ~[main/:?]
> at
> org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.runOnNewLog(LogManagerImpl.java:1197)
> ~[main/:?]
> at
> org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.lambda$wakeupAllWaiter$6(LogManagerImpl.java:398)
> ~[main/:?]
> at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515) ~[?:?]
> at java.util.concurrent.FutureTask.run(FutureTask.java:264) ~[?:?]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> ~[?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> ~[?:?]
> at java.lang.Thread.run(Thread.java:834) ~[?:?]
>
> {*}Update{*}: as of 2023-11-01, these failures can not be reproduced anymore,
> but others can be seen (with much lower frequency, approx 1 in a few dozen
> runs).
> These happen for the following reason. When we recover an in-memory
> partition, we want to ask other participants of the group whether they have
> data in this partition or not. If we don't have the corresponding nodes in
> our local physical topology, we treat this as if they did not have the data.
> So if we recover a partition before SWIM has managed to fully deliver
> information about other cluster nodes (as ClusterService start does not imply
> that all this information is received), we skip those nodes, so we might
> think there is no majority and fail the partition start.
> A possible solution is to wait till the nodes appear in the topology, up to
> some timeout (like 3 seconds).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
