[jira] [Updated] (IGNITE-11618) Assertion got removed exception on entry with dht local candidate on transaction timeout
[
https://issues.apache.org/jira/browse/IGNITE-11618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11618:
--
Fix Version/s: 2.8
> Assertion got removed exception on entry with dht local candidate on
> transaction timeout
>
>
> Key: IGNITE-11618
> URL: https://issues.apache.org/jira/browse/IGNITE-11618
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Priority: Major
> Fix For: 2.8
>
> Attachments: TxOptimisticSerializableTest.java
>
>
> IGNITE-11171 Did not fix the issue completely. The {{checkReadConflict}}
> method is called right before {{onEntriesLocked}} and contains the same
> assertion which may cause node failure.
> Attached test reproduces the problem if the following code is added to the
> very beginning of the {{checkReadConflict}} method:
> {code}
> U.sleep(ThreadLocalRandom.current().nextInt(200) + 1);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11618) Assertion got removed exception on entry with dht local candidate on transaction timeout
[
https://issues.apache.org/jira/browse/IGNITE-11618?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16799818#comment-16799818
]
Alexey Goncharuk commented on IGNITE-11618:
---
Similarly to IGNITE-11171 we need to replace the assertion with
{{onError(tx.rollbackException());}}.
However, it is still not clear why this situation may appear as timeout and
prepare stages are properly synchronized. Additional ticket for investigation
should be created before this ticket is resolved.
> Assertion got removed exception on entry with dht local candidate on
> transaction timeout
>
>
> Key: IGNITE-11618
> URL: https://issues.apache.org/jira/browse/IGNITE-11618
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Priority: Major
> Attachments: TxOptimisticSerializableTest.java
>
>
> IGNITE-11171 Did not fix the issue completely. The {{checkReadConflict}}
> method is called right before {{onEntriesLocked}} and contains the same
> assertion which may cause node failure.
> Attached test reproduces the problem if the following code is added to the
> very beginning of the {{checkReadConflict}} method:
> {code}
> U.sleep(ThreadLocalRandom.current().nextInt(200) + 1);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11618) Assertion got removed exception on entry with dht local candidate on transaction timeout
[
https://issues.apache.org/jira/browse/IGNITE-11618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11618:
--
Priority: Critical (was: Major)
> Assertion got removed exception on entry with dht local candidate on
> transaction timeout
>
>
> Key: IGNITE-11618
> URL: https://issues.apache.org/jira/browse/IGNITE-11618
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Priority: Critical
> Fix For: 2.8
>
> Attachments: TxOptimisticSerializableTest.java
>
>
> IGNITE-11171 Did not fix the issue completely. The {{checkReadConflict}}
> method is called right before {{onEntriesLocked}} and contains the same
> assertion which may cause node failure.
> Attached test reproduces the problem if the following code is added to the
> very beginning of the {{checkReadConflict}} method:
> {code}
> U.sleep(ThreadLocalRandom.current().nextInt(200) + 1);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11618) Assertion got removed exception on entry with dht local candidate on transaction timeout
[
https://issues.apache.org/jira/browse/IGNITE-11618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11618:
--
Attachment: TxOptimisticSerializableTest.java
> Assertion got removed exception on entry with dht local candidate on
> transaction timeout
>
>
> Key: IGNITE-11618
> URL: https://issues.apache.org/jira/browse/IGNITE-11618
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Priority: Major
> Attachments: TxOptimisticSerializableTest.java
>
>
> IGNITE-11171 Did not fix the issue completely. The {{checkReadConflict}}
> method is called right before {{onEntriesLocked}} and contains the same
> assertion which may cause node failure.
> Attached test reproduces the problem if the following code is added to the
> very beginning of the {{checkReadConflict}} method:
> {code}
> U.sleep(ThreadLocalRandom.current().nextInt(200) + 1);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11618) Assertion got removed exception on entry with dht local candidate on transaction timeout
[
https://issues.apache.org/jira/browse/IGNITE-11618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11618:
--
Description:
IGNITE-11171 Did not fix the issue completely. The {{checkReadConflict}} method
is called right before {{onEntriesLocked}} and contains the same assertion
which may cause node failure.
Attached test reproduces the problem if the following code is added to the very
beginning of the {{checkReadConflict}} method:
{code}
U.sleep(ThreadLocalRandom.current().nextInt(200) + 1);
{code}
> Assertion got removed exception on entry with dht local candidate on
> transaction timeout
>
>
> Key: IGNITE-11618
> URL: https://issues.apache.org/jira/browse/IGNITE-11618
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Priority: Major
>
> IGNITE-11171 Did not fix the issue completely. The {{checkReadConflict}}
> method is called right before {{onEntriesLocked}} and contains the same
> assertion which may cause node failure.
> Attached test reproduces the problem if the following code is added to the
> very beginning of the {{checkReadConflict}} method:
> {code}
> U.sleep(ThreadLocalRandom.current().nextInt(200) + 1);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11618) Assertion got removed exception on entry with dht local candidate on transaction timeout
[ https://issues.apache.org/jira/browse/IGNITE-11618?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-11618: -- Ignite Flags: (was: Docs Required) > Assertion got removed exception on entry with dht local candidate on > transaction timeout > > > Key: IGNITE-11618 > URL: https://issues.apache.org/jira/browse/IGNITE-11618 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Goncharuk >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11618) Assertion got removed exception on entry with dht local candidate on transaction timeout
Alexey Goncharuk created IGNITE-11618: - Summary: Assertion got removed exception on entry with dht local candidate on transaction timeout Key: IGNITE-11618 URL: https://issues.apache.org/jira/browse/IGNITE-11618 Project: Ignite Issue Type: Bug Reporter: Alexey Goncharuk -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11617) New exchange coordinator skips client fast reply for previous exchange
[
https://issues.apache.org/jira/browse/IGNITE-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11617:
--
Attachment: ClientFastReplyCoordinatorFailureTest.java
> New exchange coordinator skips client fast reply for previous exchange
> --
>
> Key: IGNITE-11617
> URL: https://issues.apache.org/jira/browse/IGNITE-11617
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Priority: Critical
> Fix For: 2.8
>
> Attachments: ClientFastReplyCoordinatorFailureTest.java
>
>
> The following scenario is broken:
> 1) A client joins topology, all server nodes complete client exchange, client
> delays sending it's single message
> 2) A new node joins topology, next exchange is started
> 3) Coordinator of the new exchange fails
> 4) New coordinator attempts to restore exchange state from all nodes,
> including client from step 1
> 5) Client send single message. The message should be processed by a
> fast-reply path because the corresponding exchange is completed. However,
> this does not happen because this exchange was completed with state {{SRV}}
> on new coordinator. Fast-reply is omitted and exchange hangs.
> Attached is a test reproducing the problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11617) New exchange coordinator skips client fast reply for previous exchange
[
https://issues.apache.org/jira/browse/IGNITE-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11617:
--
Description:
The following scenario is broken:
1) A client joins topology, all server nodes complete client exchange, client
delays sending it's single message
2) A new node joins topology, next exchange is started
3) Coordinator of the new exchange fails
4) New coordinator attempts to restore exchange state from all nodes, including
client from step 1
5) Client send single message. The message should be processed by a fast-reply
path because the corresponding exchange is completed. However, this does not
happen because this exchange was completed with state {{SRV}} on new
coordinator. Fast-reply is omitted and exchange hangs.
Attached is a test reproducing the problem.
> New exchange coordinator skips client fast reply for previous exchange
> --
>
> Key: IGNITE-11617
> URL: https://issues.apache.org/jira/browse/IGNITE-11617
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Priority: Major
>
> The following scenario is broken:
> 1) A client joins topology, all server nodes complete client exchange, client
> delays sending it's single message
> 2) A new node joins topology, next exchange is started
> 3) Coordinator of the new exchange fails
> 4) New coordinator attempts to restore exchange state from all nodes,
> including client from step 1
> 5) Client send single message. The message should be processed by a
> fast-reply path because the corresponding exchange is completed. However,
> this does not happen because this exchange was completed with state {{SRV}}
> on new coordinator. Fast-reply is omitted and exchange hangs.
> Attached is a test reproducing the problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11617) New exchange coordinator skips client fast reply for previous exchange
[
https://issues.apache.org/jira/browse/IGNITE-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11617:
--
Fix Version/s: 2.8
> New exchange coordinator skips client fast reply for previous exchange
> --
>
> Key: IGNITE-11617
> URL: https://issues.apache.org/jira/browse/IGNITE-11617
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Priority: Major
> Fix For: 2.8
>
>
> The following scenario is broken:
> 1) A client joins topology, all server nodes complete client exchange, client
> delays sending it's single message
> 2) A new node joins topology, next exchange is started
> 3) Coordinator of the new exchange fails
> 4) New coordinator attempts to restore exchange state from all nodes,
> including client from step 1
> 5) Client send single message. The message should be processed by a
> fast-reply path because the corresponding exchange is completed. However,
> this does not happen because this exchange was completed with state {{SRV}}
> on new coordinator. Fast-reply is omitted and exchange hangs.
> Attached is a test reproducing the problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11617) New exchange coordinator skips client fast reply for previous exchange
[
https://issues.apache.org/jira/browse/IGNITE-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11617:
--
Ignite Flags: (was: Docs Required)
> New exchange coordinator skips client fast reply for previous exchange
> --
>
> Key: IGNITE-11617
> URL: https://issues.apache.org/jira/browse/IGNITE-11617
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Priority: Major
>
> The following scenario is broken:
> 1) A client joins topology, all server nodes complete client exchange, client
> delays sending it's single message
> 2) A new node joins topology, next exchange is started
> 3) Coordinator of the new exchange fails
> 4) New coordinator attempts to restore exchange state from all nodes,
> including client from step 1
> 5) Client send single message. The message should be processed by a
> fast-reply path because the corresponding exchange is completed. However,
> this does not happen because this exchange was completed with state {{SRV}}
> on new coordinator. Fast-reply is omitted and exchange hangs.
> Attached is a test reproducing the problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11617) New exchange coordinator skips client fast reply for previous exchange
[
https://issues.apache.org/jira/browse/IGNITE-11617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11617:
--
Priority: Critical (was: Major)
> New exchange coordinator skips client fast reply for previous exchange
> --
>
> Key: IGNITE-11617
> URL: https://issues.apache.org/jira/browse/IGNITE-11617
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Priority: Critical
> Fix For: 2.8
>
>
> The following scenario is broken:
> 1) A client joins topology, all server nodes complete client exchange, client
> delays sending it's single message
> 2) A new node joins topology, next exchange is started
> 3) Coordinator of the new exchange fails
> 4) New coordinator attempts to restore exchange state from all nodes,
> including client from step 1
> 5) Client send single message. The message should be processed by a
> fast-reply path because the corresponding exchange is completed. However,
> this does not happen because this exchange was completed with state {{SRV}}
> on new coordinator. Fast-reply is omitted and exchange hangs.
> Attached is a test reproducing the problem.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11617) New exchange coordinator skips client fast reply for previous exchange
Alexey Goncharuk created IGNITE-11617: - Summary: New exchange coordinator skips client fast reply for previous exchange Key: IGNITE-11617 URL: https://issues.apache.org/jira/browse/IGNITE-11617 Project: Ignite Issue Type: Bug Reporter: Alexey Goncharuk -- 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=16799658#comment-16799658
]
Yury Gerzhedovich commented on IGNITE-10654:
[~zstan], under the hood for all index _key added at the and. e.g. for user
index for NAME, AGE will be create NAME, AGE, _KEY index. It required for
guarantee uniques key
> 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: 1.5h
> 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)
[jira] [Updated] (IGNITE-11615) IgniteBaselineAffinityTopologyActivationTest sometimes fails due to NPE on node stop
[
https://issues.apache.org/jira/browse/IGNITE-11615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11615:
--
Labels: MakeTeamcityGreenAgain (was: )
> IgniteBaselineAffinityTopologyActivationTest sometimes fails due to NPE on
> node stop
>
>
> Key: IGNITE-11615
> URL: https://issues.apache.org/jira/browse/IGNITE-11615
> Project: Ignite
> Issue Type: Test
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> I observe the following NPE in the test:
> {code}
> [13:24:30]W: [org.apache.ignite:ignite-core]
> java.lang.NullPointerException
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.onKernalStop(CacheGroupContext.java:742)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:1158)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2335)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2283)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2570)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2533)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:330)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.Ignition.stop(Ignition.java:223)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1187)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1230)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.persistence.IgniteBaselineAffinityTopologyActivationTest.afterTest(IgniteBaselineAffinityTopologyActivationTest.java:126)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1804)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.testframework.junits.JUnit3TestLegacySupport.runTestCase(JUnit3TestLegacySupport.java:70)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.testframework.junits.GridAbstractTest$2.evaluate(GridAbstractTest.java:185)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.junit.rules.RunRules.evaluate(RunRules.java:20)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.testframework.junits.GridAbstractTest.evaluateInsideFixture(GridAbstractTest.java:2579)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.testframework.junits.GridAbstractTest.access$500(GridAbstractTest.java:152)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
>
[jira] [Commented] (IGNITE-11615) IgniteBaselineAffinityTopologyActivationTest sometimes fails due to NPE on node stop
[
https://issues.apache.org/jira/browse/IGNITE-11615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16799656#comment-16799656
]
Alexey Goncharuk commented on IGNITE-11615:
---
It is safely to ignore the {{null}} field for preloader because by the time the
NPE happens exchange worker is already stopped and preloader will not be
created.
> IgniteBaselineAffinityTopologyActivationTest sometimes fails due to NPE on
> node stop
>
>
> Key: IGNITE-11615
> URL: https://issues.apache.org/jira/browse/IGNITE-11615
> Project: Ignite
> Issue Type: Test
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.8
>
>
> I observe the following NPE in the test:
> {code}
> [13:24:30]W: [org.apache.ignite:ignite-core]
> java.lang.NullPointerException
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.onKernalStop(CacheGroupContext.java:742)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:1158)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2335)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2283)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2570)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2533)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:330)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.Ignition.stop(Ignition.java:223)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1187)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1230)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.persistence.IgniteBaselineAffinityTopologyActivationTest.afterTest(IgniteBaselineAffinityTopologyActivationTest.java:126)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1804)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.testframework.junits.JUnit3TestLegacySupport.runTestCase(JUnit3TestLegacySupport.java:70)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.testframework.junits.GridAbstractTest$2.evaluate(GridAbstractTest.java:185)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.junit.rules.RunRules.evaluate(RunRules.java:20)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.testframework.junits.GridAbstractTest.evaluateInsideFixture(GridAbstractTest.java:2579)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
>
[jira] [Created] (IGNITE-11616) NPE in MvccProcessorImpl when stopping a starting node
Alexey Goncharuk created IGNITE-11616:
-
Summary: NPE in MvccProcessorImpl when stopping a starting node
Key: IGNITE-11616
URL: https://issues.apache.org/jira/browse/IGNITE-11616
Project: Ignite
Issue Type: Test
Components: sql
Reporter: Alexey Goncharuk
Fix For: 2.8
I observe the following NPE in IgniteBaselineAffinityTopologyActivationTest.
It happens because we shutdown when MVCC coordinator is not assigned yet
{code}
java.lang.NullPointerException
at
java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
at
java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
at
org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onCoordinatorFailed(MvccProcessorImpl.java:527)
at
org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onKernalStop(MvccProcessorImpl.java:459)
at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2335)
at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2283)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1194)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1992)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1683)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1109)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:607)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:984)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:925)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:913)
at
org.apache.ignite.internal.processors.cache.persistence.IgniteBaselineAffinityTopologyActivationTest.startGridWithConsistentId(IgniteBaselineAffinityTopologyActivationTest.java:729)
at
org.apache.ignite.internal.processors.cache.persistence.IgniteBaselineAffinityTopologyActivationTest.testNodeWithBltIsNotAllowedToJoinClusterDuringFirstActivation(IgniteBaselineAffinityTopologyActivationTest.java:532)
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:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2102)
at java.lang.Thread.run(Thread.java:745)
{code}
>From the first glance it looks like we can simply ignore the {{null}} node ID,
>however, there is a race - in {{onKernalStop}} we block a busy lock and remove
>discovery listener, then do a coordinator cleanup. However, the discovery
>notification worker is only stopped in {{stop}} phase, but MVCC manager does a
>cleanup in {{onKernalStop}} phase - so listener can execute some code after
>the {{onKernalStop}} is executed because there is no busy lock protection in
>the discovery listener itself.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11615) IgniteBaselineAffinityTopologyActivationTest sometimes fails due to NPE on node stop
[
https://issues.apache.org/jira/browse/IGNITE-11615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11615:
--
Description:
I observe the following NPE in the test:
{code}
[13:24:30]W: [org.apache.ignite:ignite-core]
java.lang.NullPointerException
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.cache.CacheGroupContext.onKernalStop(CacheGroupContext.java:742)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:1158)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2335)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2283)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2570)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2533)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:330)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.Ignition.stop(Ignition.java:223)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1187)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1230)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.cache.persistence.IgniteBaselineAffinityTopologyActivationTest.afterTest(IgniteBaselineAffinityTopologyActivationTest.java:126)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.testframework.junits.GridAbstractTest.tearDown(GridAbstractTest.java:1804)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.testframework.junits.JUnit3TestLegacySupport.runTestCase(JUnit3TestLegacySupport.java:70)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.testframework.junits.GridAbstractTest$2.evaluate(GridAbstractTest.java:185)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.junit.rules.TestWatcher$1.evaluate(TestWatcher.java:55)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.junit.rules.RunRules.evaluate(RunRules.java:20)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.testframework.junits.GridAbstractTest.evaluateInsideFixture(GridAbstractTest.java:2579)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.testframework.junits.GridAbstractTest.access$500(GridAbstractTest.java:152)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.testframework.junits.GridAbstractTest$BeforeFirstAndAfterLastTestRule$1.evaluate(GridAbstractTest.java:2559)
{code}
was:
I observe two kind of NPEs in the test:
The first one happens because we shutdown when MVCC coordinator is not assigned
yet
{code}
java.lang.NullPointerException
at
java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
at
java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
at
org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onCoordinatorFailed(MvccProcessorImpl.java:527)
at
[jira] [Updated] (IGNITE-11615) IgniteBaselineAffinityTopologyActivationTest sometimes fails due to NPE on node stop
[
https://issues.apache.org/jira/browse/IGNITE-11615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-11615:
--
Ignite Flags: (was: Docs Required)
> IgniteBaselineAffinityTopologyActivationTest sometimes fails due to NPE on
> node stop
>
>
> Key: IGNITE-11615
> URL: https://issues.apache.org/jira/browse/IGNITE-11615
> Project: Ignite
> Issue Type: Test
>Reporter: Alexey Goncharuk
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.8
>
>
> I observe two kind of NPEs in the test:
> The first one happens because we shutdown when MVCC coordinator is not
> assigned yet
> {code}
> java.lang.NullPointerException
> at
> java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
> at
> java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onCoordinatorFailed(MvccProcessorImpl.java:527)
> at
> org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onKernalStop(MvccProcessorImpl.java:459)
> at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2335)
> at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2283)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1194)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1992)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1683)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1109)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:607)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:984)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:925)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:913)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteBaselineAffinityTopologyActivationTest.startGridWithConsistentId(IgniteBaselineAffinityTopologyActivationTest.java:729)
> at
> org.apache.ignite.internal.processors.cache.persistence.IgniteBaselineAffinityTopologyActivationTest.testNodeWithBltIsNotAllowedToJoinClusterDuringFirstActivation(IgniteBaselineAffinityTopologyActivationTest.java:532)
> 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:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> at
> org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2102)
> at java.lang.Thread.run(Thread.java:745)
> {code}
> The second one happens because we shutdown before the preloader was
> initialized:
> {code}
> [13:24:30]W: [org.apache.ignite:ignite-core]
> java.lang.NullPointerException
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.CacheGroupContext.onKernalStop(CacheGroupContext.java:742)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:1158)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2335)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2283)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2570)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2533)
> [13:24:30]W: [org.apache.ignite:ignite-core]at
>
[jira] [Created] (IGNITE-11615) IgniteBaselineAffinityTopologyActivationTest sometimes fails due to NPE on node stop
Alexey Goncharuk created IGNITE-11615:
-
Summary: IgniteBaselineAffinityTopologyActivationTest sometimes
fails due to NPE on node stop
Key: IGNITE-11615
URL: https://issues.apache.org/jira/browse/IGNITE-11615
Project: Ignite
Issue Type: Test
Reporter: Alexey Goncharuk
Assignee: Alexey Goncharuk
Fix For: 2.8
I observe two kind of NPEs in the test:
The first one happens because we shutdown when MVCC coordinator is not assigned
yet
{code}
java.lang.NullPointerException
at
java.util.concurrent.ConcurrentHashMap.replaceNode(ConcurrentHashMap.java:1106)
at
java.util.concurrent.ConcurrentHashMap.remove(ConcurrentHashMap.java:1097)
at
org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onCoordinatorFailed(MvccProcessorImpl.java:527)
at
org.apache.ignite.internal.processors.cache.mvcc.MvccProcessorImpl.onKernalStop(MvccProcessorImpl.java:459)
at org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2335)
at org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2283)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1194)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1992)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1683)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1109)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:607)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:984)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:925)
at
org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:913)
at
org.apache.ignite.internal.processors.cache.persistence.IgniteBaselineAffinityTopologyActivationTest.startGridWithConsistentId(IgniteBaselineAffinityTopologyActivationTest.java:729)
at
org.apache.ignite.internal.processors.cache.persistence.IgniteBaselineAffinityTopologyActivationTest.testNodeWithBltIsNotAllowedToJoinClusterDuringFirstActivation(IgniteBaselineAffinityTopologyActivationTest.java:532)
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:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2102)
at java.lang.Thread.run(Thread.java:745)
{code}
The second one happens because we shutdown before the preloader was initialized:
{code}
[13:24:30]W: [org.apache.ignite:ignite-core]
java.lang.NullPointerException
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.cache.CacheGroupContext.onKernalStop(CacheGroupContext.java:742)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.onKernalStop(GridCacheProcessor.java:1158)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.IgniteKernal.stop0(IgniteKernal.java:2335)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.IgniteKernal.stop(IgniteKernal.java:2283)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop0(IgnitionEx.java:2570)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.stop(IgnitionEx.java:2533)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.internal.IgnitionEx.stop(IgnitionEx.java:330)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.Ignition.stop(Ignition.java:223)
[13:24:30]W: [org.apache.ignite:ignite-core]at
org.apache.ignite.testframework.junits.GridAbstractTest.stopGrid(GridAbstractTest.java:1187)
[13:24:30]W: [org.apache.ignite:ignite-core]
[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=16799646#comment-16799646
]
Stanilovsky Evgeny commented on IGNITE-10654:
-
[~jooger], thanks a lot for review, i have no clue how could i create idx under
_KEY field.
> 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: 1.5h
> 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)
[jira] [Commented] (IGNITE-11568) Change afterTest() annotation in TcpDiscoveryFailedJoinTest
[ https://issues.apache.org/jira/browse/IGNITE-11568?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16799607#comment-16799607 ] Ivan Fedotov commented on IGNITE-11568: --- The TC results for RunAll (Nightly) are ready [1]. There are no blockers. [1] [https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAllNightly=pull/6303/head=Latest] > Change afterTest() annotation in TcpDiscoveryFailedJoinTest > --- > > Key: IGNITE-11568 > URL: https://issues.apache.org/jira/browse/IGNITE-11568 > Project: Ignite > Issue Type: Bug >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > afterTest() method in TcpDiscoveryFailedJoinTest is overridden and annotated > by after. Meanwhile, it is under prohibition because afterTest will be > executed after test anyway (see JUnit3TestLegacySupport and > beforeTest/afterTest usage in GridAbstractTest for more details). > > So, it is necessary to change after annotation on override. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11043) CPP Thin: Improve Best Effort Affinity for C++ thin client
[ https://issues.apache.org/jira/browse/IGNITE-11043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16799568#comment-16799568 ] Pavel Tupitsyn commented on IGNITE-11043: - [~isapego] please see some comments in UpSource. My primary concern are tests. Are the following cases covered? * Enable/disable the feature * Request routing to proper node * Complex keys (user-defined) * Topology update (add node, remove node) > CPP Thin: Improve Best Effort Affinity for C++ thin client > -- > > Key: IGNITE-11043 > URL: https://issues.apache.org/jira/browse/IGNITE-11043 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 2.7 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: iep-23 > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > [IEP-23|https://cwiki.apache.org/confluence/display/IGNITE/IEP-23%3A+Best+Effort+Affinity+for+thin+clients] > was updated recently, and we need to implement described changes in C++ > thin client. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
