[jira] [Assigned] (IGNITE-20447) Introduce a new failure handling component
[ https://issues.apache.org/jira/browse/IGNITE-20447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel reassigned IGNITE-20447: -- Assignee: Sergey Uttsel > Introduce a new failure handling component > -- > > Key: IGNITE-20447 > URL: https://issues.apache.org/jira/browse/IGNITE-20447 > Project: Ignite > Issue Type: Improvement >Reporter: Vyacheslav Koptilin >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3 > > Let's add a new component `failure` to Apache Ignite 3 and add base > interfaces to this component. > *Definition of done:* > - introduced a new module to Ignite 3 codebase > - introduced a new Ignite component - _FailureProcessor _with minimal no-op > implementation. This component is responsible for processing critical errors. > - introduced a new _FailureHandler _interface. An implementation of this > interface represents a concrete strategy for handling errors. > - introduced a new enum _FailureType _that describes a possible type of > failure. The following types can be considered as a starting point: > _CRITICAL_ERROR_, _SYSTEM_WORKER_TERMINATION_, _SYSTEM_WORKER_BLOCKED_, > _SYSTEM_CRITICAL_OPERATION_TIMEOUT_ > - introduced a new class _FailureContext _that contains information about > failure type and exception. > *Implemenattion notes:* > All these classes and interfaces should be a part of internal API due to > the end user should not provide a custom implementation of the failure > handler, Apache Ignite should provide a closed list of handlers out of the > box. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20468) .NET: Thin 3.0: Intermittent timeouts on TC
Pavel Tupitsyn created IGNITE-20468: --- Summary: .NET: Thin 3.0: Intermittent timeouts on TC Key: IGNITE-20468 URL: https://issues.apache.org/jira/browse/IGNITE-20468 Project: Ignite Issue Type: Bug Components: platforms, thin client Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 Increased number of .NET TC builds fail with timeout errors. Investigate whether some specific test or behavior is causing this, whether this is a problem on server side, etc * https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunNetTests?branch=%3Cdefault%3E&mode=builds#all-projects * `Fail to issue RPC to org.apache.ignite.internal.runner.app.PlatformTestNodeRunner_2, consecutiveErrorTimes=10, error=Status[ETIMEDOUT<1010>: RPC exception:null]` * `OneTimeSetUp: System.TimeoutException : The operation has timed out.` ** Which operation? Why is there no stack trace? -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20376) ItServerDataStreamerTest.testManyItems is flaky: PrimaryReplicaMissException
[ https://issues.apache.org/jira/browse/IGNITE-20376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20376: Description: {code} java.util.concurrent.CompletionException: org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException: IGN-REP-6 TraceId:72a5da42-c429-447a-aaf3-86c1137994dd The primary replica has changed because the term has been changed [expectedPrimaryReplicaTerm=1, currentPrimaryReplicaTerm=2] {code} Looks like we should handle and retry *PrimaryReplicaMissException* in the server streamer. was: {code} java.util.concurrent.CompletionException: org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException: IGN-REP-6 TraceId:72a5da42-c429-447a-aaf3-86c1137994dd The primary replica has changed because the term has been changed [expectedPrimaryReplicaTerm=1, currentPrimaryReplicaTerm=2] {code} > ItServerDataStreamerTest.testManyItems is flaky: PrimaryReplicaMissException > > > Key: IGNITE-20376 > URL: https://issues.apache.org/jira/browse/IGNITE-20376 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Attachments: ignite-20376.txt > > > {code} > java.util.concurrent.CompletionException: > org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException: > IGN-REP-6 TraceId:72a5da42-c429-447a-aaf3-86c1137994dd The primary replica > has changed because the term has been changed [expectedPrimaryReplicaTerm=1, > currentPrimaryReplicaTerm=2] > {code} > Looks like we should handle and retry *PrimaryReplicaMissException* in the > server streamer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20055) Durable txCleanupReplicaRequest send from the commit partition
[ https://issues.apache.org/jira/browse/IGNITE-20055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Sizov reassigned IGNITE-20055: -- Assignee: Kirill Sizov > Durable txCleanupReplicaRequest send from the commit partition > -- > > Key: IGNITE-20055 > URL: https://issues.apache.org/jira/browse/IGNITE-20055 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Kirill Sizov >Priority: Major > Labels: ignite-3, transaction3_recovery, transactions > > h3. Motivation > It's required to continuously send txCleanupReplicaRequest to the primary > replica. Suggested flow is following. > h3. Definition of Done > # Resend exact the same type of finish output that was initially evaluated, > meaning that commit will be resent infinitely even if previous > txCleanupReplicaRequest returns an exception. > # Await commit partition primary replica appearance in case of initially > enlisted recipient failure. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20424) [Thin clients] Slow thin clients connection can lead to huge amount heap consuming
[ https://issues.apache.org/jira/browse/IGNITE-20424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-20424: Summary: [Thin clients] Slow thin clients connection can lead to huge amount heap consuming (was: [Thin clients] Slow thin clients connection can lead to node failure with OOM) > [Thin clients] Slow thin clients connection can lead to huge amount heap > consuming > -- > > Key: IGNITE-20424 > URL: https://issues.apache.org/jira/browse/IGNITE-20424 > Project: Ignite > Issue Type: Task >Reporter: Mikhail Petrov >Priority: Major > Labels: ise > > All messages designated for the thin client are accumulated in the selector > queue GridSelectorNioSessionImpl#queue before they are sent. Note that > GridSelectorNioSessionImpl#queue is unbound. If the thin client connection > is slow and a huge number of messages with a large weight will be sent to it, > GridSelectorNioSessionImpl#queue growing size can lead to OOM. > See > 1. https://issues.apache.org/jira/browse/IGNITE-20327 > 2. https://github.com/apache/ignite/issues/10559 > We need to investigate mechanisms to limit the thin client message queue size. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20469) Sql. improve usability of EXPLAIN
Yury Gerzhedovich created IGNITE-20469: -- Summary: Sql. improve usability of EXPLAIN Key: IGNITE-20469 URL: https://issues.apache.org/jira/browse/IGNITE-20469 Project: Ignite Issue Type: Improvement Components: sql Reporter: Yury Gerzhedovich -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20469) Sql. improve usability of EXPLAIN
[ https://issues.apache.org/jira/browse/IGNITE-20469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-20469: --- Description: Let's try to improve usability output of EXPLAIN command. We could use different levels/verbose. Default level should be the simplest, but more verbose should help to advanced users/developer understand what is going on more deeply. > Sql. improve usability of EXPLAIN > - > > Key: IGNITE-20469 > URL: https://issues.apache.org/jira/browse/IGNITE-20469 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > Let's try to improve usability output of EXPLAIN command. We could use > different levels/verbose. Default level should be the simplest, but more > verbose should help to advanced users/developer understand what is going on > more deeply. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20412) Fix ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart
[ https://issues.apache.org/jira/browse/IGNITE-20412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel updated IGNITE-20412: --- Description: h3. Motivation org.apache.ignite.internal.distribution.zones.ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart started to fall in the catalog-feature branch and fails in the main branch after catalog-feature is merged [https://ci.ignite.apache.org/viewLog.html?buildId=7501721&tab=buildResultsDiv&buildTypeId=ApacheIgnite3xGradle_Test_RunAllTests&logTab=] {code:java} java.lang.AssertionError: Expected: is <[]> but: was <[A]> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6) at org.apache.ignite.internal.distributionzones.DistributionZonesTestUtil.assertValueInStorage(DistributionZonesTestUtil.java:459) at org.apache.ignite.internal.distribution.zones.ItIgniteDistributionZoneManagerNodeRestartTest.testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart(ItIgniteDistributionZoneManagerNodeRestartTest.java:539) {code} h3. Implementation notes The root cause: # This test changes metaStorageManager behavior and it throws expected exception on ms.invoke. # The test alters zone with new filter. # DistributionZoneManager#onUpdateFilter return a future from saveDataNodesToMetaStorageOnScaleUp(zoneId, causalityToken) # The future is completed exceptionally and WatchProcessor#notificationFuture will be completed exceptionally. # Next updates will not be handled properly because notificationFuture is completed exceptionally. We have already created tickets obout exception handling: * https://issues.apache.org/jira/browse/IGNITE-14693 * https://issues.apache.org/jira/browse/IGNITE-14611 The test scenario is incorrect because the node should be stopped (by failure handler) if the ms.invoke failed. We need to rewrite it when the DZM restart will be updated. was: h3. Motivation org.apache.ignite.internal.distribution.zones.ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart started to fall in the catalog-feature branch and fails in the main branch after catalog-feature is merged https://ci.ignite.apache.org/viewLog.html?buildId=7501721&tab=buildResultsDiv&buildTypeId=ApacheIgnite3xGradle_Test_RunAllTests&logTab= {code:java} java.lang.AssertionError: Expected: is <[]> but: was <[A]> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6) at org.apache.ignite.internal.distributionzones.DistributionZonesTestUtil.assertValueInStorage(DistributionZonesTestUtil.java:459) at org.apache.ignite.internal.distribution.zones.ItIgniteDistributionZoneManagerNodeRestartTest.testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart(ItIgniteDistributionZoneManagerNodeRestartTest.java:539) {code} h3. Implementation notes The root cause: # This test changes metaStorageManager behavior and it throws expected exception on ms.invoke. # The test alters zone with new filter. # DistributionZoneManager#onUpdateFilter return a future from saveDataNodesToMetaStorageOnScaleUp(zoneId, causalityToken) # The future is completed exceptionally and WatchProcessor#notificationFuture will be completed exceptionally. # Next updates will not be handled properly because notificationFuture is completed exceptionally. We have already created tickets obout exception handling: * https://issues.apache.org/jira/browse/IGNITE-14693 * https://issues.apache.org/jira/browse/IGNITE-14611 I think the test scenario is incorrect because the node should be stopped (by failure handler) if the ms.invoke failed. > Fix > ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart > > > Key: IGNITE-20412 > URL: https://issues.apache.org/jira/browse/IGNITE-20412 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > h3. Motivation > org.apache.ignite.internal.distribution.zones.ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart > started to fall in the catalog-feature branch and fails in the main branch > after catalog-feature is merged > [https://ci.ignite.apache.org/viewLog.html?buildId=7501721&tab=buildResultsDiv&buildTypeId=ApacheIgnite3xGradle_Test_RunAllTests&logTab=] > {code:java} > java.lang.AssertionError: > Expected: is <[]> > but: was <[
[jira] [Updated] (IGNITE-20397) java.lang.AssertionError: Group of the event is unsupported
[ https://issues.apache.org/jira/browse/IGNITE-20397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel updated IGNITE-20397: --- Description: {code:java} java.lang.AssertionError: Group of the event is unsupported [nodeId=<11_part_18/isaat_n_2>, event=org.apache.ignite.raft.jraft.core.NodeImpl$LogEntryAndClosure@653d84a] at org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:224) ~[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} [https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7498320?expandCode+Inspection=true&expandBuildProblemsSection=true&hideProblemsFromDependencies=false&expandBuildTestsSection=true&hideTestsFromDependencies=false&expandBuildChangesSection=true] The root cause: # StripedDisruptor.StripeEntryHandler#onEvent method gets handler from StripedDisruptor.StripeEntryHandler#subscribers by event.nodeId(). # In some cases the `subscribers` map is cleared by invocation of StripedDisruptor.StripeEntryHandler#unsubscribe, and then StripeEntryHandler receives event with SafeTimeSyncCommandImpl. # It produces an assertion error: `assert handler != null` The issue is not caused by the catalog feature changes. It possible to reproduced it if add Thread.sleep in StripeEntryHandler#onEvent. Originally it was reproduced on a table dropping. But it possible to reproduce it on a table creation if set "IDLE_SAFE_TIME_PROPAGATION_PERIOD_MILLISECONDS = 500;". was: {code:java} java.lang.AssertionError: Group of the event is unsupported [nodeId=<11_part_18/isaat_n_2>, event=org.apache.ignite.raft.jraft.core.NodeImpl$LogEntryAndClosure@653d84a] at org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:224) ~[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} [https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7498320?expandCode+Inspection=true&expandBuildProblemsSection=true&hideProblemsFromDependencies=false&expandBuildTestsSection=true&hideTestsFromDependencies=false&expandBuildChangesSection=true] The root cause: # StripedDisruptor.StripeEntryHandler#onEvent method gets handler from StripedDisruptor.StripeEntryHandler#subscribers by event.nodeId(). # In some cases the `subscribers` map is cleared by invocation of StripedDisruptor.StripeEntryHandler#unsubscribe, and then StripeEntryHandler receives event with SafeTimeSyncCommandImpl. # It produces an assertion error: `assert handler != null` > java.lang.AssertionError: Group of the event is unsupported > --- > > Key: IGNITE-20397 > URL: https://issues.apache.org/jira/browse/IGNITE-20397 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > > {code:java} > java.lang.AssertionError: Group of the event is unsupported > [nodeId=<11_part_18/isaat_n_2>, > event=org.apache.ignite.raft.jraft.core.NodeImpl$LogEntryAndClosure@653d84a] > at > org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:224) > ~[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} > [https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7498320?expandCode+Inspection=true&expandBuildProblemsSection=true&hideProblemsFromDependencies=false&expandBuildTestsSection=true&hideTestsFromDependencies=false&expandBuildChangesSection=true] > The root cause: > # StripedDisruptor.StripeEntryHandler#onEvent method gets handler from > StripedDisruptor.StripeEntryHandler#subscribers by event.nodeId(). > # In some cases the `subscribers` map is cleared by invocation of > StripedDisruptor.StripeEntryHandler#unsubscribe, and then StripeEntryHandler > receives event with SafeTimeSyncCommandImpl. > # It produces an assertion erro
[jira] [Created] (IGNITE-20470) Ducktape to check dump performance
Nikolay Izhikov created IGNITE-20470: Summary: Ducktape to check dump performance Key: IGNITE-20470 URL: https://issues.apache.org/jira/browse/IGNITE-20470 Project: Ignite Issue Type: Task Reporter: Nikolay Izhikov Dump creation can affect transactions performance with change listener and disc operations. We must create ducktape test to check this. Example test scenario: * Start nodes * Start transaction operations: insert, update, remove. * Create dump * Check dump consistency. Measure * Transaction performance penalty. * GC utilization. * Disc utilization. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20471) Handle TxManagerImpl#finish correctly when recipientNode is null
Mirza Aliev created IGNITE-20471: Summary: Handle TxManagerImpl#finish correctly when recipientNode is null Key: IGNITE-20471 URL: https://issues.apache.org/jira/browse/IGNITE-20471 Project: Ignite Issue Type: Bug Reporter: Mirza Aliev *Motivation* According the logic of invocations of {{TxManagerImpl#finish}}, it is possible that {{recipientNode}}, which is passed to {{finish}}, could be {{null}}. Further in the code of {{finish}} method we make {{replicaService.invoke(recipientNode)}} and this could lead to NullPointerException. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20471) Handle TxManagerImpl#finish correctly when recipientNode is null
[ https://issues.apache.org/jira/browse/IGNITE-20471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-20471: - Description: *Motivation* According the logic of invocations of {{TxManagerImpl#finish}}, it is possible that {{recipientNode}}, which is passed to {{finish}}, could be {{null}}. Further in the code of {{finish}} method we make {{replicaService.invoke(recipientNode)}} and this could lead to {{NullPointerException}}. was: *Motivation* According the logic of invocations of {{TxManagerImpl#finish}}, it is possible that {{recipientNode}}, which is passed to {{finish}}, could be {{null}}. Further in the code of {{finish}} method we make {{replicaService.invoke(recipientNode)}} and this could lead to NullPointerException. > Handle TxManagerImpl#finish correctly when recipientNode is null > > > Key: IGNITE-20471 > URL: https://issues.apache.org/jira/browse/IGNITE-20471 > Project: Ignite > Issue Type: Bug >Reporter: Mirza Aliev >Priority: Major > Labels: ignite-3 > > *Motivation* > According the logic of invocations of {{TxManagerImpl#finish}}, it is > possible that {{recipientNode}}, which is passed to {{finish}}, could be > {{null}}. Further in the code of {{finish}} method we make > {{replicaService.invoke(recipientNode)}} and this could lead to > {{NullPointerException}}. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20470) Ducktape to check dump performance
[ https://issues.apache.org/jira/browse/IGNITE-20470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-20470: - Labels: IEP-109 ise (was: IEP-109) > Ducktape to check dump performance > -- > > Key: IGNITE-20470 > URL: https://issues.apache.org/jira/browse/IGNITE-20470 > Project: Ignite > Issue Type: Task >Reporter: Nikolay Izhikov >Priority: Major > Labels: IEP-109, ise > > Dump creation can affect transactions performance with change listener and > disc operations. We must create ducktape test to check this. > Example test scenario: > * Start nodes > * Start transaction operations: insert, update, remove. > * Create dump > * Check dump consistency. > Measure > * Transaction performance penalty. > * GC utilization. > * Disc utilization. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20472) API to consumer cache dumps
Nikolay Izhikov created IGNITE-20472: Summary: API to consumer cache dumps Key: IGNITE-20472 URL: https://issues.apache.org/jira/browse/IGNITE-20472 Project: Ignite Issue Type: Task Reporter: Nikolay Izhikov Ignite must provide API to consume cache dumps by user defined consumer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20367) ItTableRaftSnapshotsTest times out with high flaky rate
[ https://issues.apache.org/jira/browse/IGNITE-20367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-20367: - Description: {code:java} org.apache.ignite.lang.IgniteException: IGN-CMN-65535 TraceId:f1535407-3cf9-48cd-9091-825ecf308526 at java.base@11.0.17/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710) at app//org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:772) at app//org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:706) at app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:543) at app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:641) at app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:494) at app//org.apache.ignite.internal.sql.AbstractSession.execute(AbstractSession.java:63) at app//org.apache.ignite.internal.SessionUtils.executeUpdate(SessionUtils.java:38) at app//org.apache.ignite.internal.SessionUtils.executeUpdate(SessionUtils.java:50) at app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.lambda$executeDmlWithRetry$1(ItTableRaftSnapshotsTest.java:231) at app//org.apache.ignite.internal.Cluster.doInSession(Cluster.java:448) at app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.lambda$executeDmlWithRetry$2(ItTableRaftSnapshotsTest.java:230) at app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.withRetry(ItTableRaftSnapshotsTest.java:184) at app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.executeDmlWithRetry(ItTableRaftSnapshotsTest.java:229) at app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.prepareClusterForInstallingSnapshotToNode2(ItTableRaftSnapshotsTest.java:351) at app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.snapshotInstallTimeoutDoesNotBreakSubsequentInstallsWhenSecondAttemptIsIdenticalToFirst(ItTableRaftSnapshotsTest.java:685) 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 app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217) at app//org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) at app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213) at app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138) at app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68) at app//org.jun
[jira] [Updated] (IGNITE-20367) ItTableRaftSnapshotsTest times out with high flaky rate
[ https://issues.apache.org/jira/browse/IGNITE-20367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-20367: - Description: {code:java} org.apache.ignite.lang.IgniteException: IGN-CMN-65535 TraceId:f1535407-3cf9-48cd-9091-825ecf308526 at java.base@11.0.17/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710) at app//org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:772) at app//org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:706) at app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:543) at app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:641) at app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:494) at app//org.apache.ignite.internal.sql.AbstractSession.execute(AbstractSession.java:63) at app//org.apache.ignite.internal.SessionUtils.executeUpdate(SessionUtils.java:38) at app//org.apache.ignite.internal.SessionUtils.executeUpdate(SessionUtils.java:50) at app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.lambda$executeDmlWithRetry$1(ItTableRaftSnapshotsTest.java:231) at app//org.apache.ignite.internal.Cluster.doInSession(Cluster.java:448) at app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.lambda$executeDmlWithRetry$2(ItTableRaftSnapshotsTest.java:230) at app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.withRetry(ItTableRaftSnapshotsTest.java:184) at app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.executeDmlWithRetry(ItTableRaftSnapshotsTest.java:229) at app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.prepareClusterForInstallingSnapshotToNode2(ItTableRaftSnapshotsTest.java:351) at app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.snapshotInstallTimeoutDoesNotBreakSubsequentInstallsWhenSecondAttemptIsIdenticalToFirst(ItTableRaftSnapshotsTest.java:685) 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 app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217) at app//org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) at app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213) at app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138) at app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68) at app//org.jun
[jira] [Updated] (IGNITE-20367) ItTableRaftSnapshotsTest times out with high flaky rate
[ https://issues.apache.org/jira/browse/IGNITE-20367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-20367: - Description: {code:java} org.apache.ignite.lang.IgniteException: IGN-CMN-65535 TraceId:f1535407-3cf9-48cd-9091-825ecf308526 at java.base@11.0.17/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710) at app//org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:772) at app//org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:706) at app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:543) at app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:641) at app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:494) at app//org.apache.ignite.internal.sql.AbstractSession.execute(AbstractSession.java:63) at app//org.apache.ignite.internal.SessionUtils.executeUpdate(SessionUtils.java:38) at app//org.apache.ignite.internal.SessionUtils.executeUpdate(SessionUtils.java:50) at app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.lambda$executeDmlWithRetry$1(ItTableRaftSnapshotsTest.java:231) at app//org.apache.ignite.internal.Cluster.doInSession(Cluster.java:448) at app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.lambda$executeDmlWithRetry$2(ItTableRaftSnapshotsTest.java:230) at app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.withRetry(ItTableRaftSnapshotsTest.java:184) at app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.executeDmlWithRetry(ItTableRaftSnapshotsTest.java:229) at app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.prepareClusterForInstallingSnapshotToNode2(ItTableRaftSnapshotsTest.java:351) at app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.snapshotInstallTimeoutDoesNotBreakSubsequentInstallsWhenSecondAttemptIsIdenticalToFirst(ItTableRaftSnapshotsTest.java:685) 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 app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217) at app//org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) at app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213) at app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138) at app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68) at app//org.jun
[jira] [Updated] (IGNITE-20367) ItTableRaftSnapshotsTest times out with high flaky rate
[ https://issues.apache.org/jira/browse/IGNITE-20367?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-20367: - Description: {code:java} org.apache.ignite.lang.IgniteException: IGN-CMN-65535 TraceId:f1535407-3cf9-48cd-9091-825ecf308526 at java.base@11.0.17/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710) at app//org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:772) at app//org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:706) at app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:543) at app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:641) at app//org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:494) at app//org.apache.ignite.internal.sql.AbstractSession.execute(AbstractSession.java:63) at app//org.apache.ignite.internal.SessionUtils.executeUpdate(SessionUtils.java:38) at app//org.apache.ignite.internal.SessionUtils.executeUpdate(SessionUtils.java:50) at app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.lambda$executeDmlWithRetry$1(ItTableRaftSnapshotsTest.java:231) at app//org.apache.ignite.internal.Cluster.doInSession(Cluster.java:448) at app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.lambda$executeDmlWithRetry$2(ItTableRaftSnapshotsTest.java:230) at app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.withRetry(ItTableRaftSnapshotsTest.java:184) at app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.executeDmlWithRetry(ItTableRaftSnapshotsTest.java:229) at app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.prepareClusterForInstallingSnapshotToNode2(ItTableRaftSnapshotsTest.java:351) at app//org.apache.ignite.internal.raftsnapshot.ItTableRaftSnapshotsTest.snapshotInstallTimeoutDoesNotBreakSubsequentInstallsWhenSecondAttemptIsIdenticalToFirst(ItTableRaftSnapshotsTest.java:685) 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 app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217) at app//org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73) at app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.invokeTestMethod(TestMethodTestDescriptor.java:213) at app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:138) at app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.execute(TestMethodTestDescriptor.java:68) at app//org.jun
[jira] [Updated] (IGNITE-16088) Reuse Marshaller code in marshaller-common module
[ https://issues.apache.org/jira/browse/IGNITE-16088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-16088: - Fix Version/s: 3.0.0-beta2 > Reuse Marshaller code in marshaller-common module > - > > Key: IGNITE-16088 > URL: https://issues.apache.org/jira/browse/IGNITE-16088 > Project: Ignite > Issue Type: Improvement >Affects Versions: 3.0.0-alpha4 >Reporter: Pavel Tupitsyn >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 40m > Remaining Estimate: 0h > > IGNITE-14971 added *ignite-marshaller-common* module to reuse serialization > logic between the server and client parts. > This module duplicates some logic from *ignite-schema* module. > * Remove duplicated code from *ignite-schema* and reuse the logic from common > module. > * Extract other common bits where applicable (e.g. *AsmSerializerGenerator*) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20465) *.mvccEnabled() removal
[ https://issues.apache.org/jira/browse/IGNITE-20465?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17767928#comment-17767928 ] Ignite TC Bot commented on IGNITE-20465: {panel:title=Branch: [pull/10945/head] Base: [master] : No blockers found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel} {panel:title=Branch: [pull/10945/head] Base: [master] : No new tests found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel} [TeamCity *--> Run :: All* Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7344975&buildTypeId=IgniteTests24Java8_RunAll] > *.mvccEnabled() removal > --- > > Key: IGNITE-20465 > URL: https://issues.apache.org/jira/browse/IGNITE-20465 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Fix For: 2.16 > > Time Spent: 50m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20473) Catalog service improvements
Andrey Mashenkov created IGNITE-20473: - Summary: Catalog service improvements Key: IGNITE-20473 URL: https://issues.apache.org/jira/browse/IGNITE-20473 Project: Ignite Issue Type: Epic Reporter: Andrey Mashenkov Umbrella ticket for tech-debt and improvements after IGNITE-19502 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (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 ] Andrey Mashenkov updated IGNITE-18536: -- Epic Link: IGNITE-20473 (was: IGNITE-19502) > 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] [Updated] (IGNITE-19223) Implement accumulation of schema updates in CatalogService
[ https://issues.apache.org/jira/browse/IGNITE-19223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-19223: -- Epic Link: IGNITE-20473 (was: IGNITE-19502) > Implement accumulation of schema updates in CatalogService > -- > > Key: IGNITE-19223 > URL: https://issues.apache.org/jira/browse/IGNITE-19223 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > CatalogService implementation should hold the historical information about > schema updates. This means that: > # It needs to load the known history of schema updates on node start > # It should subsribe to new schema updates -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19082) Describe Catalog operation flow in README and cleanup dead code.
[ https://issues.apache.org/jira/browse/IGNITE-19082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-19082: -- Epic Link: IGNITE-20473 (was: IGNITE-19502) > Describe Catalog operation flow in README and cleanup dead code. > > > Key: IGNITE-19082 > URL: https://issues.apache.org/jira/browse/IGNITE-19082 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Let's > * ensure Catalog is used by default as a single schema management point by > TableManager, IndexManager, SqlSchemaManager, SchemaRegistry. > * Describe CatalogService operations in README.md > * drop schema related code from configuration. > * drop outdated code from TableManager, IndexManager, SqlSchemaManager, > SchemaRegistry. > * make a PR for merging feature branch to main (if applicable). > * ensure there are end-to-end tests for the cases (if applicable) described > in CatalogServiceSelfTest. Also drop InternalSchemaTest. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19643) Catalog validation code refactoring.
[ https://issues.apache.org/jira/browse/IGNITE-19643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-19643: -- Epic Link: IGNITE-20473 (was: IGNITE-19502) > Catalog validation code refactoring. > > > Key: IGNITE-19643 > URL: https://issues.apache.org/jira/browse/IGNITE-19643 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Priority: Minor > Labels: ignite-3, tech-debt > > Let's implement some validation rules that each Catalog command should check > before the execution. Then replace current boilerplate validation code with > applying these rules using Visitor pattern. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19670) Improve CatalogService test coverage.
[ https://issues.apache.org/jira/browse/IGNITE-19670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-19670: -- Epic Link: IGNITE-20473 (was: IGNITE-19502) > Improve CatalogService test coverage. > - > > Key: IGNITE-19670 > URL: https://issues.apache.org/jira/browse/IGNITE-19670 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Priority: Minor > Labels: ignite-3, tech-debt-test > > 1. CatalogServiceSelftTest.testCreateTable (+testDropTable) looks a bit > complicated. It checks creation of more than one table. Let's simplify the > test by reverting last changes > 2. We use shared counter to generate unique identifier for schema objects. > Some tests checks schema object id, and some doesn't. Let's move > schema-object's id check into separate test, to verify which command > increments the counter, and which doesn't. > 3. Let's add a test that will check ABA problem. E.g. create-drop-create > table (or index) with same name and check the object can be resolved > correctly by name and by id (regarding object versioning in Catalog, of > course). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19549) Handle wrap-around of Catalog object IDs
[ https://issues.apache.org/jira/browse/IGNITE-19549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-19549: -- Epic Link: IGNITE-20473 (was: IGNITE-19502) > Handle wrap-around of Catalog object IDs > > > Key: IGNITE-19549 > URL: https://issues.apache.org/jira/browse/IGNITE-19549 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > We are planning to switch from UUIDs to ints as Catalog object (tables, > indices, zones, views) IDs (IGNITE-19524). int allows 2/4 billion of values > (approx); if we add columns to the category of objects that need these IDs, > it seems theoretically possible to get into wrap-around situation. > Design of some mechanism might be needed. > (Although, in practice, it seems that WA cannot happen). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19680) Get rid of org.apache.ignite.internal.index.event.IndexEventParameters
[ https://issues.apache.org/jira/browse/IGNITE-19680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-19680: -- Epic Link: IGNITE-20473 (was: IGNITE-19502) > Get rid of org.apache.ignite.internal.index.event.IndexEventParameters > -- > > Key: IGNITE-19680 > URL: https://issues.apache.org/jira/browse/IGNITE-19680 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > In the process of migrating to the catalog, we need to get rid of > *org.apache.ignite.internal.index.event.IndexEventParameters* (and related > classes) and use a different entity when working with indexes for sql. > h2. Update > The index creation/destroy event can be useful when building indexes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19550) Reuse IDs of dropped Catalog objects for new objects
[ https://issues.apache.org/jira/browse/IGNITE-19550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-19550: -- Epic Link: IGNITE-20473 (was: IGNITE-19502) > Reuse IDs of dropped Catalog objects for new objects > > > Key: IGNITE-19550 > URL: https://issues.apache.org/jira/browse/IGNITE-19550 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > In IGNITE-19524, we are switching from UUIDs to ints as IDs of the Catalog > objects (tables, indices, views, zones). Some users have use-cases where they > constantly create, drop and recreate same tables. In such cases, it might > make sense to reuse object IDs to slow down the growth of the global counter. > A design is required. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19687) Support default distribution zone reassignment.
[ https://issues.apache.org/jira/browse/IGNITE-19687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-19687: -- Epic Link: IGNITE-20473 (was: IGNITE-19502) > Support default distribution zone reassignment. > --- > > Key: IGNITE-19687 > URL: https://issues.apache.org/jira/browse/IGNITE-19687 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > *Motivation.* > We have no reasonable arguments that we need a special distribution zone > instance. All distribution zones are equals. Thus, conceptually, any zone can > be used as default one and can be renamed. > For better UX, we still can require at least one distribution zone, which is > currently assigned as default zone, must always exists. > Let's > * Avoid using any hardcoded zone id or zone name for getting or detecting the > default distribution zone. > * Distributed zone manager shouldn't care which zone is default. Catalog will > be responsible for resolving default zone if it is not specified when table > is creating. > * Add a property in Configuration that will to default zone by zone id. > * A distribution zone with name "Default"(?) and some default parameters must > be created on cluster initialization phase and an id, which was assigned to > such zone, must be stored to Configuration. > * Forbid dropping of distribution zone, which is currently marked as default. > * Add support {{ALTER ZONE SET DEFAULT}} to reassign default zone. > * Allow renaming for all zones. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19719) Make CatalogDataStorageDescriptor support for each storage engine
[ https://issues.apache.org/jira/browse/IGNITE-19719?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-19719: -- Epic Link: IGNITE-20473 (was: IGNITE-19502) > Make CatalogDataStorageDescriptor support for each storage engine > - > > Key: IGNITE-19719 > URL: https://issues.apache.org/jira/browse/IGNITE-19719 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > At the moment, we do not have the ability to implement > *org.apache.ignite.internal.catalog.descriptors.CatalogDataStorageDescriptor* > for each storage engine, we need to come up with a mechanism for how to do > this. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20098) Move exception classes related to distribution zones to an appropriate package/module
[ https://issues.apache.org/jira/browse/IGNITE-20098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-20098: -- Epic Link: IGNITE-20473 (was: IGNITE-19502) > Move exception classes related to distribution zones to an appropriate > package/module > - > > Key: IGNITE-20098 > URL: https://issues.apache.org/jira/browse/IGNITE-20098 > Project: Ignite > Issue Type: Bug >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20474) .NET: Thin 3.0: Source-generated serializer
Pavel Tupitsyn created IGNITE-20474: --- Summary: .NET: Thin 3.0: Source-generated serializer Key: IGNITE-20474 URL: https://issues.apache.org/jira/browse/IGNITE-20474 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] [Updated] (IGNITE-20046) Improve the Catalog interfaces
[ https://issues.apache.org/jira/browse/IGNITE-20046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-20046: -- Epic Link: IGNITE-20473 (was: IGNITE-19502) > Improve the Catalog interfaces > -- > > Key: IGNITE-20046 > URL: https://issues.apache.org/jira/browse/IGNITE-20046 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Catalog related interfaces and classes are missing javadocs, need to fix this. > CatalogService getters, which accepts ID and timestamp, looks useless and, > probably, could be removed. > Let's also change timestamp type `long->HybridTimestamp` -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20051) Add startup recovery to CatalogSchemaManager
[ https://issues.apache.org/jira/browse/IGNITE-20051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-20051: -- Epic Link: IGNITE-20473 (was: IGNITE-19502) > Add startup recovery to CatalogSchemaManager > > > Key: IGNITE-20051 > URL: https://issues.apache.org/jira/browse/IGNITE-20051 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Currently, {{CatalogSchemaManager}} does not implement a proper recovery > procedure at start. It needs a way to get all tables from the CatalogService > (including the dropped ones). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19790) Read range from metastore at start UpdateLogImpl
[ https://issues.apache.org/jira/browse/IGNITE-19790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-19790: -- Epic Link: IGNITE-20473 (was: IGNITE-19502) > Read range from metastore at start UpdateLogImpl > > > Key: IGNITE-19790 > URL: https://issues.apache.org/jira/browse/IGNITE-19790 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Now, in > *org.apache.ignite.internal.catalog.storage.UpdateLogImpl#restoreStateFromVault*, > versions are read from the volt, starting from 1, which is not correct > because the log can be cut off. We need to read from the metastore by range. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20096) Fix building indexes after switch to Catalog
[ https://issues.apache.org/jira/browse/IGNITE-20096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-20096: -- Epic Link: IGNITE-20473 (was: IGNITE-19502) > Fix building indexes after switch to Catalog > > > Key: IGNITE-20096 > URL: https://issues.apache.org/jira/browse/IGNITE-20096 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > When switch the *IndexManager* to the Catalog, a number of problems are > revealed, one of them is the building of indexes, it is proposed to solve > this problem separately so that the switch is smoother. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20380) Try to deal with TableManager#assignmentsChangeListeners
[ https://issues.apache.org/jira/browse/IGNITE-20380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-20380: -- Epic Link: IGNITE-20473 (was: IGNITE-19502) > Try to deal with TableManager#assignmentsChangeListeners > > > Key: IGNITE-20380 > URL: https://issues.apache.org/jira/browse/IGNITE-20380 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > *org.apache.ignite.internal.table.distributed.TableManager#assignmentsChangeListeners* > that are used in > *org.apache.ignite.client.handler.ClientInboundMessageHandler* have been > discovered and I would like to see if it would be possible to change these > listeners to catalog listeners for example or something like that. > And also, most likely, the call of listeners should be made after writing to > the metastore. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20339) Get rid of IndexEvent and TableEvent
[ https://issues.apache.org/jira/browse/IGNITE-20339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-20339: -- Epic Link: IGNITE-20473 (was: IGNITE-19502) > Get rid of IndexEvent and TableEvent > > > Key: IGNITE-20339 > URL: https://issues.apache.org/jira/browse/IGNITE-20339 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > It was found that no one uses > *org.apache.ignite.internal.index.event.IndexEvent* and > *org.apache.ignite.internal.table.event.TableEvent* except for tests, I > propose to get rid of this and related code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20287) Clean up abandoned resources for destroyed zones in catalog
[ https://issues.apache.org/jira/browse/IGNITE-20287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-20287: -- Epic Link: IGNITE-20473 (was: IGNITE-19502) > Clean up abandoned resources for destroyed zones in catalog > --- > > Key: IGNITE-20287 > URL: https://issues.apache.org/jira/browse/IGNITE-20287 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > We need to clean up abandoned resources (from vault and metastore) for > destroyed distribution zones from the catalog. > Perhaps it will be two separate ticket. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20381) Add busyLock usage in CatalogManagerImpl
[ https://issues.apache.org/jira/browse/IGNITE-20381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-20381: -- Epic Link: IGNITE-20473 (was: IGNITE-19502) > Add busyLock usage in CatalogManagerImpl > > > Key: IGNITE-20381 > URL: https://issues.apache.org/jira/browse/IGNITE-20381 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > It was found that the *IgniteSpinBusyLock* is not used in > *org.apache.ignite.internal.catalog.CatalogManagerImpl*, this needs to be > fixed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20384) Clean up abandoned resources for destroyed tables in catalog
[ https://issues.apache.org/jira/browse/IGNITE-20384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-20384: -- Epic Link: IGNITE-20473 (was: IGNITE-19502) > Clean up abandoned resources for destroyed tables in catalog > > > Key: IGNITE-20384 > URL: https://issues.apache.org/jira/browse/IGNITE-20384 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > We need to clean up abandoned resources (from vault and metastore) for > destroyed tables from the catalog. > Perhaps it will be two separate ticket. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20412) Fix ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart
[ https://issues.apache.org/jira/browse/IGNITE-20412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-20412: -- Epic Link: IGNITE-20473 (was: IGNITE-19502) > Fix > ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart > > > Key: IGNITE-20412 > URL: https://issues.apache.org/jira/browse/IGNITE-20412 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > h3. Motivation > org.apache.ignite.internal.distribution.zones.ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart > started to fall in the catalog-feature branch and fails in the main branch > after catalog-feature is merged > [https://ci.ignite.apache.org/viewLog.html?buildId=7501721&tab=buildResultsDiv&buildTypeId=ApacheIgnite3xGradle_Test_RunAllTests&logTab=] > {code:java} > java.lang.AssertionError: > Expected: is <[]> > but: was <[A]> > at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) > at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6) > at > org.apache.ignite.internal.distributionzones.DistributionZonesTestUtil.assertValueInStorage(DistributionZonesTestUtil.java:459) > at > org.apache.ignite.internal.distribution.zones.ItIgniteDistributionZoneManagerNodeRestartTest.testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart(ItIgniteDistributionZoneManagerNodeRestartTest.java:539) > {code} > h3. Implementation notes > The root cause: > # This test changes metaStorageManager behavior and it throws expected > exception on ms.invoke. > # The test alters zone with new filter. > # DistributionZoneManager#onUpdateFilter return a future from > saveDataNodesToMetaStorageOnScaleUp(zoneId, causalityToken) > # The future is completed exceptionally and > WatchProcessor#notificationFuture will be completed exceptionally. > # Next updates will not be handled properly because notificationFuture is > completed exceptionally. > We have already created tickets obout exception handling: > * https://issues.apache.org/jira/browse/IGNITE-14693 > * https://issues.apache.org/jira/browse/IGNITE-14611 > > The test scenario is incorrect because the node should be stopped (by failure > handler) if the ms.invoke failed. We need to rewrite it when the DZM restart > will be updated. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20263) Get rid of DataStorageConfigurationSchema
[ https://issues.apache.org/jira/browse/IGNITE-20263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-20263: -- Epic Link: IGNITE-20473 (was: IGNITE-19502) > Get rid of DataStorageConfigurationSchema > - > > Key: IGNITE-20263 > URL: https://issues.apache.org/jira/browse/IGNITE-20263 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > We need to get rid of > *org.apache.ignite.internal.schema.configuration.storage.DataStorageConfigurationSchema*, > its descendants and the code associated with it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20315) Add support for renaming a table column
[ https://issues.apache.org/jira/browse/IGNITE-20315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-20315: -- Epic Link: IGNITE-20473 (was: IGNITE-19502) > Add support for renaming a table column > --- > > Key: IGNITE-20315 > URL: https://issues.apache.org/jira/browse/IGNITE-20315 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > At the moment there are tests for renaming table columns, but this function > is not supported in the catalog and SQL, I think it needs to be fixed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20474) .NET: Thin 3.0: Source-generated serializer
[ https://issues.apache.org/jira/browse/IGNITE-20474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20474: Description: Currently, .NET thin client relies on reflection to emit serialization/deserialization code. This approach is very flexible and user-friendly, but does not work with AOT, which is getting increasingly popular. Provide an additional serialization mechanism based on [Source Generators|https://learn.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/source-generators-overview] that does not require reflection. The difficult part is that we don't know the table schema at compile time. > .NET: Thin 3.0: Source-generated serializer > --- > > Key: IGNITE-20474 > URL: https://issues.apache.org/jira/browse/IGNITE-20474 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Minor > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > Currently, .NET thin client relies on reflection to emit > serialization/deserialization code. This approach is very flexible and > user-friendly, but does not work with AOT, which is getting increasingly > popular. > Provide an additional serialization mechanism based on [Source > Generators|https://learn.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/source-generators-overview] > that does not require reflection. > The difficult part is that we don't know the table schema at compile time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (IGNITE-20293) Deal with CatalogService#latestCatalogVersion at the start of the components
[ https://issues.apache.org/jira/browse/IGNITE-20293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov closed IGNITE-20293. - > Deal with CatalogService#latestCatalogVersion at the start of the components > > > Key: IGNITE-20293 > URL: https://issues.apache.org/jira/browse/IGNITE-20293 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > At the moment, in some components, we have started using > *org.apache.ignite.internal.catalog.CatalogService#latestCatalogVersion* so > that we can get the latest state of the catalog after it is recovered. > But this value is not immutable, so there may be consequences because of > this, we need to figure it out. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (IGNITE-19852) Deal with RecoveryCompletionFutureFactory
[ https://issues.apache.org/jira/browse/IGNITE-19852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov closed IGNITE-19852. - > Deal with RecoveryCompletionFutureFactory > - > > Key: IGNITE-19852 > URL: https://issues.apache.org/jira/browse/IGNITE-19852 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > The main problem is described in IGNITE-19801, but due to the fact that we > now have code closely related to updating the configuration revision, it is > difficult to do everything at once in IGNITE-19801, so it will be divided > into parts. > As part of ticket IGNITE-19777, we will have a new meta storage recovery > mechanism, so we need to do something with *RecoveryCompletionFutureFactory*, > I think that in general we can get rid of it, but this needs to be checked > more carefully. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20474) .NET: Thin 3.0: Source-generated serializer
[ https://issues.apache.org/jira/browse/IGNITE-20474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20474: Description: Currently, .NET thin client relies on reflection to emit serialization/deserialization code. This approach is very flexible and user-friendly, but does not work with [Native AOT|https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=net7%2Cwindows], which is getting increasingly popular. Provide an additional serialization mechanism based on [Source Generators|https://learn.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/source-generators-overview] that does not require reflection. The difficult part is that we don't know the table schema at compile time. was: Currently, .NET thin client relies on reflection to emit serialization/deserialization code. This approach is very flexible and user-friendly, but does not work with AOT, which is getting increasingly popular. Provide an additional serialization mechanism based on [Source Generators|https://learn.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/source-generators-overview] that does not require reflection. The difficult part is that we don't know the table schema at compile time. > .NET: Thin 3.0: Source-generated serializer > --- > > Key: IGNITE-20474 > URL: https://issues.apache.org/jira/browse/IGNITE-20474 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Minor > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > Currently, .NET thin client relies on reflection to emit > serialization/deserialization code. This approach is very flexible and > user-friendly, but does not work with [Native > AOT|https://learn.microsoft.com/en-us/dotnet/core/deploying/native-aot/?tabs=net7%2Cwindows], > which is getting increasingly popular. > Provide an additional serialization mechanism based on [Source > Generators|https://learn.microsoft.com/en-us/dotnet/csharp/roslyn-sdk/source-generators-overview] > that does not require reflection. > The difficult part is that we don't know the table schema at compile time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (IGNITE-19752) Ignite 3.0: Umbrella. Migrate Ignite 3 components to using Catalog
[ https://issues.apache.org/jira/browse/IGNITE-19752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov closed IGNITE-19752. - > Ignite 3.0: Umbrella. Migrate Ignite 3 components to using Catalog > -- > > Key: IGNITE-19752 > URL: https://issues.apache.org/jira/browse/IGNITE-19752 > Project: Ignite > Issue Type: Task > Components: persistence, sql >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > This umbrella ticket for refactoring of main Ignite 3 components to make them > using the Catalog. > Each of tickets separately may broke some functionality and test, so let's > merge them into a feature branch first. > Once feature branch will be stable, let's merge all of them to the main at > once. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-19502) Separate component to keep database schema and manage changes in it
[ https://issues.apache.org/jira/browse/IGNITE-19502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov resolved IGNITE-19502. --- Resolution: Fixed > Separate component to keep database schema and manage changes in it > --- > > Key: IGNITE-19502 > URL: https://issues.apache.org/jira/browse/IGNITE-19502 > Project: Ignite > Issue Type: Epic > Components: persistence, sql >Reporter: Sergey Chugunov >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > Right now database schema information in Ignite 3.0 is stored and treated as > regular configuration. All business processes related to schema changes are > distributed via internal mechanisms of configuration engine and orchestrated > ad-hoc by consumer components like TableManager or IndexManager. > But there is a strong evidence that API and guarantees of configuration > engine don't satisfy important requirements that emerge in the field of db > schema management. > So we need to stop treating schema as any other configuration and move it to > a separate component called Catalog Service. > This component will provide high-level API to modify the schema and will take > responsibility for all other necessary processes like synchronizing schema > changes between nodes, managing schema change events, notifying all necessary > components and providing orchestration between them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19502) Separate component to keep database schema and manage changes in it
[ https://issues.apache.org/jira/browse/IGNITE-19502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-19502: - Assignee: Kirill Tkalenko > Separate component to keep database schema and manage changes in it > --- > > Key: IGNITE-19502 > URL: https://issues.apache.org/jira/browse/IGNITE-19502 > Project: Ignite > Issue Type: Epic > Components: persistence, sql >Reporter: Sergey Chugunov >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > Right now database schema information in Ignite 3.0 is stored and treated as > regular configuration. All business processes related to schema changes are > distributed via internal mechanisms of configuration engine and orchestrated > ad-hoc by consumer components like TableManager or IndexManager. > But there is a strong evidence that API and guarantees of configuration > engine don't satisfy important requirements that emerge in the field of db > schema management. > So we need to stop treating schema as any other configuration and move it to > a separate component called Catalog Service. > This component will provide high-level API to modify the schema and will take > responsibility for all other necessary processes like synchronizing schema > changes between nodes, managing schema change events, notifying all necessary > components and providing orchestration between them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19502) Separate component to keep database schema and manage changes in it
[ https://issues.apache.org/jira/browse/IGNITE-19502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-19502: -- Fix Version/s: 3.0.0-beta2 > Separate component to keep database schema and manage changes in it > --- > > Key: IGNITE-19502 > URL: https://issues.apache.org/jira/browse/IGNITE-19502 > Project: Ignite > Issue Type: Epic > Components: persistence, sql >Reporter: Sergey Chugunov >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Right now database schema information in Ignite 3.0 is stored and treated as > regular configuration. All business processes related to schema changes are > distributed via internal mechanisms of configuration engine and orchestrated > ad-hoc by consumer components like TableManager or IndexManager. > But there is a strong evidence that API and guarantees of configuration > engine don't satisfy important requirements that emerge in the field of db > schema management. > So we need to stop treating schema as any other configuration and move it to > a separate component called Catalog Service. > This component will provide high-level API to modify the schema and will take > responsibility for all other necessary processes like synchronizing schema > changes between nodes, managing schema change events, notifying all necessary > components and providing orchestration between them. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-19752) Ignite 3.0: Umbrella. Migrate Ignite 3 components to using Catalog
[ https://issues.apache.org/jira/browse/IGNITE-19752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov resolved IGNITE-19752. --- Resolution: Duplicate > Ignite 3.0: Umbrella. Migrate Ignite 3 components to using Catalog > -- > > Key: IGNITE-19752 > URL: https://issues.apache.org/jira/browse/IGNITE-19752 > Project: Ignite > Issue Type: Task > Components: persistence, sql >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > This umbrella ticket for refactoring of main Ignite 3 components to make them > using the Catalog. > Each of tickets separately may broke some functionality and test, so let's > merge them into a feature branch first. > Once feature branch will be stable, let's merge all of them to the main at > once. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20475) .NET: Thin 3.0: EF Core provider
Pavel Tupitsyn created IGNITE-20475: --- Summary: .NET: Thin 3.0: EF Core provider Key: IGNITE-20475 URL: https://issues.apache.org/jira/browse/IGNITE-20475 Project: Ignite Issue Type: New Feature 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] [Updated] (IGNITE-20473) Catalog service improvements
[ https://issues.apache.org/jira/browse/IGNITE-20473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-20473: -- Epic Name: Catalog Service part 2 (was: Catalog service part 2) > Catalog service improvements > > > Key: IGNITE-20473 > URL: https://issues.apache.org/jira/browse/IGNITE-20473 > Project: Ignite > Issue Type: Epic >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > Umbrella ticket for tech-debt and improvements after IGNITE-19502 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20475) .NET: Thin 3.0: EF Core provider
[ https://issues.apache.org/jira/browse/IGNITE-20475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20475: Description: EF Core provider will allow using Ignite as any other DB supported by EF. This makes adoption incredibly easy for the users - a matter of a few changed lines to switch from Postgres/MsSQL/MySQL, keeping all existing code. This is also a big undertaking and needs more investigation/PoC. > .NET: Thin 3.0: EF Core provider > > > Key: IGNITE-20475 > URL: https://issues.apache.org/jira/browse/IGNITE-20475 > Project: Ignite > Issue Type: New Feature > 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 > > > EF Core provider will allow using Ignite as any other DB supported by EF. > This makes adoption incredibly easy for the users - a matter of a few changed > lines to switch from Postgres/MsSQL/MySQL, keeping all existing code. > This is also a big undertaking and needs more investigation/PoC. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20476) improve checking SQL exceptions in tests
Yury Gerzhedovich created IGNITE-20476: -- Summary: improve checking SQL exceptions in tests Key: IGNITE-20476 URL: https://issues.apache.org/jira/browse/IGNITE-20476 Project: Ignite Issue Type: Improvement Components: sql Reporter: Yury Gerzhedovich As of now there are few different approaches to check exception from SQLengine. It leads to hard control exceptions handling, like that all public Exception should be really public and don't belong to internal packages, or that all public exceptions have a text messages. Let's move all exceptions checks related to SQL to two main points: 1) SqlTestUtils.assertThrowsSqlException(...) methods for SQL API 2) JdbcTestUtils.assertThrowsSqlException(...) methods fro JDBC API -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20476) improve checking SQL exceptions in tests
[ https://issues.apache.org/jira/browse/IGNITE-20476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich reassigned IGNITE-20476: -- Assignee: Yury Gerzhedovich > improve checking SQL exceptions in tests > > > Key: IGNITE-20476 > URL: https://issues.apache.org/jira/browse/IGNITE-20476 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > As of now there are few different approaches to check exception from > SQLengine. It leads to hard control exceptions handling, like that all public > Exception should be really public and don't belong to internal packages, or > that all public exceptions have a text messages. > Let's move all exceptions checks related to SQL to two main points: > 1) SqlTestUtils.assertThrowsSqlException(...) methods for SQL API > 2) JdbcTestUtils.assertThrowsSqlException(...) methods fro JDBC API -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20376) ItServerDataStreamerTest.testManyItems is flaky: PrimaryReplicaMissException
[ https://issues.apache.org/jira/browse/IGNITE-20376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17767949#comment-17767949 ] Pavel Tupitsyn commented on IGNITE-20376: - Discussed with [~alapin] in private - this should be fixed by IGNITE-18856 . Closing this for now and keeping an eye on it. > ItServerDataStreamerTest.testManyItems is flaky: PrimaryReplicaMissException > > > Key: IGNITE-20376 > URL: https://issues.apache.org/jira/browse/IGNITE-20376 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Attachments: ignite-20376.txt > > > {code} > java.util.concurrent.CompletionException: > org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException: > IGN-REP-6 TraceId:72a5da42-c429-447a-aaf3-86c1137994dd The primary replica > has changed because the term has been changed [expectedPrimaryReplicaTerm=1, > currentPrimaryReplicaTerm=2] > {code} > Looks like we should handle and retry *PrimaryReplicaMissException* in the > server streamer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-20376) ItServerDataStreamerTest.testManyItems is flaky: PrimaryReplicaMissException
[ https://issues.apache.org/jira/browse/IGNITE-20376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn resolved IGNITE-20376. - Resolution: Fixed > ItServerDataStreamerTest.testManyItems is flaky: PrimaryReplicaMissException > > > Key: IGNITE-20376 > URL: https://issues.apache.org/jira/browse/IGNITE-20376 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Attachments: ignite-20376.txt > > > {code} > java.util.concurrent.CompletionException: > org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException: > IGN-REP-6 TraceId:72a5da42-c429-447a-aaf3-86c1137994dd The primary replica > has changed because the term has been changed [expectedPrimaryReplicaTerm=1, > currentPrimaryReplicaTerm=2] > {code} > Looks like we should handle and retry *PrimaryReplicaMissException* in the > server streamer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-20376) ItServerDataStreamerTest.testManyItems is flaky: PrimaryReplicaMissException
[ https://issues.apache.org/jira/browse/IGNITE-20376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17767949#comment-17767949 ] Pavel Tupitsyn edited comment on IGNITE-20376 at 9/22/23 10:48 AM: --- Could not reproduce locally. Discussed with [~alapin] in private - this is most likely fixed by IGNITE-18856 . Closing this for now and keeping an eye on it. was (Author: ptupitsyn): Discussed with [~alapin] in private - this should be fixed by IGNITE-18856 . Closing this for now and keeping an eye on it. > ItServerDataStreamerTest.testManyItems is flaky: PrimaryReplicaMissException > > > Key: IGNITE-20376 > URL: https://issues.apache.org/jira/browse/IGNITE-20376 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Attachments: ignite-20376.txt > > > {code} > java.util.concurrent.CompletionException: > org.apache.ignite.internal.replicator.exception.PrimaryReplicaMissException: > IGN-REP-6 TraceId:72a5da42-c429-447a-aaf3-86c1137994dd The primary replica > has changed because the term has been changed [expectedPrimaryReplicaTerm=1, > currentPrimaryReplicaTerm=2] > {code} > Looks like we should handle and retry *PrimaryReplicaMissException* in the > server streamer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20472) API to consumer cache dumps
[ https://issues.apache.org/jira/browse/IGNITE-20472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov reassigned IGNITE-20472: Assignee: Nikolay Izhikov > API to consumer cache dumps > --- > > Key: IGNITE-20472 > URL: https://issues.apache.org/jira/browse/IGNITE-20472 > Project: Ignite > Issue Type: Task >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-109, ise > > Ignite must provide API to consume cache dumps by user defined consumer. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19633) Exclude org.apache.calcite.plan.volcano from Javadoc
[ https://issues.apache.org/jira/browse/IGNITE-19633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin reassigned IGNITE-19633: -- Assignee: Mikhail Pochatkin > Exclude org.apache.calcite.plan.volcano from Javadoc > - > > Key: IGNITE-19633 > URL: https://issues.apache.org/jira/browse/IGNITE-19633 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17882) Remove org.apache.ignite.binary.BinaryObject from public API
[ https://issues.apache.org/jira/browse/IGNITE-17882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17767965#comment-17767965 ] Evgeny Stanilovsky commented on IGNITE-17882: - [~mzhuravkov] thanks ! merged. > Remove org.apache.ignite.binary.BinaryObject from public API > > > Key: IGNITE-17882 > URL: https://issues.apache.org/jira/browse/IGNITE-17882 > Project: Ignite > Issue Type: Bug >Reporter: Vyacheslav Koptilin >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > It does not make sense to have BinaryObject interface in the public API until > IGNITE-14316 is resolved (this ticket should introduce the right interface(s) > at least). > For now, let's just remove BinaryObject. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20477) Async component start
Aleksandr Polovtcev created IGNITE-20477: Summary: Async component start Key: IGNITE-20477 URL: https://issues.apache.org/jira/browse/IGNITE-20477 Project: Ignite Issue Type: Task Reporter: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20478) Sql. Rework use of UNSPECIFIED_VALUE_PLACEHOLDER value in row.
Pavel Pereslegin created IGNITE-20478: - Summary: Sql. Rework use of UNSPECIFIED_VALUE_PLACEHOLDER value in row. Key: IGNITE-20478 URL: https://issues.apache.org/jira/browse/IGNITE-20478 Project: Ignite Issue Type: Improvement Components: sql Reporter: Pavel Pereslegin Currently, when scanning an index, we set a special value called "UNSPECIFIED_VALUE_PLACEHOLDER" to row. Which means that any value matches the bound (more details in IGNITE-16443). To be able to complete the transition to using a binary tuple, we need to rework this approach and try to avoid storing non-conforming schema values in row. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20388) Sql. Migrate ClusterPerClassIntegrationTest to run queries via public api
[ https://issues.apache.org/jira/browse/IGNITE-20388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich reassigned IGNITE-20388: -- Assignee: Yury Gerzhedovich > Sql. Migrate ClusterPerClassIntegrationTest to run queries via public api > - > > Key: IGNITE-20388 > URL: https://issues.apache.org/jira/browse/IGNITE-20388 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > ClusterPerClassIntegrationTest provides convenient shortcuts to run sql > queries {{ClusterPerClassIntegrationTest#sql}}). This shortcuts are used to > prepare cluster to run certain statements as well as validate in case of > errors certain exceptions are raised. > The problem is that both these shortcuts uses internal api under the hood, > and internal api doesn't have exception conversion (by design). With that > said, it's possible to get {{CatalogValidationException}} where SqlException > with code STMT_VALIDATION_ERR was expected. > Since vast majority of the tests using those shortcuts have e2e semantic, > it's better to change implementation of the shortcuts to use public api > instead. Tests that relies on internal api semantic, if any, should be > reworked to use different shortcuts. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20478) Sql. Rework use of UNSPECIFIED_VALUE_PLACEHOLDER in row.
[ https://issues.apache.org/jira/browse/IGNITE-20478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-20478: -- Summary: Sql. Rework use of UNSPECIFIED_VALUE_PLACEHOLDER in row. (was: Sql. Rework use of UNSPECIFIED_VALUE_PLACEHOLDER value in row.) > Sql. Rework use of UNSPECIFIED_VALUE_PLACEHOLDER in row. > > > Key: IGNITE-20478 > URL: https://issues.apache.org/jira/browse/IGNITE-20478 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > Currently, when scanning an index, we set a special value called > "UNSPECIFIED_VALUE_PLACEHOLDER" to row. Which means that any value matches > the bound (more details in IGNITE-16443). > To be able to complete the transition to using a binary tuple, we need to > rework this approach and try to avoid storing non-conforming schema values in > row. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20385) Incorrect code INTERNAL_ERROR on node left
[ https://issues.apache.org/jira/browse/IGNITE-20385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin reassigned IGNITE-20385: - Assignee: Pavel Pereslegin > Incorrect code INTERNAL_ERROR on node left > --- > > Key: IGNITE-20385 > URL: https://issues.apache.org/jira/browse/IGNITE-20385 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > During execute SQL query we could got Exception with INTERNAL_ERR in case > remote node left. Node left sholdn't be interpret as INTERNAL ERROR, due to > it's normal situation and user can be informed about it. > Let's map the situation to SqlException with code NODE_LEFT_ERR. > Also need to check wich similar situation we could cover here. > As start point need to find all places where used > ExceptionUtils.withCauseAndCode method > {code:java} > org.apache.ignite.lang.IgniteException: IGN-CMN-65535 > TraceId:6a9a41f8-a6f4-44f1-87b0-4516c514d1df Unable to send fragment > [targetNode=idt_n_1, fragmentId=1, cause=Node left the cluster. Node: idt_n_1] > at > org.apache.ignite.lang.IgniteExceptionMapperUtil.mapToPublicException(IgniteExceptionMapperUtil.java:106) > at > org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.wrapIfNecessary(AsyncSqlCursorImpl.java:100) > at > org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$0(AsyncSqlCursorImpl.java:76) > at > java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930) > at > java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907) > at > java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506) > at > java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088) > at > org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$execute$15(ExecutionServiceImpl.java:747) > at > java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930) > at > java.base/java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:946) > at > java.base/java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2266) > at > org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$execute$17(ExecutionServiceImpl.java:726) > at > java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859) > at > java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837) > at > java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478) > at > org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:81) > at > java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) > at > java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) > at java.base/java.lang.Thread.run(Thread.java:834) > Suppressed: java.lang.RuntimeException: This is a trimmed root > ... > Caused by: org.apache.ignite.lang.IgniteInternalException: IGN-CMN-65535 > TraceId:6a9a41f8-a6f4-44f1-87b0-4516c514d1df Unable to send fragment > [targetNode=idt_n_1, fragmentId=1, cause=Node left the cluster. Node: idt_n_1] > at > org.apache.ignite.internal.util.ExceptionUtils.lambda$withCauseAndCode$3(ExceptionUtils.java:440) > at > org.apache.ignite.internal.util.ExceptionUtils.withCauseInternal(ExceptionUtils.java:467) > at > org.apache.ignite.internal.util.ExceptionUtils.withCauseAndCode(ExceptionUtils.java:440) > at > org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$execute$12(ExecutionServiceImpl.java:714) > at > java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930) > at > java.base/java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:946) > at > java.base/java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2266) > at > org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$execute$17(ExecutionServiceImpl.java:698) > ... 7 more > Caused by: org.apache.ignite.internal.sql.engine.NodeLeftException: IGN-CMN-5 > TraceId:bf122f9c-e697-4dfa-b59f-0692595fa94c Node left the cluster. Node: > idt_n_1 > at > org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.send(MessageS
[jira] [Updated] (IGNITE-20476) improve checking SQL exceptions in tests
[ https://issues.apache.org/jira/browse/IGNITE-20476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-20476: --- Description: As of now there are few different approaches to check exception from SQLengine. It leads to hard control exceptions handling, like that all public Exception should be really public and don't belong to internal packages, or that all public exceptions have a text messages and so on. Let's move all exceptions checks related to SQL to two main points: 1) SqlTestUtils.assertThrowsSqlException(...) methods for SQL API 2) JdbcTestUtils.assertThrowsSqlException(...) methods fro JDBC API was: As of now there are few different approaches to check exception from SQLengine. It leads to hard control exceptions handling, like that all public Exception should be really public and don't belong to internal packages, or that all public exceptions have a text messages. Let's move all exceptions checks related to SQL to two main points: 1) SqlTestUtils.assertThrowsSqlException(...) methods for SQL API 2) JdbcTestUtils.assertThrowsSqlException(...) methods fro JDBC API > improve checking SQL exceptions in tests > > > Key: IGNITE-20476 > URL: https://issues.apache.org/jira/browse/IGNITE-20476 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > As of now there are few different approaches to check exception from > SQLengine. It leads to hard control exceptions handling, like that all public > Exception should be really public and don't belong to internal packages, or > that all public exceptions have a text messages and so on. > Let's move all exceptions checks related to SQL to two main points: > 1) SqlTestUtils.assertThrowsSqlException(...) methods for SQL API > 2) JdbcTestUtils.assertThrowsSqlException(...) methods fro JDBC API -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20339) Get rid of IndexEvent and TableEvent
[ https://issues.apache.org/jira/browse/IGNITE-20339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reassigned IGNITE-20339: - Assignee: Andrey Mashenkov > Get rid of IndexEvent and TableEvent > > > Key: IGNITE-20339 > URL: https://issues.apache.org/jira/browse/IGNITE-20339 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > It was found that no one uses > *org.apache.ignite.internal.index.event.IndexEvent* and > *org.apache.ignite.internal.table.event.TableEvent* except for tests, I > propose to get rid of this and related code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20339) Get rid of IndexEvent and TableEvent
[ https://issues.apache.org/jira/browse/IGNITE-20339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-20339: -- Description: It was found that no one uses *org.apache.ignite.internal.index.event.IndexEvent*, *org.apache.ignite.internal.table.event.TableEvent* and *org.apache.ignite.internal.schema.event.SchemaEvent* except for tests, I propose to get rid of this and related code. was:It was found that no one uses *org.apache.ignite.internal.index.event.IndexEvent* and *org.apache.ignite.internal.table.event.TableEvent* except for tests, I propose to get rid of this and related code. > Get rid of IndexEvent and TableEvent > > > Key: IGNITE-20339 > URL: https://issues.apache.org/jira/browse/IGNITE-20339 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > It was found that no one uses > *org.apache.ignite.internal.index.event.IndexEvent*, > *org.apache.ignite.internal.table.event.TableEvent* and > *org.apache.ignite.internal.schema.event.SchemaEvent* except for tests, I > propose to get rid of this and related code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20339) Get rid of IndexEvent and TableEvent
[ https://issues.apache.org/jira/browse/IGNITE-20339?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-20339: -- Fix Version/s: 3.0.0-beta2 > Get rid of IndexEvent and TableEvent > > > Key: IGNITE-20339 > URL: https://issues.apache.org/jira/browse/IGNITE-20339 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > It was found that no one uses > *org.apache.ignite.internal.index.event.IndexEvent*, > *org.apache.ignite.internal.table.event.TableEvent* and > *org.apache.ignite.internal.schema.event.SchemaEvent* except for tests, I > propose to get rid of this and related code. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20412) Fix ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart
[ https://issues.apache.org/jira/browse/IGNITE-20412?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-20412: - Description: h3. Motivation org.apache.ignite.internal.distribution.zones.ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart started to fall in the catalog-feature branch and fails in the main branch after catalog-feature is merged [https://ci.ignite.apache.org/viewLog.html?buildId=7501721&tab=buildResultsDiv&buildTypeId=ApacheIgnite3xGradle_Test_RunAllTests&logTab=] {code:java} java.lang.AssertionError: Expected: is <[]> but: was <[A]> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6) at org.apache.ignite.internal.distributionzones.DistributionZonesTestUtil.assertValueInStorage(DistributionZonesTestUtil.java:459) at org.apache.ignite.internal.distribution.zones.ItIgniteDistributionZoneManagerNodeRestartTest.testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart(ItIgniteDistributionZoneManagerNodeRestartTest.java:539) {code} h3. Implementation notes The root cause: # This test changes metaStorageManager behavior and it throws expected exception on ms.invoke. # The test alters zone with new filter. # DistributionZoneManager#onUpdateFilter return a future from saveDataNodesToMetaStorageOnScaleUp(zoneId, causalityToken) # The future is completed exceptionally and WatchProcessor#notificationFuture will be completed exceptionally. # Next updates will not be handled properly because notificationFuture is completed exceptionally. We have already created tickets obout exception handling: * https://issues.apache.org/jira/browse/IGNITE-14693 * https://issues.apache.org/jira/browse/IGNITE-14611 The test scenario is incorrect because the node should be stopped (by failure handler) if the ms.invoke failed. We need to rewrite it when the DZM restart will be updated. UPD1: I've tried to rewrite test, so we could not throw exception in metastorage handler, but just force thread to wait in this invoke, but this lead the to the problem that because we use spy on Standalone Metastorage, and mockito use synchronised block when we call ms.invoke, so that leads to the problem that blocking of one invoke leads to blocking all other communication with ms. Need further investigation how to rewrite this test was: h3. Motivation org.apache.ignite.internal.distribution.zones.ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart started to fall in the catalog-feature branch and fails in the main branch after catalog-feature is merged [https://ci.ignite.apache.org/viewLog.html?buildId=7501721&tab=buildResultsDiv&buildTypeId=ApacheIgnite3xGradle_Test_RunAllTests&logTab=] {code:java} java.lang.AssertionError: Expected: is <[]> but: was <[A]> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20) at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6) at org.apache.ignite.internal.distributionzones.DistributionZonesTestUtil.assertValueInStorage(DistributionZonesTestUtil.java:459) at org.apache.ignite.internal.distribution.zones.ItIgniteDistributionZoneManagerNodeRestartTest.testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart(ItIgniteDistributionZoneManagerNodeRestartTest.java:539) {code} h3. Implementation notes The root cause: # This test changes metaStorageManager behavior and it throws expected exception on ms.invoke. # The test alters zone with new filter. # DistributionZoneManager#onUpdateFilter return a future from saveDataNodesToMetaStorageOnScaleUp(zoneId, causalityToken) # The future is completed exceptionally and WatchProcessor#notificationFuture will be completed exceptionally. # Next updates will not be handled properly because notificationFuture is completed exceptionally. We have already created tickets obout exception handling: * https://issues.apache.org/jira/browse/IGNITE-14693 * https://issues.apache.org/jira/browse/IGNITE-14611 The test scenario is incorrect because the node should be stopped (by failure handler) if the ms.invoke failed. We need to rewrite it when the DZM restart will be updated. > Fix > ItIgniteDistributionZoneManagerNodeRestartTest#testScaleUpsTriggeredByFilterUpdateAndNodeJoinAreRestoredAfterRestart > > > Key: IGNITE-20412 > URL: https://issues.apache.org/jira/browse/IGNITE-20412 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > h3. Moti
[jira] [Updated] (IGNITE-20471) Handle TxManagerImpl#finish correctly when recipientNode is null
[ https://issues.apache.org/jira/browse/IGNITE-20471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-20471: - Description: *Motivation* According the logic of invocations of {{TxManagerImpl#finish}}, it is possible that {{recipientNode}}, which is passed to {{finish}}, could be {{null}}. Further in the code of {{finish}} method we make {{replicaService.invoke(recipientNode)}} and this could lead to {{NullPointerException}}. UPD1: It is possible that I was wrong and we even don't reach the code where we call invoke {{replicaService.invoke(recipientNode)}}, because before we check {{groups.isEmpty()}} and seems that we go through the other branch. Need to investigate why I've got {{null}} when run {{ItTableRaftSnapshotsTest#entriesKeepAppendedAfterSnapshotInstallation}} was: *Motivation* According the logic of invocations of {{TxManagerImpl#finish}}, it is possible that {{recipientNode}}, which is passed to {{finish}}, could be {{null}}. Further in the code of {{finish}} method we make {{replicaService.invoke(recipientNode)}} and this could lead to {{NullPointerException}}. UPD1: It is possible that I was wrong and we even don't reach the code where we call invoke {{replicaService.invoke(recipientNode)}}, because before we check {{groups.isEmpty()}} and seems that we go through the other branch. Need to investigate why I've got {{null}} when run ItTableRaftSnapshotsTest#entriesKeepAppendedAfterSnapshotInstallation}} > Handle TxManagerImpl#finish correctly when recipientNode is null > > > Key: IGNITE-20471 > URL: https://issues.apache.org/jira/browse/IGNITE-20471 > Project: Ignite > Issue Type: Bug >Reporter: Mirza Aliev >Priority: Major > Labels: ignite-3 > > *Motivation* > According the logic of invocations of {{TxManagerImpl#finish}}, it is > possible that {{recipientNode}}, which is passed to {{finish}}, could be > {{null}}. Further in the code of {{finish}} method we make > {{replicaService.invoke(recipientNode)}} and this could lead to > {{NullPointerException}}. > UPD1: > It is possible that I was wrong and we even don't reach the code where we > call invoke {{replicaService.invoke(recipientNode)}}, because before we > check {{groups.isEmpty()}} and seems that we go through the other branch. > Need to investigate why I've got {{null}} when run > {{ItTableRaftSnapshotsTest#entriesKeepAppendedAfterSnapshotInstallation}} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20471) Handle TxManagerImpl#finish correctly when recipientNode is null
[ https://issues.apache.org/jira/browse/IGNITE-20471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-20471: - Description: *Motivation* According the logic of invocations of {{TxManagerImpl#finish}}, it is possible that {{recipientNode}}, which is passed to {{finish}}, could be {{null}}. Further in the code of {{finish}} method we make {{replicaService.invoke(recipientNode)}} and this could lead to {{NullPointerException}}. UPD1: It is possible that I was wrong and we even don't reach the code where we call invoke {{replicaService.invoke(recipientNode)}}, because before we check {{groups.isEmpty()}} and seems that we go through the other branch. Need to investigate why I've got {{null}} when run ItTableRaftSnapshotsTest#entriesKeepAppendedAfterSnapshotInstallation}} was: *Motivation* According the logic of invocations of {{TxManagerImpl#finish}}, it is possible that {{recipientNode}}, which is passed to {{finish}}, could be {{null}}. Further in the code of {{finish}} method we make {{replicaService.invoke(recipientNode)}} and this could lead to {{NullPointerException}}. > Handle TxManagerImpl#finish correctly when recipientNode is null > > > Key: IGNITE-20471 > URL: https://issues.apache.org/jira/browse/IGNITE-20471 > Project: Ignite > Issue Type: Bug >Reporter: Mirza Aliev >Priority: Major > Labels: ignite-3 > > *Motivation* > According the logic of invocations of {{TxManagerImpl#finish}}, it is > possible that {{recipientNode}}, which is passed to {{finish}}, could be > {{null}}. Further in the code of {{finish}} method we make > {{replicaService.invoke(recipientNode)}} and this could lead to > {{NullPointerException}}. > UPD1: > It is possible that I was wrong and we even don't reach the code where we > call invoke {{replicaService.invoke(recipientNode)}}, because before we > check {{groups.isEmpty()}} and seems that we go through the other branch. > Need to investigate why I've got {{null}} when run > ItTableRaftSnapshotsTest#entriesKeepAppendedAfterSnapshotInstallation}} -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20477) Async component start
[ https://issues.apache.org/jira/browse/IGNITE-20477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-20477: - Description: Currently all Ignite components start synchronously (see {{IgniteComponent#start}}). This is inconvenient, because some components can complete their startup only when Meta Storage has initialized all Version Values (see {{IgniteImpl#recoverComponentsStateOnStart}}). Because of this, some components employ a hack which consists of having a "special" Versioned Value, which is injected with a future that gets resolved only after the enclosing component completes its startup (see {{startVv}} in {{TableManager}} or {{IndexManager}}). This blocks the Watch Processor inside Meta Storage, preventing it from processing further updates. This problem with this approach that it is quite cryptic and hard to understand. Instead I propose to do the following: # Change the signature of {{IgniteComponent#start}} to {{CompletableFuture start()}}. # All actions in the components startup will be divided into two categories: sync actions, that can be executed synchronously in order for the component to be usable by other components during their startup, and async actions, which need to wait for any of the Versioned Values to be initialized by the Meta Storage. Such async actions should be wrapped in a {{CompletableFuture}} and returned from the {{start}} method. # {{IgniteImpl}} startup procedure should be updated to collect the futures from all components and wait for their completion inside {{recoverComponentsStateOnStart}}, after {{metaStorageMgr.notifyRevisionUpdateListenerOnStart()}} has been called, but before Watches are deployed ({{metaStorageMgr.deployWatches()}}) > Async component start > - > > Key: IGNITE-20477 > URL: https://issues.apache.org/jira/browse/IGNITE-20477 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > > Currently all Ignite components start synchronously (see > {{IgniteComponent#start}}). This is inconvenient, because some components can > complete their startup only when Meta Storage has initialized all Version > Values (see {{IgniteImpl#recoverComponentsStateOnStart}}). Because of this, > some components employ a hack which consists of having a "special" Versioned > Value, which is injected with a future that gets resolved only after the > enclosing component completes its startup (see {{startVv}} in > {{TableManager}} or {{IndexManager}}). This blocks the Watch Processor inside > Meta Storage, preventing it from processing further updates. > This problem with this approach that it is quite cryptic and hard to > understand. Instead I propose to do the following: > # Change the signature of {{IgniteComponent#start}} to > {{CompletableFuture start()}}. > # All actions in the components startup will be divided into two categories: > sync actions, that can be executed synchronously in order for the component > to be usable by other components during their startup, and async actions, > which need to wait for any of the Versioned Values to be initialized by the > Meta Storage. Such async actions should be wrapped in a {{CompletableFuture}} > and returned from the {{start}} method. > # {{IgniteImpl}} startup procedure should be updated to collect the futures > from all components and wait for their completion inside > {{recoverComponentsStateOnStart}}, after > {{metaStorageMgr.notifyRevisionUpdateListenerOnStart()}} has been called, but > before Watches are deployed ({{metaStorageMgr.deployWatches()}}) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20462) Idle_verify prints partitions hash conflicts when entries are expiring concurrently
[ https://issues.apache.org/jira/browse/IGNITE-20462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17768139#comment-17768139 ] Ignite TC Bot commented on IGNITE-20462: {panel:title=Branch: [pull/10947/head] Base: [master] : No blockers found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel} {panel:title=Branch: [pull/10947/head] Base: [master] : New Tests (14)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1} {color:#8b}Disk Page Compressions 1{color} [[tests 2|https://ci2.ignite.apache.org/viewLog.html?buildId=7346471]] * {color:#013220}IgnitePdsCompressionTestSuite: IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckWithExpiring[encryption=false, onlyPrimay=true] - PASSED{color} * {color:#013220}IgnitePdsCompressionTestSuite: IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckWithExpiring[encryption=false, onlyPrimay=false] - PASSED{color} {color:#8b}Snapshots{color} [[tests 4|https://ci2.ignite.apache.org/viewLog.html?buildId=7344840]] * {color:#013220}IgniteSnapshotTestSuite: IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckWithExpiring[encryption=false, onlyPrimay=true] - PASSED{color} * {color:#013220}IgniteSnapshotTestSuite: IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckWithExpiring[encryption=false, onlyPrimay=false] - PASSED{color} * {color:#013220}IgniteSnapshotTestSuite: IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckWithExpiring[encryption=true, onlyPrimay=true] - PASSED{color} * {color:#013220}IgniteSnapshotTestSuite: IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckWithExpiring[encryption=true, onlyPrimay=false] - PASSED{color} {color:#8b}Control Utility 1{color} [[tests 4|https://ci2.ignite.apache.org/viewLog.html?buildId=7346473]] * {color:#013220}IgniteControlUtilityTestSuite: GridCommandHandlerTest.testCacheIdleVerifyExpiringEntries[cmdHnd=cli] - PASSED{color} * {color:#013220}IgniteControlUtilityTestSuite: GridCommandHandlerTest.testCacheIdleVerifyExpiringEntries[cmdHnd=jmx] - PASSED{color} * {color:#013220}IgniteControlUtilityTestSuite: GridCommandHandlerWithSslFactoryTest.testCacheIdleVerifyExpiringEntries[cmdHnd=cli] - PASSED{color} * {color:#013220}IgniteControlUtilityTestSuite: GridCommandHandlerWithSslTest.testCacheIdleVerifyExpiringEntries[cmdHnd=cli] - PASSED{color} {color:#8b}Control Utility (Zookeeper){color} [[tests 4|https://ci2.ignite.apache.org/viewLog.html?buildId=7344796]] * {color:#013220}ZookeeperIgniteControlUtilityTestSuite: GridCommandHandlerTest.testCacheIdleVerifyExpiringEntries[cmdHnd=cli] - PASSED{color} * {color:#013220}ZookeeperIgniteControlUtilityTestSuite: GridCommandHandlerTest.testCacheIdleVerifyDumpExpiringEntries[cmdHnd=cli] - PASSED{color} * {color:#013220}ZookeeperIgniteControlUtilityTestSuite: GridCommandHandlerTest.testCacheIdleVerifyExpiringEntries[cmdHnd=jmx] - PASSED{color} * {color:#013220}ZookeeperIgniteControlUtilityTestSuite: GridCommandHandlerTest.testCacheIdleVerifyDumpExpiringEntries[cmdHnd=jmx] - PASSED{color} {panel} [TeamCity *--> Run :: All* Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7344860&buildTypeId=IgniteTests24Java8_RunAll] > Idle_verify prints partitions hash conflicts when entries are expiring > concurrently > --- > > Key: IGNITE-20462 > URL: https://issues.apache.org/jira/browse/IGNITE-20462 > Project: Ignite > Issue Type: Bug >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: ise > Time Spent: 20m > Remaining Estimate: 0h > > Background process of entries expire (ttl-cleaner-worker) always working on > activated cluster, so, during idle_verify execution entries still can be > expired even without workload on cluster. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20429) Support dump check command
[ https://issues.apache.org/jira/browse/IGNITE-20429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17768166#comment-17768166 ] Ignite TC Bot commented on IGNITE-20429: {panel:title=Branch: [pull/10949/head] Base: [master] : Possible Blockers (1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1} {color:#d04437}Platform .NET (Core Linux){color} [[tests 0 TIMEOUT , Exit Code , TC_SERVICE_MESSAGE |https://ci2.ignite.apache.org/viewLog.html?buildId=7346479]] {panel} {panel:title=Branch: [pull/10949/head] Base: [master] : New Tests (34)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1} {color:#8b}Disk Page Compressions 1{color} [[tests 17|https://ci2.ignite.apache.org/viewLog.html?buildId=7346018]] * {color:#013220}IgnitePdsCompressionTestSuite: IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=1,persistence=true,mode=ATOMIC] - PASSED{color} * {color:#013220}IgnitePdsCompressionTestSuite: IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=1,persistence=false,mode=TRANSACTIONAL] - PASSED{color} * {color:#013220}IgnitePdsCompressionTestSuite: IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=1,persistence=false,mode=ATOMIC] - PASSED{color} * {color:#013220}IgnitePdsCompressionTestSuite: IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=2,persistence=true,mode=TRANSACTIONAL] - PASSED{color} * {color:#013220}IgnitePdsCompressionTestSuite: IgniteCacheDumpSelf2Test.testCheckFailOnCorruptedData - PASSED{color} * {color:#013220}IgnitePdsCompressionTestSuite: IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=1,persistence=true,mode=TRANSACTIONAL] - PASSED{color} * {color:#013220}IgnitePdsCompressionTestSuite: IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=3,backups=1,persistence=true,mode=ATOMIC] - PASSED{color} * {color:#013220}IgnitePdsCompressionTestSuite: IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=3,backups=1,persistence=false,mode=TRANSACTIONAL] - PASSED{color} * {color:#013220}IgnitePdsCompressionTestSuite: IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=3,backups=1,persistence=false,mode=ATOMIC] - PASSED{color} * {color:#013220}IgnitePdsCompressionTestSuite: IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=3,backups=2,persistence=true,mode=TRANSACTIONAL] - PASSED{color} * {color:#013220}IgnitePdsCompressionTestSuite: IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=2,persistence=true,mode=ATOMIC] - PASSED{color} ... and 6 new tests {color:#8b}Snapshots{color} [[tests 17|https://ci2.ignite.apache.org/viewLog.html?buildId=7346001]] * {color:#013220}IgniteSnapshotTestSuite: IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=1,persistence=false,mode=TRANSACTIONAL] - PASSED{color} * {color:#013220}IgniteSnapshotTestSuite: IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=1,persistence=false,mode=ATOMIC] - PASSED{color} * {color:#013220}IgniteSnapshotTestSuite: IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=2,persistence=true,mode=TRANSACTIONAL] - PASSED{color} * {color:#013220}IgniteSnapshotTestSuite: IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=2,persistence=true,mode=ATOMIC] - PASSED{color} * {color:#013220}IgniteSnapshotTestSuite: IgniteCacheDumpSelf2Test.testCheckFailOnCorruptedData - PASSED{color} * {color:#013220}IgniteSnapshotTestSuite: IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=1,persistence=true,mode=TRANSACTIONAL] - PASSED{color} * {color:#013220}IgniteSnapshotTestSuite: IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=2,backups=1,persistence=true,mode=ATOMIC] - PASSED{color} * {color:#013220}IgniteSnapshotTestSuite: IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=3,backups=1,persistence=false,mode=TRANSACTIONAL] - PASSED{color} * {color:#013220}IgniteSnapshotTestSuite: IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=3,backups=1,persistence=false,mode=ATOMIC] - PASSED{color} * {color:#013220}IgniteSnapshotTestSuite: IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=3,backups=2,persistence=true,mode=TRANSACTIONAL] - PASSED{color} * {color:#013220}IgniteSnapshotTestSuite: IgniteConcurrentCacheDumpTest.testDumpWithConcurrentOperations[nodes=3,backups=2,persistence=true,mode=ATOMIC] - PASSED{color} ... and 6 new tests {panel} [TeamCity *--> Run :: All* Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7346021&buildTypeId=IgniteTests24Java8_RunAll] > Support dump check command > -- > > Key: IGNITE-20429 >