[jira] [Commented] (IGNITE-10663) Implement cache mode allows reads with consistency check and fix
[
https://issues.apache.org/jira/browse/IGNITE-10663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808171#comment-16808171
]
Ignite TC Bot commented on IGNITE-10663:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests
5|https://ci.ignite.apache.org/viewLog.html?buildId=3491092]]
* ZookeeperDiscoverySpiTestSuite2:
IgniteClientReconnectCacheTest.testTxStateAfterClientReconnect - 0,3% fails in
last 349 master runs.
* ZookeeperDiscoverySpiTestSuite2:
IgniteClientReconnectCacheTest.testReconnectMultinodeLongHistory - 0,0% fails
in last 349 master runs.
* ZookeeperDiscoverySpiTestSuite2:
IgniteClientReconnectCacheTest.testReconnectCacheDestroyedAndCreated - 0,0%
fails in last 349 master runs.
* ZookeeperDiscoverySpiTestSuite2:
IgniteClientReconnectCacheTest.testReconnectInitialExchangeInProgress - 0,0%
fails in last 349 master runs.
{color:#d04437}Continuous Query 3{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3491127]]
{color:#d04437}Thin client: Node.js{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3491095]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3491169buildTypeId=IgniteTests24Java8_RunAll]
> Implement cache mode allows reads with consistency check and fix
>
>
> Key: IGNITE-10663
> URL: https://issues.apache.org/jira/browse/IGNITE-10663
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.8
>
>
> The main idea is to provide special "read from cache" mode which will read a
> value from primary and all backups and will check that values are the same.
> In case values differ they should be fixed according to the appropriate
> strategy.
> ToDo list:
> 1) {{cache.withConsistency().get(key)}} should guarantee values will be
> checked across the topology and fixed if necessary.
> 2) LWW (Last Write Wins) strategy should be used for validation.
> 3) Since LWW and any other strategy do not guarantee that the correct value
> will be chosen.
> We have to record the event contains all values and the chosen one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11673) SQL: It looks like security check is missed in h2 indexing.
Roman Kondakov created IGNITE-11673:
---
Summary: SQL: It looks like security check is missed in h2
indexing.
Key: IGNITE-11673
URL: https://issues.apache.org/jira/browse/IGNITE-11673
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Roman Kondakov
Assignee: Roman Kondakov
Security check is no longer conducted in {{IgniteH2Indexing#executeSelect0}}
after IGNITE-10104 having been merged.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7101) .NET: IIgnite.GetVersion
[
https://issues.apache.org/jira/browse/IGNITE-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807975#comment-16807975
]
Ignite TC Bot commented on IGNITE-7101:
---
{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=3445665buildTypeId=IgniteTests24Java8_RunAll]
> .NET: IIgnite.GetVersion
>
>
> Key: IGNITE-7101
> URL: https://issues.apache.org/jira/browse/IGNITE-7101
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Alexandr Shapkin
>Priority: Trivial
> Labels: .NET, newbie
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Add {{IIgnite.GetVersion}} method and {{IClusterNode.Version}} property.
--
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=16807931#comment-16807931 ] Igor Sapego commented on IGNITE-11043: -- [~vozerov] please, take another look at the code - I've tried to handle your 5th remark. > 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)
[jira] [Updated] (IGNITE-11614) Transaction with timeout on cache hangs after cache store failure
[ https://issues.apache.org/jira/browse/IGNITE-11614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Kurbanov updated IGNITE-11614: Attachment: CacheStoreTxPutAllMultiNodeTest.java > Transaction with timeout on cache hangs after cache store failure > - > > Key: IGNITE-11614 > URL: https://issues.apache.org/jira/browse/IGNITE-11614 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Anton Kurbanov >Priority: Major > Attachments: CacheStoreTxPutAllMultiNodeTest.java > > > If CacheStore fails before/during transaction commit, transaction with set > timeout remains active. > Setting cfg.setTransactionConfiguration(new > TransactionConfiguration().setTxTimeoutOnPartitionMapExchange(5000)); fixes > the issue in test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11614) Transaction with timeout on cache hangs after cache store failure
[ https://issues.apache.org/jira/browse/IGNITE-11614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Kurbanov updated IGNITE-11614: Attachment: (was: GridNearCacheStoreTxPutAllMultiNodeTest.java) > Transaction with timeout on cache hangs after cache store failure > - > > Key: IGNITE-11614 > URL: https://issues.apache.org/jira/browse/IGNITE-11614 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Anton Kurbanov >Priority: Major > > If CacheStore fails before/during transaction commit, transaction with set > timeout remains active. > Setting cfg.setTransactionConfiguration(new > TransactionConfiguration().setTxTimeoutOnPartitionMapExchange(5000)); fixes > the issue in test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11614) Transaction with timeout on cache hangs after cache store failure
[ https://issues.apache.org/jira/browse/IGNITE-11614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Kurbanov updated IGNITE-11614: Description: If CacheStore fails before/during transaction commit, transaction with set timeout remains active. Setting cfg.setTransactionConfiguration(new TransactionConfiguration().setTxTimeoutOnPartitionMapExchange(5000)); fixes the issue in test. > Transaction with timeout on cache hangs after cache store failure > - > > Key: IGNITE-11614 > URL: https://issues.apache.org/jira/browse/IGNITE-11614 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Anton Kurbanov >Priority: Major > > If CacheStore fails before/during transaction commit, transaction with set > timeout remains active. > Setting cfg.setTransactionConfiguration(new > TransactionConfiguration().setTxTimeoutOnPartitionMapExchange(5000)); fixes > the issue in test. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11672) JdbcThinConnectionSelfTest.testInvalidEndpoint failed after thin client retry
Ilya Kasnacheev created IGNITE-11672: Summary: JdbcThinConnectionSelfTest.testInvalidEndpoint failed after thin client retry Key: IGNITE-11672 URL: https://issues.apache.org/jira/browse/IGNITE-11672 Project: Ignite Issue Type: Bug Components: clients Reporter: Ilya Kasnacheev Assignee: Ilya Kasnacheev Broken after IGNITE-11599 Looks like error message/exception has changed -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11413) Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport
[ https://issues.apache.org/jira/browse/IGNITE-11413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807876#comment-16807876 ] Ivan Fedotov commented on IGNITE-11413: --- [~Pavlukhin], Thus, I will close current issue as "Not a problem". In the context of JUnit 3->4 migration it remains only IGNITE-11412 which is about some documentation stuff. > Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport > - > > Key: IGNITE-11413 > URL: https://issues.apache.org/jira/browse/IGNITE-11413 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep-30 > > beforeTestsStarted and afterTestsStarted methods are deprecated in context of > JUnit4 functional. The 4th version provides @BeforeClass, @AfterClass > annotations for such purposes. Methods must be moved in corresponded classes > and marked by annotations. > It could require changes in start/stop nodes process because methods under > @BeforeClass, @AfterClass annotations must be static. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11629) Cassandra dependencies missing from deliverable
[ https://issues.apache.org/jira/browse/IGNITE-11629?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807874#comment-16807874 ] Vladimir Pligin commented on IGNITE-11629: -- Looks good to me > Cassandra dependencies missing from deliverable > --- > > Key: IGNITE-11629 > URL: https://issues.apache.org/jira/browse/IGNITE-11629 > Project: Ignite > Issue Type: Bug > Components: cassandra >Affects Versions: 2.7 >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Labels: easyfix > Time Spent: 20m > Remaining Estimate: 0h > > After IGNITE-9046 we lack an explicit netty-resolver dependency for > ignite-cassandra-store module. This means that tests still run, project can > be made working by fixing dependencies, but apache-ignite-bin deliverable's > libs/optional/ignite-cassandra-store does not contain all required > depencencies since we only put explicit ones there. > Need to add this dependency explicitly, check that it works. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11614) Transaction with timeout on cache hangs after cache store failure
[ https://issues.apache.org/jira/browse/IGNITE-11614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Kurbanov updated IGNITE-11614: Attachment: GridNearCacheStoreTxPutAllMultiNodeTest.java > Transaction with timeout on cache hangs after cache store failure > - > > Key: IGNITE-11614 > URL: https://issues.apache.org/jira/browse/IGNITE-11614 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Anton Kurbanov >Priority: Major > Attachments: GridNearCacheStoreTxPutAllMultiNodeTest.java > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11614) Transaction with timeout on cache hangs after cache store failure
[ https://issues.apache.org/jira/browse/IGNITE-11614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Kurbanov updated IGNITE-11614: Summary: Transaction with timeout on cache hangs after cache store failure (was: Transaction with timeout on cache with near configuration hangs after cache store failure indefinitely) > Transaction with timeout on cache hangs after cache store failure > - > > Key: IGNITE-11614 > URL: https://issues.apache.org/jira/browse/IGNITE-11614 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Anton Kurbanov >Priority: Major > Attachments: GridNearCacheStoreTxPutAllMultiNodeTest.java > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11413) Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport
[ https://issues.apache.org/jira/browse/IGNITE-11413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807859#comment-16807859 ] Ivan Pavlukhin commented on IGNITE-11413: - [~ivanan.fed], I think currently it is not critical. > Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport > - > > Key: IGNITE-11413 > URL: https://issues.apache.org/jira/browse/IGNITE-11413 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Labels: iep-30 > > beforeTestsStarted and afterTestsStarted methods are deprecated in context of > JUnit4 functional. The 4th version provides @BeforeClass, @AfterClass > annotations for such purposes. Methods must be moved in corresponded classes > and marked by annotations. > It could require changes in start/stop nodes process because methods under > @BeforeClass, @AfterClass annotations must be static. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11413) Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport
[
https://issues.apache.org/jira/browse/IGNITE-11413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807834#comment-16807834
]
Ivan Fedotov commented on IGNITE-11413:
---
[~Pavlukhin], yes, except of those fact that {{setUp}} and {{tearDown}} methods
locate in {{runTest}}.
Do you think that making them out of {{runTest}}, directly in {{runRule}} will
make code more understandable?
> Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport
> -
>
> Key: IGNITE-11413
> URL: https://issues.apache.org/jira/browse/IGNITE-11413
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
> Labels: iep-30
>
> beforeTestsStarted and afterTestsStarted methods are deprecated in context of
> JUnit4 functional. The 4th version provides @BeforeClass, @AfterClass
> annotations for such purposes. Methods must be moved in corresponded classes
> and marked by annotations.
> It could require changes in start/stop nodes process because methods under
> @BeforeClass, @AfterClass annotations must be static.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11334) SQL: Deprecate SqlQuery
[
https://issues.apache.org/jira/browse/IGNITE-11334?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807829#comment-16807829
]
Vladimir Ozerov commented on IGNITE-11334:
--
[~tledkov-gridgain], do we have TC visa?
> SQL: Deprecate SqlQuery
> ---
>
> Key: IGNITE-11334
> URL: https://issues.apache.org/jira/browse/IGNITE-11334
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: usability
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This API is very limited comparing to {{SqlFieldsQuery}}. Let's deprecate it
> with proper links to {{SqlFieldsQuery}}. This should be not only deprecation
> on public API, but removal from examples as well.
> Separate ticket for documentation is needed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10104) MVCC TX: client SFU doesn't work on replicated caches
[
https://issues.apache.org/jira/browse/IGNITE-10104?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807824#comment-16807824
]
Vladimir Ozerov commented on IGNITE-10104:
--
Merged to master.
> MVCC TX: client SFU doesn't work on replicated caches
> -
>
> Key: IGNITE-10104
> URL: https://issues.apache.org/jira/browse/IGNITE-10104
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Igor Seliverstov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: transactions
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When select for update executes from client node the execution is sent to
> random owning node. On that node dht enlist operation is started what causes
> an assertion error because dht enlist operation implies that the node is
> primary for all processed keys.
> see
> {{CacheMvccReplicatedBackupsTest.testBackupsCoherenceWithLargeOperations}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11600) Fix launch script for Java 12 - clearly state that version is not supported
[
https://issues.apache.org/jira/browse/IGNITE-11600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807792#comment-16807792
]
Ignite TC Bot commented on IGNITE-11600:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}SPI{color} [[tests
47|https://ci.ignite.apache.org/viewLog.html?buildId=3489311]]
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientNodeLeave - 0,0% fails in
last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testReconnectSegmentedAfterJoinTimeoutServerFailed
- 0,0% fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientNodeFailOneServer - 0,0%
fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientAndRouterFail - 0,0%
fails in last 354 master runs.
* IgniteSpiTestSuite: TcpClientDiscoverySpiFailureTimeoutSelfTest.testMetrics -
0,0% fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientReconnectOnRouterSuspend
- 0,0% fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testPingFailedClientNode - 0,0%
fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientNodeFail - 0,0% fails in
last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientReconnectTopologyChange1
- 0,0% fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientNodeJoin - 0,0% fails in
last 354 master runs.
* IgniteSpiTestSuite: TcpDiscoverySegmentationPolicyTest.testStopOnSegmentation
- 0,0% fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientReconnectTopologyChange2
- 0,0% fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientNodeJoinOneServer - 0,0%
fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testServerNodeFail - 0,0% fails in
last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testReconnectAfterFail - 0,0% fails
in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testDisconnectAfterNetworkTimeout -
0,0% fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientMessageWorkerStartSingleServer
- 0,0% fails in last 354 master runs.
* IgniteSpiTestSuite: AuthenticationRestartTest.testClientReconnect - 0,0%
fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testDuplicateId - 0,0% fails in
last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientReconnectOneServerOneClient
- 0,0% fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testForceClientReconnect - 0,0%
fails in last 354 master runs.
* IgniteSpiTestSuite: TcpClientDiscoverySpiFailureTimeoutSelfTest.testPing -
0,0% fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testReconnectClusterRestart - 0,0%
fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientSegmentation - 0,0% fails
in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testReconnectAfterFailConcurrentJoin
- 0,0% fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientNodeLeaveOneServer - 0,0%
fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testServerNodeJoin - 0,0% fails in
last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testJoinTimeout - 0,0% fails in
last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testReconnectAfterMassiveTopologyChange
- 0,0% fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientMessageWorkerStartTwoServers1
- 0,0% fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testGridStartTime - 0,0% fails in
last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientReconnectOnRouterFail -
0,0% fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testClientFailReconnectDisabled -
0,0% fails in last 354 master runs.
* IgniteSpiTestSuite:
TcpClientDiscoverySpiFailureTimeoutSelfTest.testReconnectAfterPause - 0,0%
fails in last 354 master runs.
* IgniteSpiTestSuite:
[jira] [Comment Edited] (IGNITE-11413) Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport
[
https://issues.apache.org/jira/browse/IGNITE-11413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807769#comment-16807769
]
Ivan Pavlukhin edited comment on IGNITE-11413 at 4/2/19 1:46 PM:
-
[~ivanan.fed], indeed you are right. By some reason I thought of a code
(schematically) like below. But effectively current code does the same.
{code}
@Rule public transient TestRule runRule = (base, desc) -> new Statement() {
@Override public void evaluate() throws Throwable {
assert getName() != null : "getName returned null";
setUp();
try {
runTest(base);
}
finally {
tearDown();
}
}
};
{code}
was (Author: pavlukhin):
[~ivanan.fed], indeed you are right. By some reason I thought of a code
(schematically) like below. But effectively current code does the same.
```
@Rule public transient TestRule runRule = (base, desc) -> new Statement() {
@Override public void evaluate() throws Throwable {
assert getName() != null : "getName returned null";
setUp();
try {
runTest(base);
}
finally {
tearDown();
}
}
};
```
> Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport
> -
>
> Key: IGNITE-11413
> URL: https://issues.apache.org/jira/browse/IGNITE-11413
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
> Labels: iep-30
>
> beforeTestsStarted and afterTestsStarted methods are deprecated in context of
> JUnit4 functional. The 4th version provides @BeforeClass, @AfterClass
> annotations for such purposes. Methods must be moved in corresponded classes
> and marked by annotations.
> It could require changes in start/stop nodes process because methods under
> @BeforeClass, @AfterClass annotations must be static.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11413) Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport
[
https://issues.apache.org/jira/browse/IGNITE-11413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807769#comment-16807769
]
Ivan Pavlukhin commented on IGNITE-11413:
-
[~ivanan.fed], indeed you are right. By some reason I thought of a code
(schematically) like below. But effectively current code does the same.
```
@Rule public transient TestRule runRule = (base, desc) -> new Statement() {
@Override public void evaluate() throws Throwable {
assert getName() != null : "getName returned null";
setUp();
try {
runTest(base);
}
finally {
tearDown();
}
}
};
```
> Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport
> -
>
> Key: IGNITE-11413
> URL: https://issues.apache.org/jira/browse/IGNITE-11413
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
> Labels: iep-30
>
> beforeTestsStarted and afterTestsStarted methods are deprecated in context of
> JUnit4 functional. The 4th version provides @BeforeClass, @AfterClass
> annotations for such purposes. Methods must be moved in corresponded classes
> and marked by annotations.
> It could require changes in start/stop nodes process because methods under
> @BeforeClass, @AfterClass annotations must be static.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11670) Java thin client: Queries are inconsistent in case of failover
[
https://issues.apache.org/jira/browse/IGNITE-11670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-11670:
---
Affects Version/s: 2.7
> Java thin client: Queries are inconsistent in case of failover
> --
>
> Key: IGNITE-11670
> URL: https://issues.apache.org/jira/browse/IGNITE-11670
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.7
>Reporter: Aleksey Plekhanov
>Priority: Major
>
> When a thin client does failover and switches to a new server, open cursors
> become inconsistent and silently returns the wrong result.
> Reproducer:
> {code:java}
> public void testQueryFailover() throws Exception {
> try (LocalIgniteCluster cluster = LocalIgniteCluster.start(1);
> IgniteClient client = Ignition.startClient(new
> ClientConfiguration()
> .setAddresses(cluster.clientAddresses().iterator().next()))
> ) {
> ObjectName mbeanName =
> U.makeMBeanName(Ignition.allGrids().get(0).name(), "Clients",
> ClientListenerProcessor.class.getSimpleName());
> ClientProcessorMXBean mxBean =
> MBeanServerInvocationHandler.newProxyInstance(
> ManagementFactory.getPlatformMBeanServer(), mbeanName,
> ClientProcessorMXBean.class, true);
> ClientCache cache = client.createCache("cache");
> cache.put(0, 0);
> cache.put(1, 1);
> Query> qry = new ScanQuery String>().setPageSize(1);
> try (QueryCursor> cur =
> cache.query(qry)) {
> int cnt = 0;
> for (Iterator> it =
> cur.iterator(); it.hasNext(); it.next()) {
> cnt++;
> if (cnt == 1)
> mxBean.dropAllConnections();
> }
> assertEquals(2, cnt);
> }
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11671) Thin client: Client may hang when connected to a starting server
Aleksey Plekhanov created IGNITE-11671:
--
Summary: 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
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] [Created] (IGNITE-11670) Java thin client: Queries are inconsistent in case of failover
Aleksey Plekhanov created IGNITE-11670:
--
Summary: Java thin client: Queries are inconsistent in case of
failover
Key: IGNITE-11670
URL: https://issues.apache.org/jira/browse/IGNITE-11670
Project: Ignite
Issue Type: Bug
Components: thin client
Reporter: Aleksey Plekhanov
When a thin client does failover and switches to a new server, open cursors
become inconsistent and silently returns the wrong result.
Reproducer:
{code:java}
public void testQueryFailover() throws Exception {
try (LocalIgniteCluster cluster = LocalIgniteCluster.start(1);
IgniteClient client = Ignition.startClient(new
ClientConfiguration()
.setAddresses(cluster.clientAddresses().iterator().next()))
) {
ObjectName mbeanName =
U.makeMBeanName(Ignition.allGrids().get(0).name(), "Clients",
ClientListenerProcessor.class.getSimpleName());
ClientProcessorMXBean mxBean =
MBeanServerInvocationHandler.newProxyInstance(
ManagementFactory.getPlatformMBeanServer(), mbeanName,
ClientProcessorMXBean.class, true);
ClientCache cache = client.createCache("cache");
cache.put(0, 0);
cache.put(1, 1);
Query> qry = new ScanQuery().setPageSize(1);
try (QueryCursor> cur =
cache.query(qry)) {
int cnt = 0;
for (Iterator> it =
cur.iterator(); it.hasNext(); it.next()) {
cnt++;
if (cnt == 1)
mxBean.dropAllConnections();
}
assertEquals(2, cnt);
}
}
}
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11600) Fix launch script for Java 12 - clearly state that version is not supported
[ https://issues.apache.org/jira/browse/IGNITE-11600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807721#comment-16807721 ] Dmitriy Pavlov commented on IGNITE-11600: - [~agoncharuk], could you please review the proposed solution? https://github.com/apache/ignite/pull/6384 In subtask and alternative branch, I've enforced the new ByteBuffer creation approach for Java 8 and all tests were passed here: https://issues.apache.org/jira/browse/IGNITE-11669?focusedCommentId=16807696=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-16807696 https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/6385/head=Latest > Fix launch script for Java 12 - clearly state that version is not supported > --- > > Key: IGNITE-11600 > URL: https://issues.apache.org/jira/browse/IGNITE-11600 > Project: Ignite > Issue Type: Bug >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Critical > Labels: important > Fix For: 2.8, 2.7.5 > > Time Spent: 50m > Remaining Estimate: 0h > > bin/ignite.bat:251 > if "%MAJOR_JAVA_VER%" == "11" ( > need to change to "%MAJOR_JAVA_VER%" GEQ "11" ( -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11669) Research/test reflection based approach for creating direct buffers
[
https://issues.apache.org/jira/browse/IGNITE-11669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807696#comment-16807696
]
Ignite TC Bot commented on IGNITE-11669:
{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=3482844buildTypeId=IgniteTests24Java8_RunAll]
> Research/test reflection based approach for creating direct buffers
> ---
>
> Key: IGNITE-11669
> URL: https://issues.apache.org/jira/browse/IGNITE-11669
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In 2.7.5 discussion
> https://lists.apache.org/thread.html/e575a96bd1eb2fe323006314c15f9fcce7400d56b8ba7a5587ebe44c@%3Cdev.ignite.apache.org%3E
> Ivan Pavluchin proposed a simple fix for the byte buffer creation problem:
> https://lists.apache.org/thread.html/84a35e720af7a0af849685d6abfd7d80a72eab9d7513106262568afa@%3Cdev.ignite.apache.org%3E
> It is necessary to test this approach (probably enforcing to apply it for all
> Javas)
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8409) Ignite gets stuck on IgniteDataStreamer.addData when using Object with AffinityKeyMapped
[ https://issues.apache.org/jira/browse/IGNITE-8409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov reassigned IGNITE-8409: Assignee: Alexey Goncharuk (was: Peter Ivanov) > Ignite gets stuck on IgniteDataStreamer.addData when using Object with > AffinityKeyMapped > > > Key: IGNITE-8409 > URL: https://issues.apache.org/jira/browse/IGNITE-8409 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.3, 2.4 >Reporter: Andrey Aleksandrov >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.8 > > Attachments: ContextCpty.java, TradeKey.java, TradeKeyNew.java > > > This problem reproduces from time to time when we are streaming the data > (TradeKey.java) to Ignite sql cache. As AffinityKeyMapped we used the object > type (ContextCpty.java) > When we change AffinityKeyMapped type from object to long type > (TradeKeyNew.java) then problem disappears. > Investigation help to understand that we hang in BPlusTree.java class in next > method: > private Result putDown(final Put p, final long pageId, final long fwdId, > final int lvl) > In this method: > res = p.tryReplaceInner(pageId, page, fwdId, lvl); > if (res != RETRY) // Go down recursively. > res = putDown(p, p.pageId, p.fwdId, lvl - 1); > if (res == RETRY_ROOT || p.isFinished()) > return res; > if (res == RETRY) > checkInterrupted(); //WE ALWAYS GO TO THIS PLACE -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8409) Ignite gets stuck on IgniteDataStreamer.addData when using Object with AffinityKeyMapped
[ https://issues.apache.org/jira/browse/IGNITE-8409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov updated IGNITE-8409: - Affects Version/s: (was: 2.4) > Ignite gets stuck on IgniteDataStreamer.addData when using Object with > AffinityKeyMapped > > > Key: IGNITE-8409 > URL: https://issues.apache.org/jira/browse/IGNITE-8409 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Andrey Aleksandrov >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.8 > > Attachments: ContextCpty.java, TradeKey.java, TradeKeyNew.java > > > This problem reproduces from time to time when we are streaming the data > (TradeKey.java) to Ignite sql cache. As AffinityKeyMapped we used the object > type (ContextCpty.java) > When we change AffinityKeyMapped type from object to long type > (TradeKeyNew.java) then problem disappears. > Investigation help to understand that we hang in BPlusTree.java class in next > method: > private Result putDown(final Put p, final long pageId, final long fwdId, > final int lvl) > In this method: > res = p.tryReplaceInner(pageId, page, fwdId, lvl); > if (res != RETRY) // Go down recursively. > res = putDown(p, p.pageId, p.fwdId, lvl - 1); > if (res == RETRY_ROOT || p.isFinished()) > return res; > if (res == RETRY) > checkInterrupted(); //WE ALWAYS GO TO THIS PLACE -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8409) Ignite gets stuck on IgniteDataStreamer.addData when using Object with AffinityKeyMapped
[ https://issues.apache.org/jira/browse/IGNITE-8409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov updated IGNITE-8409: - Affects Version/s: 2.4 > Ignite gets stuck on IgniteDataStreamer.addData when using Object with > AffinityKeyMapped > > > Key: IGNITE-8409 > URL: https://issues.apache.org/jira/browse/IGNITE-8409 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.3, 2.4 >Reporter: Andrey Aleksandrov >Assignee: Alexey Goncharuk >Priority: Major > Fix For: 2.8 > > Attachments: ContextCpty.java, TradeKey.java, TradeKeyNew.java > > > This problem reproduces from time to time when we are streaming the data > (TradeKey.java) to Ignite sql cache. As AffinityKeyMapped we used the object > type (ContextCpty.java) > When we change AffinityKeyMapped type from object to long type > (TradeKeyNew.java) then problem disappears. > Investigation help to understand that we hang in BPlusTree.java class in next > method: > private Result putDown(final Put p, final long pageId, final long fwdId, > final int lvl) > In this method: > res = p.tryReplaceInner(pageId, page, fwdId, lvl); > if (res != RETRY) // Go down recursively. > res = putDown(p, p.pageId, p.fwdId, lvl - 1); > if (res == RETRY_ROOT || p.isFinished()) > return res; > if (res == RETRY) > checkInterrupted(); //WE ALWAYS GO TO THIS PLACE -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8409) Ignite gets stuck on IgniteDataStreamer.addData when using Object with AffinityKeyMapped
[ https://issues.apache.org/jira/browse/IGNITE-8409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov reassigned IGNITE-8409: Assignee: Peter Ivanov (was: Alexey Goncharuk) > Ignite gets stuck on IgniteDataStreamer.addData when using Object with > AffinityKeyMapped > > > Key: IGNITE-8409 > URL: https://issues.apache.org/jira/browse/IGNITE-8409 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.3, 2.4 >Reporter: Andrey Aleksandrov >Assignee: Peter Ivanov >Priority: Major > Fix For: 2.8 > > Attachments: ContextCpty.java, TradeKey.java, TradeKeyNew.java > > > This problem reproduces from time to time when we are streaming the data > (TradeKey.java) to Ignite sql cache. As AffinityKeyMapped we used the object > type (ContextCpty.java) > When we change AffinityKeyMapped type from object to long type > (TradeKeyNew.java) then problem disappears. > Investigation help to understand that we hang in BPlusTree.java class in next > method: > private Result putDown(final Put p, final long pageId, final long fwdId, > final int lvl) > In this method: > res = p.tryReplaceInner(pageId, page, fwdId, lvl); > if (res != RETRY) // Go down recursively. > res = putDown(p, p.pageId, p.fwdId, lvl - 1); > if (res == RETRY_ROOT || p.isFinished()) > return res; > if (res == RETRY) > checkInterrupted(); //WE ALWAYS GO TO THIS PLACE -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8465) Reject control.sh connecton to a cluster in case the versions differ
[ https://issues.apache.org/jira/browse/IGNITE-8465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov reassigned IGNITE-8465: Assignee: (was: Peter Ivanov) > Reject control.sh connecton to a cluster in case the versions differ > > > Key: IGNITE-8465 > URL: https://issues.apache.org/jira/browse/IGNITE-8465 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Dmitry Sherstobitov >Priority: Major > > control.sh --tx from 2.5 for now may be launched with 2.4 cluster e.g > It may cause errors on cluster > > This communications should be prevented in control.sh utility -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8465) Reject control.sh connecton to a cluster in case the versions differ
[ https://issues.apache.org/jira/browse/IGNITE-8465?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov reassigned IGNITE-8465: Assignee: Peter Ivanov > Reject control.sh connecton to a cluster in case the versions differ > > > Key: IGNITE-8465 > URL: https://issues.apache.org/jira/browse/IGNITE-8465 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.5 >Reporter: Dmitry Sherstobitov >Assignee: Peter Ivanov >Priority: Major > > control.sh --tx from 2.5 for now may be launched with 2.4 cluster e.g > It may cause errors on cluster > > This communications should be prevented in control.sh utility -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-11397) Binary mode for Ignite Set
[
https://issues.apache.org/jira/browse/IGNITE-11397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807642#comment-16807642
]
Uday Kale commented on IGNITE-11397:
Thanks for reviewing my code [~ibessonov]
Regarding
private static final boolean BINARY_SET_MODE =
IgniteSystemProperties.getBoolean(BINARY_SET, true);
Yes this is wrong I need to set default as true. The true value is set in
IgniteCacheDataStructuresBinarySelfTestSuite.
{code:java}
public IgniteSet withKeepBinary();{code}
There are types like Integer, String, Enum, etc apart from BinaryObject
possible here.
I am still trying to study the last part. I will get back to you if I have any
questions.
> Binary mode for Ignite Set
> --
>
> Key: IGNITE-11397
> URL: https://issues.apache.org/jira/browse/IGNITE-11397
> Project: Ignite
> Issue Type: New Feature
> Components: binary, data structures
>Reporter: Uday Kale
>Assignee: Uday Kale
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Add binary mode (withKeepBinary) to Data Structures Set.
> This will allow retrieving values in binary format when needed or when class
> is not available, and will allow implementing the structures in other
> platforms (.NET, C++).
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11413) Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport
[
https://issues.apache.org/jira/browse/IGNITE-11413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807641#comment-16807641
]
Ivan Fedotov commented on IGNITE-11413:
---
[~Pavlukhin],
In principal {{beforeTest/afterTest}} methods now work from rule. It is clear
from {{GridAbstractTest}} class: methods are used in {{setUp}}, {{tearDown}}
respectively. And the last ones are used under rule in {{runTest}} method [1].
What kind of work do you mean?
[1][https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/testframework/junits/GridAbstractTest.java#L2035]
> Remove beforeTestsStarted, afterTestsStarted from JUnit3TestLegacySupport
> -
>
> Key: IGNITE-11413
> URL: https://issues.apache.org/jira/browse/IGNITE-11413
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
> Labels: iep-30
>
> beforeTestsStarted and afterTestsStarted methods are deprecated in context of
> JUnit4 functional. The 4th version provides @BeforeClass, @AfterClass
> annotations for such purposes. Methods must be moved in corresponded classes
> and marked by annotations.
> It could require changes in start/stop nodes process because methods under
> @BeforeClass, @AfterClass annotations must be static.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10789) CacheInterceptor on server node get BinaryObject if put was invoked by ClientCache.
[
https://issues.apache.org/jira/browse/IGNITE-10789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov reassigned IGNITE-10789:
---
Assignee: (was: Sergey Antonov)
> CacheInterceptor on server node get BinaryObject if put was invoked by
> ClientCache.
> ---
>
> Key: IGNITE-10789
> URL: https://issues.apache.org/jira/browse/IGNITE-10789
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7
>Reporter: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Cache interceptor on server node expects deserialized object, but gets
> BinaryObject in case of put was from thin client.
> The exception is following:
> {noformat}
> [2018-12-21
> 17:25:08,213][ERROR][client-connector-#53%cache.Test20%][ClientListenerNioListener]
> Failed to process client request
> [req=o.a.i.i.processors.platform.client.cache.ClientCachePutRequest@72009659]
> org.apache.ignite.cache.CachePartialUpdateException: Failed to update keys
> (retry update if possible).: [key]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1313)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1754)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1107)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:820)
> at
> org.apache.ignite.internal.processors.platform.client.cache.ClientCachePutRequest.process(ClientCachePutRequest.java:40)
> at
> org.apache.ignite.internal.processors.platform.client.ClientRequestHandler.handle(ClientRequestHandler.java:52)
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:174)
> 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)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class
> org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException:
> Failed to update keys (retry update if possible).: [key]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:397)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.onPrimaryResponse(GridNearAtomicSingleUpdateFuture.java:252)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture$1.apply(GridNearAtomicAbstractUpdateFuture.java:304)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture$1.apply(GridNearAtomicAbstractUpdateFuture.java:301)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.map(GridDhtAtomicAbstractUpdateFuture.java:394)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1942)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1671)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:300)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:482)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:442)
> at
>
[jira] [Commented] (IGNITE-10799) Optimize affinity initialization/re-calculation
[
https://issues.apache.org/jira/browse/IGNITE-10799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807640#comment-16807640
]
Alexey Goncharuk commented on IGNITE-10799:
---
[~Jokser], looks good, please proceed with merge.
> Optimize affinity initialization/re-calculation
> ---
>
> Key: IGNITE-10799
> URL: https://issues.apache.org/jira/browse/IGNITE-10799
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Affects Versions: 2.4
>Reporter: Pavel Kovalenko
>Assignee: Pavel Kovalenko
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In case of persistence enabled and a baseline is set we have 2 main
> approaches to recalculate affinity:
> {noformat}
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager#onServerJoinWithExchangeMergeProtocol
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager#onServerLeftWithExchangeMergeProtocol
> {noformat}
> Both of them following the same approach of recalculating:
> 1) Take a current baseline (ideal assignment).
> 2) Filter out offline nodes from it.
> 3) Choose new primary nodes if previous went away.
> 4) Place temporal primary nodes to late affinity assignment set.
> Looking at implementation details we may notice that we do a lot of
> unnecessary online nodes cache lookups and array list copies. The performance
> becomes too slow if we do recalculate affinity for replicated caches (It
> takes P * N on each node, where P - partitions count, N - the number of nodes
> in the cluster). In case of large partitions count or large cluster, it may
> take few seconds, which is unacceptable, because this process happens during
> PME and freezes ongoing cluster operations.
> We should investigate possible bottlenecks and improve the performance of
> affinity recalculation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11434) SQL: Create a view with list of existing COLUMNS
[
https://issues.apache.org/jira/browse/IGNITE-11434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-11434:
--
Description:
Need to expose SQL system view with COLUMNS information.
Need to investigate more deeper which of information should be there.
As start point we can take
[https://dev.mysql.com/doc/refman/8.0/en/columns-table.html]
Columns description:
|| Name || Type || Description||
| SCHEMA_NAME | string | Schema name |
| TABLE_NAME | string | Table name |
| COLUMN_ID | int | Column ID |
| COLUMN_NAME | string | Column name |
| DEFAULT VALUE | string | Defaut column's value |
| IS_NULLABLE | boolean | Nullable flag corresponds to
{{QueryEntity#setNotNullFields}} |
| SQL TYPE | int | SQL data type ID |
| DATA_TYPE | string | SQL data type |
| DISPLAY_SIZE| int | Size (e.g. for VARCHAR) |
| PRECISION | int | Precision |
| SCALE | int | Scale |
| AFFINITY_KEY | boolean | {{true}} whan the column is affinity key |
was:
Need to expose SQL system view with COLUMNS information.
Need to investigate more deeper which of information should be there.
As start point we can take
[https://dev.mysql.com/doc/refman/8.0/en/columns-table.html]
Columns description:
|| Name || Type || Description||
| SCHEMA_NAME | string | Schema name |
| TABLE_NAME | string | Table name |
| COLUMN_ID | int | Column ID |
| COLUMN_NAME | string | Column name |
| DEFAULT VALUE | string | Defaut column's value |
| IS_NULLABLE | boolean | Nullable flag corresponds to
{{QueryEntity#setNotNullFields}} |
| DATA_TYPE | string | SQL data type |
| DISPLAY_SIZE| int | Size (e.g. for VARCHAR) |
| PRECISION | int | Precision |
| SCALE | int | Scale |
| AFFINITY_KEY | boolean | {{true}} whan the column is affinity key |
> SQL: Create a view with list of existing COLUMNS
>
>
> Key: IGNITE-11434
> URL: https://issues.apache.org/jira/browse/IGNITE-11434
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Taras Ledkov
>Priority: Major
> Labels: iep-29
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Need to expose SQL system view with COLUMNS information.
> Need to investigate more deeper which of information should be there.
>
> As start point we can take
> [https://dev.mysql.com/doc/refman/8.0/en/columns-table.html]
> Columns description:
> || Name || Type || Description||
> | SCHEMA_NAME | string | Schema name |
> | TABLE_NAME | string | Table name |
> | COLUMN_ID | int | Column ID |
> | COLUMN_NAME | string | Column name |
> | DEFAULT VALUE | string | Defaut column's value |
> | IS_NULLABLE | boolean | Nullable flag corresponds to
> {{QueryEntity#setNotNullFields}} |
> | SQL TYPE | int | SQL data type ID |
> | DATA_TYPE | string | SQL data type |
> | DISPLAY_SIZE| int | Size (e.g. for VARCHAR) |
> | PRECISION | int | Precision |
> | SCALE | int | Scale |
> | AFFINITY_KEY | boolean | {{true}} whan the column is affinity key |
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11434) SQL: Create a view with list of existing COLUMNS
[
https://issues.apache.org/jira/browse/IGNITE-11434?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-11434:
--
Description:
Need to expose SQL system view with COLUMNS information.
Need to investigate more deeper which of information should be there.
As start point we can take
[https://dev.mysql.com/doc/refman/8.0/en/columns-table.html]
Columns description:
|| Name || Type || Description||
| SCHEMA_NAME | string | Schema name |
| TABLE_NAME | string | Table name |
| COLUMN_ID | int | Column ID |
| COLUMN_NAME | string | Column name |
| DEFAULT VALUE | string | Defaut column's value |
| IS_NULLABLE | boolean | Nullable flag corresponds to
{{QueryEntity#setNotNullFields}} |
| DATA_TYPE | string | SQL data type |
| DISPLAY_SIZE| int | Size (e.g. for VARCHAR) |
| PRECISION | int | Precision |
| SCALE | int | Scale |
| AFFINITY_KEY | boolean | {{true}} whan the column is affinity key |
was:
Need to expose SQL system view with COLUMNS information.
Need to investigate more deeper which of information should be there.
As start point we can take
[https://dev.mysql.com/doc/refman/8.0/en/columns-table.html]
Columns description:
|| Name || Type || Description||
| SCHEMA_NAME | string | Schema name |
| TABLE_NAME | string | Table name |
| COLUMN_NAME | string | Columns name |
| DATA_TYPE | string | SQL data type |
| IS_NULLABLE | boolean | Nullable flag corresponds to
{{QueryEntity#setNotNullFields}} |
| DISPLAY_SIZE| int | Size (e.g. for VARCHAR) |
| PRECISION | int | Precision |
| SCALE | int | Scale |
| AFFINITY_KEY | boolean | {{true}} whan the column is affinity key |
> SQL: Create a view with list of existing COLUMNS
>
>
> Key: IGNITE-11434
> URL: https://issues.apache.org/jira/browse/IGNITE-11434
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Taras Ledkov
>Priority: Major
> Labels: iep-29
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Need to expose SQL system view with COLUMNS information.
> Need to investigate more deeper which of information should be there.
>
> As start point we can take
> [https://dev.mysql.com/doc/refman/8.0/en/columns-table.html]
> Columns description:
> || Name || Type || Description||
> | SCHEMA_NAME | string | Schema name |
> | TABLE_NAME | string | Table name |
> | COLUMN_ID | int | Column ID |
> | COLUMN_NAME | string | Column name |
> | DEFAULT VALUE | string | Defaut column's value |
> | IS_NULLABLE | boolean | Nullable flag corresponds to
> {{QueryEntity#setNotNullFields}} |
> | DATA_TYPE | string | SQL data type |
> | DISPLAY_SIZE| int | Size (e.g. for VARCHAR) |
> | PRECISION | int | Precision |
> | SCALE | int | Scale |
> | AFFINITY_KEY | boolean | {{true}} whan the column is affinity key |
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10663) Implement cache mode allows reads with consistency check and fix
[
https://issues.apache.org/jira/browse/IGNITE-10663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807603#comment-16807603
]
Ignite TC Bot commented on IGNITE-10663:
{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=3479508buildTypeId=IgniteTests24Java8_RunAll]
> Implement cache mode allows reads with consistency check and fix
>
>
> Key: IGNITE-10663
> URL: https://issues.apache.org/jira/browse/IGNITE-10663
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.8
>
>
> The main idea is to provide special "read from cache" mode which will read a
> value from primary and all backups and will check that values are the same.
> In case values differ they should be fixed according to the appropriate
> strategy.
> ToDo list:
> 1) {{cache.withConsistency().get(key)}} should guarantee values will be
> checked across the topology and fixed if necessary.
> 2) LWW (Last Write Wins) strategy should be used for validation.
> 3) Since LWW and any other strategy do not guarantee that the correct value
> will be chosen.
> We have to record the event contains all values and the chosen one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11416) DistributedMetaStorage improvements
[ https://issues.apache.org/jira/browse/IGNITE-11416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807602#comment-16807602 ] Anton Kalashnikov commented on IGNITE-11416: [~ibessonov] thanks for your changes. Looks good for me. > DistributedMetaStorage improvements > --- > > Key: IGNITE-11416 > URL: https://issues.apache.org/jira/browse/IGNITE-11416 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > We need following improvements: > * do not write the same value twice in a row, this would lead to history > pollution; > * add "putAll" functionality on binary level, not in public API yet. This > would simplify the migration in future; > * do not use "*HistoryItem" class for everything, this is not conventional; > * retrieve "dmsVer" from cluster on handshake, this would help to reduce > joining node DataBag size drastically; > * add "isEmpty()" or "long getVersion()" method to metastorage, will be > helpful for components that use it; > * there has to be an ability to read data on client nodes, maybe write as > well, not sure yet; > * implement more optimal in-memory storage for history cache; > * start in-memory metastorage at proper time, current implementation does it > a bit too late. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-10663) Implement cache mode allows reads with consistency check and fix
[
https://issues.apache.org/jira/browse/IGNITE-10663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-10663:
--
Comment: was deleted
(was: {panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0 Exit Code ,
TC_SERVICE_MESSAGE |https://ci.ignite.apache.org/viewLog.html?buildId=3488258]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3479508buildTypeId=IgniteTests24Java8_RunAll])
> Implement cache mode allows reads with consistency check and fix
>
>
> Key: IGNITE-10663
> URL: https://issues.apache.org/jira/browse/IGNITE-10663
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.8
>
>
> The main idea is to provide special "read from cache" mode which will read a
> value from primary and all backups and will check that values are the same.
> In case values differ they should be fixed according to the appropriate
> strategy.
> ToDo list:
> 1) {{cache.withConsistency().get(key)}} should guarantee values will be
> checked across the topology and fixed if necessary.
> 2) LWW (Last Write Wins) strategy should be used for validation.
> 3) Since LWW and any other strategy do not guarantee that the correct value
> will be chosen.
> We have to record the event contains all values and the chosen one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7113) "Key is missing from query" when creating table with key_type=java.lang.String
[
https://issues.apache.org/jira/browse/IGNITE-7113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807543#comment-16807543
]
Pavel Kuznetsov commented on IGNITE-7113:
-
p2 : added tests
> "Key is missing from query" when creating table with key_type=java.lang.String
> --
>
> Key: IGNITE-7113
> URL: https://issues.apache.org/jira/browse/IGNITE-7113
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.3
>Reporter: Ilya Kasnacheev
>Assignee: Pavel Kuznetsov
>Priority: Major
> Labels: sql-stability
> Attachments: IgniteStringKeyTest.java
>
>
> When creating a table of
> {code}
> CREATE TABLE IF NOT EXISTS TableWithStringKey (
> ID VARCHAR PRIMARY KEY,
> DataNodeId VARCHAR
> ) WITH "backups=1, cache_name=TableWithStringKey, atomicity=transactional,
> key_type=java.lang.String, value_type=TableWithStringKey"
> {code}
> and attempting an insert later
> {code}
> INSERT INTO TableWithStringKey (ID, DataNodeId) VALUES ('ref2', 'src2')
> {code}
> There's suddently an exception
> {code}
> javax.cache.CacheException: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId)
> VALUES ('ref2', 'src2'), params=null]
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:597)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:560)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:382)
> at
> com.gridgain.reproducer.IgniteStringKeyTest.insertTest(IgniteStringKeyTest.java:34)
> ... 24 more
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> execute DML statement [stmt=INSERT INTO TableWithStringKey (ID, DataNodeId)
> VALUES ('ref2', 'src2'), params=null]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1459)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1909)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$5.applyx(GridQueryProcessor.java:1907)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2445)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1914)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:585)
> ... 27 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Key is missing
> from query
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.createSupplier(UpdatePlanBuilder.java:369)
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.planForInsert(UpdatePlanBuilder.java:211)
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlanBuilder.planForStatement(UpdatePlanBuilder.java:98)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.getPlanForStatement(DmlStatementsProcessor.java:473)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFields(DmlStatementsProcessor.java:170)
> at
> org.apache.ignite.internal.processors.query.h2.DmlStatementsProcessor.updateSqlFieldsDistributed(DmlStatementsProcessor.java:229)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.queryDistributedSqlFields(IgniteH2Indexing.java:1453)
> ... 33 more
> {code}
> that goes away if you remove "key_type=java.lang.String"
> I'm attaching a reproducer class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-10663) Implement cache mode allows reads with consistency check and fix
[
https://issues.apache.org/jira/browse/IGNITE-10663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-10663:
--
Comment: was deleted
(was: {panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0 Exit Code ,
TC_SERVICE_MESSAGE |https://ci.ignite.apache.org/viewLog.html?buildId=3482366]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3479508buildTypeId=IgniteTests24Java8_RunAll])
> Implement cache mode allows reads with consistency check and fix
>
>
> Key: IGNITE-10663
> URL: https://issues.apache.org/jira/browse/IGNITE-10663
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.8
>
>
> The main idea is to provide special "read from cache" mode which will read a
> value from primary and all backups and will check that values are the same.
> In case values differ they should be fixed according to the appropriate
> strategy.
> ToDo list:
> 1) {{cache.withConsistency().get(key)}} should guarantee values will be
> checked across the topology and fixed if necessary.
> 2) LWW (Last Write Wins) strategy should be used for validation.
> 3) Since LWW and any other strategy do not guarantee that the correct value
> will be chosen.
> We have to record the event contains all values and the chosen one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10663) Implement cache mode allows reads with consistency check and fix
[
https://issues.apache.org/jira/browse/IGNITE-10663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807509#comment-16807509
]
Ignite TC Bot commented on IGNITE-10663:
{panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0 Exit Code ,
TC_SERVICE_MESSAGE |https://ci.ignite.apache.org/viewLog.html?buildId=3488258]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3479508buildTypeId=IgniteTests24Java8_RunAll]
> Implement cache mode allows reads with consistency check and fix
>
>
> Key: IGNITE-10663
> URL: https://issues.apache.org/jira/browse/IGNITE-10663
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.8
>
>
> The main idea is to provide special "read from cache" mode which will read a
> value from primary and all backups and will check that values are the same.
> In case values differ they should be fixed according to the appropriate
> strategy.
> ToDo list:
> 1) {{cache.withConsistency().get(key)}} should guarantee values will be
> checked across the topology and fixed if necessary.
> 2) LWW (Last Write Wins) strategy should be used for validation.
> 3) Since LWW and any other strategy do not guarantee that the correct value
> will be chosen.
> We have to record the event contains all values and the chosen one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-10663) Implement cache mode allows reads with consistency check and fix
[
https://issues.apache.org/jira/browse/IGNITE-10663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-10663:
--
Comment: was deleted
(was: {panel:title=-- Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests
122|https://ci.ignite.apache.org/viewLog.html?buildId=3479430]]
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoverySpiSaslSuccessfulAuthTest.testIgniteNodeWithoutSaslConfigurationSuccessfullyJoins
- 0,0% fails in last 373 master runs.
{color:#d04437}Cassandra Store{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=3479507]]
* IgniteCassandraStoreTestSuite: tests.IgnitePersistentStoreTest - 0,0% fails
in last 0 master runs.
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0 Exit Code ,
TC_SERVICE_MESSAGE |https://ci.ignite.apache.org/viewLog.html?buildId=3479479]]
{color:#d04437}Platform C++ (Linux Clang){color} [[tests 0 Exit Code , Failure
on metric |https://ci.ignite.apache.org/viewLog.html?buildId=3479438]]
{color:#d04437}Thin client: Python{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=3479485]]
{color:#d04437}Platform C++ (Win x64 | Release){color} [[tests 1
BuildFailureOnMessage
|https://ci.ignite.apache.org/viewLog.html?buildId=3479433]]
* IgniteOdbcTest: SslQueriesTestSuite: TestConnectionSslSuccess - 1,7% fails in
last 786 master runs.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=3479508buildTypeId=IgniteTests24Java8_RunAll])
> Implement cache mode allows reads with consistency check and fix
>
>
> Key: IGNITE-10663
> URL: https://issues.apache.org/jira/browse/IGNITE-10663
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.8
>
>
> The main idea is to provide special "read from cache" mode which will read a
> value from primary and all backups and will check that values are the same.
> In case values differ they should be fixed according to the appropriate
> strategy.
> ToDo list:
> 1) {{cache.withConsistency().get(key)}} should guarantee values will be
> checked across the topology and fixed if necessary.
> 2) LWW (Last Write Wins) strategy should be used for validation.
> 3) Since LWW and any other strategy do not guarantee that the correct value
> will be chosen.
> We have to record the event contains all values and the chosen one.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11621) Node is stuck in "No next node in topology" infinite loop in special case.
[ https://issues.apache.org/jira/browse/IGNITE-11621?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-11621: - Ignite Flags: (was: Docs Required) Fix Version/s: 2.8 > Node is stuck in "No next node in topology" infinite loop in special case. > -- > > Key: IGNITE-11621 > URL: https://issues.apache.org/jira/browse/IGNITE-11621 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Critical > Fix For: 2.8 > > Attachments: NoNextNodeInTopologyReproducer.java > > Time Spent: 10m > Remaining Estimate: 0h > > In special case (reproducer is attached) node may stuck in the loop when the > following sequence of events happens: > * Nodes A and B are already in cluster. > * Node C starts joining the cluster. > * On node C NodeAdded message new node D is started. > * Before NodeAddFinished for node C reaches it socket to node C fails and > node is considered failed by the cluster. > * When NodeFailed message for node C reaches node B both A and B fails. > * After that node D gets stuck in infinite "No next node in topology" loop > processing NodeFailed messages for A, B and C indefinitely. > The main logic in attached reproducer lives in node1SpecialSpi - it is a > TcpDiscoverySpi node B starts with. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-7101) .NET: IIgnite.GetVersion
[
https://issues.apache.org/jira/browse/IGNITE-7101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807476#comment-16807476
]
Pavel Tupitsyn commented on IGNITE-7101:
[~ashapkin]
* See {{BinaryUtils.ReadSbyteArray}}, let's use that
* When I run current master branch, I get 2.8.0 from {{Ignite.version()}} in
Java, this matches .NET assembly version
> .NET: IIgnite.GetVersion
>
>
> Key: IGNITE-7101
> URL: https://issues.apache.org/jira/browse/IGNITE-7101
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Alexandr Shapkin
>Priority: Trivial
> Labels: .NET, newbie
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Add {{IIgnite.GetVersion}} method and {{IClusterNode.Version}} property.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-8588) .NET: Serialization issue when derived type hides base type member
[
https://issues.apache.org/jira/browse/IGNITE-8588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807470#comment-16807470
]
Pavel Tupitsyn commented on IGNITE-8588:
[~ashapkin] let's keep existing error message for all use cases except the one
from this ticket when two fields have the same name.
> .NET: Serialization issue when derived type hides base type member
> --
>
> Key: IGNITE-8588
> URL: https://issues.apache.org/jira/browse/IGNITE-8588
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.4
>Reporter: Pavel Tupitsyn
>Assignee: Alexandr Shapkin
>Priority: Major
> Labels: .NET
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The following class structure causes an exception that is hard to understand
> (when putting instance of B into Ignite cache):
> {code}
> public class A
> {
> public int bob;
> }
> public class B : A
> {
> public int bob;
> }
> {code}
> Exception:
> {code}
> Apache.Ignite.Core.Binary.BinaryObjectException: Conflicting field IDs
> [type=SubGridsRequestArgument, field1=Filters, field2=Filters,
> fieldId=-854547461]
> at
> Apache.Ignite.Core.Impl.Binary.BinaryReflectiveSerializerInternal.Register(Type
> type, Int32 typeId, IBinaryNameMapper converter, IBinaryIdMapper idMapper,
> Boolean forceTimestamp)
> at
> Apache.Ignite.Core.Impl.Binary.Marshaller.GetSerializer(BinaryConfiguration
> cfg, BinaryTypeConfiguration typeCfg, Type type, Int32 typeId,
> IBinaryNameMapper nameMapper, IBinaryIdMapper idMapper, ILogger log)
> at Apache.Ignite.Core.Impl.Binary.Marshaller.AddUserType(Type type, Int32
> typeId, String typeName, Boolean registered, BinaryFullTypeDescriptor desc)
> at Apache.Ignite.Core.Impl.Binary.Marshaller.RegisterType(Type type,
> BinaryFullTypeDescriptor desc)
> at Apache.Ignite.Core.Impl.Binary.Marshaller.GetDescriptor(Type type)
> at Apache.Ignite.Core.Impl.Binary.BinaryWriter.Write[T](T obj)
> at
> Apache.Ignite.Core.Impl.Deployment.PeerLoadingExtensions.WriteWithPeerDeployment(BinaryWriter
> writer, Object o)
> at
> Apache.Ignite.Core.Impl.Binary.BinarySystemTypeSerializer`1.WriteBinary[T1](T1
> obj, BinaryWriter writer)
> at Apache.Ignite.Core.Impl.Binary.BinaryWriter.Write[T](T obj)
> at
> Apache.Ignite.Core.Impl.Binary.BinarySystemTypeSerializer`1.WriteBinary[T1](T1
> obj, BinaryWriter writer)
> at Apache.Ignite.Core.Impl.Binary.BinaryWriter.Write[T](T obj)
> at Apache.Ignite.Core.Impl.Binary.BinaryWriter.WriteObjectDetached[T](T o)
> at Apache.Ignite.Core.Impl.Compute.ComputeImpl.WriteJob(IComputeJob job,
> BinaryWriter writer)
> at
> Apache.Ignite.Core.Impl.Compute.ComputeImpl.<>c__DisplayClass1d`3.b__1a(BinaryWriter
> writer)
> at Apache.Ignite.Core.Impl.PlatformTargetAdapter.WriteToStream(Action`1
> action, IBinaryStream stream, Marshaller marsh)
> at Apache.Ignite.Core.Impl.PlatformJniTarget.InStreamOutObject(Int32 type,
> Action`1 writeAction)
> at
> Apache.Ignite.Core.Impl.Compute.ComputeImpl.ExecuteClosures0[TArg,TJobRes,TReduceRes](IComputeTask`3
> task, IComputeJob job, IEnumerable`1 jobs, Int32 opId, Int32 jobsCount,
> Action`1 writeAction)
> --- End of inner exception stack trace ---
> at System.Threading.Tasks.Task.ThrowIfExceptional(Boolean
> includeTaskCanceledExceptions)
> at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout,
> CancellationToken cancellationToken)
> at System.Threading.Tasks.Task.Wait(Int32 millisecondsTimeout)
> at VSS.TRex.GridFabric.Requests.SubGridRequestsProgressive`2.Execute() in
> C:\Dev\VSS.TRex\src\netstandard\RaptorClassLibrary.netstandard\GridFabric\Requests\SubGridRequestsProgressive.cs:line
> 107
> at VSS.TRex.Pipelines.SubGridPipelineBase`3.Initiate() in
> C:\Dev\VSS.TRex\src\netstandard\RaptorClassLibrary.netstandard\Pipelines\SubGridPipelineBase.cs:line
> 241
> at VSS.TRex.Rendering.PlanViewTileRenderer.ExecutePipeline() in
> C:\Dev\VSS.TRex\src\netstandard\RaptorClassLibrary.netstandard\Rendering\PlanViewTileRenderer.cs:line
> 262
> ---> (Inner Exception #0) Apache.Ignite.Core.Binary.BinaryObjectException:
> Conflicting field IDs [type=SubGridsRequestArgument, field1=Filters,
> field2=Filters, fieldId=-854547461]
> at
> Apache.Ignite.Core.Impl.Binary.BinaryReflectiveSerializerInternal.Register(Type
> type, Int32 typeId, IBinaryNameMapper converter, IBinaryIdMapper idMapper,
> Boolean forceTimestamp)
> at
> Apache.Ignite.Core.Impl.Binary.Marshaller.GetSerializer(BinaryConfiguration
> cfg, BinaryTypeConfiguration typeCfg, Type type, Int32 typeId,
> IBinaryNameMapper nameMapper, IBinaryIdMapper idMapper, ILogger log)
> at Apache.Ignite.Core.Impl.Binary.Marshaller.AddUserType(Type type, Int32
>
[jira] [Updated] (IGNITE-9876) .NET: Thin Client: Implement Best Effort Affinity
[ https://issues.apache.org/jira/browse/IGNITE-9876?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-9876: --- Description: See linked IEP-23. First iteration is going to be an "experimental feature" with the following limitations: * No reconnect support for failed nodes * No AffinityKeyMapped support was: Currently we connect to a random node, so when the primary node for the given key is different from that random node, there is an additional network hop. For single-key operations (scope of this ticket) we should strive to determine primary node and connect there directly. To determine primary node for a given key: 1. Retrieve partition map from server node (partition -> primaryNodeId) 2. Connect to all known server nodes (all endpoints from IgniteClientConfiguration) and get their Node Ids, build a map from endpoint (IP or host) to Node Id 3. Implement RendezvousAffinityFunction in C# Efficient automatic partition map retrieval: 1. When a partition map is needed, send a separate asynchronous operation (new server op type is required) 2. Do not block current user operation. If partition map is not present, just skip affinity step and use current connection 3. When response arrives with the partition map, save it with a timestamp 4. On every partition map access check the timestamp. Request new map if current map is older than N minutes. > .NET: Thin Client: Implement Best Effort Affinity > - > > Key: IGNITE-9876 > URL: https://issues.apache.org/jira/browse/IGNITE-9876 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, iep-23 > > See linked IEP-23. > First iteration is going to be an "experimental feature" with the following > limitations: > * No reconnect support for failed nodes > * No AffinityKeyMapped support -- 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=16807454#comment-16807454 ] Pavel Tupitsyn commented on IGNITE-11043: - [~isapego] ok, let's keep it simple for now, I will follow the same for .NET implementation. > 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)
