[jira] [Commented] (IGNITE-11592) NPE in case of continuing tx and cache stop operation.
[
https://issues.apache.org/jira/browse/IGNITE-11592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16846001#comment-16846001
]
Pavel Kovalenko commented on IGNITE-11592:
--
[~zstan] Looks good to me. Please proceed with merge.
> NPE in case of continuing tx and cache stop operation.
> ---
>
> Key: IGNITE-11592
> URL: https://issues.apache.org/jira/browse/IGNITE-11592
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 2h 40m
> Remaining Estimate: 0h
>
> Parallel cache stop and tx operations may lead to NPE.
> {code}
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.cache.CacheObjectImpl.finishUnmarshal(CacheObjectImpl.java:129)
> at
> org.apache.ignite.internal.processors.cache.transactions.TxEntryValueHolder.unmarshal(TxEntryValueHolder.java:151)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxEntry.unmarshal(IgniteTxEntry.java:964)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.unmarshal(IgniteTxHandler.java:306)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:338)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:154)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.lambda$null$0(IgniteTxHandler.java:580)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:496)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> i hope that correct decision would be to roll back tx (on exchange phase)
> participating in stopped caches.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11256) Implement read-only mode for grid
[
https://issues.apache.org/jira/browse/IGNITE-11256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845996#comment-16845996
]
Ignite TC Bot commented on IGNITE-11256:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=3912834]]
* ZookeeperDiscoverySpiTestSuite2:
GridCommandHandlerTest.testReadOnlyEnableDisable
* ZookeeperDiscoverySpiTestSuite2: GridCommandHandlerTest.testState
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3912465buildTypeId=IgniteTests24Java8_RunAll]
> Implement read-only mode for grid
> -
>
> Key: IGNITE-11256
> URL: https://issues.apache.org/jira/browse/IGNITE-11256
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexei Scherbakov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Should be triggered from control.sh utility.
> Useful for maintenance work, for example checking partition consistency
> (idle_verify)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
[ https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845953#comment-16845953 ] Ivan Fedotov edited comment on IGNITE-11708 at 5/22/19 3:01 PM: [~Pavlukhin] , I run TC with the latest changes, it seems not good now [1]. The problem is in NPE in IgniteCacheConfigVariationsAbstractTest#beforeTest [2]. With default VariationsTestsConfig all works fine, it is clear from the previous TC results. But when we use injected config, default ignite instance does not create - ignite() method returns null [3]. I think that the problem is in makeTestClass method when configs are injected [4]. For some reason, configs are not correct or are not correct injected. But this reason is unclear for me now. [1][https://ci.ignite.apache.org/viewLog.html?buildId=3911405=IgniteTests24Java8_RunAllNightly] [2] [https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteCacheConfigVariationsAbstractTest.java#L204] [3] [https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteCacheConfigVariationsAbstractTest.java#L469] [4] [https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/configvariations/ConfigVariationsTestSuiteBuilder.java#L434] was (Author: ivanan.fed): [~Pavlukhin] , I run TC with the latest changes, it seems not good now [1]. The problem is in NPE in IgniteCacheConfigVariationsAbstractTest#beforeTest [2]. With default VariationsTestsConfig all works fine, it is clear from the previous TC results. But when we use injected config, default ignite instance does not create - ignite() method returns null [3]. I think that the problem is in makeTestClass method when configs are injected. For some reason, configs are not correct or are not correct injected. But this reason is unclear for me now. [1][https://ci.ignite.apache.org/viewLog.html?buildId=3911405=IgniteTests24Java8_RunAllNightly] [2] [https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteCacheConfigVariationsAbstractTest.java#L204] [3] [https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteCacheConfigVariationsAbstractTest.java#L469] [4] [https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/configvariations/ConfigVariationsTestSuiteBuilder.java#L434] > Unable to run tests in IgniteConfigVariationsAbstractTest subclasses > > > Key: IGNITE-11708 > URL: https://issues.apache.org/jira/browse/IGNITE-11708 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep30 > Attachments: read_through_eviction_self_test.patch, > tx_out_test_fixed.patch > > Time Spent: 3h 20m > Remaining Estimate: 0h > > It seems that test classes that extend from > IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test > annotation. > It is easy to check: if throw exception in any test methods, nothing will > happen. > Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1], > maybe it destroys existing test workflow. > [1] > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11708) Unable to run tests in IgniteConfigVariationsAbstractTest subclasses
[ https://issues.apache.org/jira/browse/IGNITE-11708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845953#comment-16845953 ] Ivan Fedotov commented on IGNITE-11708: --- [~Pavlukhin] , I run TC with the latest changes, it seems not good now [1]. The problem is in NPE in IgniteCacheConfigVariationsAbstractTest#beforeTest [2]. With default VariationsTestsConfig all works fine, it is clear from the previous TC results. But when we use injected config, default ignite instance does not create - ignite() method returns null [3]. I think that the problem is in makeTestClass method when configs are injected. For some reason, configs are not correct or are not correct injected. But this reason is unclear for me now. [1][https://ci.ignite.apache.org/viewLog.html?buildId=3911405=IgniteTests24Java8_RunAllNightly] [2] [https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteCacheConfigVariationsAbstractTest.java#L204] [3] [https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteCacheConfigVariationsAbstractTest.java#L469] [4] [https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/configvariations/ConfigVariationsTestSuiteBuilder.java#L434] > Unable to run tests in IgniteConfigVariationsAbstractTest subclasses > > > Key: IGNITE-11708 > URL: https://issues.apache.org/jira/browse/IGNITE-11708 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep30 > Attachments: read_through_eviction_self_test.patch, > tx_out_test_fixed.patch > > Time Spent: 3h 20m > Remaining Estimate: 0h > > It seems that test classes that extend from > IgniteConfigVariationsAbstractTest cannot be started with JUnit4 @Test > annotation. > It is easy to check: if throw exception in any test methods, nothing will > happen. > Reason can be in rule chain in IgniteConfigVariationsAbstractTest class [1], > maybe it destroys existing test workflow. > [1] > https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/IgniteConfigVariationsAbstractTest.java#L62 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10078) Node failure during concurrent partition updates may cause partition desync between primary and backup.
[
https://issues.apache.org/jira/browse/IGNITE-10078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845931#comment-16845931
]
Alexei Scherbakov edited comment on IGNITE-10078 at 5/22/19 2:42 PM:
-
IgniteCache150ClientsTest from Cache 6 also oftenly timed out in master
[~ivan.glukos] All comments are fixed, ready for merge.
was (Author: ascherbakov):
_IgniteCache150ClientsTest from Cache 6 also oftenly timed out in master_
[~ivan.glukos] All comments are fixed, ready for merge.
> Node failure during concurrent partition updates may cause partition desync
> between primary and backup.
> ---
>
> Key: IGNITE-10078
> URL: https://issues.apache.org/jira/browse/IGNITE-10078
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> This is possible if some updates are not written to WAL before node failure.
> They will be not applied by rebalancing due to same partition counters in
> certain scenario:
> 1. Start grid with 3 nodes, 2 backups.
> 2. Preload some data to partition P.
> 3. Start two concurrent transactions writing single key to the same partition
> P, keys are different
> {noformat}
> try(Transaction tx = client.transactions().txStart(PESSIMISTIC,
> REPEATABLE_READ, 0, 1)) {
> client.cache(DEFAULT_CACHE_NAME).put(k, v);
> tx.commit();
> }
> {noformat}
> 4. Order updates on backup in the way such update with max partition counter
> is written to WAL and update with lesser partition counter failed due to
> triggering of FH before it's added to WAL
> 5. Return failed node to grid, observe no rebalancing due to same partition
> counters.
> Possible solution: detect gaps in update counters on recovery and force
> rebalance from a node without gaps if detected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10078) Node failure during concurrent partition updates may cause partition desync between primary and backup.
[
https://issues.apache.org/jira/browse/IGNITE-10078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845931#comment-16845931
]
Alexei Scherbakov commented on IGNITE-10078:
_IgniteCache150ClientsTest from Cache 6 also oftenly timed out in master_
[~ivan.glukos] All comments are fixed, ready for merge.
> Node failure during concurrent partition updates may cause partition desync
> between primary and backup.
> ---
>
> Key: IGNITE-10078
> URL: https://issues.apache.org/jira/browse/IGNITE-10078
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> This is possible if some updates are not written to WAL before node failure.
> They will be not applied by rebalancing due to same partition counters in
> certain scenario:
> 1. Start grid with 3 nodes, 2 backups.
> 2. Preload some data to partition P.
> 3. Start two concurrent transactions writing single key to the same partition
> P, keys are different
> {noformat}
> try(Transaction tx = client.transactions().txStart(PESSIMISTIC,
> REPEATABLE_READ, 0, 1)) {
> client.cache(DEFAULT_CACHE_NAME).put(k, v);
> tx.commit();
> }
> {noformat}
> 4. Order updates on backup in the way such update with max partition counter
> is written to WAL and update with lesser partition counter failed due to
> triggering of FH before it's added to WAL
> 5. Return failed node to grid, observe no rebalancing due to same partition
> counters.
> Possible solution: detect gaps in update counters on recovery and force
> rebalance from a node without gaps if detected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10078) Node failure during concurrent partition updates may cause partition desync between primary and backup.
[
https://issues.apache.org/jira/browse/IGNITE-10078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845927#comment-16845927
]
Ignite TC Bot commented on IGNITE-10078:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 6{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3912704]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3911754buildTypeId=IgniteTests24Java8_RunAll]
> Node failure during concurrent partition updates may cause partition desync
> between primary and backup.
> ---
>
> Key: IGNITE-10078
> URL: https://issues.apache.org/jira/browse/IGNITE-10078
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexei Scherbakov
>Assignee: Alexei Scherbakov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 2h 50m
> Remaining Estimate: 0h
>
> This is possible if some updates are not written to WAL before node failure.
> They will be not applied by rebalancing due to same partition counters in
> certain scenario:
> 1. Start grid with 3 nodes, 2 backups.
> 2. Preload some data to partition P.
> 3. Start two concurrent transactions writing single key to the same partition
> P, keys are different
> {noformat}
> try(Transaction tx = client.transactions().txStart(PESSIMISTIC,
> REPEATABLE_READ, 0, 1)) {
> client.cache(DEFAULT_CACHE_NAME).put(k, v);
> tx.commit();
> }
> {noformat}
> 4. Order updates on backup in the way such update with max partition counter
> is written to WAL and update with lesser partition counter failed due to
> triggering of FH before it's added to WAL
> 5. Return failed node to grid, observe no rebalancing due to same partition
> counters.
> Possible solution: detect gaps in update counters on recovery and force
> rebalance from a node without gaps if detected.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11256) Implement read-only mode for grid
[ https://issues.apache.org/jira/browse/IGNITE-11256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845867#comment-16845867 ] Sergey Antonov commented on IGNITE-11256: - [~ascherbakov] I created ticket for activate cluster in read-only mode IGNITE-11866. Also I fixed your comments. Please review again. > Implement read-only mode for grid > - > > Key: IGNITE-11256 > URL: https://issues.apache.org/jira/browse/IGNITE-11256 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Should be triggered from control.sh utility. > Useful for maintenance work, for example checking partition consistency > (idle_verify) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11866) Add ability to activate cluster in read-only mode
Sergey Antonov created IGNITE-11866: --- Summary: Add ability to activate cluster in read-only mode Key: IGNITE-11866 URL: https://issues.apache.org/jira/browse/IGNITE-11866 Project: Ignite Issue Type: Improvement Reporter: Sergey Antonov After IGNITE-11256 we have cluster read-only mode. We should have ability to activate cluster and enable read-only mode like atomic operation. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11865) FailureProcessor treats tcp-comm-worker as blocked when it works on reestablishing connect to failed client node
Sergey Chugunov created IGNITE-11865: Summary: FailureProcessor treats tcp-comm-worker as blocked when it works on reestablishing connect to failed client node Key: IGNITE-11865 URL: https://issues.apache.org/jira/browse/IGNITE-11865 Project: Ignite Issue Type: Bug Affects Versions: 2.7 Reporter: Sergey Chugunov Assignee: Sergey Chugunov Fix For: 2.8 When client node fails tcp-comm-worker thread on server keeps trying to reestablish connection to the client until failed node is removed from topology (on expiration of clientFailureDetectionTimeout). As tcp-comm-worker thread doesn't update its heartbeats from internal loops FailureProcessor considers it as blocked and prints out misleading message to logs along with full thread dump. To avoid polluting logs with unnecessary messages we need to teach tcp-comm-worker how to update its heartbeat timestamp in FailureProcessor. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11864) Log FileNotFoundException on restore if no segments were found.
[ https://issues.apache.org/jira/browse/IGNITE-11864?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-11864: Fix Version/s: 2.8 > Log FileNotFoundException on restore if no segments were found. > --- > > Key: IGNITE-11864 > URL: https://issues.apache.org/jira/browse/IGNITE-11864 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11864) Log FileNotFoundException on restore if no segments were found.
Ivan Bessonov created IGNITE-11864: -- Summary: Log FileNotFoundException on restore if no segments were found. Key: IGNITE-11864 URL: https://issues.apache.org/jira/browse/IGNITE-11864 Project: Ignite Issue Type: Improvement Reporter: Ivan Bessonov Assignee: Ivan Bessonov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11863) .NET: Add cluster read-only mode API (status, run-time change)
[ https://issues.apache.org/jira/browse/IGNITE-11863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-11863: Summary: .NET: Add cluster read-only mode API (status, run-time change) (was: .NET: Add clurster read-only mode API (status, run-time change)) > .NET: Add cluster read-only mode API (status, run-time change) > -- > > Key: IGNITE-11863 > URL: https://issues.apache.org/jira/browse/IGNITE-11863 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Sergey Antonov >Priority: Major > Labels: .NET > > We would introduce at IGNITE-11256 new methods in IgniteCluster. > We need their support in .Net side. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11863) .NET: Add clurster read-only mode API (status, run-time change)
Sergey Antonov created IGNITE-11863: --- Summary: .NET: Add clurster read-only mode API (status, run-time change) Key: IGNITE-11863 URL: https://issues.apache.org/jira/browse/IGNITE-11863 Project: Ignite Issue Type: Improvement Components: platforms Reporter: Sergey Antonov We would introduce at IGNITE-11256 new methods in IgniteCluster. We need their support in .Net side. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11862) Cache stopping on supplier during rebalance causes NPE and supplying failure.
[
https://issues.apache.org/jira/browse/IGNITE-11862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexei Scherbakov updated IGNITE-11862:
---
Fix Version/s: 2.8
> Cache stopping on supplier during rebalance causes NPE and supplying failure.
> -
>
> Key: IGNITE-11862
> URL: https://issues.apache.org/jira/browse/IGNITE-11862
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexei Scherbakov
>Priority: Major
> Fix For: 2.8
>
>
> {noformat}
> [21:12:14]W: [org.apache.ignite:ignite-core] [2019-05-20
> 21:12:14,376][ERROR][sys-#60310%distributed.CacheParallelStartTest0%][GridDhtPartitionSupplier]
> Failed to continue supplying [grp=static-cache-group45,
> demander=ed1c0109-8721-4cd8-80d9-d36e8251, top
> Ver=AffinityTopologyVersion [topVer=2, minorTopVer=0], topic=0]
> [21:12:14]W: [org.apache.ignite:ignite-core] java.lang.NullPointerException
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.addRebalanceSupplyEvent(CacheGroupContext.java:525)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionSupplier.handleDemandMessage(GridDhtPartitionSupplier.java:422)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleDemandMessage(GridDhtPreloader.java:397)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:455)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:440)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1141)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$800(GridCacheIoManager.java:109)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1706)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1566)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:129)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2795)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1523)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4500(GridIoManager.java:129)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1492)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> [21:12:14]W: [org.apache.ignite:ignite-core] at
> java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11862) Cache stopping on supplier during rebalance causes NPE and supplying failure.
Alexei Scherbakov created IGNITE-11862:
--
Summary: Cache stopping on supplier during rebalance causes NPE
and supplying failure.
Key: IGNITE-11862
URL: https://issues.apache.org/jira/browse/IGNITE-11862
Project: Ignite
Issue Type: Bug
Reporter: Alexei Scherbakov
{noformat}
[21:12:14]W: [org.apache.ignite:ignite-core] [2019-05-20
21:12:14,376][ERROR][sys-#60310%distributed.CacheParallelStartTest0%][GridDhtPartitionSupplier]
Failed to continue supplying [grp=static-cache-group45,
demander=ed1c0109-8721-4cd8-80d9-d36e8251, top
Ver=AffinityTopologyVersion [topVer=2, minorTopVer=0], topic=0]
[21:12:14]W: [org.apache.ignite:ignite-core] java.lang.NullPointerException
[21:12:14]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.processors.cache.CacheGroupContext.addRebalanceSupplyEvent(CacheGroupContext.java:525)
[21:12:14]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionSupplier.handleDemandMessage(GridDhtPartitionSupplier.java:422)
[21:12:14]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPreloader.handleDemandMessage(GridDhtPreloader.java:397)
[21:12:14]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:455)
[21:12:14]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$5.apply(GridCachePartitionExchangeManager.java:440)
[21:12:14]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1141)
[21:12:14]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
[21:12:14]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$800(GridCacheIoManager.java:109)
[21:12:14]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$OrderedMessageListener.onMessage(GridCacheIoManager.java:1706)
[21:12:14]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1566)
[21:12:14]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:129)
[21:12:14]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.managers.communication.GridIoManager$GridCommunicationMessageSet.unwind(GridIoManager.java:2795)
[21:12:14]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.managers.communication.GridIoManager.unwindMessageSet(GridIoManager.java:1523)
[21:12:14]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4500(GridIoManager.java:129)
[21:12:14]W: [org.apache.ignite:ignite-core] at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1492)
[21:12:14]W: [org.apache.ignite:ignite-core] at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
[21:12:14]W: [org.apache.ignite:ignite-core] at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
[21:12:14]W: [org.apache.ignite:ignite-core] at
java.lang.Thread.run(Thread.java:748)
{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11757) Missed partitions during rebalancing when new blank node joins
[ https://issues.apache.org/jira/browse/IGNITE-11757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev reassigned IGNITE-11757: Assignee: Vladislav Pyatkov (was: Ivan Rakov) > Missed partitions during rebalancing when new blank node joins > -- > > Key: IGNITE-11757 > URL: https://issues.apache.org/jira/browse/IGNITE-11757 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Ilya Kasnacheev >Assignee: Vladislav Pyatkov >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Please take a look at newly added test > GridCachePartitionedSupplyEventsSelfTest.testSupplyEvents > There's logging of missed partitions during rebalancing, and as you can see > partitions are missed even when a new node joins stable topology, with no > nodes leaving. > Expected behavior is that in this case no partitions will be missed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11757) Missed partitions during rebalancing when new blank node joins
[ https://issues.apache.org/jira/browse/IGNITE-11757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev updated IGNITE-11757: - Labels: MakeTeamcityGreenAgain (was: ) > Missed partitions during rebalancing when new blank node joins > -- > > Key: IGNITE-11757 > URL: https://issues.apache.org/jira/browse/IGNITE-11757 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Ilya Kasnacheev >Assignee: Vladislav Pyatkov >Priority: Minor > Labels: MakeTeamcityGreenAgain > Time Spent: 20m > Remaining Estimate: 0h > > Please take a look at newly added test > GridCachePartitionedSupplyEventsSelfTest.testSupplyEvents > There's logging of missed partitions during rebalancing, and as you can see > partitions are missed even when a new node joins stable topology, with no > nodes leaving. > Expected behavior is that in this case no partitions will be missed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-11757) Missed partitions during rebalancing when new blank node joins
[ https://issues.apache.org/jira/browse/IGNITE-11757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Kasnacheev resolved IGNITE-11757. -- Resolution: Fixed > Missed partitions during rebalancing when new blank node joins > -- > > Key: IGNITE-11757 > URL: https://issues.apache.org/jira/browse/IGNITE-11757 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Ilya Kasnacheev >Assignee: Vladislav Pyatkov >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Please take a look at newly added test > GridCachePartitionedSupplyEventsSelfTest.testSupplyEvents > There's logging of missed partitions during rebalancing, and as you can see > partitions are missed even when a new node joins stable topology, with no > nodes leaving. > Expected behavior is that in this case no partitions will be missed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11757) Missed partitions during rebalancing when new blank node joins
[ https://issues.apache.org/jira/browse/IGNITE-11757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845742#comment-16845742 ] Ilya Kasnacheev commented on IGNITE-11757: -- Thank you for fixing this test! I have merged it to master. > Missed partitions during rebalancing when new blank node joins > -- > > Key: IGNITE-11757 > URL: https://issues.apache.org/jira/browse/IGNITE-11757 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Ilya Kasnacheev >Assignee: Ivan Rakov >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Please take a look at newly added test > GridCachePartitionedSupplyEventsSelfTest.testSupplyEvents > There's logging of missed partitions during rebalancing, and as you can see > partitions are missed even when a new node joins stable topology, with no > nodes leaving. > Expected behavior is that in this case no partitions will be missed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11298) TcpCommunicationSpi does not support TLSv1.3
[
https://issues.apache.org/jira/browse/IGNITE-11298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845736#comment-16845736
]
Ilya Kasnacheev commented on IGNITE-11298:
--
[~VitaliyB] do you have plans to continue work on this issue?
> TcpCommunicationSpi does not support TLSv1.3
>
>
> Key: IGNITE-11298
> URL: https://issues.apache.org/jira/browse/IGNITE-11298
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.7
>Reporter: Ilya Kasnacheev
>Assignee: Vitaliy Biryukov
>Priority: Major
> Labels: Java11
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When started on Java 11 we cannot form a secure cluster - Discovery will
> happily use the default TLSv1.3 but Communication will fail with its custom
> SSLEngine-using code.
> Need to fix that.
> Until that, nodes may be salvaged by setProtocol("TLSv1.2") on
> SslContextFactory, or by system property -Djdk.tls.client.protocols="TLSv1.2"
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11791) Fix IgnitePdsContinuousRestartTestWithExpiryPolicy
[ https://issues.apache.org/jira/browse/IGNITE-11791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexei Scherbakov updated IGNITE-11791: --- Description: Test reproduces partition counter validation errors (but passes nevertheless). (was: Test reproduces partition counter validation errors.) > Fix IgnitePdsContinuousRestartTestWithExpiryPolicy > --- > > Key: IGNITE-11791 > URL: https://issues.apache.org/jira/browse/IGNITE-11791 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Priority: Major > > Test reproduces partition counter validation errors (but passes nevertheless). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11820) Add persistence to IgniteCacheGroupTest
[ https://issues.apache.org/jira/browse/IGNITE-11820?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexei Scherbakov updated IGNITE-11820: --- Summary: Add persistence to IgniteCacheGroupTest (was: Add partition consistency tests for multiple caches in group.) > Add persistence to IgniteCacheGroupTest > --- > > Key: IGNITE-11820 > URL: https://issues.apache.org/jira/browse/IGNITE-11820 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11756) SQL: implement a table row count statistics for the local queries
[
https://issues.apache.org/jira/browse/IGNITE-11756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845699#comment-16845699
]
Roman Kondakov commented on IGNITE-11756:
-
[~tledkov-gridgain], [~amashenkov], patch is ready for review. Tests look good.
> SQL: implement a table row count statistics for the local queries
> -
>
> Key: IGNITE-11756
> URL: https://issues.apache.org/jira/browse/IGNITE-11756
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Row count statistics should help the H2 optimizer to select the better query
> execution plan. Currently the row count supplied to H2 engine is hardcoded
> value == 1 (see {{org.h2.index.Index#getRowCountApproximation}}). As a
> first step we can provide an actual table size in the case of local query. To
> prevent counting size on each invocation we can cache row count value and
> invalidate it in some cases:
> * Rebalancing
> * Multiple updates (after the initial loading)
> * On timeout (i.e. 1 minute)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11756) SQL: implement a table row count statistics for the local queries
[
https://issues.apache.org/jira/browse/IGNITE-11756?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845698#comment-16845698
]
Ignite TC Bot commented on IGNITE-11756:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3904395buildTypeId=IgniteTests24Java8_RunAll]
> SQL: implement a table row count statistics for the local queries
> -
>
> Key: IGNITE-11756
> URL: https://issues.apache.org/jira/browse/IGNITE-11756
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Row count statistics should help the H2 optimizer to select the better query
> execution plan. Currently the row count supplied to H2 engine is hardcoded
> value == 1 (see {{org.h2.index.Index#getRowCountApproximation}}). As a
> first step we can provide an actual table size in the case of local query. To
> prevent counting size on each invocation we can cache row count value and
> invalidate it in some cases:
> * Rebalancing
> * Multiple updates (after the initial loading)
> * On timeout (i.e. 1 minute)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11671) Thin client: Client may hang when connected to a starting server
[
https://issues.apache.org/jira/browse/IGNITE-11671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845696#comment-16845696
]
Ignite TC Bot commented on IGNITE-11671:
{panel:title=-- Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3905360buildTypeId=IgniteTests24Java8_RunAll]
> Thin client: Client may hang when connected to a starting server
>
>
> Key: IGNITE-11671
> URL: https://issues.apache.org/jira/browse/IGNITE-11671
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If the server start process has not completed yet, but NIO listeners already
> started, the client may never get a response for the handshake request.
> Exception on the server-side:
>
> {noformat}
> [client-connector-#6416%f3b837aa-d726-46b0-a58b-8cc6267c9f96%][ClientListenerProcessor]
> Runtime error caught during grid runnable execution: GridWorker
> [name=message-received-notify,
> igniteInstanceName=f3b837aa-d726-46b0-a58b-8cc6267c9f96, finished=false,
> heartbeatTs=1554209548706, hashCode=519781823, interrupted=false,
> runner=client-connector-#6416%f3b837aa-d726-46b0-a58b-8cc6267c9f96%]
> java.lang.NullPointerException
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.nextConnectionId(ClientListenerNioListener.java:334)
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.prepareContext(ClientListenerNioListener.java:313)
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onHandshake(ClientListenerNioListener.java:251)
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:132)
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:48)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
> at
> org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70){noformat}
>
> This happens because NIO listeners start before {{GridDiscoveryManager}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11860) Temporarily peg SSL version to TLSv1.2 to fix Java 11/12
[ https://issues.apache.org/jira/browse/IGNITE-11860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845681#comment-16845681 ] Ilya Kasnacheev commented on IGNITE-11860: -- [~dpavlov] I have devised a temporary fix, but for some reason tests will fail. Is it an issue of 2.7.5? > Temporarily peg SSL version to TLSv1.2 to fix Java 11/12 > > > Key: IGNITE-11860 > URL: https://issues.apache.org/jira/browse/IGNITE-11860 > Project: Ignite > Issue Type: Improvement > Components: security >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Fix For: 2.7.5 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11858) IgniteClientRejoinTest.testClientsReconnectAfterStart is flaky
[ https://issues.apache.org/jira/browse/IGNITE-11858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845672#comment-16845672 ] Dmitriy Govorukhin commented on IGNITE-11858: - [~ibessonov] Looks good to me, thanks for the contribution! Merged to master. > IgniteClientRejoinTest.testClientsReconnectAfterStart is flaky > -- > > Key: IGNITE-11858 > URL: https://issues.apache.org/jira/browse/IGNITE-11858 > Project: Ignite > Issue Type: Test >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > [https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=594525236246121383=testDetails_IgniteTests24Java8=%3Cdefault%3E] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11757) Missed partitions during rebalancing when new blank node joins
[ https://issues.apache.org/jira/browse/IGNITE-11757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845605#comment-16845605 ] Vladislav Pyatkov commented on IGNITE-11757: Test passed https://ci.ignite.apache.org/viewLog.html?currentGroup=test=org.apache.ignite.testsuites.IgniteCacheTestSuite2%23teamcity%23*%23teamcity%23*=1=DURATION_DESC=20=testSupplyEvents==IgniteTests24Java8_RunAll=3905006=testsInfo > Missed partitions during rebalancing when new blank node joins > -- > > Key: IGNITE-11757 > URL: https://issues.apache.org/jira/browse/IGNITE-11757 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Ilya Kasnacheev >Assignee: Ivan Rakov >Priority: Minor > Time Spent: 20m > Remaining Estimate: 0h > > Please take a look at newly added test > GridCachePartitionedSupplyEventsSelfTest.testSupplyEvents > There's logging of missed partitions during rebalancing, and as you can see > partitions are missed even when a new node joins stable topology, with no > nodes leaving. > Expected behavior is that in this case no partitions will be missed. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10654) Report in case of creating index with already existing fields collection.
[
https://issues.apache.org/jira/browse/IGNITE-10654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16845596#comment-16845596
]
Stanilovsky Evgeny commented on IGNITE-10654:
-
[~jooger] i fixed both of your comments, plz take a look once more ?
> Report in case of creating index with already existing fields collection.
> -
>
> Key: IGNITE-10654
> URL: https://issues.apache.org/jira/browse/IGNITE-10654
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.7
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Report in log if new index creating with already existing fields collection.
> for example, need to log warn here:
> {code:java}
> cache.query(new SqlFieldsQuery("create index \"idx1\" on Val(keyStr,
> keyLong)"));
> cache.query(new SqlFieldsQuery("create index \"idx3\" on Val(keyStr,
> keyLong)"));
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
