[jira] [Commented] (IGNITE-14010) Ignite-extensions: KafkaIgniteSteamerSelfTest is flaky
[
https://issues.apache.org/jira/browse/IGNITE-14010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17275375#comment-17275375
]
Mikhail Petrov commented on IGNITE-14010:
-
[~NSAmelchev], Thanks a lot for the review!
> Ignite-extensions: KafkaIgniteSteamerSelfTest is flaky
> --
>
> Key: IGNITE-14010
> URL: https://issues.apache.org/jira/browse/IGNITE-14010
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
>
> KafkaIgniteSteamerSelfTest test is flaky - [TC
> build|https://ci.ignite.apache.org/test/4285346063968224069?currentProjectId=IgniteExtensions_Tests=IgniteExtensions_Tests_Build=].
> It fails with the following error:
> {code:java}
> java.lang.AssertionError: Failed to wait latch completion, still wait 100
> events at
> org.apache.ignite.stream.kafka.KafkaIgniteStreamerSelfTest.consumerStream(KafkaIgniteStreamerSelfTest.java:242)
> at
> org.apache.ignite.stream.kafka.KafkaIgniteStreamerSelfTest.testKafkaStreamer(KafkaIgniteStreamerSelfTest.java:113)
> {code}
> This needs to be fixed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14010) Ignite-extensions: KafkaIgniteSteamerSelfTest is flaky
[
https://issues.apache.org/jira/browse/IGNITE-14010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17275372#comment-17275372
]
Amelchev Nikita commented on IGNITE-14010:
--
Merged to the master.
[~PetrovMikhail] Thanks for the contribution!
> Ignite-extensions: KafkaIgniteSteamerSelfTest is flaky
> --
>
> Key: IGNITE-14010
> URL: https://issues.apache.org/jira/browse/IGNITE-14010
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
>
> KafkaIgniteSteamerSelfTest test is flaky - [TC
> build|https://ci.ignite.apache.org/test/4285346063968224069?currentProjectId=IgniteExtensions_Tests=IgniteExtensions_Tests_Build=].
> It fails with the following error:
> {code:java}
> java.lang.AssertionError: Failed to wait latch completion, still wait 100
> events at
> org.apache.ignite.stream.kafka.KafkaIgniteStreamerSelfTest.consumerStream(KafkaIgniteStreamerSelfTest.java:242)
> at
> org.apache.ignite.stream.kafka.KafkaIgniteStreamerSelfTest.testKafkaStreamer(KafkaIgniteStreamerSelfTest.java:113)
> {code}
> This needs to be fixed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14010) Ignite-extensions: KafkaIgniteSteamerSelfTest is flaky
[
https://issues.apache.org/jira/browse/IGNITE-14010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-14010:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Ignite-extensions: KafkaIgniteSteamerSelfTest is flaky
> --
>
> Key: IGNITE-14010
> URL: https://issues.apache.org/jira/browse/IGNITE-14010
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
>
> KafkaIgniteSteamerSelfTest test is flaky - [TC
> build|https://ci.ignite.apache.org/test/4285346063968224069?currentProjectId=IgniteExtensions_Tests=IgniteExtensions_Tests_Build=].
> It fails with the following error:
> {code:java}
> java.lang.AssertionError: Failed to wait latch completion, still wait 100
> events at
> org.apache.ignite.stream.kafka.KafkaIgniteStreamerSelfTest.consumerStream(KafkaIgniteStreamerSelfTest.java:242)
> at
> org.apache.ignite.stream.kafka.KafkaIgniteStreamerSelfTest.testKafkaStreamer(KafkaIgniteStreamerSelfTest.java:113)
> {code}
> This needs to be fixed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14009) Ignite-extensions: PubSubStreamerSelfTest is flaky
[
https://issues.apache.org/jira/browse/IGNITE-14009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17275370#comment-17275370
]
Mikhail Petrov commented on IGNITE-14009:
-
[~NSAmelchev], Thanks a lot for the review.
> Ignite-extensions: PubSubStreamerSelfTest is flaky
> --
>
> Key: IGNITE-14009
> URL: https://issues.apache.org/jira/browse/IGNITE-14009
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
>
> PubSubStreamerSelfTest is flaky - [TC
> build|https://ci.ignite.apache.org/test/-1227012852016489408?currentProjectId=IgniteExtensions_Tests=IgniteExtensions_Tests_Build=pull%2F34%2F].
> It fails with the following error:
> {code:java}
> java.lang.AssertionError: Failed to wait latch completion, still wait 100
> events
> at
> org.apache.ignite.stream.pubsub.PubSubStreamerSelfTest.consumerStream(PubSubStreamerSelfTest.java:214)
> at
> org.apache.ignite.stream.pubsub.PubSubStreamerSelfTest.testPubSubStreamer(PubSubStreamerSelfTest.java:138)
> {code}
>
>
> This needs to be fixed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14009) Ignite-extensions: PubSubStreamerSelfTest is flaky
[
https://issues.apache.org/jira/browse/IGNITE-14009?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17275356#comment-17275356
]
Amelchev Nikita commented on IGNITE-14009:
--
Merged to the master.
[~PetrovMikhail] Thanks for the contribution!
> Ignite-extensions: PubSubStreamerSelfTest is flaky
> --
>
> Key: IGNITE-14009
> URL: https://issues.apache.org/jira/browse/IGNITE-14009
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
>
> PubSubStreamerSelfTest is flaky - [TC
> build|https://ci.ignite.apache.org/test/-1227012852016489408?currentProjectId=IgniteExtensions_Tests=IgniteExtensions_Tests_Build=pull%2F34%2F].
> It fails with the following error:
> {code:java}
> java.lang.AssertionError: Failed to wait latch completion, still wait 100
> events
> at
> org.apache.ignite.stream.pubsub.PubSubStreamerSelfTest.consumerStream(PubSubStreamerSelfTest.java:214)
> at
> org.apache.ignite.stream.pubsub.PubSubStreamerSelfTest.testPubSubStreamer(PubSubStreamerSelfTest.java:138)
> {code}
>
>
> This needs to be fixed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14009) Ignite-extensions: PubSubStreamerSelfTest is flaky
[
https://issues.apache.org/jira/browse/IGNITE-14009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-14009:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Ignite-extensions: PubSubStreamerSelfTest is flaky
> --
>
> Key: IGNITE-14009
> URL: https://issues.apache.org/jira/browse/IGNITE-14009
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Assignee: Mikhail Petrov
>Priority: Major
>
> PubSubStreamerSelfTest is flaky - [TC
> build|https://ci.ignite.apache.org/test/-1227012852016489408?currentProjectId=IgniteExtensions_Tests=IgniteExtensions_Tests_Build=pull%2F34%2F].
> It fails with the following error:
> {code:java}
> java.lang.AssertionError: Failed to wait latch completion, still wait 100
> events
> at
> org.apache.ignite.stream.pubsub.PubSubStreamerSelfTest.consumerStream(PubSubStreamerSelfTest.java:214)
> at
> org.apache.ignite.stream.pubsub.PubSubStreamerSelfTest.testPubSubStreamer(PubSubStreamerSelfTest.java:138)
> {code}
>
>
> This needs to be fixed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14073) False alarm to lose all transaction nodes
[
https://issues.apache.org/jira/browse/IGNITE-14073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17275267#comment-17275267
]
Vyacheslav Koptilin commented on IGNITE-14073:
--
Hi [~v.pyatkov],
The patch looks good to me. Merged to the master branch. Thank you for the
contribution.
> False alarm to lose all transaction nodes
> -
>
> Key: IGNITE-14073
> URL: https://issues.apache.org/jira/browse/IGNITE-14073
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This exception will happen when losing a primary and other one node during
> the transaction.
> But it may not be truth, because the transaction will be able to continue on
> backups (if they are still alive).
> {noformat}
> [2021-01-23
> 22:32:50,584][ERROR][test-runner-#1%near.IgniteTxExceptionNodeFailTest%][root]
> Transaction was not committed.
> class org.apache.ignite.IgniteException: Failed to commit a transaction (all
> partition owners have left the grid, partition data has been lost)
> [cacheName=default, partition=3, key=386050343]
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1096)
> at
> org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.commit(TransactionProxyImpl.java:323)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.IgniteTxExceptionNodeFailTest.cacheWithBackups(IgniteTxExceptionNodeFailTest.java:280)
> 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:2367)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class
> org.apache.ignite.internal.processors.cache.CacheInvalidStateException:
> Failed to commit a transaction (all partition owners have left the grid,
> partition data has been lost) [cacheName=default, partition=3, key=386050343]
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture$FinishMiniFuture.onNodeLeft(GridNearTxFinishFuture.java:993)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.onNodeLeft(GridNearTxFinishFuture.java:167)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMvccManager$4.onEvent(GridCacheMvccManager.java:265)
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager$LocalListenerWrapper.onEvent(GridEventStorageManager.java:1393)
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:888)
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:873)
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record0(GridEventStorageManager.java:349)
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record(GridEventStorageManager.java:312)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.recordEvent(GridDiscoveryManager.java:2948)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body0(GridDiscoveryManager.java:3164)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body(GridDiscoveryManager.java:2968)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> ... 1 more
> {noformat}
> It will frighten a user, because it looks like a data lose.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14073) False alarm to lose all transaction nodes
[
https://issues.apache.org/jira/browse/IGNITE-14073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-14073:
-
Fix Version/s: 2.11
> False alarm to lose all transaction nodes
> -
>
> Key: IGNITE-14073
> URL: https://issues.apache.org/jira/browse/IGNITE-14073
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> This exception will happen when losing a primary and other one node during
> the transaction.
> But it may not be truth, because the transaction will be able to continue on
> backups (if they are still alive).
> {noformat}
> [2021-01-23
> 22:32:50,584][ERROR][test-runner-#1%near.IgniteTxExceptionNodeFailTest%][root]
> Transaction was not committed.
> class org.apache.ignite.IgniteException: Failed to commit a transaction (all
> partition owners have left the grid, partition data has been lost)
> [cacheName=default, partition=3, key=386050343]
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1096)
> at
> org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.commit(TransactionProxyImpl.java:323)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.IgniteTxExceptionNodeFailTest.cacheWithBackups(IgniteTxExceptionNodeFailTest.java:280)
> 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:2367)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class
> org.apache.ignite.internal.processors.cache.CacheInvalidStateException:
> Failed to commit a transaction (all partition owners have left the grid,
> partition data has been lost) [cacheName=default, partition=3, key=386050343]
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture$FinishMiniFuture.onNodeLeft(GridNearTxFinishFuture.java:993)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.onNodeLeft(GridNearTxFinishFuture.java:167)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMvccManager$4.onEvent(GridCacheMvccManager.java:265)
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager$LocalListenerWrapper.onEvent(GridEventStorageManager.java:1393)
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:888)
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:873)
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record0(GridEventStorageManager.java:349)
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record(GridEventStorageManager.java:312)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.recordEvent(GridDiscoveryManager.java:2948)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body0(GridDiscoveryManager.java:3164)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body(GridDiscoveryManager.java:2968)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> ... 1 more
> {noformat}
> It will frighten a user, because it looks like a data lose.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14100) GridCachePartitionedNodeRestartTest fails due to wrong tx mapping
[
https://issues.apache.org/jira/browse/IGNITE-14100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17275263#comment-17275263
]
Vyacheslav Koptilin commented on IGNITE-14100:
--
Hello [~alapin],
The patch looks good to me. Merged to the master branch. Thank you for your
efforts.
> GridCachePartitionedNodeRestartTest fails due to wrong tx mapping
> -
>
> Key: IGNITE-14100
> URL: https://issues.apache.org/jira/browse/IGNITE-14100
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
> Fix For: 2.11
>
>
> Sometimes
> GridCachePartitionedNodeRestartTest#testRestartWithTxEightNodesTwoBackups
> hangs with the following AssertionError:
> {code:java}
> [18:06:54]W: [org.gridgain:ignite-core] java.lang.AssertionError:
> cacheId=-838655627, localNode = c2156a8f-1ac7-4098-8808-b1f9fad5,
> dhtNodes = [TcpDiscoveryNode [id=51df7fb1-2cad-4bfc-a02e-8225fbc0,
> consistentId=127.0.0.1:47500, addrs=ArrayList [127.0.0.1], sockAddrs=HashSet
> [/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
> lastExchangeTime=1603552013349, loc=false,
> ver=8.8.127#20201023-sha1:8f62caf2, isClient=false], TcpDiscoveryNode
> [id=c2156a8f-1ac7-4098-8808-b1f9fad5, consistentId=127.0.0.1:47504,
> addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47504],
> discPort=47504, order=21, intOrder=13, lastExchangeTime=1603552013259,
> loc=true, ver=8.8.127#20201023-sha1:8f62caf2, isClient=false],
> TcpDiscoveryNode [id=f7355089-fdea-4a96-af57-00ebeb94,
> consistentId=127.0.0.1:47505, addrs=ArrayList [127.0.0.1], sockAddrs=HashSet
> [/127.0.0.1:47505], discPort=47505, order=22, intOrder=14,
> lastExchangeTime=1603552013390, loc=false,
> ver=8.8.127#20201023-sha1:8f62caf2, isClient=false], TcpDiscoveryNode
> [id=4e8a8c17-e1c7-43e2-8461-9b5348d3, consistentId=127.0.0.1:47503,
> addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47503],
> discPort=47503, order=4, intOrder=4, lastExchangeTime=1603552013349,
> loc=false, ver=8.8.127#20201023-sha1:8f62caf2, isClient=false],
> TcpDiscoveryNode [id=d4f66e72-4ecc-4aca-a6d1-91242331,
> consistentId=127.0.0.1:47501, addrs=ArrayList [127.0.0.1], sockAddrs=HashSet
> [/127.0.0.1:47501], discPort=47501, order=2, intOrder=2,
> lastExchangeTime=1603552013349, loc=false,
> ver=8.8.127#20201023-sha1:8f62caf2, isClient=false]]
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.map(GridDhtTxPrepareFuture.java:1669)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1355)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:732)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1125)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:410)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:591)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:388)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:197)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:174)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:134)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:219)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:217)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
> [18:06:54]W:
[jira] [Updated] (IGNITE-14100) GridCachePartitionedNodeRestartTest fails due to wrong tx mapping
[
https://issues.apache.org/jira/browse/IGNITE-14100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-14100:
-
Fix Version/s: 2.11
> GridCachePartitionedNodeRestartTest fails due to wrong tx mapping
> -
>
> Key: IGNITE-14100
> URL: https://issues.apache.org/jira/browse/IGNITE-14100
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
> Fix For: 2.11
>
>
> Sometimes
> GridCachePartitionedNodeRestartTest#testRestartWithTxEightNodesTwoBackups
> hangs with the following AssertionError:
> {code:java}
> [18:06:54]W: [org.gridgain:ignite-core] java.lang.AssertionError:
> cacheId=-838655627, localNode = c2156a8f-1ac7-4098-8808-b1f9fad5,
> dhtNodes = [TcpDiscoveryNode [id=51df7fb1-2cad-4bfc-a02e-8225fbc0,
> consistentId=127.0.0.1:47500, addrs=ArrayList [127.0.0.1], sockAddrs=HashSet
> [/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
> lastExchangeTime=1603552013349, loc=false,
> ver=8.8.127#20201023-sha1:8f62caf2, isClient=false], TcpDiscoveryNode
> [id=c2156a8f-1ac7-4098-8808-b1f9fad5, consistentId=127.0.0.1:47504,
> addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47504],
> discPort=47504, order=21, intOrder=13, lastExchangeTime=1603552013259,
> loc=true, ver=8.8.127#20201023-sha1:8f62caf2, isClient=false],
> TcpDiscoveryNode [id=f7355089-fdea-4a96-af57-00ebeb94,
> consistentId=127.0.0.1:47505, addrs=ArrayList [127.0.0.1], sockAddrs=HashSet
> [/127.0.0.1:47505], discPort=47505, order=22, intOrder=14,
> lastExchangeTime=1603552013390, loc=false,
> ver=8.8.127#20201023-sha1:8f62caf2, isClient=false], TcpDiscoveryNode
> [id=4e8a8c17-e1c7-43e2-8461-9b5348d3, consistentId=127.0.0.1:47503,
> addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47503],
> discPort=47503, order=4, intOrder=4, lastExchangeTime=1603552013349,
> loc=false, ver=8.8.127#20201023-sha1:8f62caf2, isClient=false],
> TcpDiscoveryNode [id=d4f66e72-4ecc-4aca-a6d1-91242331,
> consistentId=127.0.0.1:47501, addrs=ArrayList [127.0.0.1], sockAddrs=HashSet
> [/127.0.0.1:47501], discPort=47501, order=2, intOrder=2,
> lastExchangeTime=1603552013349, loc=false,
> ver=8.8.127#20201023-sha1:8f62caf2, isClient=false]]
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.map(GridDhtTxPrepareFuture.java:1669)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1355)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:732)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1125)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:410)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:591)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:388)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:197)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:174)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:134)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:219)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:217)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
> [18:06:54]W: [org.gridgain:ignite-core] at
>
[jira] [Updated] (IGNITE-14073) False alarm to lose all transaction nodes
[
https://issues.apache.org/jira/browse/IGNITE-14073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-14073:
-
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> False alarm to lose all transaction nodes
> -
>
> Key: IGNITE-14073
> URL: https://issues.apache.org/jira/browse/IGNITE-14073
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This exception will happen when losing a primary and other one node during
> the transaction.
> But it may not be truth, because the transaction will be able to continue on
> backups (if they are still alive).
> {noformat}
> [2021-01-23
> 22:32:50,584][ERROR][test-runner-#1%near.IgniteTxExceptionNodeFailTest%][root]
> Transaction was not committed.
> class org.apache.ignite.IgniteException: Failed to commit a transaction (all
> partition owners have left the grid, partition data has been lost)
> [cacheName=default, partition=3, key=386050343]
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1096)
> at
> org.apache.ignite.internal.processors.cache.transactions.TransactionProxyImpl.commit(TransactionProxyImpl.java:323)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.IgniteTxExceptionNodeFailTest.cacheWithBackups(IgniteTxExceptionNodeFailTest.java:280)
> 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:2367)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class
> org.apache.ignite.internal.processors.cache.CacheInvalidStateException:
> Failed to commit a transaction (all partition owners have left the grid,
> partition data has been lost) [cacheName=default, partition=3, key=386050343]
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture$FinishMiniFuture.onNodeLeft(GridNearTxFinishFuture.java:993)
> at
> org.apache.ignite.internal.processors.cache.distributed.near.GridNearTxFinishFuture.onNodeLeft(GridNearTxFinishFuture.java:167)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMvccManager$4.onEvent(GridCacheMvccManager.java:265)
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager$LocalListenerWrapper.onEvent(GridEventStorageManager.java:1393)
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:888)
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:873)
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record0(GridEventStorageManager.java:349)
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record(GridEventStorageManager.java:312)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.recordEvent(GridDiscoveryManager.java:2948)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body0(GridDiscoveryManager.java:3164)
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body(GridDiscoveryManager.java:2968)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> ... 1 more
> {noformat}
> It will frighten a user, because it looks like a data lose.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14100) GridCachePartitionedNodeRestartTest fails due to wrong tx mapping
[
https://issues.apache.org/jira/browse/IGNITE-14100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-14100:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> GridCachePartitionedNodeRestartTest fails due to wrong tx mapping
> -
>
> Key: IGNITE-14100
> URL: https://issues.apache.org/jira/browse/IGNITE-14100
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
>
> Sometimes
> GridCachePartitionedNodeRestartTest#testRestartWithTxEightNodesTwoBackups
> hangs with the following AssertionError:
> {code:java}
> [18:06:54]W: [org.gridgain:ignite-core] java.lang.AssertionError:
> cacheId=-838655627, localNode = c2156a8f-1ac7-4098-8808-b1f9fad5,
> dhtNodes = [TcpDiscoveryNode [id=51df7fb1-2cad-4bfc-a02e-8225fbc0,
> consistentId=127.0.0.1:47500, addrs=ArrayList [127.0.0.1], sockAddrs=HashSet
> [/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
> lastExchangeTime=1603552013349, loc=false,
> ver=8.8.127#20201023-sha1:8f62caf2, isClient=false], TcpDiscoveryNode
> [id=c2156a8f-1ac7-4098-8808-b1f9fad5, consistentId=127.0.0.1:47504,
> addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47504],
> discPort=47504, order=21, intOrder=13, lastExchangeTime=1603552013259,
> loc=true, ver=8.8.127#20201023-sha1:8f62caf2, isClient=false],
> TcpDiscoveryNode [id=f7355089-fdea-4a96-af57-00ebeb94,
> consistentId=127.0.0.1:47505, addrs=ArrayList [127.0.0.1], sockAddrs=HashSet
> [/127.0.0.1:47505], discPort=47505, order=22, intOrder=14,
> lastExchangeTime=1603552013390, loc=false,
> ver=8.8.127#20201023-sha1:8f62caf2, isClient=false], TcpDiscoveryNode
> [id=4e8a8c17-e1c7-43e2-8461-9b5348d3, consistentId=127.0.0.1:47503,
> addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47503],
> discPort=47503, order=4, intOrder=4, lastExchangeTime=1603552013349,
> loc=false, ver=8.8.127#20201023-sha1:8f62caf2, isClient=false],
> TcpDiscoveryNode [id=d4f66e72-4ecc-4aca-a6d1-91242331,
> consistentId=127.0.0.1:47501, addrs=ArrayList [127.0.0.1], sockAddrs=HashSet
> [/127.0.0.1:47501], discPort=47501, order=2, intOrder=2,
> lastExchangeTime=1603552013349, loc=false,
> ver=8.8.127#20201023-sha1:8f62caf2, isClient=false]]
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.map(GridDhtTxPrepareFuture.java:1669)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1355)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:732)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1125)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:410)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:591)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:388)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:197)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:174)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:134)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:219)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:217)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
> [18:06:54]W: [org.gridgain:ignite-core] at
>
[jira] [Commented] (IGNITE-14100) GridCachePartitionedNodeRestartTest fails due to wrong tx mapping
[
https://issues.apache.org/jira/browse/IGNITE-14100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17274543#comment-17274543
]
Ignite TC Bot commented on IGNITE-14100:
{panel:title=Branch: [pull/8727/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8727/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5848877buildTypeId=IgniteTests24Java8_RunAll]
> GridCachePartitionedNodeRestartTest fails due to wrong tx mapping
> -
>
> Key: IGNITE-14100
> URL: https://issues.apache.org/jira/browse/IGNITE-14100
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
>
> Sometimes
> GridCachePartitionedNodeRestartTest#testRestartWithTxEightNodesTwoBackups
> hangs with the following AssertionError:
> {code:java}
> [18:06:54]W: [org.gridgain:ignite-core] java.lang.AssertionError:
> cacheId=-838655627, localNode = c2156a8f-1ac7-4098-8808-b1f9fad5,
> dhtNodes = [TcpDiscoveryNode [id=51df7fb1-2cad-4bfc-a02e-8225fbc0,
> consistentId=127.0.0.1:47500, addrs=ArrayList [127.0.0.1], sockAddrs=HashSet
> [/127.0.0.1:47500], discPort=47500, order=1, intOrder=1,
> lastExchangeTime=1603552013349, loc=false,
> ver=8.8.127#20201023-sha1:8f62caf2, isClient=false], TcpDiscoveryNode
> [id=c2156a8f-1ac7-4098-8808-b1f9fad5, consistentId=127.0.0.1:47504,
> addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47504],
> discPort=47504, order=21, intOrder=13, lastExchangeTime=1603552013259,
> loc=true, ver=8.8.127#20201023-sha1:8f62caf2, isClient=false],
> TcpDiscoveryNode [id=f7355089-fdea-4a96-af57-00ebeb94,
> consistentId=127.0.0.1:47505, addrs=ArrayList [127.0.0.1], sockAddrs=HashSet
> [/127.0.0.1:47505], discPort=47505, order=22, intOrder=14,
> lastExchangeTime=1603552013390, loc=false,
> ver=8.8.127#20201023-sha1:8f62caf2, isClient=false], TcpDiscoveryNode
> [id=4e8a8c17-e1c7-43e2-8461-9b5348d3, consistentId=127.0.0.1:47503,
> addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47503],
> discPort=47503, order=4, intOrder=4, lastExchangeTime=1603552013349,
> loc=false, ver=8.8.127#20201023-sha1:8f62caf2, isClient=false],
> TcpDiscoveryNode [id=d4f66e72-4ecc-4aca-a6d1-91242331,
> consistentId=127.0.0.1:47501, addrs=ArrayList [127.0.0.1], sockAddrs=HashSet
> [/127.0.0.1:47501], discPort=47501, order=2, intOrder=2,
> lastExchangeTime=1603552013349, loc=false,
> ver=8.8.127#20201023-sha1:8f62caf2, isClient=false]]
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.map(GridDhtTxPrepareFuture.java:1669)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1355)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:732)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1125)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:410)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:591)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:388)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:197)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:174)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:134)
> [18:06:54]W: [org.gridgain:ignite-core] at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:219)
> [18:06:54]W: [org.gridgain:ignite-core] at
>
[jira] [Updated] (IGNITE-14017) Willing to add s390x support to the docker image.
[ https://issues.apache.org/jira/browse/IGNITE-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov updated IGNITE-14017: -- Fix Version/s: 2.11 > Willing to add s390x support to the docker image. > - > > Key: IGNITE-14017 > URL: https://issues.apache.org/jira/browse/IGNITE-14017 > Project: Ignite > Issue Type: New Feature >Reporter: Prajakta Chaudhari >Assignee: Ilya Murchenko >Priority: Major > Fix For: 2.11 > > Time Spent: 10m > Remaining Estimate: 0h > > We are willing to add s390x support to the docker image. Dockerfile provided > on Apache Ignite GitHub repository > (https://github.com/apache/ignite/tree/master/docker/apache-ignite) is > working fine on s390x architecture. However we could not get any information > about how does the docker image build and release process work. Can you > please give some pointers to go ahead with the task? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14017) Willing to add s390x support to the docker image.
[ https://issues.apache.org/jira/browse/IGNITE-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov reassigned IGNITE-14017: - Assignee: Ilya Murchenko (was: Peter Ivanov) > Willing to add s390x support to the docker image. > - > > Key: IGNITE-14017 > URL: https://issues.apache.org/jira/browse/IGNITE-14017 > Project: Ignite > Issue Type: New Feature >Reporter: Prajakta Chaudhari >Assignee: Ilya Murchenko >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > We are willing to add s390x support to the docker image. Dockerfile provided > on Apache Ignite GitHub repository > (https://github.com/apache/ignite/tree/master/docker/apache-ignite) is > working fine on s390x architecture. However we could not get any information > about how does the docker image build and release process work. Can you > please give some pointers to go ahead with the task? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14064) .NET: Incorrect table name when query type is generic
[
https://issues.apache.org/jira/browse/IGNITE-14064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17274507#comment-17274507
]
Ignite TC Bot commented on IGNITE-14064:
{panel:title=Branch: [pull/8730/head] Base: [master] : Possible Blockers
(8)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Control Utility{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5849205]]
{color:#d04437}SPI{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5849141]]
* IgniteSpiTestSuite:
GridTcpCommunicationSpiTcpFailureDetectionSelfTest.testSendToManyNodes - Test
has low fail rate in base branch 0,0% and is not flaky
* IgniteSpiTestSuite: TcpDiscoverySslSelfTest.testFailedNodes3 - Test has low
fail rate in base branch 0,0% and is not flaky
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5849148]]
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoveryClientReconnectTest.testReconnectServersRestart_1 - Test has
low fail rate in base branch 1,4% and is not flaky
{color:#d04437}Examples{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5849123]]
{color:#d04437}Java Client{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5849130]]
{color:#d04437}PDS 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5849182]]
* IgnitePdsTestSuite: DistributedMetaStoragePersistentTest.testUnstableTopology
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cassandra Store{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5849199]]
* IgniteCassandraStoreTestSuite:
IgnitePersistentStoreTest.directPersistenceConfigTest - Test has low fail rate
in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/8730/head] Base: [master] : New Tests
(12)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Platform .NET (Core Linux){color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=5849187]]
* {color:#013220}dll: CacheLinqTestSqlEscapeAll.TestNestedGenericCacheTypes -
PASSED{color}
* {color:#013220}dll: CacheLinqTestSimpleName.TestNestedGenericCacheTypes -
PASSED{color}
* {color:#013220}dll: CacheLinqTestSqlEscapeAll.TestGenericCacheTypes -
PASSED{color}
* {color:#013220}dll: CacheLinqTest.TestNestedGenericCacheTypes - PASSED{color}
* {color:#013220}dll: CacheLinqTestSimpleName.TestGenericCacheTypes -
PASSED{color}
* {color:#013220}dll: CacheLinqTest.TestGenericCacheTypes - PASSED{color}
{color:#8b}Platform .NET{color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=5849186]]
* {color:#013220}exe: CacheLinqTest.TestGenericCacheTypes - PASSED{color}
* {color:#013220}exe: CacheLinqTest.TestNestedGenericCacheTypes - PASSED{color}
* {color:#013220}exe: CacheLinqTest.TestGenericCacheTypes - PASSED{color}
* {color:#013220}exe: CacheLinqTest.TestNestedGenericCacheTypes - PASSED{color}
* {color:#013220}exe: CacheLinqTest.TestGenericCacheTypes - PASSED{color}
* {color:#013220}exe: CacheLinqTest.TestNestedGenericCacheTypes - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5849211buildTypeId=IgniteTests24Java8_RunAll]
> .NET: Incorrect table name when query type is generic
> -
>
> Key: IGNITE-14064
> URL: https://issues.apache.org/jira/browse/IGNITE-14064
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
> Labels: .NET
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Using a generic type as a QueryEntity value type results in a broken SQL
> table name:
> {code}
> var ignite = Ignition.Start(TestUtils.GetTestConfiguration());
> var cfg = new CacheConfiguration(
> TestUtils.TestName,
> new QueryEntity(typeof(int), typeof(GenericTest)));
> var cache = ignite.GetOrCreateCache GenericTest>(cfg);
> cache[1] = new GenericTest {Prop = "1"};
> var tables = cache.Query(new SqlFieldsQuery("SELECT TABLE_NAME
> FROM INFORMATION_SCHEMA.TABLES"))
> .Select(x => (string) x.Single()).ToArray();
> {code}
> Resulting table name is *0, CULTURE=NEUTRAL,
> PUBLICKEYTOKEN=7CEC85D7BEA7798E]]*.
> We should add .NET generics support to
> {{org.apache.ignite.internal.processors.query.QueryUtils.typeName}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14017) Willing to add s390x support to the docker image.
[ https://issues.apache.org/jira/browse/IGNITE-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17274457#comment-17274457 ] Peter Ivanov commented on IGNITE-14017: --- Thanks! I'll take it from here – prepare PR and pass for review. > Willing to add s390x support to the docker image. > - > > Key: IGNITE-14017 > URL: https://issues.apache.org/jira/browse/IGNITE-14017 > Project: Ignite > Issue Type: New Feature >Reporter: Prajakta Chaudhari >Assignee: Peter Ivanov >Priority: Major > > We are willing to add s390x support to the docker image. Dockerfile provided > on Apache Ignite GitHub repository > (https://github.com/apache/ignite/tree/master/docker/apache-ignite) is > working fine on s390x architecture. However we could not get any information > about how does the docker image build and release process work. Can you > please give some pointers to go ahead with the task? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14017) Willing to add s390x support to the docker image.
[ https://issues.apache.org/jira/browse/IGNITE-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov reassigned IGNITE-14017: - Assignee: Peter Ivanov > Willing to add s390x support to the docker image. > - > > Key: IGNITE-14017 > URL: https://issues.apache.org/jira/browse/IGNITE-14017 > Project: Ignite > Issue Type: New Feature >Reporter: Prajakta Chaudhari >Assignee: Peter Ivanov >Priority: Major > > We are willing to add s390x support to the docker image. Dockerfile provided > on Apache Ignite GitHub repository > (https://github.com/apache/ignite/tree/master/docker/apache-ignite) is > working fine on s390x architecture. However we could not get any information > about how does the docker image build and release process work. Can you > please give some pointers to go ahead with the task? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14017) Willing to add s390x support to the docker image.
[ https://issues.apache.org/jira/browse/IGNITE-14017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17274451#comment-17274451 ] Prajakta Chaudhari commented on IGNITE-14017: - Hi [~vveider], We publish and maintain Apache Ignite dockerfile for the latest stable version [here|[https://github.com/linux-on-ibm-z/dockerfile-examples/tree/master/ApacheIgnite]]. It is similar to the [Dockerfile|[https://github.com/apache/ignite/blob/master/docker/apache-ignite/Dockerfile]] present on the official Apache Ignite repository. Let me know if anything else is needed from our end. Thanks! > Willing to add s390x support to the docker image. > - > > Key: IGNITE-14017 > URL: https://issues.apache.org/jira/browse/IGNITE-14017 > Project: Ignite > Issue Type: New Feature >Reporter: Prajakta Chaudhari >Priority: Major > > We are willing to add s390x support to the docker image. Dockerfile provided > on Apache Ignite GitHub repository > (https://github.com/apache/ignite/tree/master/docker/apache-ignite) is > working fine on s390x architecture. However we could not get any information > about how does the docker image build and release process work. Can you > please give some pointers to go ahead with the task? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14080) binary-metadata-writer hung with no ignite instance
[
https://issues.apache.org/jira/browse/IGNITE-14080?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17274450#comment-17274450
]
Ignite TC Bot commented on IGNITE-14080:
{panel:title=Branch: [pull/8720/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache (Restarts) 1{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5848477]]
{panel}
{panel:title=Branch: [pull/8720/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5847634]]
* {color:#013220}IgnitePdsTestSuite2:
StandaloneWalRecordsIteratorTest.testBinaryMetadataWriterStopped - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5847662buildTypeId=IgniteTests24Java8_RunAll]
> binary-metadata-writer hung with no ignite instance
> ---
>
> Key: IGNITE-14080
> URL: https://issues.apache.org/jira/browse/IGNITE-14080
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If you start with no ignite instance, {{IgniteWalIteratorFactory}} creates
> {{BinaryMetadataFileStore}} which never stops by itself and hung on
> {{queue.take()}}.
> stacktrace:
> {code:java}
> "binary-metadata-writer-#1" #22 prio=5 os_prio=0 tid=0x7f2c0885b800
> nid=0x2a3ac9 waiting on condition [0x7f2afc55b000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x000580ad7130> (a
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
> at
> java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
> at
> org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore$BinaryMetadataAsyncWriter.body0(BinaryMetadataFileStore.java:362)
> at
> org.apache.ignite.internal.processors.cache.binary.BinaryMetadataFileStore$BinaryMetadataAsyncWriter.body(BinaryMetadataFileStore.java:343)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13639) .NET: Type cast exception on cache.Get with an array of empty Lists
[
https://issues.apache.org/jira/browse/IGNITE-13639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17274425#comment-17274425
]
Pavel Tupitsyn commented on IGNITE-13639:
-
Merged to master: a7f35ac0670aed074ef88054ee17c0da6b47068c
> .NET: Type cast exception on cache.Get with an array of empty Lists
> ---
>
> Key: IGNITE-13639
> URL: https://issues.apache.org/jira/browse/IGNITE-13639
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.9
> Environment: Apache Ignite: v2.9.0
> JDK: v1.8
> .NET Core: v3.1
>Reporter: Danut Radoaica
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET, 2.9.1-rc
> Fix For: 2.11
>
> Attachments: BotXEntityDto.cs, ConsoleApp1.zip, exception.txt,
> stream_dump.txt
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> [^exception.txt] contains the stack trace
> [^stream_dump.txt] contains the stream that fails, dumped using
> System.Text.Encoding.UTF8.GetString
> [^BotXEntityDto.cs] contains the dto definition
> Minimal reproducer:
> {code}
> using System.Collections.Generic;
> using Apache.Ignite.Core;
> var ignite = Ignition.Start();
> var cache = ignite.GetOrCreateCache("c");
> cache.Put(1, new[]
> {
> new Entity {Inner = new List()},
> new Entity {Inner = new List()}
> });
> cache.Get(1);
> class Entity
> {
> public IList Inner { get; set; }
> }
> {code}
> Works on 2.8.0, fails on 2.9.1.
> The problem is that IGNITE-12827 has changed the detach semantics for arrays
> and collections, and this revealed the problem on .NET side: array and
> collection elements can share handles (same object references), which is a
> problem, because Java handles every element separately. And the bug occurs
> because an empty list has {{_items}} initialized to a shared empty array
> instance.
> *Workaround*: use {{List}} instead of {{Entity[]}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13639) .NET: Type cast exception on cache.Get with an array of empty Lists
[
https://issues.apache.org/jira/browse/IGNITE-13639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17274412#comment-17274412
]
Igor Sapego commented on IGNITE-13639:
--
[~ptupitsyn] ship it.
> .NET: Type cast exception on cache.Get with an array of empty Lists
> ---
>
> Key: IGNITE-13639
> URL: https://issues.apache.org/jira/browse/IGNITE-13639
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.9
> Environment: Apache Ignite: v2.9.0
> JDK: v1.8
> .NET Core: v3.1
>Reporter: Danut Radoaica
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET, 2.9.1-rc
> Fix For: 2.11
>
> Attachments: BotXEntityDto.cs, ConsoleApp1.zip, exception.txt,
> stream_dump.txt
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> [^exception.txt] contains the stack trace
> [^stream_dump.txt] contains the stream that fails, dumped using
> System.Text.Encoding.UTF8.GetString
> [^BotXEntityDto.cs] contains the dto definition
> Minimal reproducer:
> {code}
> using System.Collections.Generic;
> using Apache.Ignite.Core;
> var ignite = Ignition.Start();
> var cache = ignite.GetOrCreateCache("c");
> cache.Put(1, new[]
> {
> new Entity {Inner = new List()},
> new Entity {Inner = new List()}
> });
> cache.Get(1);
> class Entity
> {
> public IList Inner { get; set; }
> }
> {code}
> Works on 2.8.0, fails on 2.9.1.
> The problem is that IGNITE-12827 has changed the detach semantics for arrays
> and collections, and this revealed the problem on .NET side: array and
> collection elements can share handles (same object references), which is a
> problem, because Java handles every element separately. And the bug occurs
> because an empty list has {{_items}} initialized to a shared empty array
> instance.
> *Workaround*: use {{List}} instead of {{Entity[]}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14102) Create escaping and searching util methods for configuration framework
Ivan Bessonov created IGNITE-14102: -- Summary: Create escaping and searching util methods for configuration framework Key: IGNITE-14102 URL: https://issues.apache.org/jira/browse/IGNITE-14102 Project: Ignite Issue Type: Sub-task Reporter: Ivan Bessonov Assignee: Ivan Bessonov Right of the bat, I can think of two useful things to do: * escaping / unescaping; * replace for BaseSelectors#find that'll work on new trees. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13763) C++: Add a configuration property allowing thin CPP client to limit connection count.
[ https://issues.apache.org/jira/browse/IGNITE-13763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17274398#comment-17274398 ] Pavel Tupitsyn commented on IGNITE-13763: - [~isapego] looks good to me, thanks! > C++: Add a configuration property allowing thin CPP client to limit > connection count. > - > > Key: IGNITE-13763 > URL: https://issues.apache.org/jira/browse/IGNITE-13763 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 2.9 >Reporter: Vladimir Pligin >Assignee: Igor Sapego >Priority: Major > Labels: cpp > Time Spent: 50m > Remaining Estimate: 0h > > It seems that C++ thin client behaves differently from Java client. Assuming > that partition awareness is disabled we still have connection attempts to all > servers from the list. It would be great to have a property to limit it > somehow. It could potentially cause performance issues in some cases > involving big number of clients per server. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14054) Improve discovery ducktest: add partial network drop.
[ https://issues.apache.org/jira/browse/IGNITE-14054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17274394#comment-17274394 ] Anton Vinogradov commented on IGNITE-14054: --- Merged to ignite-ducktape. Thanks for your contribution. > Improve discovery ducktest: add partial network drop. > - > > Key: IGNITE-14054 > URL: https://issues.apache.org/jira/browse/IGNITE-14054 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Time Spent: 1h 10m > Remaining Estimate: 0h > > Discovery ducktape test lacks simulation of partial network failure. Also it > doesn't check disabled recoveryTimeout (connRecoveryTimeout==0). Raised by > tickets: > IGNITE-14068 > IGNITE-13980 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13763) C++: Add a configuration property allowing thin CPP client to limit connection count.
[ https://issues.apache.org/jira/browse/IGNITE-13763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17274395#comment-17274395 ] Igor Sapego commented on IGNITE-13763: -- [~ptupitsyn] answered questions/fixed comments. Please, take another look > C++: Add a configuration property allowing thin CPP client to limit > connection count. > - > > Key: IGNITE-13763 > URL: https://issues.apache.org/jira/browse/IGNITE-13763 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 2.9 >Reporter: Vladimir Pligin >Assignee: Igor Sapego >Priority: Major > Labels: cpp > Time Spent: 50m > Remaining Estimate: 0h > > It seems that C++ thin client behaves differently from Java client. Assuming > that partition awareness is disabled we still have connection attempts to all > servers from the list. It would be great to have a property to limit it > somehow. It could potentially cause performance issues in some cases > involving big number of clients per server. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13285) Document control.sh indexes manipulation commands
[
https://issues.apache.org/jira/browse/IGNITE-13285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17274385#comment-17274385
]
Maxim Muzafarov commented on IGNITE-13285:
--
Cherry-picked to 2.10
> Document control.sh indexes manipulation commands
> -
>
> Key: IGNITE-13285
> URL: https://issues.apache.org/jira/browse/IGNITE-13285
> Project: Ignite
> Issue Type: Task
> Components: control.sh, documentation
>Reporter: Vladimir Malinovskiy
>Assignee: Nikita Safonov
>Priority: Major
> Labels: important
> Fix For: 2.10
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Under IGNITE-13268 3 new cache commands were added:
> {code:java}
> --indexes_list
> --indexes_rebuild_status
> --indexes_force_rebuild
> {code}
> New commands should be documented.
> Here is part of cache help that corresponds to the commands:
> {code:java}
> --cache indexes_list [--node-id nodeId] [--group-name grpRegExp]
> [--cache-name cacheRegExp] [--index-name idxNameRegExp]
> List all indexes that match specified filters.
> Parameters:
> --node-id nodeId - Specify node for job execution. If not specified
> explicitly, node will be chosen by grid
> --group-name regExp - Regular expression allowing filtering by cache
> group name
> --cache-name regExp - Regular expression allowing filtering by cache
> name
> --index-name regExp - Regular expression allowing filtering by index
> name
> --cache indexes_rebuild_status [--node-id nodeId]
> List all indexes that have index rebuild in progress.
> Parameters:
> --node-id nodeId - Specify node for job execution. If not specified
> explicitly, info will be gathered from all nodes
> --cache indexes_force_rebuild --node-id nodeId --cache-name
> cacheName1,...cacheNameN|--group-name groupName1,...groupNameN
> Triggers rebuild of all indexes for specified caches or cache groups.
> Parameters:
> --node-id - Specify node for indexes rebuild.
> --cache-names - Comma-separated list of cache names for which indexes
> should be rebuilt.
> --group-names - Comma-separated list of cache group names for which
> indexes should be rebuilt.
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13639) .NET: Type cast exception on cache.Get with an array of empty Lists
[
https://issues.apache.org/jira/browse/IGNITE-13639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17274362#comment-17274362
]
Pavel Tupitsyn commented on IGNITE-13639:
-
[~isapego] replied to the comments
> .NET: Type cast exception on cache.Get with an array of empty Lists
> ---
>
> Key: IGNITE-13639
> URL: https://issues.apache.org/jira/browse/IGNITE-13639
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.9
> Environment: Apache Ignite: v2.9.0
> JDK: v1.8
> .NET Core: v3.1
>Reporter: Danut Radoaica
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET, 2.9.1-rc
> Fix For: 2.11
>
> Attachments: BotXEntityDto.cs, ConsoleApp1.zip, exception.txt,
> stream_dump.txt
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> [^exception.txt] contains the stack trace
> [^stream_dump.txt] contains the stream that fails, dumped using
> System.Text.Encoding.UTF8.GetString
> [^BotXEntityDto.cs] contains the dto definition
> Minimal reproducer:
> {code}
> using System.Collections.Generic;
> using Apache.Ignite.Core;
> var ignite = Ignition.Start();
> var cache = ignite.GetOrCreateCache("c");
> cache.Put(1, new[]
> {
> new Entity {Inner = new List()},
> new Entity {Inner = new List()}
> });
> cache.Get(1);
> class Entity
> {
> public IList Inner { get; set; }
> }
> {code}
> Works on 2.8.0, fails on 2.9.1.
> The problem is that IGNITE-12827 has changed the detach semantics for arrays
> and collections, and this revealed the problem on .NET side: array and
> collection elements can share handles (same object references), which is a
> problem, because Java handles every element separately. And the bug occurs
> because an empty list has {{_items}} initialized to a shared empty array
> instance.
> *Workaround*: use {{List}} instead of {{Entity[]}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13639) .NET: Type cast exception on cache.Get with an array of empty Lists
[
https://issues.apache.org/jira/browse/IGNITE-13639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17274359#comment-17274359
]
Igor Sapego commented on IGNITE-13639:
--
[~ptupitsyn] see my comments in PR, but overall looks good.
> .NET: Type cast exception on cache.Get with an array of empty Lists
> ---
>
> Key: IGNITE-13639
> URL: https://issues.apache.org/jira/browse/IGNITE-13639
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.9
> Environment: Apache Ignite: v2.9.0
> JDK: v1.8
> .NET Core: v3.1
>Reporter: Danut Radoaica
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET, 2.9.1-rc
> Fix For: 2.11
>
> Attachments: BotXEntityDto.cs, ConsoleApp1.zip, exception.txt,
> stream_dump.txt
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> [^exception.txt] contains the stack trace
> [^stream_dump.txt] contains the stream that fails, dumped using
> System.Text.Encoding.UTF8.GetString
> [^BotXEntityDto.cs] contains the dto definition
> Minimal reproducer:
> {code}
> using System.Collections.Generic;
> using Apache.Ignite.Core;
> var ignite = Ignition.Start();
> var cache = ignite.GetOrCreateCache("c");
> cache.Put(1, new[]
> {
> new Entity {Inner = new List()},
> new Entity {Inner = new List()}
> });
> cache.Get(1);
> class Entity
> {
> public IList Inner { get; set; }
> }
> {code}
> Works on 2.8.0, fails on 2.9.1.
> The problem is that IGNITE-12827 has changed the detach semantics for arrays
> and collections, and this revealed the problem on .NET side: array and
> collection elements can share handles (same object references), which is a
> problem, because Java handles every element separately. And the bug occurs
> because an empty list has {{_items}} initialized to a shared empty array
> instance.
> *Workaround*: use {{List}} instead of {{Entity[]}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14101) .NET Thin Client: Add connection limit configuration property.
Pavel Tupitsyn created IGNITE-14101: --- Summary: .NET Thin Client: Add connection limit configuration property. Key: IGNITE-14101 URL: https://issues.apache.org/jira/browse/IGNITE-14101 Project: Ignite Issue Type: Improvement Components: platforms, thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn With partition awareness enabled, the thin client connects to every server node in the cluster. Provide a config property to limit the number of connections to limit the resource usage on servers and clients. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13763) C++: Add a configuration property allowing thin CPP client to limit connection count.
[ https://issues.apache.org/jira/browse/IGNITE-13763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17274346#comment-17274346 ] Pavel Tupitsyn commented on IGNITE-13763: - [~isapego] please see a couple comments on GitHub > C++: Add a configuration property allowing thin CPP client to limit > connection count. > - > > Key: IGNITE-13763 > URL: https://issues.apache.org/jira/browse/IGNITE-13763 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 2.9 >Reporter: Vladimir Pligin >Assignee: Igor Sapego >Priority: Major > Labels: cpp > Time Spent: 20m > Remaining Estimate: 0h > > It seems that C++ thin client behaves differently from Java client. Assuming > that partition awareness is disabled we still have connection attempts to all > servers from the list. It would be great to have a property to limit it > somehow. It could potentially cause performance issues in some cases > involving big number of clients per server. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14068) Infinite node persistance in the ring while outcoming connections are lost
[ https://issues.apache.org/jira/browse/IGNITE-14068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-14068: -- Description: If node loses +outgoing+ connections, it can decide it is alone in the cluster and won't fail. Happens on small clusters where failed node is able to unsuccessfully try to connect to all other nodes before _connRecoveryTimeout_ expires. Consider: The cluster n1 -> n2 -> n3 -> n4 -> n1 * n4 looses all outgoing connections. * n3 keeps successful ping to n4. * n4 attempts to connect to n1, n2, n3. Fails with each due to outgoing network failure. * spi.connrecoveryTimeout is not reached. n4 decides it is alone and continues working. * n3 still sends messages to n4. n4 does not lack incoming connections. * ring is actually broken because of n4. n3 cannot determine failure of n4. was: If node loses +outcoming+ connections, it can decide it is alone in the cluster and won't fail. Happens on small clusters where failed node is able to unsuccessfully try to connect to all other nodes before _connRecoveryTimeout_ expires. Consider: The cluster n1 -> n2 -> n3 -> n4 -> n1 * n4 looses all outgoing connections. * n3 keeps successful ping to n4. * n4 attempts to connect to n1, n2, n3. Fails with each due to outgoing network failure. * spi.connrecoveryTimeout is not reached. n4 decides it is alone and continues working. * n3 still sends messages to n4. n4 does not lack incoming connections. * ring is actually broken because of n4. n3 cannot determine failure of n4. > Infinite node persistance in the ring while outcoming connections are lost > -- > > Key: IGNITE-14068 > URL: https://issues.apache.org/jira/browse/IGNITE-14068 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > If node loses +outgoing+ connections, it can decide it is alone in the > cluster and won't fail. Happens on small clusters where failed node is able > to unsuccessfully try to connect to all other nodes before > _connRecoveryTimeout_ expires. > Consider: > The cluster n1 -> n2 -> n3 -> n4 -> n1 > * n4 looses all outgoing connections. > * n3 keeps successful ping to n4. > * n4 attempts to connect to n1, n2, n3. Fails with each due to outgoing > network failure. > * spi.connrecoveryTimeout is not reached. n4 decides it is alone and > continues working. > * n3 still sends messages to n4. n4 does not lack incoming connections. > * ring is actually broken because of n4. n3 cannot determine failure of n4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14068) Infinite node persistance in the ring while outcoming connections are lost
[ https://issues.apache.org/jira/browse/IGNITE-14068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-14068: -- Description: If node loses +outcoming+ connections, it can decide it is alone in the cluster and won't fail. Happens on small clusters where failed node is able to unsuccessfully try to connect to all other nodes before _connRecoveryTimeout_ expires. Consider: The cluster n1 -> n2 -> n3 -> n4 -> n1 * n4 looses all outgoing connections. * n3 keeps successful ping to n4. * n4 attempts to connect to n1, n2, n3. Fails with each due to outgoing network failure. * spi.connrecoveryTimeout is not reached. n4 decides it is alone and continues working. * n3 still sends messages to n4. n4 does not lack incoming connections. * ring is actually broken because of n4. n3 cannot determine failure of n4. was:If node loses +outcoming+ connections, it can decide it is alone in the cluster and won't fail. Happens on small clusters where failed node is able to unsuccessfully try to connect to all other nodes before _connRecoveryTimeout_ expires. > Infinite node persistance in the ring while outcoming connections are lost > -- > > Key: IGNITE-14068 > URL: https://issues.apache.org/jira/browse/IGNITE-14068 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > If node loses +outcoming+ connections, it can decide it is alone in the > cluster and won't fail. Happens on small clusters where failed node is able > to unsuccessfully try to connect to all other nodes before > _connRecoveryTimeout_ expires. > Consider: > The cluster n1 -> n2 -> n3 -> n4 -> n1 > * n4 looses all outgoing connections. > * n3 keeps successful ping to n4. > * n4 attempts to connect to n1, n2, n3. Fails with each due to outgoing > network failure. > * spi.connrecoveryTimeout is not reached. n4 decides it is alone and > continues working. > * n3 still sends messages to n4. n4 does not lack incoming connections. > * ring is actually broken because of n4. n3 cannot determine failure of n4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14068) Infinite node persistance in the ring while outgoing connections are lost
[ https://issues.apache.org/jira/browse/IGNITE-14068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-14068: -- Summary: Infinite node persistance in the ring while outgoing connections are lost (was: Infinite node persistance in the ring while outcoming connections are lost) > Infinite node persistance in the ring while outgoing connections are lost > - > > Key: IGNITE-14068 > URL: https://issues.apache.org/jira/browse/IGNITE-14068 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > If node loses +outgoing+ connections, it can decide it is alone in the > cluster and won't fail. Happens on small clusters where failed node is able > to unsuccessfully try to connect to all other nodes before > _connRecoveryTimeout_ expires. > Consider: > The cluster n1 -> n2 -> n3 -> n4 -> n1 > * n4 looses all outgoing connections. > * n3 keeps successful ping to n4. > * n4 attempts to connect to n1, n2, n3. Fails with each due to outgoing > network failure. > * spi.connrecoveryTimeout is not reached. n4 decides it is alone and > continues working. > * n3 still sends messages to n4. n4 does not lack incoming connections. > * ring is actually broken because of n4. n3 cannot determine failure of n4. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13763) C++: Add a configuration property allowing thin CPP client to limit connection count.
[ https://issues.apache.org/jira/browse/IGNITE-13763?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-13763: - Reviewer: Pavel Tupitsyn > C++: Add a configuration property allowing thin CPP client to limit > connection count. > - > > Key: IGNITE-13763 > URL: https://issues.apache.org/jira/browse/IGNITE-13763 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 2.9 >Reporter: Vladimir Pligin >Assignee: Igor Sapego >Priority: Major > Labels: cpp > Time Spent: 10m > Remaining Estimate: 0h > > It seems that C++ thin client behaves differently from Java client. Assuming > that partition awareness is disabled we still have connection attempts to all > servers from the list. It would be great to have a property to limit it > somehow. It could potentially cause performance issues in some cases > involving big number of clients per server. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13763) C++: Add a configuration property allowing thin CPP client to limit connection count.
[
https://issues.apache.org/jira/browse/IGNITE-13763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17274342#comment-17274342
]
Ignite TC Bot commented on IGNITE-13763:
{panel:title=Branch: [pull/8726/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8726/head] Base: [master] : New Tests
(1992)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Platform C++ CMake (Win x64 / Debug){color} [[tests
994|https://ci.ignite.apache.org/viewLog.html?buildId=5848987]]
* {color:#013220}IgniteThinClientTest: SqlFieldsQueryTestSuite: SelectTwoValues
- PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionFloor - PASSED{color}
* {color:#013220}IgniteThinClientTest: SqlFieldsQueryTestSuite:
SelectSingleValue - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionLog - PASSED{color}
* {color:#013220}IgniteThinClientTest: SqlFieldsQueryTestSuite:
CreateTableInsertSelect - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlDateTimeFunctionTestSuite: TestCurrentDate
- PASSED{color}
* {color:#013220}IgniteThinClientTest: SqlFieldsQueryTestSuite:
SelectTwoValuesInDifferentOrder - PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForCacheNodes -
PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForClientNodes -
PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQueryTestSuite:
TestFieldsQueryByteArrayInsertSelect - PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForDaemons -
PASSED{color}
... and 983 new tests
{color:#8b}Platform C++ (Win x64 / Debug){color} [[tests
994|https://ci.ignite.apache.org/viewLog.html?buildId=5848604]]
* {color:#013220}IgniteThinClientTest: SqlFieldsQueryTestSuite: SelectTwoValues
- PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionFloor - PASSED{color}
* {color:#013220}IgniteThinClientTest: SqlFieldsQueryTestSuite:
SelectSingleValue - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlNumericFunctionTestSuite:
TestNumericFunctionLog - PASSED{color}
* {color:#013220}IgniteThinClientTest: SqlFieldsQueryTestSuite:
CreateTableInsertSelect - PASSED{color}
* {color:#013220}IgniteOdbcTest: SqlDateTimeFunctionTestSuite: TestCurrentDate
- PASSED{color}
* {color:#013220}IgniteThinClientTest: SqlFieldsQueryTestSuite:
SelectTwoValuesInDifferentOrder - PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForCacheNodes -
PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQueryTestSuite:
TestFieldsQueryByteArrayInsertSelect - PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForClientNodes -
PASSED{color}
* {color:#013220}IgniteCoreTest: ClusterTestSuite: IgniteForDaemons -
PASSED{color}
... and 983 new tests
{color:#8b}Platform C++ (Win x64 / Release){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5848605]]
* {color:#013220}IgniteThinClientTest: IgniteClientTestSuite:
IgniteClientConnectionLimit - PASSED{color}
{color:#8b}Platform C++ CMake (Win x64 / Release){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5848612]]
* {color:#013220}IgniteThinClientTest: IgniteClientTestSuite:
IgniteClientConnectionLimit - PASSED{color}
{color:#8b}Platform C++ CMake (Linux){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5848610]]
* {color:#013220}IgniteThinClientTest: IgniteClientTestSuite:
IgniteClientConnectionLimit - PASSED{color}
{color:#8b}Platform C++ CMake (Linux Clang){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5848609]]
* {color:#013220}IgniteThinClientTest: IgniteClientTestSuite:
IgniteClientConnectionLimit - PASSED{color}
{panel}
[TeamCity *- Run :: CPP*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5848613buildTypeId=IgniteTests24Java8_RunCpp]
> C++: Add a configuration property allowing thin CPP client to limit
> connection count.
> -
>
> Key: IGNITE-13763
> URL: https://issues.apache.org/jira/browse/IGNITE-13763
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 2.9
>Reporter: Vladimir Pligin
>Assignee: Igor Sapego
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It seems that C++ thin client behaves differently from Java client. Assuming
> that partition awareness is disabled we still have connection attempts to all
> servers from the list. It would be great to have a property to limit it
> somehow. It could potentially cause performance issues in some cases
> involving big number of clients per server.
[jira] [Commented] (IGNITE-13639) .NET: Type cast exception on cache.Get with an array of empty Lists
[
https://issues.apache.org/jira/browse/IGNITE-13639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17274321#comment-17274321
]
Ignite TC Bot commented on IGNITE-13639:
{panel:title=Branch: [pull/8724/head] Base: [master] : Possible Blockers
(6)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache (Restarts) 1{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5848938]]
{color:#d04437}Control Utility{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5848979]]
{color:#d04437}Cache 5{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5848945]]
* IgniteCacheTestSuite5:
ClusterStateClientReplicatedSelfTest.testActivationWithReadOnly - Test has low
fail rate in base branch 0,0% and is not flaky
* IgniteCacheTestSuite5:
ClusterStateClientReplicatedSelfTest.testEnablingReadOnly - Test has low fail
rate in base branch 0,0% and is not flaky
* IgniteCacheTestSuite5: ClusterStateClientReplicatedSelfTest.testDeactivation
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteCacheTestSuite5: ClusterStateClientReplicatedSelfTest.testActivation -
Test has low fail rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/8724/head] Base: [master] : New Tests
(22)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Platform .NET (Core Linux){color} [[tests
11|https://ci.ignite.apache.org/viewLog.html?buildId=5848961]]
* {color:#013220}dll:
JavaBinaryInteropTest.TestHashtableOfObjectsWithSharedObjectProperty -
PASSED{color}
* {color:#013220}dll:
JavaBinaryInteropTest.TestListOfObjectsWithSharedObjectProperty - PASSED{color}
* {color:#013220}dll:
JavaBinaryInteropTest.TestArrayListOfObjectsWithSharedObjectProperty -
PASSED{color}
* {color:#013220}dll:
JavaBinaryInteropTest.TestArrayOfObjectsWithSharedArrayElement - PASSED{color}
* {color:#013220}dll:
JavaBinaryInteropTest.TestArrayOfObjectsWithSharedObjectProperty - PASSED{color}
* {color:#013220}dll:
JavaBinaryInteropTest.TestDictionaryOfObjectsWithSharedObjectProperty -
PASSED{color}
* {color:#013220}dll:
JavaBinaryInteropTest.TestArrayOfObjectsWithSharedArrayElementAndReferenceLoop
- PASSED{color}
* {color:#013220}dll:
JavaBinaryInteropTest.TestArrayOfObjectsWithSharedListProperty - PASSED{color}
* {color:#013220}dll: BinarySelfTestSimpleName.TestNestedLists - PASSED{color}
* {color:#013220}dll: BinarySelfTest.TestNestedLists - PASSED{color}
* {color:#013220}dll: BinarySelfTestFullFooter.TestNestedLists - PASSED{color}
... and 0 new tests
{color:#8b}Platform .NET{color} [[tests
11|https://ci.ignite.apache.org/viewLog.html?buildId=5848960]]
* {color:#013220}exe:
JavaBinaryInteropTest.TestArrayListOfObjectsWithSharedObjectProperty -
PASSED{color}
* {color:#013220}exe:
JavaBinaryInteropTest.TestArrayOfObjectsWithSharedArrayElement - PASSED{color}
* {color:#013220}exe:
JavaBinaryInteropTest.TestArrayOfObjectsWithSharedObjectProperty - PASSED{color}
* {color:#013220}exe:
JavaBinaryInteropTest.TestDictionaryOfObjectsWithSharedObjectProperty -
PASSED{color}
* {color:#013220}exe:
JavaBinaryInteropTest.TestArrayOfObjectsWithSharedArrayElementAndReferenceLoop
- PASSED{color}
* {color:#013220}exe:
JavaBinaryInteropTest.TestArrayOfObjectsWithSharedListProperty - PASSED{color}
* {color:#013220}exe:
JavaBinaryInteropTest.TestHashtableOfObjectsWithSharedObjectProperty -
PASSED{color}
* {color:#013220}exe:
JavaBinaryInteropTest.TestListOfObjectsWithSharedObjectProperty - PASSED{color}
* {color:#013220}exe: BinarySelfTest.TestNestedLists - PASSED{color}
* {color:#013220}exe: BinarySelfTest.TestNestedLists - PASSED{color}
* {color:#013220}exe: BinarySelfTest.TestNestedLists - PASSED{color}
... and 0 new tests
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5848985buildTypeId=IgniteTests24Java8_RunAll]
> .NET: Type cast exception on cache.Get with an array of empty Lists
> ---
>
> Key: IGNITE-13639
> URL: https://issues.apache.org/jira/browse/IGNITE-13639
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.9
> Environment: Apache Ignite: v2.9.0
> JDK: v1.8
> .NET Core: v3.1
>Reporter: Danut Radoaica
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET, 2.9.1-rc
> Fix For: 2.11
>
> Attachments: BotXEntityDto.cs, ConsoleApp1.zip, exception.txt,
> stream_dump.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> [^exception.txt] contains the stack trace
> [^stream_dump.txt] contains the stream that fails, dumped using
> System.Text.Encoding.UTF8.GetString
> [^BotXEntityDto.cs] contains the dto definition
>
[jira] [Comment Edited] (IGNITE-14096) Try to bring randomization in node waiting with TcpDiscoverySpi.reconnectDelay.
[ https://issues.apache.org/jira/browse/IGNITE-14096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17274304#comment-17274304 ] Vladimir Steshin edited comment on IGNITE-14096 at 1/29/21, 10:39 AM: -- Typical timers to clean and start cluster of 44 nodes on the Discovery ducktape test [1]: 111-129s (for dev. and 2.9.0 versions) 'Ignite cluster start time (s)': 129.5 'Ignite cluster start time (s)': 112.2 'Ignite cluster start time (s)': 128.6 'Ignite cluster start time (s)': 129.1 'Ignite cluster start time (s)': 112.0 'Ignite cluster start time (s)': 111.4 With this PR it shows same results: 'Ignite cluster start time (s)': 128.8 'Ignite cluster start time (s)': 112.9 'Ignite cluster start time (s)': 129.0 'Ignite cluster start time (s)': 112.5 Logs attached. [1] https://github.com/apache/ignite/blob/ignite-ducktape/modules/ducktests/tests/ignitetest/tests/discovery_test.py was (Author: vladsz83): Typical timers to clean and start cluster of 44 nodes on the Discovery ducktape test [1]: 111-129s (for dev. and 2.9.0 versions) 'Ignite cluster start time (s)': 129.5 'Ignite cluster start time (s)': 112.2 'Ignite cluster start time (s)': 128.6 'Ignite cluster start time (s)': 129.1 'Ignite cluster start time (s)': 112.0 'Ignite cluster start time (s)': 111.4 With this PR it shows same results: 'Ignite cluster start time (s)': 128.8 'Ignite cluster start time (s)': 112.9 'Ignite cluster start time (s)': 129.0 'Ignite cluster start time (s)': 112.5 [1] https://github.com/apache/ignite/blob/ignite-ducktape/modules/ducktests/tests/ignitetest/tests/discovery_test.py > Try to bring randomization in node waiting with > TcpDiscoverySpi.reconnectDelay. > --- > > Key: IGNITE-14096 > URL: https://issues.apache.org/jira/browse/IGNITE-14096 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Attachments: session_log_14096_pr8723.info, session_log_standard.info > > Time Spent: 0.5h > Remaining Estimate: 0h > > To speed up cluster start slyghtly, try to bring randomization in node > waiting with TcpDiscoverySpi.reconnectDelay. Check with the ducktape > integration tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14095) Try to fasten cluster start in the ducktests with decreasing 'spi.reconnectDelay'
[ https://issues.apache.org/jira/browse/IGNITE-14095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17274296#comment-17274296 ] Vladimir Steshin edited comment on IGNITE-14095 at 1/29/21, 10:39 AM: -- Typical timers to clean and start cluster of 44 nodes on the Discovery ducktape test [1]: 110-129s (dev. and 2.9.0 versions) 'Ignite cluster start time (s)': 129.5 'Ignite cluster start time (s)': 112.2 'Ignite cluster start time (s)': 128.6 'Ignite cluster start time (s)': 112.0 'Ignite cluster start time (s)': 129.1 'Ignite cluster start time (s)': 127.8 With this PR: it shows same results: 'Ignite cluster start time (s)': 128.0 'Ignite cluster start time (s)': 111.8 'Ignite cluster start time (s)': 127.7 'Ignite cluster start time (s)': 110.6 'Ignite cluster start time (s)': 128.3 Logs attached. [1] https://github.com/apache/ignite/blob/ignite-ducktape/modules/ducktests/tests/ignitetest/tests/discovery_test.py was (Author: vladsz83): Typical timers to clean and start cluster of 44 nodes on the Discovery ducktape test [1]: 110-129s (dev. and 2.9.0 versions) 'Ignite cluster start time (s)': 129.5 'Ignite cluster start time (s)': 112.2 'Ignite cluster start time (s)': 128.6 'Ignite cluster start time (s)': 112.0 'Ignite cluster start time (s)': 129.1 'Ignite cluster start time (s)': 127.8 With this PR: it shows same results: 'Ignite cluster start time (s)': 128.0 'Ignite cluster start time (s)': 111.8 'Ignite cluster start time (s)': 127.7 'Ignite cluster start time (s)': 110.6 'Ignite cluster start time (s)': 128.3 [1] https://github.com/apache/ignite/blob/ignite-ducktape/modules/ducktests/tests/ignitetest/tests/discovery_test.py > Try to fasten cluster start in the ducktests with decreasing > 'spi.reconnectDelay' > - > > Key: IGNITE-14095 > URL: https://issues.apache.org/jira/browse/IGNITE-14095 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Attachments: session_log_ignite_14095_pr8722.info, > session_log_standard.info > > Time Spent: 0.5h > Remaining Estimate: 0h > > Try to speed up cluster start ath the ducktests with decreasing > TcpDiscoverySpi.reconnectDelay -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14096) Try to bring randomization in node waiting with TcpDiscoverySpi.reconnectDelay.
[ https://issues.apache.org/jira/browse/IGNITE-14096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-14096: -- Attachment: session_log_14096_pr8723.info > Try to bring randomization in node waiting with > TcpDiscoverySpi.reconnectDelay. > --- > > Key: IGNITE-14096 > URL: https://issues.apache.org/jira/browse/IGNITE-14096 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Attachments: session_log_14096_pr8723.info, session_log_standard.info > > Time Spent: 0.5h > Remaining Estimate: 0h > > To speed up cluster start slyghtly, try to bring randomization in node > waiting with TcpDiscoverySpi.reconnectDelay. Check with the ducktape > integration tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14096) Try to bring randomization in node waiting with TcpDiscoverySpi.reconnectDelay.
[ https://issues.apache.org/jira/browse/IGNITE-14096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-14096: -- Attachment: session_log_standard.info > Try to bring randomization in node waiting with > TcpDiscoverySpi.reconnectDelay. > --- > > Key: IGNITE-14096 > URL: https://issues.apache.org/jira/browse/IGNITE-14096 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Attachments: session_log_14096_pr8723.info, session_log_standard.info > > Time Spent: 0.5h > Remaining Estimate: 0h > > To speed up cluster start slyghtly, try to bring randomization in node > waiting with TcpDiscoverySpi.reconnectDelay. Check with the ducktape > integration tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IGNITE-14096) Try to bring randomization in node waiting with TcpDiscoverySpi.reconnectDelay.
[ https://issues.apache.org/jira/browse/IGNITE-14096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin closed IGNITE-14096. - Ignite Flags: (was: Docs Required,Release Notes Required) > Try to bring randomization in node waiting with > TcpDiscoverySpi.reconnectDelay. > --- > > Key: IGNITE-14096 > URL: https://issues.apache.org/jira/browse/IGNITE-14096 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > To speed up cluster start slyghtly, try to bring randomization in node > waiting with TcpDiscoverySpi.reconnectDelay. Check with the ducktape > integration tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-14096) Try to bring randomization in node waiting with TcpDiscoverySpi.reconnectDelay.
[ https://issues.apache.org/jira/browse/IGNITE-14096?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin resolved IGNITE-14096. --- Resolution: Invalid Won't work. Same results. No start speed up. > Try to bring randomization in node waiting with > TcpDiscoverySpi.reconnectDelay. > --- > > Key: IGNITE-14096 > URL: https://issues.apache.org/jira/browse/IGNITE-14096 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > To speed up cluster start slyghtly, try to bring randomization in node > waiting with TcpDiscoverySpi.reconnectDelay. Check with the ducktape > integration tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14095) Try to fasten cluster start in the ducktests with decreasing 'spi.reconnectDelay'
[ https://issues.apache.org/jira/browse/IGNITE-14095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17274296#comment-17274296 ] Vladimir Steshin edited comment on IGNITE-14095 at 1/29/21, 10:36 AM: -- Typical timers to clean and start cluster of 44 nodes on the Discovery ducktape test [1]: 110-129s (dev. and 2.9.0 versions) 'Ignite cluster start time (s)': 129.5 'Ignite cluster start time (s)': 112.2 'Ignite cluster start time (s)': 128.6 'Ignite cluster start time (s)': 112.0 'Ignite cluster start time (s)': 129.1 'Ignite cluster start time (s)': 127.8 With this PR: it shows same results: 'Ignite cluster start time (s)': 128.0 'Ignite cluster start time (s)': 111.8 'Ignite cluster start time (s)': 127.7 'Ignite cluster start time (s)': 110.6 'Ignite cluster start time (s)': 128.3 [1] https://github.com/apache/ignite/blob/ignite-ducktape/modules/ducktests/tests/ignitetest/tests/discovery_test.py was (Author: vladsz83): Typical timers to clean and start cluster of 44 nodes on the Discovery ducktape test [1]: 110-129s: 'Ignite cluster start time (s)': 129.5 'Ignite cluster start time (s)': 112.2 'Ignite cluster start time (s)': 128.6 'Ignite cluster start time (s)': 112.0 'Ignite cluster start time (s)': 129.1 'Ignite cluster start time (s)': 127.8 With this PR: it shows same results: 'Ignite cluster start time (s)': 128.0 'Ignite cluster start time (s)': 111.8 'Ignite cluster start time (s)': 127.7 'Ignite cluster start time (s)': 110.6 'Ignite cluster start time (s)': 128.3 [1] https://github.com/apache/ignite/blob/ignite-ducktape/modules/ducktests/tests/ignitetest/tests/discovery_test.py > Try to fasten cluster start in the ducktests with decreasing > 'spi.reconnectDelay' > - > > Key: IGNITE-14095 > URL: https://issues.apache.org/jira/browse/IGNITE-14095 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Attachments: session_log_ignite_14095_pr8722.info, > session_log_standard.info > > Time Spent: 0.5h > Remaining Estimate: 0h > > Try to speed up cluster start ath the ducktests with decreasing > TcpDiscoverySpi.reconnectDelay -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14096) Try to bring randomization in node waiting with TcpDiscoverySpi.reconnectDelay.
[ https://issues.apache.org/jira/browse/IGNITE-14096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17274304#comment-17274304 ] Vladimir Steshin commented on IGNITE-14096: --- Typical timers to clean and start cluster of 44 nodes on the Discovery ducktape test [1]: 111-129s (for dev. and 2.9.0 versions) 'Ignite cluster start time (s)': 129.5 'Ignite cluster start time (s)': 112.2 'Ignite cluster start time (s)': 128.6 'Ignite cluster start time (s)': 129.1 'Ignite cluster start time (s)': 112.0 'Ignite cluster start time (s)': 111.4 With this PR it shows same results: 'Ignite cluster start time (s)': 128.8 'Ignite cluster start time (s)': 112.9 'Ignite cluster start time (s)': 129.0 'Ignite cluster start time (s)': 112.5 [1] https://github.com/apache/ignite/blob/ignite-ducktape/modules/ducktests/tests/ignitetest/tests/discovery_test.py > Try to bring randomization in node waiting with > TcpDiscoverySpi.reconnectDelay. > --- > > Key: IGNITE-14096 > URL: https://issues.apache.org/jira/browse/IGNITE-14096 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > To speed up cluster start slyghtly, try to bring randomization in node > waiting with TcpDiscoverySpi.reconnectDelay. Check with the ducktape > integration tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14095) Try to fasten cluster start in the ducktests with decreasing 'spi.reconnectDelay'
[ https://issues.apache.org/jira/browse/IGNITE-14095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17274296#comment-17274296 ] Vladimir Steshin edited comment on IGNITE-14095 at 1/29/21, 10:35 AM: -- Typical timers to clean and start cluster of 44 nodes on the Discovery ducktape test [1]: 110-129s: 'Ignite cluster start time (s)': 129.5 'Ignite cluster start time (s)': 112.2 'Ignite cluster start time (s)': 128.6 'Ignite cluster start time (s)': 112.0 'Ignite cluster start time (s)': 129.1 'Ignite cluster start time (s)': 127.8 With this PR: it shows same results: 'Ignite cluster start time (s)': 128.0 'Ignite cluster start time (s)': 111.8 'Ignite cluster start time (s)': 127.7 'Ignite cluster start time (s)': 110.6 'Ignite cluster start time (s)': 128.3 [1] https://github.com/apache/ignite/blob/ignite-ducktape/modules/ducktests/tests/ignitetest/tests/discovery_test.py was (Author: vladsz83): Typical timers to clean and start cluster of 44 nodes on the Discovery ducktape test [1]: 110-129s: 'Ignite cluster start time (s)': 129.5 'Ignite cluster start time (s)': 112.2 'Ignite cluster start time (s)': 128.6 'Ignite cluster start time (s)': 112.0 'Ignite cluster start time (s)': 129.1 'Ignite cluster start time (s)': 127.8 With this PR: it shows same results: 'Ignite cluster start time (s)': 128.0 'Ignite cluster start time (s)': 111.8 'Ignite cluster start time (s)': 127.7 'Ignite cluster start time (s)': 110.6 'Ignite cluster start time (s)': 128.3 [1] https://github.com/apache/ignite/blob/ignite-ducktape/modules/ducktests/tests/ignitetest/tests/discovery_test.py > Try to fasten cluster start in the ducktests with decreasing > 'spi.reconnectDelay' > - > > Key: IGNITE-14095 > URL: https://issues.apache.org/jira/browse/IGNITE-14095 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Attachments: session_log_ignite_14095_pr8722.info, > session_log_standard.info > > Time Spent: 0.5h > Remaining Estimate: 0h > > Try to speed up cluster start ath the ducktests with decreasing > TcpDiscoverySpi.reconnectDelay -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IGNITE-14095) Try to fasten cluster start in the ducktests with decreasing 'spi.reconnectDelay'
[ https://issues.apache.org/jira/browse/IGNITE-14095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin closed IGNITE-14095. - > Try to fasten cluster start in the ducktests with decreasing > 'spi.reconnectDelay' > - > > Key: IGNITE-14095 > URL: https://issues.apache.org/jira/browse/IGNITE-14095 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Attachments: session_log_ignite_14095_pr8722.info, > session_log_standard.info > > Time Spent: 10m > > Try to speed up cluster start ath the ducktests with decreasing > TcpDiscoverySpi.reconnectDelay -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-14095) Try to fasten cluster start in the ducktests with decreasing 'spi.reconnectDelay'
[ https://issues.apache.org/jira/browse/IGNITE-14095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin resolved IGNITE-14095. --- Resolution: Invalid Won't work. Same results. No start speed up. > Try to fasten cluster start in the ducktests with decreasing > 'spi.reconnectDelay' > - > > Key: IGNITE-14095 > URL: https://issues.apache.org/jira/browse/IGNITE-14095 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Attachments: session_log_ignite_14095_pr8722.info, > session_log_standard.info > > Time Spent: 10m > > Try to speed up cluster start ath the ducktests with decreasing > TcpDiscoverySpi.reconnectDelay -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14095) Try to fasten cluster start in the ducktests with decreasing 'spi.reconnectDelay'
[ https://issues.apache.org/jira/browse/IGNITE-14095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-14095: -- Attachment: session_log_ignite_14095_pr8722.info > Try to fasten cluster start in the ducktests with decreasing > 'spi.reconnectDelay' > - > > Key: IGNITE-14095 > URL: https://issues.apache.org/jira/browse/IGNITE-14095 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Attachments: session_log_ignite_14095_pr8722.info, > session_log_standard.info > > Time Spent: 10m > > Try to speed up cluster start ath the ducktests with decreasing > TcpDiscoverySpi.reconnectDelay -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14095) Try to fasten cluster start in the ducktests with decreasing 'spi.reconnectDelay'
[ https://issues.apache.org/jira/browse/IGNITE-14095?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-14095: -- Attachment: session_log_standard.info > Try to fasten cluster start in the ducktests with decreasing > 'spi.reconnectDelay' > - > > Key: IGNITE-14095 > URL: https://issues.apache.org/jira/browse/IGNITE-14095 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Attachments: session_log_standard.info > > Time Spent: 10m > > Try to speed up cluster start ath the ducktests with decreasing > TcpDiscoverySpi.reconnectDelay -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14095) Try to fasten cluster start in the ducktests with decreasing 'spi.reconnectDelay'
[ https://issues.apache.org/jira/browse/IGNITE-14095?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17274296#comment-17274296 ] Vladimir Steshin commented on IGNITE-14095: --- Typical timers to clean and start cluster of 44 nodes on the Discovery ducktape test [1]: 110-129s: 'Ignite cluster start time (s)': 129.5 'Ignite cluster start time (s)': 112.2 'Ignite cluster start time (s)': 128.6 'Ignite cluster start time (s)': 112.0 'Ignite cluster start time (s)': 129.1 'Ignite cluster start time (s)': 127.8 With this PR: it shows same results: 'Ignite cluster start time (s)': 128.0 'Ignite cluster start time (s)': 111.8 'Ignite cluster start time (s)': 127.7 'Ignite cluster start time (s)': 110.6 'Ignite cluster start time (s)': 128.3 [1] https://github.com/apache/ignite/blob/ignite-ducktape/modules/ducktests/tests/ignitetest/tests/discovery_test.py > Try to fasten cluster start in the ducktests with decreasing > 'spi.reconnectDelay' > - > > Key: IGNITE-14095 > URL: https://issues.apache.org/jira/browse/IGNITE-14095 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > Time Spent: 10m > > Try to speed up cluster start ath the ducktests with decreasing > TcpDiscoverySpi.reconnectDelay -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-14097) Fix checkstyle plugin configuration
[ https://issues.apache.org/jira/browse/IGNITE-14097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semyon Danilov resolved IGNITE-14097. - Resolution: Won't Fix > Fix checkstyle plugin configuration > --- > > Key: IGNITE-14097 > URL: https://issues.apache.org/jira/browse/IGNITE-14097 > Project: Ignite > Issue Type: Improvement >Affects Versions: 3.0.0-alpha2 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12306) .NET: Java version is not taken into account when detecting JAVA_HOME
[ https://issues.apache.org/jira/browse/IGNITE-12306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-12306: Priority: Minor (was: Major) > .NET: Java version is not taken into account when detecting JAVA_HOME > - > > Key: IGNITE-12306 > URL: https://issues.apache.org/jira/browse/IGNITE-12306 > Project: Ignite > Issue Type: Bug > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Minor > Labels: .NET > > When multiple Java versions are installed on the machine, random one is > picked up. > For example, when 7 and 8 are installed, only 8 is suitable for Ignite. > We should check versions and pick the right one: > * Collect all known versions > * Filter out all below 8 > * Pick the lowest > Lower versions are prioritized - we don't want to use latest. Brand new Java > version with breaking changes might be released where Ignite does not work. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13460) .NET: Thin client can't be collected by GC when Dispose was not called
[ https://issues.apache.org/jira/browse/IGNITE-13460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-13460: Priority: Minor (was: Major) > .NET: Thin client can't be collected by GC when Dispose was not called > -- > > Key: IGNITE-13460 > URL: https://issues.apache.org/jira/browse/IGNITE-13460 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Minor > Labels: .NET > > If the user forgets to call IIgniteClient.Dispose, thin client objects will > remain in memory forever. > Thin client creates a dedicated response reader thread that holds a reference > to the entire thin client object tree though Marshaller object. > We should detect this scenario and clean up properly. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13600) .NET: TypeResolver uses legacy ReflectionOnlyLoad
[ https://issues.apache.org/jira/browse/IGNITE-13600?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-13600: Priority: Minor (was: Major) > .NET: TypeResolver uses legacy ReflectionOnlyLoad > - > > Key: IGNITE-13600 > URL: https://issues.apache.org/jira/browse/IGNITE-13600 > Project: Ignite > Issue Type: Bug > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Minor > Labels: .NET > Original Estimate: 8h > Remaining Estimate: 8h > > ReflectionOnlyLoad is not supported on .NET Core [1] [2] > * Replace ReflectionOnlyLoad with System.Reflection.Metadata if possible > * Enable TestReferencedAssemblyLoading > [1] > https://docs.microsoft.com/en-us/dotnet/api/system.reflection.assembly.reflectiononlyload?view=netcore-3.1 > [2] https://github.com/dotnet/runtime/issues/7452 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13607) .NET: Binary meta is not registered from QueryEntity on cache start when types are not present on server node
[
https://issues.apache.org/jira/browse/IGNITE-13607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-13607:
Priority: Minor (was: Major)
> .NET: Binary meta is not registered from QueryEntity on cache start when
> types are not present on server node
> -
>
> Key: IGNITE-13607
> URL: https://issues.apache.org/jira/browse/IGNITE-13607
> Project: Ignite
> Issue Type: Bug
> Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
> Labels: .NET
>
> When {{QueryEntity}} is present in {{CacheConfiguration}},
> {{GridQueryProcessor}} registers binary metadata for key and value types by
> looking up Java classes (IGNITE-5795) and .NET types (IGNITE-13160) and
> scanning attributes. In particular, Affinity Key is determined at this point
> and then cached for future use.
> However, when corresponding Java/.NET types are not present on the server
> node, affinity key can't be determined from annotations/attributes and is
> considered null.
> This can happens only with dynamic cache start in the following cases:
> * Thin clients - the most obvious case, classes are almost never present on
> server nodes
> * Thick clients
> * Server nodes with different classpath
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13639) .NET: Type cast exception on cache.Get with an array of empty Lists
[
https://issues.apache.org/jira/browse/IGNITE-13639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-13639:
Summary: .NET: Type cast exception on cache.Get with an array of empty
Lists (was: .NET: No coercion operator is defined between types 'System.Int32'
and 'swagger.Models.IndexParameter[]'.)
> .NET: Type cast exception on cache.Get with an array of empty Lists
> ---
>
> Key: IGNITE-13639
> URL: https://issues.apache.org/jira/browse/IGNITE-13639
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.9
> Environment: Apache Ignite: v2.9.0
> JDK: v1.8
> .NET Core: v3.1
>Reporter: Danut Radoaica
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET, 2.9.1-rc
> Fix For: 2.11
>
> Attachments: BotXEntityDto.cs, ConsoleApp1.zip, exception.txt,
> stream_dump.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> [^exception.txt] contains the stack trace
> [^stream_dump.txt] contains the stream that fails, dumped using
> System.Text.Encoding.UTF8.GetString
> [^BotXEntityDto.cs] contains the dto definition
> Minimal reproducer:
> {code}
> using System.Collections.Generic;
> using Apache.Ignite.Core;
> var ignite = Ignition.Start();
> var cache = ignite.GetOrCreateCache("c");
> cache.Put(1, new[]
> {
> new Entity {Inner = new List()},
> new Entity {Inner = new List()}
> });
> cache.Get(1);
> class Entity
> {
> public IList Inner { get; set; }
> }
> {code}
> Works on 2.8.0, fails on 2.9.1.
> The problem is that IGNITE-12827 has changed the detach semantics for arrays
> and collections, and this revealed the problem on .NET side: array and
> collection elements can share handles (same object references), which is a
> problem, because Java handles every element separately. And the bug occurs
> because an empty list has {{_items}} initialized to a shared empty array
> instance.
> *Workaround*: use {{List}} instead of {{Entity[]}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13639) .NET: No coercion operator is defined between types 'System.Int32' and 'swagger.Models.IndexParameter[]'.
[
https://issues.apache.org/jira/browse/IGNITE-13639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-13639:
Description:
[^exception.txt] contains the stack trace
[^stream_dump.txt] contains the stream that fails, dumped using
System.Text.Encoding.UTF8.GetString
[^BotXEntityDto.cs] contains the dto definition
Minimal reproducer:
{code}
using System.Collections.Generic;
using Apache.Ignite.Core;
var ignite = Ignition.Start();
var cache = ignite.GetOrCreateCache("c");
cache.Put(1, new[]
{
new Entity {Inner = new List()},
new Entity {Inner = new List()}
});
cache.Get(1);
class Entity
{
public IList Inner { get; set; }
}
{code}
Works on 2.8.0, fails on 2.9.1.
The problem is that IGNITE-12827 has changed the detach semantics for arrays
and collections, and this revealed the problem on .NET side: array and
collection elements can share handles (same object references), which is a
problem, because Java handles every element separately. And the bug occurs
because an empty list has {{_items}} initialized to a shared empty array
instance.
*Workaround*: use {{List}} instead of {{Entity[]}}
was:
[^exception.txt] contains the stack trace
[^stream_dump.txt] contains the stream that fails, dumped using
System.Text.Encoding.UTF8.GetString
[^BotXEntityDto.cs] contains the dto definition
Minimal reproducer:
{code}
using System.Collections.Generic;
using Apache.Ignite.Core;
var ignite = Ignition.Start();
var cache = ignite.GetOrCreateCache("c");
cache.Put(1, new[]
{
new Entity {Inner = new List()},
new Entity {Inner = new List()}
});
cache.Get(1);
class Entity
{
public IList Inner { get; set; }
}
{code}
Works on 2.8.0, fails on 2.9.1
*Workaround*: use {{List}} instead of {{Entity[]}}
> .NET: No coercion operator is defined between types 'System.Int32' and
> 'swagger.Models.IndexParameter[]'.
> -
>
> Key: IGNITE-13639
> URL: https://issues.apache.org/jira/browse/IGNITE-13639
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.9
> Environment: Apache Ignite: v2.9.0
> JDK: v1.8
> .NET Core: v3.1
>Reporter: Danut Radoaica
>Assignee: Pavel Tupitsyn
>Priority: Critical
> Labels: .NET, 2.9.1-rc
> Fix For: 2.11
>
> Attachments: BotXEntityDto.cs, ConsoleApp1.zip, exception.txt,
> stream_dump.txt
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> [^exception.txt] contains the stack trace
> [^stream_dump.txt] contains the stream that fails, dumped using
> System.Text.Encoding.UTF8.GetString
> [^BotXEntityDto.cs] contains the dto definition
> Minimal reproducer:
> {code}
> using System.Collections.Generic;
> using Apache.Ignite.Core;
> var ignite = Ignition.Start();
> var cache = ignite.GetOrCreateCache("c");
> cache.Put(1, new[]
> {
> new Entity {Inner = new List()},
> new Entity {Inner = new List()}
> });
> cache.Get(1);
> class Entity
> {
> public IList Inner { get; set; }
> }
> {code}
> Works on 2.8.0, fails on 2.9.1.
> The problem is that IGNITE-12827 has changed the detach semantics for arrays
> and collections, and this revealed the problem on .NET side: array and
> collection elements can share handles (same object references), which is a
> problem, because Java handles every element separately. And the bug occurs
> because an empty list has {{_items}} initialized to a shared empty array
> instance.
> *Workaround*: use {{List}} instead of {{Entity[]}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
