[jira] [Assigned] (IGNITE-15037) Calcite engine. CURRENT_DATE/TIME/TIMESTAMP fails with NPE
[
https://issues.apache.org/jira/browse/IGNITE-15037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-15037:
--
Assignee: Aleksey Plekhanov
> Calcite engine. CURRENT_DATE/TIME/TIMESTAMP fails with NPE
> --
>
> Key: IGNITE-15037
> URL: https://issues.apache.org/jira/browse/IGNITE-15037
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Taras Ledkov
>Assignee: Aleksey Plekhanov
>Priority: Major
>
> The call of the functions
> - CURRENT_TIME
> - CURRENT_DATE
> - CURRENT_TIMESTAMP
> fail with NPE:
> {code}
> Caused by: java.lang.NullPointerException
> at
> org.apache.calcite.runtime.SqlFunctions.currentTimestamp(SqlFunctions.java:2480)
> at SC.execute(Unknown Source)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl$ProjectImpl.apply(ExpressionFactoryImpl.java:387)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.ProjectNode.push(ProjectNode.java:63)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.ScanNode.push(ScanNode.java:107)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:239)
> ... 4 more
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15070) Install Ignite to Solaris Sparc
Ivan Gurov created IGNITE-15070: --- Summary: Install Ignite to Solaris Sparc Key: IGNITE-15070 URL: https://issues.apache.org/jira/browse/IGNITE-15070 Project: Ignite Issue Type: Bug Components: examples Affects Versions: 2.10 Environment: OS: Oracle Solaris 11.4 SPARC Java HotSpot(TM) 64-Bit Server VM (25.291-b10) for solaris-sparc JRE (1.8.0_291-b10) Reporter: Ivan Gurov Fix For: None Hello. We have a project that is built on Oracle Solaris 11.4 SPARC. You need to connect to the Ignite server using a c++thin client. I tried to run the "thin-client-put-get-example" example and got the following error: A fatal error has been detected by the Java Runtime Environment: # # SIGBUS (0xa) at pc=0x53455930, pid=28054, tid=0x0001 The log file contains the following information: siginfo: si_signo: 10 (SIGBUS), si_code: 1 (BUS_ADRALN), si_addr: 0x000101b6c68c There is an assumption that the problem is related to the system architecture: RISC -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15064) Extended tests for extension to write CDC data to Kafka
[ https://issues.apache.org/jira/browse/IGNITE-15064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17376234#comment-17376234 ] Mikhail Petrov commented on IGNITE-15064: - [~nizhikov] LGTM. > Extended tests for extension to write CDC data to Kafka > --- > > Key: IGNITE-15064 > URL: https://issues.apache.org/jira/browse/IGNITE-15064 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-59 > > Tests should be extended to cover REPLICATED vs. PARTITIONED caches. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14952) Releasing WAL segments when reaching DataStorageConfiguration#maxWalArchiveSize
[
https://issues.apache.org/jira/browse/IGNITE-14952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17376218#comment-17376218
]
Ignite TC Bot commented on IGNITE-14952:
{panel:title=Branch: [pull/9198/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9198/head] Base: [master] : New Tests
(5)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS 1{color} [[tests
5|https://ci.ignite.apache.org/viewLog.html?buildId=6074939]]
* {color:#013220}IgnitePdsTestSuite:
SegmentAwareTest.testReleaseUnreservedSegment - PASSED{color}
* {color:#013220}IgnitePdsTestSuite:
SegmentAwareTest.testNoReleaseSegmentNearMaxWalArchiveSize - PASSED{color}
* {color:#013220}IgnitePdsTestSuite:
SegmentAwareTest.testArchiveSizeForUnlimitedWalArchive - PASSED{color}
* {color:#013220}IgnitePdsTestSuite:
SegmentAwareTest.testArchiveSizeForLimitedWalArchive - PASSED{color}
* {color:#013220}IgnitePdsTestSuite:
SegmentAwareTest.testReleaseSegmentsOnExceedMaxWalArchiveSize - PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6074969&buildTypeId=IgniteTests24Java8_RunAll]
> Releasing WAL segments when reaching
> DataStorageConfiguration#maxWalArchiveSize
> ---
>
> Key: IGNITE-14952
> URL: https://issues.apache.org/jira/browse/IGNITE-14952
> Project: Ignite
> Issue Type: Improvement
> Components: persistence
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When the *DataStorageConfiguration#maxWalArchiveSize* is reached, release the
> WAL segments to avoid overflowing the WAL archive.
> Do not allow segment reservations to a
> *DataStorageConfiguration#minWalArchiveSize*.
> Subtask from
> [discussion|http://apache-ignite-developers.2346864.n4.nabble.com/Exceeding-the-DataStorageConfiguration-getMaxWalArchiveSize-due-to-historical-rebalance-td52546.html].
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15055) Handling issue with creation a table that already exist
[
https://issues.apache.org/jira/browse/IGNITE-15055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-15055:
-
Reviewer: Vyacheslav Koptilin
> Handling issue with creation a table that already exist
> ---
>
> Key: IGNITE-15055
> URL: https://issues.apache.org/jira/browse/IGNITE-15055
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Now we have only one method to create a table, that the method is
> {{IgniteTables#createTable}}. The method allow to create a new table, but if
> the table already existed, this method hangs.
> Also, it would be great to add a method which helps to create a table if it
> isn't existed yet, otherwise returns the existed instance.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15069) Fix flaky test: GridCommandHandlerTest.testSetState
[
https://issues.apache.org/jira/browse/IGNITE-15069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17376044#comment-17376044
]
Sergei Ryzhov commented on IGNITE-15069:
problem with DiscoveryDataClusterState#state()
> Fix flaky test: GridCommandHandlerTest.testSetState
> ---
>
> Key: IGNITE-15069
> URL: https://issues.apache.org/jira/browse/IGNITE-15069
> Project: Ignite
> Issue Type: Test
>Reporter: Sergei Ryzhov
>Assignee: Sergei Ryzhov
>Priority: Minor
>
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtilityZookeeper/6073175?expandedTest=build%3A%28id%3A6073175%29%2Cid%3A22184&showLog=6073175_22184_1623.22131.22184&logFilter=debug
> {code:java}
> [2021-07-05 06:25:53,131][ERROR][main][root] Test failed
> [test=GridCommandHandlerTest#testSetState, duration=8469]
> javax.cache.CacheException: class
> org.apache.ignite.transactions.TransactionRollbackException: Transaction has
> been rolled back: 0ed43b47a71--0e1f-597b--0001
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1277)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:2084)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1320)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:868)
> at
> org.apache.ignite.internal.processors.cache.ClusterStateTestUtils.putSomeDataAndCheck(ClusterStateTestUtils.java:101)
> at
> org.apache.ignite.util.GridCommandHandlerTest.setState(GridCommandHandlerTest.java:979)
> at
> org.apache.ignite.util.GridCommandHandlerTest.testSetState(GridCommandHandlerTest.java:947)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2432)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class
> org.apache.ignite.transactions.TransactionRollbackException: Transaction has
> been rolled back: 0ed43b47a71--0e1f-597b--0001
> at
> org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:977)
> at
> org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:975)
> ... 17 more
> Caused by: class
> org.apache.ignite.internal.transactions.IgniteTxRollbackCheckedException:
> Transaction has been rolled back:
> 0ed43b47a71--0e1f-597b--0001
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4429)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put0(GridCacheAdapter.java:2624)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2602)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2581)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1317)
> ... 14 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> perform cache operation (cache topology is not valid): part_cache
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxImplicitSingleStateImpl.validateTopology(IgniteTxImplicitSingleStateImpl.java:141)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1105)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:400)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:579)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:376)
> at
> org.apache.ignite.internal.proce
[jira] [Updated] (IGNITE-15069) Fix flaky test: GridCommandHandlerTest.testSetState
[
https://issues.apache.org/jira/browse/IGNITE-15069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergei Ryzhov updated IGNITE-15069:
---
Ignite Flags: (was: Docs Required,Release Notes Required)
> Fix flaky test: GridCommandHandlerTest.testSetState
> ---
>
> Key: IGNITE-15069
> URL: https://issues.apache.org/jira/browse/IGNITE-15069
> Project: Ignite
> Issue Type: Test
>Reporter: Sergei Ryzhov
>Assignee: Sergei Ryzhov
>Priority: Minor
>
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtilityZookeeper/6073175?expandedTest=build%3A%28id%3A6073175%29%2Cid%3A22184&showLog=6073175_22184_1623.22131.22184&logFilter=debug
> {code:java}
> [2021-07-05 06:25:53,131][ERROR][main][root] Test failed
> [test=GridCommandHandlerTest#testSetState, duration=8469]
> javax.cache.CacheException: class
> org.apache.ignite.transactions.TransactionRollbackException: Transaction has
> been rolled back: 0ed43b47a71--0e1f-597b--0001
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1277)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:2084)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1320)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:868)
> at
> org.apache.ignite.internal.processors.cache.ClusterStateTestUtils.putSomeDataAndCheck(ClusterStateTestUtils.java:101)
> at
> org.apache.ignite.util.GridCommandHandlerTest.setState(GridCommandHandlerTest.java:979)
> at
> org.apache.ignite.util.GridCommandHandlerTest.testSetState(GridCommandHandlerTest.java:947)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2432)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class
> org.apache.ignite.transactions.TransactionRollbackException: Transaction has
> been rolled back: 0ed43b47a71--0e1f-597b--0001
> at
> org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:977)
> at
> org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:975)
> ... 17 more
> Caused by: class
> org.apache.ignite.internal.transactions.IgniteTxRollbackCheckedException:
> Transaction has been rolled back:
> 0ed43b47a71--0e1f-597b--0001
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4429)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put0(GridCacheAdapter.java:2624)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2602)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2581)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1317)
> ... 14 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> perform cache operation (cache topology is not valid): part_cache
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxImplicitSingleStateImpl.validateTopology(IgniteTxImplicitSingleStateImpl.java:141)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1105)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:400)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:579)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:376)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.p
[jira] [Updated] (IGNITE-15069) Fix flaky test: GridCommandHandlerTest.testSetState
[
https://issues.apache.org/jira/browse/IGNITE-15069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergei Ryzhov updated IGNITE-15069:
---
Description:
https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtilityZookeeper/6073175?expandedTest=build%3A%28id%3A6073175%29%2Cid%3A22184&showLog=6073175_22184_1623.22131.22184&logFilter=debug
{code:java}
[2021-07-05 06:25:53,131][ERROR][main][root] Test failed
[test=GridCommandHandlerTest#testSetState, duration=8469]
javax.cache.CacheException: class
org.apache.ignite.transactions.TransactionRollbackException: Transaction has
been rolled back: 0ed43b47a71--0e1f-597b--0001
at
org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1277)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:2084)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1320)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:868)
at
org.apache.ignite.internal.processors.cache.ClusterStateTestUtils.putSomeDataAndCheck(ClusterStateTestUtils.java:101)
at
org.apache.ignite.util.GridCommandHandlerTest.setState(GridCommandHandlerTest.java:979)
at
org.apache.ignite.util.GridCommandHandlerTest.testSetState(GridCommandHandlerTest.java:947)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2432)
at java.lang.Thread.run(Thread.java:748)
Caused by: class
org.apache.ignite.transactions.TransactionRollbackException: Transaction has
been rolled back: 0ed43b47a71--0e1f-597b--0001
at
org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:977)
at
org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:975)
... 17 more
Caused by: class
org.apache.ignite.internal.transactions.IgniteTxRollbackCheckedException:
Transaction has been rolled back:
0ed43b47a71--0e1f-597b--0001
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4429)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put0(GridCacheAdapter.java:2624)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2602)
at
org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2581)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1317)
... 14 more
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
perform cache operation (cache topology is not valid): part_cache
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxImplicitSingleStateImpl.validateTopology(IgniteTxImplicitSingleStateImpl.java:141)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1105)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:400)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:579)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:376)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:199)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:173)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:133)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:221)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:219)
at
org.apache.ign
[jira] [Created] (IGNITE-15069) Fix flaky test: GridCommandHandlerTest.testSetState
Sergei Ryzhov created IGNITE-15069: -- Summary: Fix flaky test: GridCommandHandlerTest.testSetState Key: IGNITE-15069 URL: https://issues.apache.org/jira/browse/IGNITE-15069 Project: Ignite Issue Type: Test Reporter: Sergei Ryzhov Assignee: Sergei Ryzhov https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ControlUtilityZookeeper/6073175?expandedTest=build%3A%28id%3A6073175%29%2Cid%3A22184&showLog=6073175_22184_1623.22131.22184&logFilter=debug [2021-07-05 06:25:53,131][ERROR][main][root] Test failed [test=GridCommandHandlerTest#testSetState, duration=8469] javax.cache.CacheException: class org.apache.ignite.transactions.TransactionRollbackException: Transaction has been rolled back: 0ed43b47a71--0e1f-597b--0001 at org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1277) at org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:2084) at org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1320) at org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:868) at org.apache.ignite.internal.processors.cache.ClusterStateTestUtils.putSomeDataAndCheck(ClusterStateTestUtils.java:101) at org.apache.ignite.util.GridCommandHandlerTest.setState(GridCommandHandlerTest.java:979) at org.apache.ignite.util.GridCommandHandlerTest.testSetState(GridCommandHandlerTest.java:947) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2432) at java.lang.Thread.run(Thread.java:748) Caused by: class org.apache.ignite.transactions.TransactionRollbackException: Transaction has been rolled back: 0ed43b47a71--0e1f-597b--0001 at org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:977) at org.apache.ignite.internal.util.IgniteUtils$11.apply(IgniteUtils.java:975) ... 17 more Caused by: class org.apache.ignite.internal.transactions.IgniteTxRollbackCheckedException: Transaction has been rolled back: 0ed43b47a71--0e1f-597b--0001 at org.apache.ignite.internal.processors.cache.GridCacheAdapter.syncOp(GridCacheAdapter.java:4429) at org.apache.ignite.internal.processors.cache.GridCacheAdapter.put0(GridCacheAdapter.java:2624) at org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2602) at org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2581) at org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1317) ... 14 more Caused by: class org.apache.ignite.IgniteCheckedException: Failed to perform cache operation (cache topology is not valid): part_cache at org.apache.ignite.internal.processors.cache.transactions.IgniteTxImplicitSingleStateImpl.validateTopology(IgniteTxImplicitSingleStateImpl.java:141) at org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1105) at org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:400) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:579) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:376) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:199) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:173) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:133) at org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.
[jira] [Commented] (IGNITE-15012) Adapting historical rebalance to segment release
[ https://issues.apache.org/jira/browse/IGNITE-15012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375982#comment-17375982 ] Vyacheslav Koptilin commented on IGNITE-15012: -- Hello [~ktkale...@gridgain.com], Thank you for the proposed PR. I left a couple of comments, please take a look. > Adapting historical rebalance to segment release > > > Key: IGNITE-15012 > URL: https://issues.apache.org/jira/browse/IGNITE-15012 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.12 > > Time Spent: 50m > Remaining Estimate: 0h > > It is necessary to adapt the historical rebalance to the release of WAL > segments after their reservation. Since IGNITE-14952 will be automatically > released when the maximum is reached. > This following proposal is part (*in bold*) of a discussion at [dev > list|http://apache-ignite-developers.2346864.n4.nabble.com/Exceeding-the-DataStorageConfiguration-getMaxWalArchiveSize-due-to-historical-rebalance-td52546.html]: > Main proposal: > When theDataStorageConfiguration#getMaxWalArchiveSize is reached, cancel and > do not give the reservation of the WAL segments until we reach > DataStorageConfiguration#getWalArchiveSize. In this case, *if there is no > segment for historical rebalance, we will automatically switch to full > rebalance.* -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15068) Ignite giving stale data - when data is inserted/updated and immediately read (from the same client node)
[
https://issues.apache.org/jira/browse/IGNITE-15068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tanmay Ambre updated IGNITE-15068:
--
Affects Version/s: 2.9
> Ignite giving stale data - when data is inserted/updated and immediately read
> (from the same client node)
> -
>
> Key: IGNITE-15068
> URL: https://issues.apache.org/jira/browse/IGNITE-15068
> Project: Ignite
> Issue Type: Task
> Components: cache
>Affects Versions: 2.9, 2.9.1
>Reporter: Tanmay Ambre
>Priority: Major
>
> Hi,
> We have a 18 node (server) cluster for Ignite. We have multiple client nodes
> that connect to ignite and use the cache api to get and put data.
> One of the client node is a Kafka streams application. This application
> receives an event and for each event:
> # we lookup the data using the key in ignite. i.e. cache.get(key)
> # we update the data if we find an entry in ignite i.e. cache.put(key, value)
> # we insert the data if we don't find an entry in ignite i.e. cache.put(key,
> value)
> This application processes more than 30 million events per day. In some
> scenarios we get multiple events for the same key "consecutively" i.e. the
> time difference between consecutive events is not more than 10 to 20
> milliseconds. We are sure they are processed sequentially as they go to the
> same Kafka partition.
> What we have observed is sometimes, the step #1 gives us an old copy of the
> data (not the one which was updated as part of #2).
>
> for e.g. when we get the first event we have following value:
> Key = 1, value = \{version: 1}
> when we get the second event for the same key, we update ignite as:
> Key = 1, value = \{version: 2} //increment version by 1
> when we get the third event for the same key and when we lookup the data in
> ignite instead of getting \{version: 2}, we get {color:#ff}{version:
> 1}{color}
> also sometimes, when we get the second event - we {color:#ff}don't even
> find the entry in ignite{color} (i.e. \{version:1})
> Our caches have the following configuration
> backups = 1
> atomicityMode = ATOMIC
> writeSynchronizationPolicy = PRIMARY_SYNC
> readFromBackup = true (default - we are not setting this)
>
> Is there something wrong? Should we set "readFromBackup = false"?
> unfortunately it is very difficult to replicate since it happens just 50 to
> 100 times in a day (i.e. out of 30 million events).
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15068) Ignite giving stale data - when data is inserted/updated and immediately read (from the same client node)
[
https://issues.apache.org/jira/browse/IGNITE-15068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tanmay Ambre updated IGNITE-15068:
--
Description:
Hi,
We have a 18 node (server) cluster for Ignite. We have multiple client nodes
that connect to ignite and use the cache api to get and put data.
One of the client node is a Kafka streams application. This application
receives an event and for each event:
# we lookup the data using the key in ignite. i.e. cache.get(key)
# we update the data if we find an entry in ignite i.e. cache.put(key, value)
# we insert the data if we don't find an entry in ignite i.e. cache.put(key,
value)
This application processes more than 30 million events per day. In some
scenarios we get multiple events for the same key "consecutively" i.e. the time
difference between consecutive events is not more than 10 to 20 milliseconds.
We are sure they are processed sequentially as they go to the same Kafka
partition.
What we have observed is sometimes, the step #1 gives us an old copy of the
data (not the one which was updated as part of #2).
for e.g. when we get the first event we have following value:
Key = 1, value = \{version: 1}
when we get the second event for the same key, we update ignite as:
Key = 1, value = \{version: 2} //increment version by 1
when we get the third event for the same key and when we lookup the data in
ignite instead of getting \{version: 2}, we get {color:#ff}{version:
1}{color}
also sometimes, when we get the second event - we {color:#ff}don't even
find the entry in ignite{color} (i.e. \{version:1})
Our caches have the following configuration
backups = 1
atomicityMode = ATOMIC
writeSynchronizationPolicy = PRIMARY_SYNC
readFromBackup = true (default - we are not setting this)
Is there something wrong? Should we set "readFromBackup = false"?
unfortunately it is very difficult to replicate since it happens just 50 to 100
times in a day (i.e. out of 30 million events).
was:
Hi,
We have a 18 node (server) cluster for Ignite. We have multiple client nodes
that connect to ignite and use the cache api to get and put data.
One of the client node is a Kafka streams application. This application
receives an event and for each event:
# we lookup the data using the key in ignite. i.e. cache.get(key)
# we update the data if we find an entry in ignite i.e. cache.put(key, value)
# we insert the data if we don't find an entry in ignite i.e. cache.put(key,
value)
This application processes more than 30 million events per day. In some
scenarios we get multiple events for the same key "consecutively" i.e. the time
difference between consecutive events is not more than 10 to 20 milliseconds.
We are sure they are processed sequentially as they go to the same Kafka
partition.
What we have observed is sometimes, the step #1 gives us an old copy of the
data (not the one which was updated as part of #2).
for e.g. when we get the first event we have following value:
Key = 1, value = \{version: 1}
when we get the second event for the same key, we update ignite as:
Key = 1, value = \{version: 2} //increment version by 1
when we get the third event for the same key and when we lookup the data in
ignite instead of getting \{version: 2}, we get {color:#ff}{version:
1}{color}
also sometimes, when we get the second event - we {color:#ff}don't even
find the entry in ignite{color} (i.e. \{version:1})
Our caches have the following configuration
backups = 1
atomicityMode = ATOMIC
writeSynchronizationPolicy = PRIMARY_SYNC
readFromBackup = true (default - we are not setting this)
Is there something wrong? Should we set "readFromBackup = false"?
unfortunately it is very difficult to replicate since it happens just a between
50 to 100 times in a day (i.e. out of 30 million events that we are getting).
> Ignite giving stale data - when data is inserted/updated and immediately read
> (from the same client node)
> -
>
> Key: IGNITE-15068
> URL: https://issues.apache.org/jira/browse/IGNITE-15068
> Project: Ignite
> Issue Type: Task
> Components: cache
>Affects Versions: 2.9.1
>Reporter: Tanmay Ambre
>Priority: Major
>
> Hi,
> We have a 18 node (server) cluster for Ignite. We have multiple client nodes
> that connect to ignite and use the cache api to get and put data.
> One of the client node is a Kafka streams application. This application
> receives an event and for each event:
> # we lookup the data using the key in ignite. i.e. cache.get(key)
> # we update the data if we find an entry in ignite i.e. cache.put(key, value)
> # we insert the data if we don't find an entry in ignite i.e. cache.put(key,
> value)
> Thi
[jira] [Updated] (IGNITE-15068) Ignite giving stale data - when data is inserted/updated and immediately read (from the same client node)
[
https://issues.apache.org/jira/browse/IGNITE-15068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tanmay Ambre updated IGNITE-15068:
--
Description:
Hi,
We have a 18 node (server) cluster for Ignite. We have multiple client nodes
that connect to ignite and use the cache api to get and put data.
One of the client node is a Kafka streams application. This application
receives an event and for each event:
# we lookup the data using the key in ignite. i.e. cache.get(key)
# we update the data if we find an entry in ignite i.e. cache.put(key, value)
# we insert the data if we don't find an entry in ignite i.e. cache.put(key,
value)
This application processes more than 30 million events per day. In some
scenarios we get multiple events for the same key "consecutively" i.e. the time
difference between consecutive events is not more than 10 to 20 milliseconds.
We are sure they are processed sequentially as they go to the same Kafka
partition.
What we have observed is sometimes, the step #1 gives us an old copy of the
data (not the one which was updated as part of #2).
for e.g. when we get the first event we have following value:
Key = 1, value = \{version: 1}
when we get the second event for the same key, we update ignite as:
Key = 1, value = \{version: 2} //increment version by 1
when we get the third event for the same key and when we lookup the data in
ignite instead of getting \{version: 2}, we get {color:#ff}{version:
1}{color}
also sometimes, when we get the second event - we {color:#ff}don't even
find the entry in ignite{color} (i.e. \{version:1})
Our caches have the following configuration
backups = 1
atomicityMode = ATOMIC
writeSynchronizationPolicy = PRIMARY_SYNC
readFromBackup = true (default - we are not setting this)
Is there something wrong? Should we set "readFromBackup = false"?
unfortunately it is very difficult to replicate since it happens just a between
50 to 100 times in a day (i.e. out of 30 million events that we are getting).
was:
Hi,
We have a 18 node (server) cluster for Ignite. We have multiple client nodes
that connect to ignite and use the cache api to get and put data.
One of the client node is a Kafka streams application. This application
receives an event and for each event:
# we lookup the data using the key in ignite. i.e. cache.get(key)
# we update the data if we find an entry in ignite i.e. cache.put(key, value)
# we insert the data if we don't find an entry in ignite i.e. cache.put(key,
value)
This application processes more than 30 million events per day. In some
scenarios we get multiple events for the same key "consecutively" i.e. the time
difference between consecutive events is not more than 10 to 20 milliseconds.
We are sure they are processed sequentially as they go to the same Kafka
partition.
What we have observed is sometimes, the step #1 gives us an old copy of the
data (not the one which was updated as part of #2).
for e.g. when we get the first event for the same key, we have following value:
Key = 1, value = \{version: 1}
when we get the second even we update ignite as:
Key = 1, value = \{version: 2} //increment version by 1
when we get the third event and when we lookup the data in ignite instead of
getting \{version: 2}, we get {color:#ff}{version: 1}{color}
also sometimes, when we get the second event - we {color:#ff}don't even
find the entry in ignite{color} (i.e. \{version:1})
Our caches have the following configuration
backups = 1
atomicityMode = ATOMIC
writeSynchronizationPolicy = PRIMARY_SYNC
readFromBackup = true (default - we are not setting this)
Is there something wrong? Should we set "readFromBackup = false"?
unfortunately it is very difficult to replicate since it happens just a between
50 to 100 times in a day (i.e. out of 30 million events that we are getting).
> Ignite giving stale data - when data is inserted/updated and immediately read
> (from the same client node)
> -
>
> Key: IGNITE-15068
> URL: https://issues.apache.org/jira/browse/IGNITE-15068
> Project: Ignite
> Issue Type: Task
> Components: cache
>Affects Versions: 2.9.1
>Reporter: Tanmay Ambre
>Priority: Major
>
> Hi,
> We have a 18 node (server) cluster for Ignite. We have multiple client nodes
> that connect to ignite and use the cache api to get and put data.
> One of the client node is a Kafka streams application. This application
> receives an event and for each event:
> # we lookup the data using the key in ignite. i.e. cache.get(key)
> # we update the data if we find an entry in ignite i.e. cache.put(key, value)
> # we insert the data if we don't find an entry in ignite i.e. cache.put(key,
> v
[jira] [Updated] (IGNITE-15068) Ignite giving stale data - when data is inserted/updated and immediately read (from the same client node)
[
https://issues.apache.org/jira/browse/IGNITE-15068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tanmay Ambre updated IGNITE-15068:
--
Description:
Hi,
We have a 18 node (server) cluster for Ignite. We have multiple client nodes
that connect to ignite and use the cache api to get and put data.
One of the client node is a Kafka streams application. This application
receives an event and for each event:
# we lookup the data using the key in ignite. i.e. cache.get(key)
# we update the data if we find an entry in ignite i.e. cache.put(key, value)
# we insert the data if we don't find an entry in ignite i.e. cache.put(key,
value)
This application processes more than 30 million events per day. In some
scenarios we get multiple events for the same key "consecutively" i.e. the time
difference between consecutive events is not more than 10 to 20 milliseconds.
We are sure they are processed sequentially as they go to the same Kafka
partition.
What we have observed is sometimes, the step #1 gives us an old copy of the
data (not the one which was updated as part of #2).
for e.g. when we get the first event for the same key, we have following value:
Key = 1, value = \{version: 1}
when we get the second even we update ignite as:
Key = 1, value = \{version: 2} //increment version by 1
when we get the third event and when we lookup the data in ignite instead of
getting \{version: 2}, we get {color:#ff}{version: 1}{color}
also sometimes, when we get the second event - we {color:#ff}don't even
find the entry in ignite{color} (i.e. \{version:1})
Our caches have the following configuration
backups = 1
atomicityMode = ATOMIC
writeSynchronizationPolicy = PRIMARY_SYNC
readFromBackup = true (default - we are not setting this)
Is there something wrong? Should we set "readFromBackup = false"?
unfortunately it is very difficult to replicate since it happens just a between
50 to 100 times in a day (i.e. out of 30 million events that we are getting).
was:
Hi,
We have a 18 node (server) cluster for Ignite. We have multiple client nodes
that connect to ignite and use the cache api to get and put data.
One of the client node is a Kafka streams application. This application
receives an event for this event:
# we lookup the data using the key in ignite. i.e. cache.get(key)
# we update the data if we find an entry in ignite i.e. cache.put(key, value)
# we insert the data if we don't find an entry in ignite i.e. cache.put(key,
value)
This application processes more than 30 million events per day. In some
scenarios we get multiple events for the same key "consecutively" i.e. the time
difference between consecutive events is not more than 10 to 20 milliseconds.
We are sure they are processed sequentially as they go to the same Kafka
partition.
What we have observed is sometimes, the step #1 gives us an old copy of the
data (not the one which was updated as part of #2).
for e.g. when we get the first event for the same key, we have following value:
Key = 1, value = \{version: 1}
when we get the second even we update ignite as:
Key = 1, value = \{version: 2} //increment version by 1
when we get the third event and when we lookup the data in ignite instead of
getting \{version: 2}, we get {color:#FF}{version: 1}{color}
also sometimes, when we get the second event - we {color:#FF}don't even
find the entry in ignite{color} (i.e. \{version:1})
Our caches have the following configuration
backups = 1
atomicityMode = ATOMIC
writeSynchronizationPolicy = PRIMARY_SYNC
readFromBackup = true (default - we are not setting this)
Is there something wrong? Should we set "readFromBackup = false"?
unfortunately it is very difficult to replicate since it happens just a between
50 to 100 times in a day (i.e. out of 30 million events that we are getting).
> Ignite giving stale data - when data is inserted/updated and immediately read
> (from the same client node)
> -
>
> Key: IGNITE-15068
> URL: https://issues.apache.org/jira/browse/IGNITE-15068
> Project: Ignite
> Issue Type: Task
> Components: cache
>Affects Versions: 2.9.1
>Reporter: Tanmay Ambre
>Priority: Major
>
> Hi,
> We have a 18 node (server) cluster for Ignite. We have multiple client nodes
> that connect to ignite and use the cache api to get and put data.
> One of the client node is a Kafka streams application. This application
> receives an event and for each event:
> # we lookup the data using the key in ignite. i.e. cache.get(key)
> # we update the data if we find an entry in ignite i.e. cache.put(key, value)
> # we insert the data if we don't find an entry in ignite i.e. cache.put(key,
> value)
> This applicatio
[jira] [Created] (IGNITE-15068) Ignite giving stale data - when data is inserted/updated and immediately read (from the same client node)
Tanmay Ambre created IGNITE-15068:
-
Summary: Ignite giving stale data - when data is inserted/updated
and immediately read (from the same client node)
Key: IGNITE-15068
URL: https://issues.apache.org/jira/browse/IGNITE-15068
Project: Ignite
Issue Type: Task
Components: cache
Affects Versions: 2.9.1
Reporter: Tanmay Ambre
Hi,
We have a 18 node (server) cluster for Ignite. We have multiple client nodes
that connect to ignite and use the cache api to get and put data.
One of the client node is a Kafka streams application. This application
receives an event for this event:
# we lookup the data using the key in ignite. i.e. cache.get(key)
# we update the data if we find an entry in ignite i.e. cache.put(key, value)
# we insert the data if we don't find an entry in ignite i.e. cache.put(key,
value)
This application processes more than 30 million events per day. In some
scenarios we get multiple events for the same key "consecutively" i.e. the time
difference between consecutive events is not more than 10 to 20 milliseconds.
We are sure they are processed sequentially as they go to the same Kafka
partition.
What we have observed is sometimes, the step #1 gives us an old copy of the
data (not the one which was updated as part of #2).
for e.g. when we get the first event for the same key, we have following value:
Key = 1, value = \{version: 1}
when we get the second even we update ignite as:
Key = 1, value = \{version: 2} //increment version by 1
when we get the third event and when we lookup the data in ignite instead of
getting \{version: 2}, we get {color:#FF}{version: 1}{color}
also sometimes, when we get the second event - we {color:#FF}don't even
find the entry in ignite{color} (i.e. \{version:1})
Our caches have the following configuration
backups = 1
atomicityMode = ATOMIC
writeSynchronizationPolicy = PRIMARY_SYNC
readFromBackup = true (default - we are not setting this)
Is there something wrong? Should we set "readFromBackup = false"?
unfortunately it is very difficult to replicate since it happens just a between
50 to 100 times in a day (i.e. out of 30 million events that we are getting).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15064) Extended tests for extension to write CDC data to Kafka
[ https://issues.apache.org/jira/browse/IGNITE-15064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375843#comment-17375843 ] Nikolay Izhikov commented on IGNITE-15064: -- https://ci.ignite.apache.org/viewLog.html?buildId=6075146&; - tests run > Extended tests for extension to write CDC data to Kafka > --- > > Key: IGNITE-15064 > URL: https://issues.apache.org/jira/browse/IGNITE-15064 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-59 > > Tests should be extended to cover REPLICATED vs. PARTITIONED caches. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15067) Add custom destination path to the snapshost API
Maxim Muzafarov created IGNITE-15067:
Summary: Add custom destination path to the snapshost API
Key: IGNITE-15067
URL: https://issues.apache.org/jira/browse/IGNITE-15067
Project: Ignite
Issue Type: Improvement
Reporter: Maxim Muzafarov
Assignee: Maxim Muzafarov
Fix For: 2.12
The default configuration path obtains from the IgniteConfiguration. However,
in some circumstances, it is good to set this destination path at runtime. This
path must be configured relatively in the node working directory and must be
accessible from the security point of view.
Proposed API:
{code}
public IgniteFuture createSnapshot(String name, Path locPath);
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15067) Add custom destination path to the snapshost API
[
https://issues.apache.org/jira/browse/IGNITE-15067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-15067:
-
Labels: iep-43 (was: )
> Add custom destination path to the snapshost API
>
>
> Key: IGNITE-15067
> URL: https://issues.apache.org/jira/browse/IGNITE-15067
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: iep-43
> Fix For: 2.12
>
>
> The default configuration path obtains from the IgniteConfiguration. However,
> in some circumstances, it is good to set this destination path at runtime.
> This path must be configured relatively in the node working directory and
> must be accessible from the security point of view.
> Proposed API:
> {code}
> public IgniteFuture createSnapshot(String name, Path locPath);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14953) Calcite. Sort out test scripts 'function'
[
https://issues.apache.org/jira/browse/IGNITE-14953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375801#comment-17375801
]
Yury Gerzhedovich commented on IGNITE-14953:
[~tledkov-gridgain], LGTM
> Calcite. Sort out test scripts 'function'
> -
>
> Key: IGNITE-14953
> URL: https://issues.apache.org/jira/browse/IGNITE-14953
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: calcite2-required, calcite3-required
> Time Spent: 1h
> Remaining Estimate: 0h
>
> We have a bunch of unsorted tests included in ScriptRunnerTestSuite. As
> result, we should have to mute all failed tests, file a ticket for related
> problems and have a green run for the suite.
> Scripts dir: {{function}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15066) Calcite. Function CONCAT and NULL arguments
[ https://issues.apache.org/jira/browse/IGNITE-15066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-15066: --- Priority: Minor (was: Major) > Calcite. Function CONCAT and NULL arguments > --- > > Key: IGNITE-15066 > URL: https://issues.apache.org/jira/browse/IGNITE-15066 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Yury Gerzhedovich >Priority: Minor > Labels: calcite2-required, calcite3-required > > The result of the work CONCAT function will be null in case any of argument > is null. > see test/sql/function/string/test_concat.test -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15066) Calcite. Function CONCAT and NULL arguments
Yury Gerzhedovich created IGNITE-15066: -- Summary: Calcite. Function CONCAT and NULL arguments Key: IGNITE-15066 URL: https://issues.apache.org/jira/browse/IGNITE-15066 Project: Ignite Issue Type: Bug Components: sql Reporter: Yury Gerzhedovich The result of the work CONCAT function will be null in case any of argument is null. see test/sql/function/string/test_concat.test -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15042) Fix flaky test: SqlSystemViewsSelfTest.testCachesViews
[
https://issues.apache.org/jira/browse/IGNITE-15042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375774#comment-17375774
]
Aleksey Plekhanov commented on IGNITE-15042:
[~RyzhovSV] looks good to me. Thanks for the contribution! Merged to master.
> Fix flaky test: SqlSystemViewsSelfTest.testCachesViews
> --
>
> Key: IGNITE-15042
> URL: https://issues.apache.org/jira/browse/IGNITE-15042
> Project: Ignite
> Issue Type: Test
>Reporter: Sergei Ryzhov
>Assignee: Sergei Ryzhov
>Priority: Minor
> Attachments: SqlSystemViewsSelfTestBug.java
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> Fix flaky test: SqlSystemViewsSelfTest.testCachesViews
> {code:java}
> java.lang.AssertionError: expected:<5> but was:<4>
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.failNotEquals(Assert.java:834)
> at org.junit.Assert.assertEquals(Assert.java:118)
> at org.junit.Assert.assertEquals(Assert.java:144)
> at
> org.apache.ignite.testframework.junits.JUnitAssertAware.assertEquals(JUnitAssertAware.java:59)
> at
> org.apache.ignite.internal.processors.query.SqlSystemViewsSelfTest.testCachesViews(SqlSystemViewsSelfTest.java:1565)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2432)
> at java.base/java.lang.Thread.run(Thread.java:834)
> [
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14776) .NET: ClientFailoverSocket sets logger too late, resulting in null loggers downstream.
[
https://issues.apache.org/jira/browse/IGNITE-14776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert May updated IGNITE-14776:
Summary: .NET: ClientFailoverSocket sets logger too late, resulting in null
loggers downstream. (was: .NET: ClientFailoverSocket sets logger to late,
resulting in null loggers downstream.)
> .NET: ClientFailoverSocket sets logger too late, resulting in null loggers
> downstream.
> --
>
> Key: IGNITE-14776
> URL: https://issues.apache.org/jira/browse/IGNITE-14776
> Project: Ignite
> Issue Type: Bug
> Components: clients, platforms
>Affects Versions: 2.10, 2.11
>Reporter: Robert May
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.12
>
>
> Because the logger is set last inside of the
> {code:c#}ClientFailoverSocket{code} class, if there are issues with the
> {code:c#}GetIpEndpoints{code} call, an argument exception can occur when a
> debug message is logged inside of {code:c#}GetIps{code} when the ip address
> can't be parsed. In my case, this occurred with a DNS failure.
> Stack Trace:
> {code:c#}
> System.ArgumentNullException: Value cannot be null. (Parameter 'logger')
> at Apache.Ignite.Core.Impl.Common.IgniteArgumentCheck.NotNull(Object arg,
> String argName)
> at Apache.Ignite.Core.Log.LoggerExtensions.Log(ILogger logger, LogLevel
> level, Exception ex, String message)
> at Apache.Ignite.Core.Log.LoggerExtensions.Debug(ILogger logger, Exception
> ex, String message)
> at Apache.Ignite.Core.Impl.Client.ClientFailoverSocket.GetIps(String host,
> Boolean suppressExceptions)
> at
> Apache.Ignite.Core.Impl.Client.ClientFailoverSocket.d__11.MoveNext()
> at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
> at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
> at
> Apache.Ignite.Core.Impl.Client.ClientFailoverSocket..ctor(IgniteClientConfiguration
> config, Marshaller marsh, TransactionsClient transactions)
> at
> Apache.Ignite.Core.Impl.Client.IgniteClient..ctor(IgniteClientConfiguration
> clientConfiguration)
> at Apache.Ignite.Core.Ignition.StartClient(IgniteClientConfiguration
> clientConfiguration)
> {code}
> Here's the constructor code:
> {code:c#}
> Debug.Assert(config != null);
> Debug.Assert(marsh != null);
> Debug.Assert(transactions != null);
> _config = config;
> _marsh = marsh;
> _transactions = transactions;
> #pragma warning disable 618 // Type or member is obsolete
> if (config.Host == null && (config.Endpoints == null ||
> config.Endpoints.Count == 0))
> {
> throw new IgniteClientException("Invalid
> IgniteClientConfiguration: Host is null, " +
> "Endpoints is null or empty.
> Nowhere to connect.");
> }
> #pragma warning restore 618
> _endPoints = GetIpEndPoints(config).ToList();
> if (_endPoints.Count == 0)
> {
> throw new IgniteClientException("Failed to resolve all
> specified hosts.");
> }
> _logger = (_config.Logger ??
> NoopLogger.Instance).GetLogger(GetType());
> ConnectDefaultSocket();
> OnFirstConnection();
> {code}
> Note how the _logger variable isn't set until the very end of the constructor.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15065) Add an explicit method to register binary type based on class
Taras Ledkov created IGNITE-15065:
-
Summary: Add an explicit method to register binary type based on
class
Key: IGNITE-15065
URL: https://issues.apache.org/jira/browse/IGNITE-15065
Project: Ignite
Issue Type: Bug
Components: binary
Reporter: Taras Ledkov
Assignee: Taras Ledkov
Fix For: 2.12
*My proposal is:*
- add new method to IgniteBinary interface
{{public BinaryType registerClass(Class cls) throws
BinaryObjectException;}}
- the implementation is simple: use {{BinaryContext#registerClass}} to register
user class and return registered metadata.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15064) Extended tests for extension to write CDC data to Kafka
[ https://issues.apache.org/jira/browse/IGNITE-15064?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-15064: - Description: Tests should be extended to cover REPLICATED vs. PARTITIONED caches. (was: The following things added: 1. CDC consumer to stream CDCEvent to kafka topic. 2. CDC consumer to stream CDCEvent to other Ignite cluster. 3. Kafka to Ignite application to read CDCEvent from kafka topic and apply them to Ignite cluster. 4. CacheVersionConflictResolver implementation(CacheVersionConflictResolverImpl) to resolve possible conflicts during streaming CDC events to other cluster.) > Extended tests for extension to write CDC data to Kafka > --- > > Key: IGNITE-15064 > URL: https://issues.apache.org/jira/browse/IGNITE-15064 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-59 > > Tests should be extended to cover REPLICATED vs. PARTITIONED caches. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15064) Extended tests for extension to write CDC data to Kafka
Nikolay Izhikov created IGNITE-15064: Summary: Extended tests for extension to write CDC data to Kafka Key: IGNITE-15064 URL: https://issues.apache.org/jira/browse/IGNITE-15064 Project: Ignite Issue Type: Improvement Reporter: Nikolay Izhikov Assignee: Nikolay Izhikov The following things added: 1. CDC consumer to stream CDCEvent to kafka topic. 2. CDC consumer to stream CDCEvent to other Ignite cluster. 3. Kafka to Ignite application to read CDCEvent from kafka topic and apply them to Ignite cluster. 4. CacheVersionConflictResolver implementation(CacheVersionConflictResolverImpl) to resolve possible conflicts during streaming CDC events to other cluster. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15063) Document system views obtaining through a control script.
[ https://issues.apache.org/jira/browse/IGNITE-15063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-15063: Ignite Flags: (was: Docs Required,Release Notes Required) > Document system views obtaining through a control script. > -- > > Key: IGNITE-15063 > URL: https://issues.apache.org/jira/browse/IGNITE-15063 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > It's needed to document system views obtaining through a control script. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15063) Document system views obtaining through a control script.
[ https://issues.apache.org/jira/browse/IGNITE-15063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov updated IGNITE-15063: Fix Version/s: 2.11 > Document system views obtaining through a control script. > -- > > Key: IGNITE-15063 > URL: https://issues.apache.org/jira/browse/IGNITE-15063 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Major > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > It's needed to document system views obtaining through a control script. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13667) Add schema columns relocation table to map from user order to system order
[
https://issues.apache.org/jira/browse/IGNITE-13667?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375706#comment-17375706
]
Konstantin Orlov commented on IGNITE-13667:
---
[~amashenkov], actually it _does_ guarantee the order.
[Here|https://stackoverflow.com/questions/11737232/column-order-in-select-statement-guaranteed]
is a good explanation with references to the SQL standard.
> Add schema columns relocation table to map from user order to system order
> --
>
> Key: IGNITE-13667
> URL: https://issues.apache.org/jira/browse/IGNITE-13667
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Goncharuk
>Priority: Minor
> Labels: iep-54, ignite-3
>
> When a schema is defined, the key chunk columns and value chunk columns are
> sorted so that fixlen columns go first and varlen columns go second, so the
> sorted column order differs from the order of the user-defined columns.
> We need to add a simple relocation table which is a permutation of indices
> {{[0..n)}}, so that an internal column order for user index {{n}} is
> {{relocationTbl[n]}}.
> NB: the tuple assembler will still need to access the internal sorted order
> for proper tuple assembly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14903) Calcite. Bump calcite version up to 1.27.0.
[ https://issues.apache.org/jira/browse/IGNITE-14903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-14903: -- Labels: calcite (was: calcite calcite3-required) > Calcite. Bump calcite version up to 1.27.0. > --- > > Key: IGNITE-14903 > URL: https://issues.apache.org/jira/browse/IGNITE-14903 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Labels: calcite > Time Spent: 50m > Remaining Estimate: 0h > > Update calcite ver up to 1.27.0. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14903) Calcite. Bump calcite version up to 1.27.0.
[ https://issues.apache.org/jira/browse/IGNITE-14903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375698#comment-17375698 ] Taras Ledkov commented on IGNITE-14903: --- Merged to [ignite-3|https://github.com/apache/ignite-3/commit/c5fb1665927dbba2ee3690d71ea430f07d4647e7] > Calcite. Bump calcite version up to 1.27.0. > --- > > Key: IGNITE-14903 > URL: https://issues.apache.org/jira/browse/IGNITE-14903 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Labels: calcite, calcite3-required > Time Spent: 50m > Remaining Estimate: 0h > > Update calcite ver up to 1.27.0. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15063) Document system views obtaining through a control script.
Mikhail Petrov created IGNITE-15063: --- Summary: Document system views obtaining through a control script. Key: IGNITE-15063 URL: https://issues.apache.org/jira/browse/IGNITE-15063 Project: Ignite Issue Type: Improvement Reporter: Mikhail Petrov Assignee: Mikhail Petrov It's needed to document system views obtaining through a control script. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14839) Migrate junit tests to jupiter in jraft package
[ https://issues.apache.org/jira/browse/IGNITE-14839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev reassigned IGNITE-14839: Assignee: Aleksandr Polovtcev > Migrate junit tests to jupiter in jraft package > --- > > Key: IGNITE-14839 > URL: https://issues.apache.org/jira/browse/IGNITE-14839 > Project: Ignite > Issue Type: Task >Reporter: Alexey Scherbakov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > > Currently jraft tests use vintage engine. > Replace it with junit5 and drop the vintage engine. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15044) Node work directory.
[
https://issues.apache.org/jira/browse/IGNITE-15044?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375660#comment-17375660
]
Aleksandr Polovtcev commented on IGNITE-15044:
--
# Added the {{@WorkDirectory}} annotation to mark paths to the work directory.
# Added the {{WorkDirectoryExtension}} to inject work directories into
annotated fields or parameters.
# Migrated the existing tests.
> Node work directory.
>
>
> Key: IGNITE-15044
> URL: https://issues.apache.org/jira/browse/IGNITE-15044
> Project: Ignite
> Issue Type: Improvement
> Components: persistence
>Reporter: Andrey Mashenkov
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Since Vault become persistent, tests create vault files in a module
> high-level directory.
> This directory is not ignored by git, which may lead to unwanted data in git
> repo,
> and maybe some other unexpected things.
> Let's
> * introduce a working directory for nodes where all node files will be stored.
> * add workdir to gitignore
> We can use Ignite-2 approach for now and improve later in a separate ticket
> if there are issues we want to resolve.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-14861) Live-schema. Detect new row version.
[ https://issues.apache.org/jira/browse/IGNITE-14861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ermakov reassigned IGNITE-14861: - Assignee: Vladimir Ermakov > Live-schema. Detect new row version. > > > Key: IGNITE-14861 > URL: https://issues.apache.org/jira/browse/IGNITE-14861 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Vladimir Ermakov >Priority: Major > Labels: iep-54, ignite-3 > Fix For: 3.0.0-alpha3 > > > Let's detect schema change and trigger registering a new schema version. > Valid changes are: > * adding a new column > * changing column type to a wider one. (e.g. int -> long) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14589) Calcite engine. Numerous problem with type Decimal
[
https://issues.apache.org/jira/browse/IGNITE-14589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-14589:
--
Labels: calcite3-required (was: calcite2-required calcite3-required)
> Calcite engine. Numerous problem with type Decimal
> --
>
> Key: IGNITE-14589
> URL: https://issues.apache.org/jira/browse/IGNITE-14589
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Vladimir Ermakov
>Priority: Major
> Labels: calcite3-required
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> There are numerous problem with a decimal types:
> * leading and trailing zeros are truncated when converting to string
> * casting to precise scale is not working( {{select cast('0.01' as
> decimal(10, 1)) * 10}} returns 0.1 instead of 0)
> Affected tests:
> {{src/test/sql/types/decimal}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14342) Extend Tuple interface with ordered field access.
[ https://issues.apache.org/jira/browse/IGNITE-14342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-14342: -- Priority: Major (was: Critical) > Extend Tuple interface with ordered field access. > - > > Key: IGNITE-14342 > URL: https://issues.apache.org/jira/browse/IGNITE-14342 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > > Let's extend Tuple interface by adding methods for indexed column access > (like JDBC resultset has). > It may need to expose more information about Tuple structure, such as > * column name -> column index > * all columns in the tuple (name + type (ColumnType)) > * length() > * value(int index) > * Iterable implementation > This may be useful for SQL\JDBC drivers and bulk operation where Tuples can > have the same structure and column order. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14903) Calcite. Bump calcite version up to 1.27.0.
[ https://issues.apache.org/jira/browse/IGNITE-14903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanilovsky Evgeny updated IGNITE-14903: Labels: calcite calcite3-required (was: calcite calcite2-required calcite3-required) > Calcite. Bump calcite version up to 1.27.0. > --- > > Key: IGNITE-14903 > URL: https://issues.apache.org/jira/browse/IGNITE-14903 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Labels: calcite, calcite3-required > Time Spent: 0.5h > Remaining Estimate: 0h > > Update calcite ver up to 1.27.0. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-13565) Potential further bugs with DurableBackgroundTasks.
[
https://issues.apache.org/jira/browse/IGNITE-13565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko resolved IGNITE-13565.
--
Resolution: Duplicate
Fixed in IGNITE-14684.
> Potential further bugs with DurableBackgroundTasks.
> ---
>
> Key: IGNITE-13565
> URL: https://issues.apache.org/jira/browse/IGNITE-13565
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.8.1
>Reporter: Stanilovsky Evgeny
>Assignee: Kirill Tkalenko
>Priority: Major
>
> After some code refactoring [1] we obtain a problem with simpe test:
> org.apache.ignite.internal.processors.cache.index.BasicIndexTest#testInlineSizeChange
> between
> {noformat}
> execSql(cache, "drop index \"idx1\"");
> {noformat}
> and
> {noformat}
> ig0 = startGrid(0);
> {noformat}
> operations, seems [2] will fix it, but problem could potentially happen again
> (check attached stacks). In few words already completed durable task not
> updated
> {noformat}
> DurableBackgroundTask#complete
> {noformat}
> status on metastore, thus after cluster running this task still can try to
> run once more with undefined behavior. [~Denis Chudov], [~makedonskaya] pay
> your attention plz.
> [1] https://issues.apache.org/jira/browse/IGNITE-13207
> [2] https://issues.apache.org/jira/browse/IGNITE-13500
> {noformat}
> 2020-10-09 11:42:41,982][INFO ][test-runner-#1%index.BasicIndexTest%][root]
> >>> Stopping grid [name=index.BasicIndexTest0,
> id=161e62a2-1a5d-46b0-892d-2e0274e0]
> [2020-10-09
> 11:42:41,999][ERROR][db-checkpoint-thread-#61%index.BasicIndexTest0%][root]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=StopNodeFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=CRITICAL_ERROR, err=class o.a.i.IgniteException: Failed to perform
> cache update: node is stopping.]]
> class org.apache.ignite.IgniteException: Failed to perform cache update: node
> is stopping.
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointTimeoutLock.checkpointReadLock(CheckpointTimeoutLock.java:125)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1297)
> at
> org.apache.ignite.internal.processors.localtask.DurableBackgroundTasksProcessor.removeDurableBackgroundTask(DurableBackgroundTasksProcessor.java:245)
> at
> org.apache.ignite.internal.processors.localtask.DurableBackgroundTasksProcessor.onMarkCheckpointBegin(DurableBackgroundTasksProcessor.java:277)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointWorkflow.markCheckpointBegin(CheckpointWorkflow.java:274)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.Checkpointer.doCheckpoint(Checkpointer.java:387)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.Checkpointer.body(Checkpointer.java:263)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> ...
> starting grid and ...
> java.lang.AssertionError: calculatedOffset=49152, allocated=45056,
> headerSize=4096,
> cfgFile=/work/repo/apache-ignite/work/db/index_BasicIndexTest0/cache-default/index.bin
> >>> +---+
> >>> Ignite ver. 2.10.0-SNAPSHOT#20201009-sha1:DEV
> >>> +---+
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:492)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:554)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:538)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:884)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:710)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:699)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:158)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.acquirePage(BPlusTree.java:6037)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2Tree.getMetaInfo(H2Tree.java:415)
> at
> org.apache.ignite.internal.processors.quer
[jira] [Closed] (IGNITE-13565) Potential further bugs with DurableBackgroundTasks.
[
https://issues.apache.org/jira/browse/IGNITE-13565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko closed IGNITE-13565.
Ignite Flags: (was: Docs Required,Release Notes Required)
> Potential further bugs with DurableBackgroundTasks.
> ---
>
> Key: IGNITE-13565
> URL: https://issues.apache.org/jira/browse/IGNITE-13565
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.8.1
>Reporter: Stanilovsky Evgeny
>Assignee: Kirill Tkalenko
>Priority: Major
>
> After some code refactoring [1] we obtain a problem with simpe test:
> org.apache.ignite.internal.processors.cache.index.BasicIndexTest#testInlineSizeChange
> between
> {noformat}
> execSql(cache, "drop index \"idx1\"");
> {noformat}
> and
> {noformat}
> ig0 = startGrid(0);
> {noformat}
> operations, seems [2] will fix it, but problem could potentially happen again
> (check attached stacks). In few words already completed durable task not
> updated
> {noformat}
> DurableBackgroundTask#complete
> {noformat}
> status on metastore, thus after cluster running this task still can try to
> run once more with undefined behavior. [~Denis Chudov], [~makedonskaya] pay
> your attention plz.
> [1] https://issues.apache.org/jira/browse/IGNITE-13207
> [2] https://issues.apache.org/jira/browse/IGNITE-13500
> {noformat}
> 2020-10-09 11:42:41,982][INFO ][test-runner-#1%index.BasicIndexTest%][root]
> >>> Stopping grid [name=index.BasicIndexTest0,
> id=161e62a2-1a5d-46b0-892d-2e0274e0]
> [2020-10-09
> 11:42:41,999][ERROR][db-checkpoint-thread-#61%index.BasicIndexTest0%][root]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=StopNodeFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=CRITICAL_ERROR, err=class o.a.i.IgniteException: Failed to perform
> cache update: node is stopping.]]
> class org.apache.ignite.IgniteException: Failed to perform cache update: node
> is stopping.
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointTimeoutLock.checkpointReadLock(CheckpointTimeoutLock.java:125)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1297)
> at
> org.apache.ignite.internal.processors.localtask.DurableBackgroundTasksProcessor.removeDurableBackgroundTask(DurableBackgroundTasksProcessor.java:245)
> at
> org.apache.ignite.internal.processors.localtask.DurableBackgroundTasksProcessor.onMarkCheckpointBegin(DurableBackgroundTasksProcessor.java:277)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointWorkflow.markCheckpointBegin(CheckpointWorkflow.java:274)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.Checkpointer.doCheckpoint(Checkpointer.java:387)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.Checkpointer.body(Checkpointer.java:263)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> ...
> starting grid and ...
> java.lang.AssertionError: calculatedOffset=49152, allocated=45056,
> headerSize=4096,
> cfgFile=/work/repo/apache-ignite/work/db/index_BasicIndexTest0/cache-default/index.bin
> >>> +---+
> >>> Ignite ver. 2.10.0-SNAPSHOT#20201009-sha1:DEV
> >>> +---+
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:492)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:554)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:538)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:884)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:710)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:699)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:158)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.acquirePage(BPlusTree.java:6037)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2Tree.getMetaInfo(H2Tree.java:415)
> at
> org.apache.ignite.internal.proce
[jira] [Assigned] (IGNITE-13565) Potential further bugs with DurableBackgroundTasks.
[
https://issues.apache.org/jira/browse/IGNITE-13565?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko reassigned IGNITE-13565:
Assignee: Kirill Tkalenko (was: Maria Makedonskaya)
> Potential further bugs with DurableBackgroundTasks.
> ---
>
> Key: IGNITE-13565
> URL: https://issues.apache.org/jira/browse/IGNITE-13565
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.8.1
>Reporter: Stanilovsky Evgeny
>Assignee: Kirill Tkalenko
>Priority: Major
>
> After some code refactoring [1] we obtain a problem with simpe test:
> org.apache.ignite.internal.processors.cache.index.BasicIndexTest#testInlineSizeChange
> between
> {noformat}
> execSql(cache, "drop index \"idx1\"");
> {noformat}
> and
> {noformat}
> ig0 = startGrid(0);
> {noformat}
> operations, seems [2] will fix it, but problem could potentially happen again
> (check attached stacks). In few words already completed durable task not
> updated
> {noformat}
> DurableBackgroundTask#complete
> {noformat}
> status on metastore, thus after cluster running this task still can try to
> run once more with undefined behavior. [~Denis Chudov], [~makedonskaya] pay
> your attention plz.
> [1] https://issues.apache.org/jira/browse/IGNITE-13207
> [2] https://issues.apache.org/jira/browse/IGNITE-13500
> {noformat}
> 2020-10-09 11:42:41,982][INFO ][test-runner-#1%index.BasicIndexTest%][root]
> >>> Stopping grid [name=index.BasicIndexTest0,
> id=161e62a2-1a5d-46b0-892d-2e0274e0]
> [2020-10-09
> 11:42:41,999][ERROR][db-checkpoint-thread-#61%index.BasicIndexTest0%][root]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=StopNodeFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=CRITICAL_ERROR, err=class o.a.i.IgniteException: Failed to perform
> cache update: node is stopping.]]
> class org.apache.ignite.IgniteException: Failed to perform cache update: node
> is stopping.
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointTimeoutLock.checkpointReadLock(CheckpointTimeoutLock.java:125)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1297)
> at
> org.apache.ignite.internal.processors.localtask.DurableBackgroundTasksProcessor.removeDurableBackgroundTask(DurableBackgroundTasksProcessor.java:245)
> at
> org.apache.ignite.internal.processors.localtask.DurableBackgroundTasksProcessor.onMarkCheckpointBegin(DurableBackgroundTasksProcessor.java:277)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.CheckpointWorkflow.markCheckpointBegin(CheckpointWorkflow.java:274)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.Checkpointer.doCheckpoint(Checkpointer.java:387)
> at
> org.apache.ignite.internal.processors.cache.persistence.checkpoint.Checkpointer.body(Checkpointer.java:263)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> ...
> starting grid and ...
> java.lang.AssertionError: calculatedOffset=49152, allocated=45056,
> headerSize=4096,
> cfgFile=/work/repo/apache-ignite/work/db/index_BasicIndexTest0/cache-default/index.bin
> >>> +---+
> >>> Ignite ver. 2.10.0-SNAPSHOT#20201009-sha1:DEV
> >>> +---+
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStore.read(FilePageStore.java:492)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:554)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:538)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:884)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:710)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:699)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:158)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.acquirePage(BPlusTree.java:6037)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2Tree.getMetaInfo(H2Tree.java:415)
> at
> org.apache.ignite.internal.pro
[jira] [Comment Edited] (IGNITE-14556) Live Schema. Add Tuple validation.
[ https://issues.apache.org/jira/browse/IGNITE-14556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17322239#comment-17322239 ] Andrey Mashenkov edited comment on IGNITE-14556 at 7/6/21, 9:53 AM: Do we need an option to relax these checks for STRICT mode? and allow arbitrary fields in the Tuple, but ignore non-relevant while building a Row? Maybe this could be a default option? If so, we only need this validation for LIVE-schema to detect schema upgrades. was (Author: amashenkov): Do we need an option to relax these checks for STRICT mode? and allow to pass any fields within the Tuple, but ignore non-relevant while building a Row? Maybe this could be a default option? If so, we only need this validation for LIVE-schema to detect schema upgrade. > Live Schema. Add Tuple validation. > -- > > Key: IGNITE-14556 > URL: https://issues.apache.org/jira/browse/IGNITE-14556 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Priority: Major > Labels: iep-54, ignite-3 > Fix For: 3.0.0-alpha3 > > Original Estimate: 48h > Remaining Estimate: 48h > > h3. Motivation. > At a point of Table public method is called by a user, we need to validate > user input (for LIVE-schema purposes at least). > h3. Description. > We can add this logic to check if value fields match the current schema > version (no new fields). > * For LIVE-Schema. If Tuple has one or more additional columns, then we > should try to register a new schema first, then proceed with the user > operation. > * For STRICT-Schema. If Tuple has one or more additional columns, then we > should fail the user operation. > * For KeyValueView, we should validate key Tuple as well, and fail if there > are unknown columns. Because a key column span is immutable. The only > exception may be if a user creates a schemaless table, then a schema of the > 1-st version should be registered instantly. > Assumed, any column type mismatch or missed Non-Nullable columns will be > caught and processed by RowAssembler. > h4. Possible optimization. > It is possible to add the validation into a TupleBuilder and then just check > the Tuple instance class (should be a builder). > For any Tuple of unknown type or if a schema was changed concurrently > (TupleBuilder validated input against outdated schema version), then fallback > to default logic and re-validate input against the latest schema. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15062) Add events for snapshot restore operation state
[ https://issues.apache.org/jira/browse/IGNITE-15062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-15062: -- Description: The snapshot restore operation states must be exposed to the user by firing Ignite events: * snapshot operation restore started * snapshot operation restore finished * snapshot operation restore failed was: The snapshot restore operation states must be exposed to the user by firing Ignite events: snapshot operation restore started snapshot operation restore finished snapshot operation restore failed > Add events for snapshot restore operation state > --- > > Key: IGNITE-15062 > URL: https://issues.apache.org/jira/browse/IGNITE-15062 > Project: Ignite > Issue Type: Task >Reporter: Pavel Pereslegin >Priority: Major > Labels: iep-43 > > The snapshot restore operation states must be exposed to the user by firing > Ignite events: > * snapshot operation restore started > * snapshot operation restore finished > * snapshot operation restore failed -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15062) Add events for snapshot restore operation state
Pavel Pereslegin created IGNITE-15062: - Summary: Add events for snapshot restore operation state Key: IGNITE-15062 URL: https://issues.apache.org/jira/browse/IGNITE-15062 Project: Ignite Issue Type: Task Reporter: Pavel Pereslegin The snapshot restore operation states must be exposed to the user by firing Ignite events: snapshot operation restore started snapshot operation restore finished snapshot operation restore failed -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15062) Add events for snapshot restore operation state
[ https://issues.apache.org/jira/browse/IGNITE-15062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-15062: -- Labels: iep-43 (was: ) > Add events for snapshot restore operation state > --- > > Key: IGNITE-15062 > URL: https://issues.apache.org/jira/browse/IGNITE-15062 > Project: Ignite > Issue Type: Task >Reporter: Pavel Pereslegin >Priority: Major > Labels: iep-43 > > The snapshot restore operation states must be exposed to the user by firing > Ignite events: > snapshot operation restore started > snapshot operation restore finished > snapshot operation restore failed -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15061) Update version in ignite-2.11 release branch
Alexey Gidaspov created IGNITE-15061: Summary: Update version in ignite-2.11 release branch Key: IGNITE-15061 URL: https://issues.apache.org/jira/browse/IGNITE-15061 Project: Ignite Issue Type: Task Reporter: Alexey Gidaspov Update version in ignite-2.11 release branch -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15060) ignitecli must provide work directory path during node start
Kirill Gusakov created IGNITE-15060: --- Summary: ignitecli must provide work directory path during node start Key: IGNITE-15060 URL: https://issues.apache.org/jira/browse/IGNITE-15060 Project: Ignite Issue Type: Task Reporter: Kirill Gusakov Assignee: Kirill Gusakov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14748) Ordered @NamedConfigValue
[
https://issues.apache.org/jira/browse/IGNITE-14748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov reassigned IGNITE-14748:
--
Assignee: Ivan Bessonov
> Ordered @NamedConfigValue
> -
>
> Key: IGNITE-14748
> URL: https://issues.apache.org/jira/browse/IGNITE-14748
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Alexander Belyak
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: iep-55
>
> Implement some order for @NamedConfigValue fields.
> Imagine that we have some
>
> {code:java}
> @Config
> public class PKIndexConfigurationSchema {
> @Value
> String type;
> @NamedConfigValue
> IndexColumnConfigurationSchema columns.
>
> {code}
> and
>
> {code:java}
> @Config
> public class IndexColumnConfigurationSchema {
> @Value
> String name;
> @Value
> boolean asc;
> @Value
> boolean affinityCol;
> }
> {code}
>
> For now we have to use indexes to store such config like:
>
> {noformat}
> "PK":
> "type":"PrimaryKey",
> "columns": {
> "0": {
> "name":"REGION",
> "asc":true,
> "affinity":true
> },
> "1": {
> "name":"COMPANY",
> "asc":true,
> "affinity":false
> }
> }
> {noformat}
>
> because we have to keep it's order.
> But if configuration keep order for @NamedConfigValue it can look like:
>
> {noformat}
> "PK":
> "type":"PrimaryKey",
> "columns": {
> "REGION": {
> "asc":true,
> "affinity":true
> },
> "COMPANY": {
> "asc":true,
> "affinity":false
> }
> }
> {noformat}
> And to allow insert value in the middle it will be nice to have some methods
> like:
> * listChange.create(idx, key, consumer(elementChange))
> or
> * listChange.createAfter(prevKeyOrNull, key, consumer(elementChange))
> in addition to existing:
> * listChange.create(key, consumer(elementChange))
> * listChange.update(key, consumer(elementChange))
> * listChange.delete(key)
> BTW, lets remove listChange.update method.
> h3. Implementation notes
> It would make sense to store order number inside of named list entry. It
> would look like implicit configuration parameter {{}}, for example. This
> value will be recalculated on every update.
> Index will be stored in named list itself, entries will not contain it.
> Reason is simple - named list entries can be used as regular "inner" nodes
> and we can't distinguish one from the another. That's why index is implicit.
> h3. API notes
> I don't get why we need to remove update method. It would be helpful to
> update their semantics, like "create" would throw "AlreadyExistsException" or
> something, update would do similar thing with "KeyNotFound"...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15059) Update Apache Ignite 2.11 release notes
Alexey Gidaspov created IGNITE-15059: Summary: Update Apache Ignite 2.11 release notes Key: IGNITE-15059 URL: https://issues.apache.org/jira/browse/IGNITE-15059 Project: Ignite Issue Type: Task Reporter: Alexey Gidaspov Assignee: Alexey Gidaspov Fix For: 2.11 Need to update Apache Ignite 2.11 release notes -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-14695) .NET: communication problems between Apache Ignite server in Azure Kubernetes and thin clients in Azure Web Apps
[
https://issues.apache.org/jira/browse/IGNITE-14695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn resolved IGNITE-14695.
-
Assignee: Pavel Tupitsyn
Resolution: Not A Bug
> .NET: communication problems between Apache Ignite server in Azure Kubernetes
> and thin clients in Azure Web Apps
>
>
> Key: IGNITE-14695
> URL: https://issues.apache.org/jira/browse/IGNITE-14695
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.10
> Environment: Apache Ignite: v2.10.0
> JDK: v1.8
> .NET Core: v3.1
>Reporter: Danut Radoaica
>Assignee: Pavel Tupitsyn
>Priority: Major
>
> If the Apache Ignite server and thin clients are in Azure Kubernetes there
> are no problems.
> If the Apache Ignite server is in Azure Kubernetes and the thin clients are
> in Azure Web Apps (same subscription) we always receive this error:
> { "Depth": 0, "ClassName": "System.IO.IOException", "Message": "Unable to
> read data from the transport connection: A connection attempt failed because
> the connected party did not properly respond after a period of time, or
> established connection failed because connected host has failed to
> respond..", "Source": "System.Net.Sockets", "StackTraceString": " at
> System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32
> size)\r\n at
> System.Net.Security.SslStream.FillBufferAsync[TReadAdapter](TReadAdapter
> adapter, Int32 minSize)\r\n at
> System.Net.Security.SslStream.ReadAsyncInternal[TReadAdapter](TReadAdapter
> adapter, Memory`1 buffer)\r\n at System.Net.Security.SslStream.Read(Byte[]
> buffer, Int32 offset, Int32 count)\r\n at
> Apache.Ignite.Core.Impl.Client.ClientSocket.SocketRead(Byte[] buf, Int32 pos,
> Int32 len)\r\n at
> Apache.Ignite.Core.Impl.Client.ClientSocket.ReceiveBytes(Int32 size)\r\n at
> Apache.Ignite.Core.Impl.Client.ClientSocket.ReceiveMessage()\r\n at
> Apache.Ignite.Core.Impl.Client.ClientSocket.SendRequest(RequestMessage&
> reqMsg)\r\n at
> Apache.Ignite.Core.Impl.Client.ClientSocket.DoOutInOp[T](ClientOp opId,
> Action`1 writeAction, Func`2 readFunc, Func`3 errorFunc)\r\n at
> Apache.Ignite.Core.Impl.Client.IgniteClient.GetOrCreateCache[TK,TV](CacheClientConfiguration
> configuration)\r\n at
> Druid.Ignite.CacheFactory.GetOrCreateCacheClient[TKey,TData](IIgniteClient
> ignite, String cacheName, Action`1 extendConfigurationAction)\r\n at
> Druid.Endpoints.Common.Utils.IgniteManager.GetOrCreateCacheClient[TKey,TData](String
> cacheName, Action`1 extendConfigurationAction) in
> /bigvol/azure.agents/bmagent03/_work/18/s/Druid.Endpoints.Common/Utils/IgniteManager.cs:line
> 28\r\n at
> Druid.Endpoints.Controllers.UiPathController.EventsJobCompleted(Nullable`1
> paramBotId) in
> /bigvol/azure.agents/bmagent03/_work/18/s/Druid.Endpoints/Controllers/UiPathController.cs:line
> 374", "RemoteStackTraceString": null, "RemoteStackIndex": 0, "HResult":
> -2146232800, "HelpURL": null }, \{ "Depth": 1, "ClassName":
> "System.Net.Sockets.SocketException", "Message": "A connection attempt failed
> because the connected party did not properly respond after a period of time,
> or established connection failed because connected host has failed to
> respond.", "Source": "System.Net.Sockets", "StackTraceString": " at
> System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size,
> SocketFlags socketFlags)\r\n at System.Net.Sockets.NetworkStream.Read(Byte[]
> buffer, Int32 offset, Int32 size)", "RemoteStackTraceString": null,
> "RemoteStackIndex": 0, "HResult": -2147467259, "HelpURL": null }
>
> Apache Ignite server: [https://github.com/dradoaica/AspNetCore.Ignite]
> P.S.: is exposed from Kubernetes via:
> apiVersion: v1
> kind: Service
> metadata:
> name: aspnetcoreignite-load-balancer-service
> namespace: develop
> annotations:
> external-dns.alpha.kubernetes.io/hostname:
> ignite.develop.aspnetcoreplatform.com
> spec:
> selector:
> app: aspnetcoreignite
> ports:
> - name: jdbc
> protocol: TCP
> port: 11211
> targetPort: jdbc
> - name: comm-spi
> protocol: TCP
> port: 47100
> targetPort: comm-spi
> - name: disc-spi
> protocol: TCP
> port: 47500
> targetPort: disc-spi
> - name: jmx
> protocol: TCP
> port: 49112
> targetPort: jmx
> - name: sql
> protocol: TCP
> port: 10800
> targetPort: sql
> - name: rest-api
> protocol: TCP
> port: 8080
> targetPort: rest-api
> - name: thin-client
> protocol: TCP
> port: 10900
> targetPort: thin-client
> externalTrafficPolicy: Local
> type: LoadBalancer
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14695) .NET: communication problems between Apache Ignite server in Azure Kubernetes and thin clients in Azure Web Apps
[
https://issues.apache.org/jira/browse/IGNITE-14695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375328#comment-17375328
]
Pavel Tupitsyn commented on IGNITE-14695:
-
[~dradoaica] since it works within k8s and does not work from outside, this is
an Azure configuration issue.
> .NET: communication problems between Apache Ignite server in Azure Kubernetes
> and thin clients in Azure Web Apps
>
>
> Key: IGNITE-14695
> URL: https://issues.apache.org/jira/browse/IGNITE-14695
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.10
> Environment: Apache Ignite: v2.10.0
> JDK: v1.8
> .NET Core: v3.1
>Reporter: Danut Radoaica
>Priority: Major
>
> If the Apache Ignite server and thin clients are in Azure Kubernetes there
> are no problems.
> If the Apache Ignite server is in Azure Kubernetes and the thin clients are
> in Azure Web Apps (same subscription) we always receive this error:
> { "Depth": 0, "ClassName": "System.IO.IOException", "Message": "Unable to
> read data from the transport connection: A connection attempt failed because
> the connected party did not properly respond after a period of time, or
> established connection failed because connected host has failed to
> respond..", "Source": "System.Net.Sockets", "StackTraceString": " at
> System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32
> size)\r\n at
> System.Net.Security.SslStream.FillBufferAsync[TReadAdapter](TReadAdapter
> adapter, Int32 minSize)\r\n at
> System.Net.Security.SslStream.ReadAsyncInternal[TReadAdapter](TReadAdapter
> adapter, Memory`1 buffer)\r\n at System.Net.Security.SslStream.Read(Byte[]
> buffer, Int32 offset, Int32 count)\r\n at
> Apache.Ignite.Core.Impl.Client.ClientSocket.SocketRead(Byte[] buf, Int32 pos,
> Int32 len)\r\n at
> Apache.Ignite.Core.Impl.Client.ClientSocket.ReceiveBytes(Int32 size)\r\n at
> Apache.Ignite.Core.Impl.Client.ClientSocket.ReceiveMessage()\r\n at
> Apache.Ignite.Core.Impl.Client.ClientSocket.SendRequest(RequestMessage&
> reqMsg)\r\n at
> Apache.Ignite.Core.Impl.Client.ClientSocket.DoOutInOp[T](ClientOp opId,
> Action`1 writeAction, Func`2 readFunc, Func`3 errorFunc)\r\n at
> Apache.Ignite.Core.Impl.Client.IgniteClient.GetOrCreateCache[TK,TV](CacheClientConfiguration
> configuration)\r\n at
> Druid.Ignite.CacheFactory.GetOrCreateCacheClient[TKey,TData](IIgniteClient
> ignite, String cacheName, Action`1 extendConfigurationAction)\r\n at
> Druid.Endpoints.Common.Utils.IgniteManager.GetOrCreateCacheClient[TKey,TData](String
> cacheName, Action`1 extendConfigurationAction) in
> /bigvol/azure.agents/bmagent03/_work/18/s/Druid.Endpoints.Common/Utils/IgniteManager.cs:line
> 28\r\n at
> Druid.Endpoints.Controllers.UiPathController.EventsJobCompleted(Nullable`1
> paramBotId) in
> /bigvol/azure.agents/bmagent03/_work/18/s/Druid.Endpoints/Controllers/UiPathController.cs:line
> 374", "RemoteStackTraceString": null, "RemoteStackIndex": 0, "HResult":
> -2146232800, "HelpURL": null }, \{ "Depth": 1, "ClassName":
> "System.Net.Sockets.SocketException", "Message": "A connection attempt failed
> because the connected party did not properly respond after a period of time,
> or established connection failed because connected host has failed to
> respond.", "Source": "System.Net.Sockets", "StackTraceString": " at
> System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size,
> SocketFlags socketFlags)\r\n at System.Net.Sockets.NetworkStream.Read(Byte[]
> buffer, Int32 offset, Int32 size)", "RemoteStackTraceString": null,
> "RemoteStackIndex": 0, "HResult": -2147467259, "HelpURL": null }
>
> Apache Ignite server: [https://github.com/dradoaica/AspNetCore.Ignite]
> P.S.: is exposed from Kubernetes via:
> apiVersion: v1
> kind: Service
> metadata:
> name: aspnetcoreignite-load-balancer-service
> namespace: develop
> annotations:
> external-dns.alpha.kubernetes.io/hostname:
> ignite.develop.aspnetcoreplatform.com
> spec:
> selector:
> app: aspnetcoreignite
> ports:
> - name: jdbc
> protocol: TCP
> port: 11211
> targetPort: jdbc
> - name: comm-spi
> protocol: TCP
> port: 47100
> targetPort: comm-spi
> - name: disc-spi
> protocol: TCP
> port: 47500
> targetPort: disc-spi
> - name: jmx
> protocol: TCP
> port: 49112
> targetPort: jmx
> - name: sql
> protocol: TCP
> port: 10800
> targetPort: sql
> - name: rest-api
> protocol: TCP
> port: 8080
> targetPort: rest-api
> - name: thin-client
> protocol: TCP
> port: 10900
> targetPort: thin-client
> externalTrafficPolicy: Local
> type: LoadBalancer
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14695) .NET: communication problems between Apache Ignite server in Azure Kubernetes and thin clients in Azure Web Apps
[
https://issues.apache.org/jira/browse/IGNITE-14695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375324#comment-17375324
]
Danut Radoaica commented on IGNITE-14695:
-
[~ptupitsyn] We did not manage to resolve it or to find the source of this
behaviour. I did not foud a related Jira ticket and I opened this ticket hoping
that somebody encountered it
> .NET: communication problems between Apache Ignite server in Azure Kubernetes
> and thin clients in Azure Web Apps
>
>
> Key: IGNITE-14695
> URL: https://issues.apache.org/jira/browse/IGNITE-14695
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.10
> Environment: Apache Ignite: v2.10.0
> JDK: v1.8
> .NET Core: v3.1
>Reporter: Danut Radoaica
>Priority: Major
>
> If the Apache Ignite server and thin clients are in Azure Kubernetes there
> are no problems.
> If the Apache Ignite server is in Azure Kubernetes and the thin clients are
> in Azure Web Apps (same subscription) we always receive this error:
> { "Depth": 0, "ClassName": "System.IO.IOException", "Message": "Unable to
> read data from the transport connection: A connection attempt failed because
> the connected party did not properly respond after a period of time, or
> established connection failed because connected host has failed to
> respond..", "Source": "System.Net.Sockets", "StackTraceString": " at
> System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32
> size)\r\n at
> System.Net.Security.SslStream.FillBufferAsync[TReadAdapter](TReadAdapter
> adapter, Int32 minSize)\r\n at
> System.Net.Security.SslStream.ReadAsyncInternal[TReadAdapter](TReadAdapter
> adapter, Memory`1 buffer)\r\n at System.Net.Security.SslStream.Read(Byte[]
> buffer, Int32 offset, Int32 count)\r\n at
> Apache.Ignite.Core.Impl.Client.ClientSocket.SocketRead(Byte[] buf, Int32 pos,
> Int32 len)\r\n at
> Apache.Ignite.Core.Impl.Client.ClientSocket.ReceiveBytes(Int32 size)\r\n at
> Apache.Ignite.Core.Impl.Client.ClientSocket.ReceiveMessage()\r\n at
> Apache.Ignite.Core.Impl.Client.ClientSocket.SendRequest(RequestMessage&
> reqMsg)\r\n at
> Apache.Ignite.Core.Impl.Client.ClientSocket.DoOutInOp[T](ClientOp opId,
> Action`1 writeAction, Func`2 readFunc, Func`3 errorFunc)\r\n at
> Apache.Ignite.Core.Impl.Client.IgniteClient.GetOrCreateCache[TK,TV](CacheClientConfiguration
> configuration)\r\n at
> Druid.Ignite.CacheFactory.GetOrCreateCacheClient[TKey,TData](IIgniteClient
> ignite, String cacheName, Action`1 extendConfigurationAction)\r\n at
> Druid.Endpoints.Common.Utils.IgniteManager.GetOrCreateCacheClient[TKey,TData](String
> cacheName, Action`1 extendConfigurationAction) in
> /bigvol/azure.agents/bmagent03/_work/18/s/Druid.Endpoints.Common/Utils/IgniteManager.cs:line
> 28\r\n at
> Druid.Endpoints.Controllers.UiPathController.EventsJobCompleted(Nullable`1
> paramBotId) in
> /bigvol/azure.agents/bmagent03/_work/18/s/Druid.Endpoints/Controllers/UiPathController.cs:line
> 374", "RemoteStackTraceString": null, "RemoteStackIndex": 0, "HResult":
> -2146232800, "HelpURL": null }, \{ "Depth": 1, "ClassName":
> "System.Net.Sockets.SocketException", "Message": "A connection attempt failed
> because the connected party did not properly respond after a period of time,
> or established connection failed because connected host has failed to
> respond.", "Source": "System.Net.Sockets", "StackTraceString": " at
> System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size,
> SocketFlags socketFlags)\r\n at System.Net.Sockets.NetworkStream.Read(Byte[]
> buffer, Int32 offset, Int32 size)", "RemoteStackTraceString": null,
> "RemoteStackIndex": 0, "HResult": -2147467259, "HelpURL": null }
>
> Apache Ignite server: [https://github.com/dradoaica/AspNetCore.Ignite]
> P.S.: is exposed from Kubernetes via:
> apiVersion: v1
> kind: Service
> metadata:
> name: aspnetcoreignite-load-balancer-service
> namespace: develop
> annotations:
> external-dns.alpha.kubernetes.io/hostname:
> ignite.develop.aspnetcoreplatform.com
> spec:
> selector:
> app: aspnetcoreignite
> ports:
> - name: jdbc
> protocol: TCP
> port: 11211
> targetPort: jdbc
> - name: comm-spi
> protocol: TCP
> port: 47100
> targetPort: comm-spi
> - name: disc-spi
> protocol: TCP
> port: 47500
> targetPort: disc-spi
> - name: jmx
> protocol: TCP
> port: 49112
> targetPort: jmx
> - name: sql
> protocol: TCP
> port: 10800
> targetPort: sql
> - name: rest-api
> protocol: TCP
> port: 8080
> targetPort: rest-api
> - name: thin-client
> protocol: TCP
> port: 10900
> targetPort: thin-client
> externalTrafficPolicy: Local
> type: LoadBalancer
--
This message was
[jira] [Comment Edited] (IGNITE-14695) .NET: communication problems between Apache Ignite server in Azure Kubernetes and thin clients in Azure Web Apps
[
https://issues.apache.org/jira/browse/IGNITE-14695?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17375324#comment-17375324
]
Danut Radoaica edited comment on IGNITE-14695 at 7/6/21, 7:34 AM:
--
[~ptupitsyn] We did not manage to resolve it or to find the source of this
behaviour. I did not found a related Jira ticket and I opened this ticket
hoping that somebody encountered it
was (Author: dradoaica):
[~ptupitsyn] We did not manage to resolve it or to find the source of this
behaviour. I did not foud a related Jira ticket and I opened this ticket hoping
that somebody encountered it
> .NET: communication problems between Apache Ignite server in Azure Kubernetes
> and thin clients in Azure Web Apps
>
>
> Key: IGNITE-14695
> URL: https://issues.apache.org/jira/browse/IGNITE-14695
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.10
> Environment: Apache Ignite: v2.10.0
> JDK: v1.8
> .NET Core: v3.1
>Reporter: Danut Radoaica
>Priority: Major
>
> If the Apache Ignite server and thin clients are in Azure Kubernetes there
> are no problems.
> If the Apache Ignite server is in Azure Kubernetes and the thin clients are
> in Azure Web Apps (same subscription) we always receive this error:
> { "Depth": 0, "ClassName": "System.IO.IOException", "Message": "Unable to
> read data from the transport connection: A connection attempt failed because
> the connected party did not properly respond after a period of time, or
> established connection failed because connected host has failed to
> respond..", "Source": "System.Net.Sockets", "StackTraceString": " at
> System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32
> size)\r\n at
> System.Net.Security.SslStream.FillBufferAsync[TReadAdapter](TReadAdapter
> adapter, Int32 minSize)\r\n at
> System.Net.Security.SslStream.ReadAsyncInternal[TReadAdapter](TReadAdapter
> adapter, Memory`1 buffer)\r\n at System.Net.Security.SslStream.Read(Byte[]
> buffer, Int32 offset, Int32 count)\r\n at
> Apache.Ignite.Core.Impl.Client.ClientSocket.SocketRead(Byte[] buf, Int32 pos,
> Int32 len)\r\n at
> Apache.Ignite.Core.Impl.Client.ClientSocket.ReceiveBytes(Int32 size)\r\n at
> Apache.Ignite.Core.Impl.Client.ClientSocket.ReceiveMessage()\r\n at
> Apache.Ignite.Core.Impl.Client.ClientSocket.SendRequest(RequestMessage&
> reqMsg)\r\n at
> Apache.Ignite.Core.Impl.Client.ClientSocket.DoOutInOp[T](ClientOp opId,
> Action`1 writeAction, Func`2 readFunc, Func`3 errorFunc)\r\n at
> Apache.Ignite.Core.Impl.Client.IgniteClient.GetOrCreateCache[TK,TV](CacheClientConfiguration
> configuration)\r\n at
> Druid.Ignite.CacheFactory.GetOrCreateCacheClient[TKey,TData](IIgniteClient
> ignite, String cacheName, Action`1 extendConfigurationAction)\r\n at
> Druid.Endpoints.Common.Utils.IgniteManager.GetOrCreateCacheClient[TKey,TData](String
> cacheName, Action`1 extendConfigurationAction) in
> /bigvol/azure.agents/bmagent03/_work/18/s/Druid.Endpoints.Common/Utils/IgniteManager.cs:line
> 28\r\n at
> Druid.Endpoints.Controllers.UiPathController.EventsJobCompleted(Nullable`1
> paramBotId) in
> /bigvol/azure.agents/bmagent03/_work/18/s/Druid.Endpoints/Controllers/UiPathController.cs:line
> 374", "RemoteStackTraceString": null, "RemoteStackIndex": 0, "HResult":
> -2146232800, "HelpURL": null }, \{ "Depth": 1, "ClassName":
> "System.Net.Sockets.SocketException", "Message": "A connection attempt failed
> because the connected party did not properly respond after a period of time,
> or established connection failed because connected host has failed to
> respond.", "Source": "System.Net.Sockets", "StackTraceString": " at
> System.Net.Sockets.Socket.Receive(Byte[] buffer, Int32 offset, Int32 size,
> SocketFlags socketFlags)\r\n at System.Net.Sockets.NetworkStream.Read(Byte[]
> buffer, Int32 offset, Int32 size)", "RemoteStackTraceString": null,
> "RemoteStackIndex": 0, "HResult": -2147467259, "HelpURL": null }
>
> Apache Ignite server: [https://github.com/dradoaica/AspNetCore.Ignite]
> P.S.: is exposed from Kubernetes via:
> apiVersion: v1
> kind: Service
> metadata:
> name: aspnetcoreignite-load-balancer-service
> namespace: develop
> annotations:
> external-dns.alpha.kubernetes.io/hostname:
> ignite.develop.aspnetcoreplatform.com
> spec:
> selector:
> app: aspnetcoreignite
> ports:
> - name: jdbc
> protocol: TCP
> port: 11211
> targetPort: jdbc
> - name: comm-spi
> protocol: TCP
> port: 47100
> targetPort: comm-spi
> - name: disc-spi
> protocol: TCP
> port: 47500
> targetPort: disc-spi
> - name: jmx
> protocol: TCP
> port: 49112
> targetPort: jmx
> - name: sql
> protocol: TCP
> p
