[jira] [Commented] (IGNITE-14612) Calcite. SELECT with CASE without boolean expression - fails.
[
https://issues.apache.org/jira/browse/IGNITE-14612?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17337114#comment-17337114
]
Stanilovsky Evgeny commented on IGNITE-14612:
-
[~tledkov-gridgain] can u merge it ?
> Calcite. SELECT with CASE without boolean expression - fails.
> -
>
> Key: IGNITE-14612
> URL: https://issues.apache.org/jira/browse/IGNITE-14612
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Labels: calcite
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> For example such expression - fails.
> {noformat}
> SELECT CASE WHEN 1 THEN 13 ELSE 12 END;{noformat}
> failed with:
> {code:java}
> class org.apache.ignite.IgniteException: Error at:
> test_constant_comparisons.test:91. sql: SELECT CASE WHEN 1 THEN 13 ELSE 12
> END;
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.execute(SqlScriptRunner.java:518)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.run(SqlScriptRunner.java:93)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.ScriptTestRunner$1.run(ScriptTestRunner.java:214)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to
> plan query.
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareQuery(ExecutionServiceImpl.java:541)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.queryPlan(QueryPlanCacheImpl.java:84)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executeQuery(ExecutionServiceImpl.java:398)
> at
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:246)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.sql(SqlScriptRunner.java:111)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.access$600(SqlScriptRunner.java:51)
> at
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.execute(SqlScriptRunner.java:513)
> ... 3 more
> Caused by: org.apache.calcite.runtime.CalciteContextException: From line 1,
> column 8 to line 1, column 38: Expected a boolean type
> at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
> at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
> at
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:467)
> at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:883)
> {code}
> and this work perfectly well:
> {noformat}
> SELECT CASE WHEN 1=1 THEN 13 ELSE 12 END;{noformat}
> a little reserch shows that calcite also fails in non boolean expression,
> root cause in
> SqlCaseOperator#checkOperandTypes and further check :
> {code:java}
> if (!SqlTypeUtil.inBooleanFamily(type){code} if we change this place,
> appropriate test
> {noformat}
> @Test void testCaseWhen2() {
> checkPlanEquals("SELECT CASE WHEN 1 THEN 13 ELSE 12 END");
> }{noformat}
> will work fine in calcite but will fail in ignite with janino error:
> {noformat}
> class org.apache.ignite.IgniteException: Line 3, Column 7: Not a boolean
> expression
> at
> org.apache.ignite.internal.processors.query.calcite.util.Commons.compile(Commons.java:299)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.compile(ExpressionFactoryImpl.java:290)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.lambda$scalar$4(ExpressionFactoryImpl.java:241)
> at
> java.util.concurrent.ConcurrentMap.computeIfAbsent(ConcurrentMap.java:324)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.scalar(ExpressionFactoryImpl.java:241)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.ExpressionFactoryImpl.project(ExpressionFactoryImpl.java:198)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:195)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.LogicalRelImplementor.visit(LogicalRelImplementor.java:102)
> at
> org.apache.ignite.internal.processors.query.calcite.rel.IgniteP
[jira] [Commented] (IGNITE-14634) NPE in ShmemClient
[
https://issues.apache.org/jira/browse/IGNITE-14634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17335851#comment-17335851
]
Sarah Grace Samji commented on IGNITE-14634:
Hi, may I know if the fix will be prioritized for the next release?
> NPE in ShmemClient
> --
>
> Key: IGNITE-14634
> URL: https://issues.apache.org/jira/browse/IGNITE-14634
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.10
>Reporter: Ilya Kazakov
>Priority: Major
>
> This code works correctly on 2.7, but do not work on 2.8, 2.9 and 2.10
> {code:java}
> public class T1 {
> static int sharedMemPort = 37235;
> public static void main(String[] args) {
> Ignition.start(getConf("I1"));
> Ignition.start(getConf("I2"));
> }
> public static IgniteConfiguration getConf(String instanceName) {
> return new
> IgniteConfiguration().setIgniteInstanceName(instanceName).setCommunicationSpi(new
> TcpCommunicationSpi().setSharedMemoryPort(sharedMemPort));
> }
> }{code}
> On 2.10
> {code:java}
> [2021-04-23
> 13:06:20,562][ERROR][exchange-worker-#129%I2%][TcpCommunicationSpi] Failed to
> send message to remote node [node=TcpDiscoveryNode
> [id=7469805f-1097-4e49-a0d9-3474a6a792bb,
> consistentId=0:0:0:0:0:0:0:1%lo,127.0.0.1,172.17.0.1,192.168.1.105,192.168.49.1:47500,
> addrs=ArrayList [0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.17.0.1, 192.168.1.105,
> 192.168.49.1], sockAddrs=HashSet [/172.17.0.1:47500, /192.168.49.1:47500,
> /0:0:0:0:0:0:0:1%lo:47500, /127.0.0.1:47500, /192.168.1.105:47500],
> discPort=47500, order=1, intOrder=1, lastExchangeTime=1619154380497,
> loc=false, ver=2.11.0#20210422-sha1:bec58b00, isClient=false],
> msg=GridIoMessage [plc=2, topic=TOPIC_CACHE, topicOrd=8, ordered=false,
> timeout=0, skipOnTimeout=false, msg=GridDhtPartitionsSingleMessage
> [parts=HashMap {-2100569601=GridDhtPartitionMap [moving=0,
> top=AffinityTopologyVersion [topVer=-1, minorTopVer=0], updateSeq=1,
> size=0]}, partCntrs=HashMap {-2100569601=CachePartitionPartialCountersMap
> {}}, partsSizes=null, partHistCntrs=null, err=null, client=false,
> exchangeStartTime=1619154380524, finishMsg=null,
> super=GridDhtPartitionsAbstractMessage [exchId=GridDhtPartitionExchangeId
> [topVer=AffinityTopologyVersion [topVer=2, minorTopVer=0],
> discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=f3b31869-bea3-406c-a8a3-6fe5a502d8c4,
> consistentId=0:0:0:0:0:0:0:1%lo,127.0.0.1,172.17.0.1,192.168.1.105,192.168.49.1:47501,
> addrs=ArrayList [0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.17.0.1, 192.168.1.105,
> 192.168.49.1], sockAddrs=HashSet [/192.168.49.1:47501,
> /0:0:0:0:0:0:0:1%lo:47501, /127.0.0.1:47501, /192.168.1.105:47501,
> /172.17.0.1:47501], discPort=47501, order=2, intOrder=2,
> lastExchangeTime=1619154380527, loc=true, ver=2.11.0#20210422-sha1:bec58b00,
> isClient=false], topVer=2, msgTemplate=null,
> span=org.apache.ignite.internal.processors.tracing.NoopSpan@4773b242,
> nodeId8=f3b31869, msg=null, type=NODE_JOINED, tstamp=1619154380517],
> nodeId=f3b31869, evt=NODE_JOINED], lastVer=GridCacheVersion [topVer=0,
> order=1619154379141, nodeOrder=0], super=GridCacheMessage [msgId=1,
> depInfo=null, lastAffChangedTopVer=AffinityTopologyVersion [topVer=-1,
> minorTopVer=0], err=null, skipPrepare=false][2021-04-23
> 13:06:20,562][ERROR][exchange-worker-#129%I2%][TcpCommunicationSpi] Failed to
> send message to remote node [node=TcpDiscoveryNode
> [id=7469805f-1097-4e49-a0d9-3474a6a792bb,
> consistentId=0:0:0:0:0:0:0:1%lo,127.0.0.1,172.17.0.1,192.168.1.105,192.168.49.1:47500,
> addrs=ArrayList [0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.17.0.1, 192.168.1.105,
> 192.168.49.1], sockAddrs=HashSet [/172.17.0.1:47500, /192.168.49.1:47500,
> /0:0:0:0:0:0:0:1%lo:47500, /127.0.0.1:47500, /192.168.1.105:47500],
> discPort=47500, order=1, intOrder=1, lastExchangeTime=1619154380497,
> loc=false, ver=2.11.0#20210422-sha1:bec58b00, isClient=false],
> msg=GridIoMessage [plc=2, topic=TOPIC_CACHE, topicOrd=8, ordered=false,
> timeout=0, skipOnTimeout=false, msg=GridDhtPartitionsSingleMessage
> [parts=HashMap {-2100569601=GridDhtPartitionMap [moving=0,
> top=AffinityTopologyVersion [topVer=-1, minorTopVer=0], updateSeq=1,
> size=0]}, partCntrs=HashMap {-2100569601=CachePartitionPartialCountersMap
> {}}, partsSizes=null, partHistCntrs=null, err=null, client=false,
> exchangeStartTime=1619154380524, finishMsg=null,
> super=GridDhtPartitionsAbstractMessage [exchId=GridDhtPartitionExchangeId
> [topVer=AffinityTopologyVersion [topVer=2, minorTopVer=0],
> discoEvt=DiscoveryEvent [evtNode=TcpDiscoveryNode
> [id=f3b31869-bea3-406c-a8a3-6fe5a502d8c4,
> consistentId=0:0:0:0:0:0:0:1%lo,127.0.0.1,172.17.0.1,192.168.1.105,192.168.49.1:47501,
> addrs=ArrayList [0:0:0:0:0:0:0:1%lo, 127.0.0.1, 172.17.0.1, 192.16
[jira] [Updated] (IGNITE-14446) Implement DMS manager with watch registry
[ https://issues.apache.org/jira/browse/IGNITE-14446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-14446: Description: MetaStorageManager must be an entry point to MetaStorageService for other components. Also, it must implement aggregation of client watches to provide the following additional guarantees to the watching mechanism: * watch events must be processed sequentially. * watch events must be resolved in the order of watch registration. > Implement DMS manager with watch registry > - > > Key: IGNITE-14446 > URL: https://issues.apache.org/jira/browse/IGNITE-14446 > Project: Ignite > Issue Type: Sub-task >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: iep-73 > Fix For: 3.0.0-alpha2 > > Time Spent: 1h > Remaining Estimate: 0h > > MetaStorageManager must be an entry point to MetaStorageService for other > components. > Also, it must implement aggregation of client watches to provide the > following additional guarantees to the watching mechanism: > * watch events must be processed sequentially. > * watch events must be resolved in the order of watch registration. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14671) Test IgniteClusterSnapshotCheckTest#testClusterSnapshotCheckOtherCluster is flaky
[
https://issues.apache.org/jira/browse/IGNITE-14671?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17335740#comment-17335740
]
Ignite TC Bot commented on IGNITE-14671:
{panel:title=Branch: [pull/9068/head] Base: [master] : Possible Blockers
(5)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 7{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5987694]]
* IgniteCacheTestSuite7:
GracefulShutdownTest.testRollingRestartEmulationReplicatedCache - Test has low
fail rate in base branch 0,0% and is not flaky
{color:#d04437}Platform .NET (Long Running){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5987711]]
* exe: PeerAssemblyLoadingAllApisTest.TestComputeCall(False) - Test has low
fail rate in base branch 0,0% and is not flaky
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0 Exit Code ,
TC_SERVICE_MESSAGE |https://ci.ignite.apache.org/viewLog.html?buildId=5987708]]
{color:#d04437}Data Structures{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5987699]]
* org.apache.ignite.testsuites.IgniteCacheDataStructuresSelfTestSuite:
org.apache.ignite.internal.processors.cache.datastructures.replicated.GridCacheReplicatedSetWithClientSelfTest.
- History for base branch is absent.
{color:#d04437}Cache 3{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5987690]]
* IgniteBinaryObjectsCacheTestSuite3:
GridCacheInterceptorTransactionalRebalanceTest.testRebalanceRemove - Test has
low fail rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/9068/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#8b}Data Structures{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5987699]]
*
{color:#8b}org.apache.ignite.testsuites.IgniteCacheDataStructuresSelfTestSuite:
org.apache.ignite.internal.processors.cache.datastructures.replicated.GridCacheReplicatedSetWithClientSelfTest.
- FAILED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5987734&buildTypeId=IgniteTests24Java8_RunAll]
> Test IgniteClusterSnapshotCheckTest#testClusterSnapshotCheckOtherCluster is
> flaky
> -
>
> Key: IGNITE-14671
> URL: https://issues.apache.org/jira/browse/IGNITE-14671
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Trivial
> Labels: iep-43
> Fix For: 2.11
>
> Attachments: testClusterSnapshotCheckOtherCluster_fix.patch,
> testClusterSnapshotCheckOtherCluster_printCount.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> To reproduce failure, run it several times, for example, set up IDE to run
> test with 'repeat until failure' option. Then you will get an assertion error:
> {code:java}
> java.lang.AssertionError: Number of jobs must be equal to the cluster size
> (except local node): [a2844419-3081-432a-b611-c4f89195]
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:29)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckOtherCluster(IgniteClusterSnapshotCheckTest.java:316)
> {code}
> With applied patch [1] exception would be as follows:
> {code:java}
> java.lang.AssertionError: Number of jobs must be equal to the cluster size
> (except local node): [e7346d3b-b257-466c-95c2-0a85a765], count: 1
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:29)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckOtherCluster(IgniteClusterSnapshotCheckTest.java:316)
> {code}
> It seems to be a concurrent update problem of thread unsafe HasSet (see [2,
> 3]):
> {code:java|title=Unsafe HashSet}
> Set assigns = new HashSet<>();
> {code}
> {code:java|title=Concurrent update}
> grid(i).context().io().addMessageListener(GridTopic.TOPIC_JOB, new
> GridMessageListener() {
> @Override public void onMessage(UUID nodeId, Object msg, byte plc) {
> if (msg instanceof GridJobExecuteRequest) {
> GridJobExecuteRequest msg0 = (GridJobExecuteRequest)msg;
> if
> (msg0.getTaskName().contains(SnapshotPartitionsVerifyTask.class.getName()))
> assigns.add(locNodeId);
> }
> }
> });
> {code}
>
[jira] [Updated] (IGNITE-6324) Transactional cache data partially available after crash and further recovery.
[ https://issues.apache.org/jira/browse/IGNITE-6324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanilovsky Evgeny updated IGNITE-6324: --- Release Note: Before this fix it was possible to obtain persistent data in inconsistent state. For example: 2 nodes with persistence and 0 backups, transaction (tx) update data cross nodes (all nodes are involved into tx update) and in the middle of commiting phase something happens with bare metal or possibly jvm crash raises on one of existing nodes, second one will detect it and rollback process will be triggered, some time later crashed node will be fixed and returned into cluster after recovery from wal it would be possible to observe data from rolled back tx. Now this situation is still possible if there is no -DIGNITE_WAL_LOG_TX_RECORDS=true appropriate flag, i plan to trigger one more ticket for changing this flag defaults. (was: Before this fix it was possible to obtain persistent data in inconsistent state. For example: 2 nodes with persistence and 0 backups, transaction (tx) update data cross nodes (all nodes are involved into tx update) and in the middle of commiting phase something happens with bare metal or possibly jvm crash raises on one of existing nodes, second one will detect it and rollback process will be triggered, some time later crashed node will be fixed and returned into cluster after recovery from wal it would be possible to observe data from rolled back tx. ) > Transactional cache data partially available after crash and further recovery. > -- > > Key: IGNITE-6324 > URL: https://issues.apache.org/jira/browse/IGNITE-6324 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.10 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Critical > Fix For: 2.11 > > Attachments: InterruptCommitedThreadTest.java > > Time Spent: 50m > Remaining Estimate: 0h > > If InterruptedException raise in client code during pds store operations we > can obtain inconsistent cache after restart. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-6324) Transactional cache data partially available after crash and further recovery.
[ https://issues.apache.org/jira/browse/IGNITE-6324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanilovsky Evgeny updated IGNITE-6324: --- Release Note: Before this fix it was possible to obtain persistent data in inconsistent state. For example: 2 nodes with persistence and 0 backups, transaction (tx) update data cross nodes (all nodes are involved into tx update) and in the middle of commiting phase something happens with bare metal or possibly jvm crash raises on one of existing nodes, second one will detect it and rollback process will be triggered, some time later crashed node will be fixed and returned into cluster after recovery from wal it would be possible to observe data from rolled back tx. > Transactional cache data partially available after crash and further recovery. > -- > > Key: IGNITE-6324 > URL: https://issues.apache.org/jira/browse/IGNITE-6324 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.10 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Critical > Fix For: 2.11 > > Attachments: InterruptCommitedThreadTest.java > > Time Spent: 50m > Remaining Estimate: 0h > > If InterruptedException raise in client code during pds store operations we > can obtain inconsistent cache after restart. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14392) Remove the SQL Transactions page from Apache Ignite docs
[ https://issues.apache.org/jira/browse/IGNITE-14392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17335690#comment-17335690 ] Denis A. Magda commented on IGNITE-14392: - [~igusev], could we remove the redirect? Let's keep it in the sources and published so that those who have a direct link to the page can open it up. > Remove the SQL Transactions page from Apache Ignite docs > > > Key: IGNITE-14392 > URL: https://issues.apache.org/jira/browse/IGNITE-14392 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Nikita Safonov >Assignee: Igor Gusev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The page: > [https://ignite.apache.org/docs/latest/SQL/sql-transactions|https://www.gridgain.com/docs/latest/developers-guide/SQL/sql-transactions] > * We should remove it from the menu (toc.yaml) > * We should make sure it's not indexed by Google -> need to update robot.txt > * We should check references to this page from other pages. The references > do exist. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14525) Empty page in docs
[ https://issues.apache.org/jira/browse/IGNITE-14525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17335688#comment-17335688 ] Denis A. Magda commented on IGNITE-14525: - [~igusev], alright, let's remove it then. I merged the patch. Thanks! > Empty page in docs > -- > > Key: IGNITE-14525 > URL: https://issues.apache.org/jira/browse/IGNITE-14525 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > [https://ignite.apache.org/docs/latest/installation/] page is empty. There > should be some introduction in it, or no page at all. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14671) Test IgniteClusterSnapshotCheckTest#testClusterSnapshotCheckOtherCluster is flaky
[
https://issues.apache.org/jira/browse/IGNITE-14671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-14671:
---
Fix Version/s: 2.11
> Test IgniteClusterSnapshotCheckTest#testClusterSnapshotCheckOtherCluster is
> flaky
> -
>
> Key: IGNITE-14671
> URL: https://issues.apache.org/jira/browse/IGNITE-14671
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Trivial
> Labels: iep-43
> Fix For: 2.11
>
> Attachments: testClusterSnapshotCheckOtherCluster_fix.patch,
> testClusterSnapshotCheckOtherCluster_printCount.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> To reproduce failure, run it several times, for example, set up IDE to run
> test with 'repeat until failure' option. Then you will get an assertion error:
> {code:java}
> java.lang.AssertionError: Number of jobs must be equal to the cluster size
> (except local node): [a2844419-3081-432a-b611-c4f89195]
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:29)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckOtherCluster(IgniteClusterSnapshotCheckTest.java:316)
> {code}
> With applied patch [1] exception would be as follows:
> {code:java}
> java.lang.AssertionError: Number of jobs must be equal to the cluster size
> (except local node): [e7346d3b-b257-466c-95c2-0a85a765], count: 1
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:29)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckOtherCluster(IgniteClusterSnapshotCheckTest.java:316)
> {code}
> It seems to be a concurrent update problem of thread unsafe HasSet (see [2,
> 3]):
> {code:java|title=Unsafe HashSet}
> Set assigns = new HashSet<>();
> {code}
> {code:java|title=Concurrent update}
> grid(i).context().io().addMessageListener(GridTopic.TOPIC_JOB, new
> GridMessageListener() {
> @Override public void onMessage(UUID nodeId, Object msg, byte plc) {
> if (msg instanceof GridJobExecuteRequest) {
> GridJobExecuteRequest msg0 = (GridJobExecuteRequest)msg;
> if
> (msg0.getTaskName().contains(SnapshotPartitionsVerifyTask.class.getName()))
> assigns.add(locNodeId);
> }
> }
> });
> {code}
> With concurrent Set implementation problem is not reproducing (see patch [4]):
> {code:java}
> Set assigns = Collections.newSetFromMap(new ConcurrentHashMap<>());
> {code}
> # [^testClusterSnapshotCheckOtherCluster_printCount.patch]
> #
> [IgniteClusterSnapshotCheckTest.java#L287|https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/snapshot/IgniteClusterSnapshotCheckTest.java#L287]
> #
> [IgniteClusterSnapshotCheckTest.java#L300|https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/snapshot/IgniteClusterSnapshotCheckTest.java#L300]
> # [^testClusterSnapshotCheckOtherCluster_fix.patch]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-11758) Python thin: a lot of documentation files without license header
[ https://issues.apache.org/jira/browse/IGNITE-11758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17335653#comment-17335653 ] Ivan Daschinsky commented on IGNITE-11758: -- [~isapego] [~dmagda] I suppose, that I've already fixed this in 70bb1d9c9e6648a74257f9c7f65922d80dc7317f [IGNITE-14418|https://issues.apache.org/jira/browse/IGNITE-14418] > Python thin: a lot of documentation files without license header > > > Key: IGNITE-11758 > URL: https://issues.apache.org/jira/browse/IGNITE-11758 > Project: Ignite > Issue Type: Bug > Components: documentation, thin client >Affects Versions: 2.7 >Reporter: Igor Sapego >Assignee: Dmitry Melnichuk >Priority: Blocker > Fix For: 2.11 > > > There are a lot of .rst documentation files in modules/platforms/python/docs/ > that does not contain license header. We need either delete them if they are > auto generated or add headers to them if they are not. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14625) Make DurableBackgroundTask return future
[
https://issues.apache.org/jira/browse/IGNITE-14625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17335603#comment-17335603
]
Ignite TC Bot commented on IGNITE-14625:
{panel:title=Branch: [pull/9037/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9037/head] Base: [master] : New Tests
(6)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS 1{color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=5986937]]
* {color:#013220}IgnitePdsTestSuite:
DurableBackgroundTasksProcessorSelfTest.testCancelTaskExecution - PASSED{color}
* {color:#013220}IgnitePdsTestSuite:
DurableBackgroundTasksProcessorSelfTest.testSimpleTaskExecutionWithoutMetaStorage
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite:
DurableBackgroundTasksProcessorSelfTest.testRestartTaskExecutionWithMetaStorage
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite:
DurableBackgroundTasksProcessorSelfTest.testRestartTaskExecutionWithoutMetaStorage
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite:
DurableBackgroundTasksProcessorSelfTest.testSimpleTaskExecutionWithMetaStorage
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite:
DurableBackgroundTasksProcessorSelfTest.testRestartTaskAfterRestartNode -
PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5986968&buildTypeId=IgniteTests24Java8_RunAll]
> Make DurableBackgroundTask return future
>
>
> Key: IGNITE-14625
> URL: https://issues.apache.org/jira/browse/IGNITE-14625
> Project: Ignite
> Issue Type: Improvement
> Components: persistence
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> While trying to implement rebuilding indexes on *DurableBackgroundTask*, I
> encountered several problems:
> * For each task, a new thread is created, which can be critical for
> rebuilding indexes, since there can be many caches and this can create many
> threads;
> * Tasks can be completed close to the end of a checkpoint, and data may not
> reach this checkpoint.
> Therefore, I propose to slightly rework the *DurableBackgroundTask*.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14671) Test IgniteClusterSnapshotCheckTest#testClusterSnapshotCheckOtherCluster is flaky
[
https://issues.apache.org/jira/browse/IGNITE-14671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-14671:
---
Description:
To reproduce failure, run it several times, for example, set up IDE to run test
with 'repeat until failure' option. Then you will get an assertion error:
{code:java}
java.lang.AssertionError: Number of jobs must be equal to the cluster size
(except local node): [a2844419-3081-432a-b611-c4f89195]
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:29)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckOtherCluster(IgniteClusterSnapshotCheckTest.java:316)
{code}
With applied patch [1] exception would be as follows:
{code:java}
java.lang.AssertionError: Number of jobs must be equal to the cluster size
(except local node): [e7346d3b-b257-466c-95c2-0a85a765], count: 1
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:29)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckOtherCluster(IgniteClusterSnapshotCheckTest.java:316)
{code}
It seems to be a concurrent update problem of thread unsafe HasSet (see [2, 3]):
{code:java|title=Unsafe HashSet}
Set assigns = new HashSet<>();
{code}
{code:java|title=Concurrent update}
grid(i).context().io().addMessageListener(GridTopic.TOPIC_JOB, new
GridMessageListener() {
@Override public void onMessage(UUID nodeId, Object msg, byte plc) {
if (msg instanceof GridJobExecuteRequest) {
GridJobExecuteRequest msg0 = (GridJobExecuteRequest)msg;
if
(msg0.getTaskName().contains(SnapshotPartitionsVerifyTask.class.getName()))
assigns.add(locNodeId);
}
}
});
{code}
With concurrent Set implementation problem is not reproducing (see patch [4]):
{code:java}
Set assigns = Collections.newSetFromMap(new ConcurrentHashMap<>());
{code}
# [^testClusterSnapshotCheckOtherCluster_printCount.patch]
#
[IgniteClusterSnapshotCheckTest.java#L287|https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/snapshot/IgniteClusterSnapshotCheckTest.java#L287]
#
[IgniteClusterSnapshotCheckTest.java#L300|https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/snapshot/IgniteClusterSnapshotCheckTest.java#L300]
# [^testClusterSnapshotCheckOtherCluster_fix.patch]
was:
To reproduce failure, run it several times, for example, set up IDE to run test
with 'repeat until failure' option. Then you will get an assertion error:
{code:java}
java.lang.AssertionError: Number of jobs must be equal to the cluster size
(except local node): [a2844419-3081-432a-b611-c4f89195]
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:29)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckOtherCluster(IgniteClusterSnapshotCheckTest.java:316)
{code}
With applied patch [1] exception would be as follows:
{code:java}
java.lang.AssertionError: Number of jobs must be equal to the cluster size
(except local node): [e7346d3b-b257-466c-95c2-0a85a765], count: 1
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:29)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckOtherCluster(IgniteClusterSnapshotCheckTest.java:316)
{code}
It seems to be a concurrent update problem of thread unsafe HasSet (see [2, 3]):
{code:java|title=Unsafe HashSet}
Set assigns = new HashSet<>();
{code}
{code:java|title=Concurrent update}
grid(i).context().io().addMessageListener(GridTopic.TOPIC_JOB, new
GridMessageListener() {
@Override public void onMessage(UUID nodeId, Object msg, byte plc) {
if (msg instanceof GridJobExecuteRequest) {
GridJobExecuteRequest msg0 = (GridJobExecuteRequest)msg;
if
(msg0.getTaskName().contains(SnapshotPartitionsVerifyTask.class.getName()))
assigns.add(locNodeId);
}
}
});
{code}
With concurrent Set implementation problem is not reproducing (see patch [4]):
{code:java}
Set assigns = Collections.newSetFromMap
[jira] [Updated] (IGNITE-14671) Test IgniteClusterSnapshotCheckTest#testClusterSnapshotCheckOtherCluster is flaky
[
https://issues.apache.org/jira/browse/IGNITE-14671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-14671:
---
Description:
To reproduce failure, run it several times, for example, set up IDE to run test
with 'repeat until failure' option. Then you will get an assertion error:
{code:java}
java.lang.AssertionError: Number of jobs must be equal to the cluster size
(except local node): [a2844419-3081-432a-b611-c4f89195]
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:29)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckOtherCluster(IgniteClusterSnapshotCheckTest.java:316)
{code}
With applied patch [1] exception would be as follows:
{code:java}
java.lang.AssertionError: Number of jobs must be equal to the cluster size
(except local node): [e7346d3b-b257-466c-95c2-0a85a765], count: 1
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:29)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckOtherCluster(IgniteClusterSnapshotCheckTest.java:316)
{code}
It seems to be a concurrent update problem of thread unsafe HasSet (see [2, 3]):
{code:java|title=Unsafe HashSet}
Set assigns = new HashSet<>();
{code}
{code:java|title=Concurrent update}
grid(i).context().io().addMessageListener(GridTopic.TOPIC_JOB, new
GridMessageListener() {
@Override public void onMessage(UUID nodeId, Object msg, byte plc) {
if (msg instanceof GridJobExecuteRequest) {
GridJobExecuteRequest msg0 = (GridJobExecuteRequest)msg;
if
(msg0.getTaskName().contains(SnapshotPartitionsVerifyTask.class.getName()))
assigns.add(locNodeId);
}
}
});
{code}
With concurrent Set implementation problem is not reproducing (see patch [4]):
{code:java}
Set assigns = Collections.newSetFromMap(new ConcurrentHashMap<>());
{code}
# [^testClusterSnapshotCheckOtherCluster_printCount.patch]
#
https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/snapshot/IgniteClusterSnapshotCheckTest.java#L287
#
https://github.com/apache/ignite/blob/master/modules/core/src/test/java/org/apache/ignite/internal/processors/cache/persistence/snapshot/IgniteClusterSnapshotCheckTest.java#L300
# [^testClusterSnapshotCheckOtherCluster_fix.patch]
was:
To reproduce failure, run it several times, for example, set up IDE to run test
with 'repeat until failure' option. Then you will get an assertion error:
{code:java}
java.lang.AssertionError: Number of jobs must be equal to the cluster size
(except local node): [a2844419-3081-432a-b611-c4f89195]
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:29)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckOtherCluster(IgniteClusterSnapshotCheckTest.java:316)
{code}
With applied patch [1] exception would be as follows:
{code:java}
java.lang.AssertionError: Number of jobs must be equal to the cluster size
(except local node): [e7346d3b-b257-466c-95c2-0a85a765], count: 1
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:29)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckOtherCluster(IgniteClusterSnapshotCheckTest.java:316)
{code}
It seems to be a concurrent update problem of thread unsafe HasSet:
{code:java|title=Unsafe HashSet}
Set assigns = new HashSet<>();
{code}
{code:java|title=Concurrent update}
grid(i).context().io().addMessageListener(GridTopic.TOPIC_JOB, new
GridMessageListener() {
@Override public void onMessage(UUID nodeId, Object msg, byte plc) {
if (msg instanceof GridJobExecuteRequest) {
GridJobExecuteRequest msg0 = (GridJobExecuteRequest)msg;
if
(msg0.getTaskName().contains(SnapshotPartitionsVerifyTask.class.getName()))
assigns.add(locNodeId);
}
}
});
{code}
With concurrent Set implementation problem is not reproducing (see patch [2]):
{code:java}
Set assigns = Collections.newSetFromMap(new ConcurrentHashMap<>());
{code}
# [^testClusterSnapshotCheckOtherCluster_printCount.patch]
#
[jira] [Updated] (IGNITE-14671) Test IgniteClusterSnapshotCheckTest#testClusterSnapshotCheckOtherCluster is flaky
[
https://issues.apache.org/jira/browse/IGNITE-14671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-14671:
---
Description:
To reproduce failure, run it several times, for example, set up IDE to run test
with 'repeat until failure' option. Then you will get an assertion error:
{code:java}
java.lang.AssertionError: Number of jobs must be equal to the cluster size
(except local node): [a2844419-3081-432a-b611-c4f89195]
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:29)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckOtherCluster(IgniteClusterSnapshotCheckTest.java:316)
{code}
With applied patch [1] exception would be as follows:
{code:java}
java.lang.AssertionError: Number of jobs must be equal to the cluster size
(except local node): [e7346d3b-b257-466c-95c2-0a85a765], count: 1
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:29)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckOtherCluster(IgniteClusterSnapshotCheckTest.java:316)
{code}
It seems to be a concurrent update problem of thread unsafe HasSet:
{code:java|title=Unsafe HashSet}
Set assigns = new HashSet<>();
{code}
{code:java|title=Concurrent update}
grid(i).context().io().addMessageListener(GridTopic.TOPIC_JOB, new
GridMessageListener() {
@Override public void onMessage(UUID nodeId, Object msg, byte plc) {
if (msg instanceof GridJobExecuteRequest) {
GridJobExecuteRequest msg0 = (GridJobExecuteRequest)msg;
if
(msg0.getTaskName().contains(SnapshotPartitionsVerifyTask.class.getName()))
assigns.add(locNodeId);
}
}
});
{code}
With concurrent Set implementation problem is not reproducing (see patch [2]):
{code:java}
Set assigns = Collections.newSetFromMap(new ConcurrentHashMap<>());
{code}
# [^testClusterSnapshotCheckOtherCluster_printCount.patch]
# [^testClusterSnapshotCheckOtherCluster_fix.patch]
was:
To reproduce failure, run it several times, for example, set up IDE to run test
with 'repeat until failure' option. Then you will get an assertion error:
{code:java}
java.lang.AssertionError: Number of jobs must be equal to the cluster size
(except local node): [a2844419-3081-432a-b611-c4f89195]
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:29)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckOtherCluster(IgniteClusterSnapshotCheckTest.java:316)
{code}
With applied patch [1] exception would be as follows:
{code:java}
java.lang.AssertionError: Number of jobs must be equal to the cluster size
(except local node): [e7346d3b-b257-466c-95c2-0a85a765], count: 1
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:29)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckOtherCluster(IgniteClusterSnapshotCheckTest.java:316)
{code}
It seems to be a concurrent update problem of thread unsafe HasSet:
{code:java|title=Unsafe HashSet}
Set assigns = new HashSet<>();
{code}
{code:java|title=Concurrent update}
grid(i).context().io().addMessageListener(GridTopic.TOPIC_JOB, new
GridMessageListener() {
@Override public void onMessage(UUID nodeId, Object msg, byte plc) {
if (msg instanceof GridJobExecuteRequest) {
GridJobExecuteRequest msg0 = (GridJobExecuteRequest)msg;
if
(msg0.getTaskName().contains(SnapshotPartitionsVerifyTask.class.getName()))
assigns.add(locNodeId);
}
}
});
{code}
With concurrent Set implementation problem is not reproducing (see patch [2]):
{code:java}
Set assigns = Collections.newSetFromMap(new ConcurrentHashMap<>());
{code}
# [^testClusterSnapshotCheckOtherCluster_printCount.patch]
> Test IgniteClusterSnapshotCheckTest#testClusterSnapshotCheckOtherCluster is
> flaky
> -
>
> Key: IGNITE-14671
> URL: https://issues.apache.org/jira/browse/IGNITE-14671
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11
>
[jira] [Updated] (IGNITE-14671) Test IgniteClusterSnapshotCheckTest#testClusterSnapshotCheckOtherCluster is flaky
[
https://issues.apache.org/jira/browse/IGNITE-14671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-14671:
---
Attachment: testClusterSnapshotCheckOtherCluster_fix.patch
> Test IgniteClusterSnapshotCheckTest#testClusterSnapshotCheckOtherCluster is
> flaky
> -
>
> Key: IGNITE-14671
> URL: https://issues.apache.org/jira/browse/IGNITE-14671
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Trivial
> Labels: iep-43
> Attachments: testClusterSnapshotCheckOtherCluster_fix.patch,
> testClusterSnapshotCheckOtherCluster_printCount.patch
>
>
> To reproduce failure, run it several times, for example, set up IDE to run
> test with 'repeat until failure' option. Then you will get an assertion error:
> {code:java}
> java.lang.AssertionError: Number of jobs must be equal to the cluster size
> (except local node): [a2844419-3081-432a-b611-c4f89195]
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:29)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckOtherCluster(IgniteClusterSnapshotCheckTest.java:316)
> {code}
> With applied patch [1] exception would be as follows:
> {code:java}
> java.lang.AssertionError: Number of jobs must be equal to the cluster size
> (except local node): [e7346d3b-b257-466c-95c2-0a85a765], count: 1
> at org.junit.Assert.fail(Assert.java:88)
> at org.junit.Assert.assertTrue(Assert.java:41)
> at
> org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:29)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckOtherCluster(IgniteClusterSnapshotCheckTest.java:316)
> {code}
> It seems to be a concurrent update problem of thread unsafe HasSet:
> {code:java|title=Unsafe HashSet}
> Set assigns = new HashSet<>();
> {code}
> {code:java|title=Concurrent update}
> grid(i).context().io().addMessageListener(GridTopic.TOPIC_JOB, new
> GridMessageListener() {
> @Override public void onMessage(UUID nodeId, Object msg, byte plc) {
> if (msg instanceof GridJobExecuteRequest) {
> GridJobExecuteRequest msg0 = (GridJobExecuteRequest)msg;
> if
> (msg0.getTaskName().contains(SnapshotPartitionsVerifyTask.class.getName()))
> assigns.add(locNodeId);
> }
> }
> });
> {code}
> With concurrent Set implementation problem is not reproducing (see patch [2]):
> {code:java}
> Set assigns = Collections.newSetFromMap(new ConcurrentHashMap<>());
> {code}
> # [^testClusterSnapshotCheckOtherCluster_printCount.patch]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14671) Test IgniteClusterSnapshotCheckTest#testClusterSnapshotCheckOtherCluster is flaky
[
https://issues.apache.org/jira/browse/IGNITE-14671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-14671:
---
Description:
To reproduce failure, run it several times, for example, set up IDE to run test
with 'repeat until failure' option. Then you will get an assertion error:
{code:java}
java.lang.AssertionError: Number of jobs must be equal to the cluster size
(except local node): [a2844419-3081-432a-b611-c4f89195]
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:29)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckOtherCluster(IgniteClusterSnapshotCheckTest.java:316)
{code}
With applied patch [1] exception would be as follows:
{code:java}
java.lang.AssertionError: Number of jobs must be equal to the cluster size
(except local node): [e7346d3b-b257-466c-95c2-0a85a765], count: 1
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:29)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckOtherCluster(IgniteClusterSnapshotCheckTest.java:316)
{code}
It seems to be a concurrent update problem of thread unsafe HasSet:
{code:java|title=Unsafe HashSet}
Set assigns = new HashSet<>();
{code}
{code:java|title=Concurrent update}
grid(i).context().io().addMessageListener(GridTopic.TOPIC_JOB, new
GridMessageListener() {
@Override public void onMessage(UUID nodeId, Object msg, byte plc) {
if (msg instanceof GridJobExecuteRequest) {
GridJobExecuteRequest msg0 = (GridJobExecuteRequest)msg;
if
(msg0.getTaskName().contains(SnapshotPartitionsVerifyTask.class.getName()))
assigns.add(locNodeId);
}
}
});
{code}
With concurrent Set implementation problem is not reproducing (see patch [2]):
{code:java}
Set assigns = Collections.newSetFromMap(new ConcurrentHashMap<>());
{code}
# [^testClusterSnapshotCheckOtherCluster_printCount.patch]
was:
To reproduce failure, run it several times, for example, set up IDE to run test
with 'repeat until failure' option. Then you will get an assertion error:
{code:java}
java.lang.AssertionError: Number of jobs must be equal to the cluster size
(except local node): [a2844419-3081-432a-b611-c4f89195]
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:29)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckOtherCluster(IgniteClusterSnapshotCheckTest.java:316)
{code}
With applied patch [1] exception would be as follows:
{code:java}
java.lang.AssertionError: Number of jobs must be equal to the cluster size
(except local node): [e7346d3b-b257-466c-95c2-0a85a765], count: 1
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:29)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckOtherCluster(IgniteClusterSnapshotCheckTest.java:316)
{code}
It seems to be a concurrent update problem of thread unsafe HasSet:
{code:java|title=Unsafe HashSet}
Set assigns = new HashSet<>();
{code}
{code:java|title=Concurrent update}
grid(i).context().io().addMessageListener(GridTopic.TOPIC_JOB, new
GridMessageListener() {
@Override public void onMessage(UUID nodeId, Object msg, byte plc) {
if (msg instanceof GridJobExecuteRequest) {
GridJobExecuteRequest msg0 = (GridJobExecuteRequest)msg;
if
(msg0.getTaskName().contains(SnapshotPartitionsVerifyTask.class.getName()))
assigns.add(locNodeId);
}
}
});
{code}
With concurrent Set implementation problem is not reproducing (see patch [2]):
{code:java}
Set assigns = Collections.newSetFromMap(new ConcurrentHashMap<>());
{code}
> Test IgniteClusterSnapshotCheckTest#testClusterSnapshotCheckOtherCluster is
> flaky
> -
>
> Key: IGNITE-14671
> URL: https://issues.apache.org/jira/browse/IGNITE-14671
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.11
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Trivial
> La
[jira] [Created] (IGNITE-14671) Test IgniteClusterSnapshotCheckTest#testClusterSnapshotCheckOtherCluster is flaky
Ilya Shishkov created IGNITE-14671:
--
Summary: Test
IgniteClusterSnapshotCheckTest#testClusterSnapshotCheckOtherCluster is flaky
Key: IGNITE-14671
URL: https://issues.apache.org/jira/browse/IGNITE-14671
Project: Ignite
Issue Type: Bug
Affects Versions: 2.11
Reporter: Ilya Shishkov
Assignee: Ilya Shishkov
Attachments: testClusterSnapshotCheckOtherCluster_printCount.patch
To reproduce failure, run it several times, for example, set up IDE to run test
with 'repeat until failure' option. Then you will get an assertion error:
{code:java}
java.lang.AssertionError: Number of jobs must be equal to the cluster size
(except local node): [a2844419-3081-432a-b611-c4f89195]
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:29)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckOtherCluster(IgniteClusterSnapshotCheckTest.java:316)
{code}
With applied patch [1] exception would be as follows:
{code:java}
java.lang.AssertionError: Number of jobs must be equal to the cluster size
(except local node): [e7346d3b-b257-466c-95c2-0a85a765], count: 1
at org.junit.Assert.fail(Assert.java:88)
at org.junit.Assert.assertTrue(Assert.java:41)
at
org.apache.ignite.testframework.junits.JUnitAssertAware.assertTrue(JUnitAssertAware.java:29)
at
org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteClusterSnapshotCheckTest.testClusterSnapshotCheckOtherCluster(IgniteClusterSnapshotCheckTest.java:316)
{code}
It seems to be a concurrent update problem of thread unsafe HasSet:
{code:java|title=Unsafe HashSet}
Set assigns = new HashSet<>();
{code}
{code:java|title=Concurrent update}
grid(i).context().io().addMessageListener(GridTopic.TOPIC_JOB, new
GridMessageListener() {
@Override public void onMessage(UUID nodeId, Object msg, byte plc) {
if (msg instanceof GridJobExecuteRequest) {
GridJobExecuteRequest msg0 = (GridJobExecuteRequest)msg;
if
(msg0.getTaskName().contains(SnapshotPartitionsVerifyTask.class.getName()))
assigns.add(locNodeId);
}
}
});
{code}
With concurrent Set implementation problem is not reproducing (see patch [2]):
{code:java}
Set assigns = Collections.newSetFromMap(new ConcurrentHashMap<>());
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14669) NPE in GridCacheIoManager when sending GridCacheQueryResponse, target node left grid
[
https://issues.apache.org/jira/browse/IGNITE-14669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-14669:
-
Ignite Flags: (was: Release Notes Required)
> NPE in GridCacheIoManager when sending GridCacheQueryResponse, target node
> left grid
>
>
> Key: IGNITE-14669
> URL: https://issues.apache.org/jira/browse/IGNITE-14669
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.10
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> ERROR o.a.i.i.p.cache.GridCacheIoManager - Failed to process message
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.sendOrderedMessage(GridCacheIoManager.java:1309)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processFailedMessage(GridCacheIoManager.java:932)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:589)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1721)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1328)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4600(GridIoManager.java:157)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$8.execute(GridIoManager.java:1213)
> at
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:54)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14669) NPE in GridCacheIoManager when sending GridCacheQueryResponse, target node left grid
[
https://issues.apache.org/jira/browse/IGNITE-14669?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17335562#comment-17335562
]
Ignite TC Bot commented on IGNITE-14669:
{panel:title=Branch: [pull/9067/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9067/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Continuous Query 4{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5987139]]
* {color:#013220}IgniteCacheQuerySelfTestSuite6:
IgniteCacheContinuousQueryClientTest.testFailedSerializationAfterNodeLeaves -
PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5987175&buildTypeId=IgniteTests24Java8_RunAll]
> NPE in GridCacheIoManager when sending GridCacheQueryResponse, target node
> left grid
>
>
> Key: IGNITE-14669
> URL: https://issues.apache.org/jira/browse/IGNITE-14669
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.10
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> ERROR o.a.i.i.p.cache.GridCacheIoManager - Failed to process message
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.sendOrderedMessage(GridCacheIoManager.java:1309)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processFailedMessage(GridCacheIoManager.java:932)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:589)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1721)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1328)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4600(GridIoManager.java:157)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$8.execute(GridIoManager.java:1213)
> at
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:54)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:834)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-14544) Calcite engine. Support DISTINCT aggregates
[
https://issues.apache.org/jira/browse/IGNITE-14544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov reassigned IGNITE-14544:
-
Assignee: Taras Ledkov
> Calcite engine. Support DISTINCT aggregates
> ---
>
> Key: IGNITE-14544
> URL: https://issues.apache.org/jira/browse/IGNITE-14544
> Project: Ignite
> Issue Type: Bug
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
>
> Now, DISTINCT aggregates not implemented.
> (e.g. {{SELECT COUNT (DISTINCT lastName) FROM person}})
> Tests:
> {{aggregate/aggregates/test_count.test}}
> {{aggregate/aggregates/test_avg.test}}
> {{aggregate/aggregates/test_distinct_aggr.test}}
> {{aggregate/aggregates/test_distinct_string_agg.test}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14496) Move configuration schemas and configuration annotations to ignite-api
[
https://issues.apache.org/jira/browse/IGNITE-14496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-14496:
---
Description:
h3. Problem
In this issue we need to move all API from *ignite-configuration* module into
*ignite-api*. This comes with a price, we can't just move our classes. The
problem is that code generator generates (in principal) two thing:
* schema-based general interfaces:
** {{*View}}
** {{*Change}}
** {{*Configuration}}
* schema-based implementations:
** {{*Node}}
** {{*ConfigurationImpl}}
First set of interfaces depends on +other interfaces only+. This is good and
pretty much all we need in resulting *ignite-api* sources.
Second set of classes requires us to have classes like {{InnerNode}} or
{{ConfigurationChanger}} in compile-time dependencies, which is clearly wrong
for API. These 2 classes must be in another Java module and that's a problem.
There are two approaches to solve the problem, I'll try my best to describe
both.
h3. Common problem for both solutions
*ignite-configuration-annotation-processor* clearly depends on *ignite-api* in
our case AND at the same time *ignite-api* should use annotation processing. We
have cycling dependency. Right way of resolving it is to create module
*ignite-configuration-api*. This shows us that having +all+ API in one module
is probably not the best idea.
h3. Solution 1 - split annotation processor into 2
There's no doubt that we need processor that will generate first set of
interfaces. We already have it. We could create a second annotation processor
that will generate implementations into other modules, let's call it
*impl-processor*. But Java annotation processing API can't do that directly. If
we compile module *B* that depends on module *A*, only classes from *B* will be
passed into environment of *impl-processor*. We have to options of how to
resolve it:
* use libraries like [classgraph|https://github.com/classgraph/classgraph],
having *ignite-api* as hardcoded compiler dependency in annotation processor.
Works in theory BUT there are issues:
** there's no clear way of distinguishing schemas that you should process in
current module from those that you shouldn't;
** *ignite-api* dependency is hardcoded as an optional source of schemas,
which is a questionable thing.
* include package with desired schemas using maven helper plugin. This
approach also has issues:
** now we understand how to configure it, but such configuration will require
more manual steps and either separate package for modules schemas or
include/exclude list in helper plugin configuration;
** we will have several identical **.class* files in target directories of
different modules.
h3. Solution 2 - leave only one annotation processor and generate everything
else at runtime
This approach requires 0 additional configuration. {{Node}} and
{{ConfigurationImpl}} can be generated from schemas when you register new root
key. We already have *ignite-bytecode* module so there's no need for additional
libraries in dependencies. Usages of the module can be seen in module
*ignite-schema*. I assume that writing tests will be much easier with runtime
code generation. Also classes like {{InnerNode}} will probably become
package-private. The problems are:
* potential problems during debugging. I don't see it as a problem. Given that
we'll cover everything with tests, generator code will be pretty stable;
* generating code requires time. Doesn't look like it really needs a
significant amount of time though;
* we can start several nodes in a single JVM so there might be collisions of
other issues. The problem is purely technical;
* choice of {{ClassLoader}} for generated classes has to be very careful.
Situation when generated configuration class cannot be loaded for some reason
is unacceptable.
h3. Solution 3 - just generate implementation classes into api module
IMHO, second solution is better. The fact that API usage becomes better
overweights the fact that we would need to generate different parts of
configuration code using different tools.
was:
h3. Problem
In this issue we need to move all API from *ignite-configuration* module into
*ignite-api*. This comes with a price, we can't just move our classes. The
problem is that code generator generates (in principal) two thing:
* schema-based general interfaces:
** {{*View}}
** {{*Change}}
** {{*Configuration}}
* schema-based implementations:
** {{*Node}}
** {{*ConfigurationImpl}}
First set of interfaces depends on +other interfaces only+. This is good and
pretty much all we need in resulting *ignite-api* sources.
Second set of classes requires us to have classes like {{InnerNode}} or
{{ConfigurationChanger}} in compile-time dependencies, which is clearly wrong
for API. These 2 classes must be in another Java module and that's a problem.
There are two approach
[jira] [Resolved] (IGNITE-14520) Plugins support in Ignite configuration
[
https://issues.apache.org/jira/browse/IGNITE-14520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov resolved IGNITE-14520.
--
Resolution: Fixed
> Plugins support in Ignite configuration
> ---
>
> Key: IGNITE-14520
> URL: https://issues.apache.org/jira/browse/IGNITE-14520
> Project: Ignite
> Issue Type: Task
>Reporter: Mikhail Filatov
>Assignee: Mikhail Filatov
>Priority: Major
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Add support for plugin configuration with custom macros
> It should be possible to add a plugin configuration toIgnite configuration by
> specifying template path and plugin parameters with code like:
> {% if config.plugins %}
>
>
> \{% for plugin in config.plugins %}
> \{{ misc_utils.generate_plugin_config(plugin['template_path'],
> plugin['config'], config) }}
> \{% endfor %}
>
>
> \{% endif %}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14600) [Ducktape: Thin client] Add SSL configuration
[ https://issues.apache.org/jira/browse/IGNITE-14600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17335511#comment-17335511 ] Evgeniya Vdovets commented on IGNITE-14600: --- PR: https://github.com/apache/ignite/pull/9035 Green run: https://sbt-jenkins.sigma.sbrf.ru/job/OSPT/job/DevOps/job/ducktest/job/run_tests/2298/ > [Ducktape: Thin client] Add SSL configuration > -- > > Key: IGNITE-14600 > URL: https://issues.apache.org/jira/browse/IGNITE-14600 > Project: Ignite > Issue Type: Sub-task >Reporter: Evgeniya Vdovets >Assignee: Evgeniya Vdovets >Priority: Major > > 1. Add SSL parameters to IgniteClientConfiguration > 2. Add SSL parameters to config template > 3. Implement "SSL parameters initialisation from globals" logic in > IgniteClientConfiguration > (it is already done for IgniteConfiguration: > https://github.com/apache/ignite/blob/ignite-ducktape/modules/ducktests/tests/ignitetest/services/utils/ignite_configuration/__init__.py#L66 > This needs to be duplicated for IgniteClientConfiguration) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14665) Security test suite runs no tests after CI test suite checker
[
https://issues.apache.org/jira/browse/IGNITE-14665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17335513#comment-17335513
]
Maksim Timonin edited comment on IGNITE-14665 at 4/29/21, 2:05 PM:
---
[~ilyak] hi! I've fixed this issue. Could you please have a look?
It affects 683 tests, wow!
Travis failed on Net check, but looks like that it was an Travis scheduler
error.
was (Author: timonin.maksim):
[~ilyak] hi! I've fixed this issue. Could you please have a look?
Travis failed on Net check, but looks like that it was an Travis scheduler
error.
> Security test suite runs no tests after CI test suite checker
> -
>
> Key: IGNITE-14665
> URL: https://issues.apache.org/jira/browse/IGNITE-14665
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Ilya Kasnacheev
>Assignee: Maksim Timonin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Please see linked development list thread as well as suite
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Security?mode=builds
> All runs end with:
> {code}
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [WARNING] ForkStarter IOException:
> org.apache.maven.surefire.util.internal.StringUtils.unescapeString(Ljava/lang/StringBuilder;Ljava/lang/CharSequence;)V
> org.apache.maven.surefire.util.internal.StringUtils.unescapeBytes(Ljava/lang/String;Ljava/lang/String;)Ljava/nio/ByteBuffer;
>
> org.apache.maven.surefire.util.internal.StringUtils.unescapeString(Ljava/lang/StringBuilder;Ljava/lang/CharSequence;)V
>
> org.apache.maven.surefire.util.internal.StringUtils.unescapeString(Ljava/lang/StringBuilder;Ljava/lang/CharSequence;)V.
> See the dump file
> /opt/buildagent/work/7bc1c54bc719b67c/modules/core/target/surefire-reports/2021-04-28T14-22-01_678-jvmRun1.dumpstream
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> {code}
> After bisecting, this is the offender:
> {code}
> commit 62cc45861c0273286e00eb6fbc510c0bb5589e52
> Author: Maksim Timonin
> Date: Fri Feb 5 19:10:18 2021 +0300
> IGNITE-13512 Add travis check that tests are not in suites - Fixes #8367.
>
> Signed-off-by: Ilya Kasnacheev
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14665) Security test suite runs no tests after CI test suite checker
[
https://issues.apache.org/jira/browse/IGNITE-14665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17335513#comment-17335513
]
Maksim Timonin commented on IGNITE-14665:
-
[~ilyak] hi! I've fixed this issue. Could you please have a look?
Travis failed on Net check, but looks like that it was an Travis scheduler
error.
> Security test suite runs no tests after CI test suite checker
> -
>
> Key: IGNITE-14665
> URL: https://issues.apache.org/jira/browse/IGNITE-14665
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Ilya Kasnacheev
>Assignee: Maksim Timonin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Please see linked development list thread as well as suite
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Security?mode=builds
> All runs end with:
> {code}
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [WARNING] ForkStarter IOException:
> org.apache.maven.surefire.util.internal.StringUtils.unescapeString(Ljava/lang/StringBuilder;Ljava/lang/CharSequence;)V
> org.apache.maven.surefire.util.internal.StringUtils.unescapeBytes(Ljava/lang/String;Ljava/lang/String;)Ljava/nio/ByteBuffer;
>
> org.apache.maven.surefire.util.internal.StringUtils.unescapeString(Ljava/lang/StringBuilder;Ljava/lang/CharSequence;)V
>
> org.apache.maven.surefire.util.internal.StringUtils.unescapeString(Ljava/lang/StringBuilder;Ljava/lang/CharSequence;)V.
> See the dump file
> /opt/buildagent/work/7bc1c54bc719b67c/modules/core/target/surefire-reports/2021-04-28T14-22-01_678-jvmRun1.dumpstream
> [INFO]
> [INFO] Results:
> [INFO]
> [INFO] Tests run: 0, Failures: 0, Errors: 0, Skipped: 0
> [INFO]
> {code}
> After bisecting, this is the offender:
> {code}
> commit 62cc45861c0273286e00eb6fbc510c0bb5589e52
> Author: Maksim Timonin
> Date: Fri Feb 5 19:10:18 2021 +0300
> IGNITE-13512 Add travis check that tests are not in suites - Fixes #8367.
>
> Signed-off-by: Ilya Kasnacheev
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14665) Security test suite runs no tests after CI test suite checker
[
https://issues.apache.org/jira/browse/IGNITE-14665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17335507#comment-17335507
]
Ignite TC Bot commented on IGNITE-14665:
{panel:title=Branch: [pull/9062/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9062/head] Base: [master] : New Tests
(683)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Service Grid{color} [[tests
341|https://ci.ignite.apache.org/viewLog.html?buildId=5985968]]
* {color:#013220}IgniteServiceGridTestSuite:
GridServiceProcessorSingleNodeSelfTest.testCancelSingleton - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
GridServiceProcessorSingleNodeSelfTest.testDeployOnEachNodeOld - PASSED{color}
* {color:#013220}IgniteServiceConfigVariationsFullApiTestSuite:
IgniteServiceConfigVariationsFullApiTest_0.testDeploy - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
GridServiceProcessorSingleNodeSelfTest.testDeployMultiple2Old - PASSED{color}
* {color:#013220}IgniteServiceConfigVariationsFullApiTestSuite:
IgniteServiceConfigVariationsFullApiTest_0.testClusterSingletonDeploy -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
GridServiceProcessorSingleNodeSelfTest.testCancelAsyncEachNode - PASSED{color}
* {color:#013220}IgniteServiceConfigVariationsFullApiTestSuite:
IgniteServiceConfigVariationsFullApiTest_0.testMultipleDeploy - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
GridServiceProcessorSingleNodeSelfTest.testNodeSingletonNotDeployedProxy -
PASSED{color}
* {color:#013220}IgniteServiceConfigVariationsFullApiTestSuite:
IgniteServiceConfigVariationsFullApiTest_0.testNodeSingletonDeploy -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
GridServiceProcessorSingleNodeSelfTest.testDeployMultiple1Old - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ComputeJobCancelWithServiceSelfTest.testJobCancel - PASSED{color}
... and 330 new tests
{color:#8b}Logging{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5985903]]
* {color:#013220}IgniteLoggingSelfTestSuite: JavaLoggerTest.testLogInitialize -
PASSED{color}
{color:#8b}Service Grid (legacy mode){color} [[tests
341|https://ci.ignite.apache.org/viewLog.html?buildId=5985969]]
* {color:#013220}IgniteServiceGridTestSuite:
GridServiceProcessorSingleNodeSelfTest.testCancelSingleton - PASSED{color}
* {color:#013220}IgniteServiceConfigVariationsFullApiTestSuite:
IgniteServiceConfigVariationsFullApiTest_0.testDeploy - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
GridServiceProcessorSingleNodeSelfTest.testDeployOnEachNodeOld - PASSED{color}
* {color:#013220}IgniteServiceConfigVariationsFullApiTestSuite:
IgniteServiceConfigVariationsFullApiTest_0.testClusterSingletonDeploy -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
GridServiceProcessorSingleNodeSelfTest.testDeployMultiple2Old - PASSED{color}
* {color:#013220}IgniteServiceConfigVariationsFullApiTestSuite:
IgniteServiceConfigVariationsFullApiTest_0.testMultipleDeploy - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
GridServiceProcessorSingleNodeSelfTest.testCancelAsyncEachNode - PASSED{color}
* {color:#013220}IgniteServiceConfigVariationsFullApiTestSuite:
IgniteServiceConfigVariationsFullApiTest_0.testNodeSingletonDeploy -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
GridServiceProcessorSingleNodeSelfTest.testNodeSingletonNotDeployedProxy -
PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
GridServiceProcessorSingleNodeSelfTest.testDeployMultiple1Old - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ComputeJobCancelWithServiceSelfTest.testJobCancel - PASSED{color}
... and 330 new tests
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5985984&buildTypeId=IgniteTests24Java8_RunAll]
> Security test suite runs no tests after CI test suite checker
> -
>
> Key: IGNITE-14665
> URL: https://issues.apache.org/jira/browse/IGNITE-14665
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Ilya Kasnacheev
>Assignee: Maksim Timonin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Please see linked development list thread as well as suite
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Security?mode=builds
> All runs end with:
> {code}
> [INFO] ---
> [INFO] T E S T S
> [INFO] ---
> [WARNING] ForkStarter IOException:
> org.apache.maven.surefire.util.internal.StringUtils.unescapeString(Ljava/lang/StringBuilder;L
[jira] [Commented] (IGNITE-14609) Document old and new async continuation behavior
[
https://issues.apache.org/jira/browse/IGNITE-14609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17335439#comment-17335439
]
Pavel Tupitsyn commented on IGNITE-14609:
-
Comments addressed, merged to master: 01e3899653d10c478beefcedff388dd657be5ba5
> Document old and new async continuation behavior
>
>
> Key: IGNITE-14609
> URL: https://issues.apache.org/jira/browse/IGNITE-14609
> Project: Ignite
> Issue Type: Improvement
> Components: documentation
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> IGNITE-12033 changed the default async behavior for cache operations in Java
> and .NET, plus Compute operations in .NET.
> Document old and new async continuation behavior for Java and .NET.
> Java:
> * Update
> https://ignite.apache.org/docs/latest/key-value-api/basic-cache-operations#asynchronous-execution
> * Mention changes in upcoming 2.11
> * Fix IgniteFuture javadoc (listen methods)
> .NET:
> * Add dedicated async page to {{.NET Specific}} section
> * Explain cache async ops
> * Explain known issues in Compute (Reduce method gets blocked)
> * Mention changes in upcoming 2.11
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-8731) .NET: intermittent failures in DataStreamerTest.TestFinalizer test
[
https://issues.apache.org/jira/browse/IGNITE-8731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-8731:
---
Fix Version/s: 2.11
> .NET: intermittent failures in DataStreamerTest.TestFinalizer test
> --
>
> Key: IGNITE-8731
> URL: https://issues.apache.org/jira/browse/IGNITE-8731
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Affects Versions: 2.5
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.11
>
>
> {{DataStreamerTest.TsetFinalizer}} constantly fails on some TC agents, while
> work OK on others. Most likely we have an environmental issue.
> OK:
> # publicagent01_03_9090
> # publicagent02_02_9090
> Not OK:
> # publicagent01_01_9090
> # publicagent01_02_9090
> # publicagent02_01_9090
> # publicagent02_03_9090
> Quick comparison of agent's configuration reveals only one difference -
> version of PowerShell. On "good" machines it is {{5.1.16299.15}}, on "bad"
> machines it is {{5.1.17134.1}}.
> PowerShell is essential part of build infrastructure so chances that some
> incorrect dependencies are linked at some point. I am not sure that this
> might be the root cause of failures, but at the very least we can try.
> Let's downgrade PowerShell on one of affected machines and see if it works.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-8731) .NET: intermittent failures in DataStreamerTest.TestFinalizer test
[
https://issues.apache.org/jira/browse/IGNITE-8731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn resolved IGNITE-8731.
Resolution: Fixed
Fixed as part of IGNITE-14655
> .NET: intermittent failures in DataStreamerTest.TestFinalizer test
> --
>
> Key: IGNITE-8731
> URL: https://issues.apache.org/jira/browse/IGNITE-8731
> Project: Ignite
> Issue Type: Task
> Components: platforms
>Affects Versions: 2.5
>Reporter: Vladimir Ozerov
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> {{DataStreamerTest.TsetFinalizer}} constantly fails on some TC agents, while
> work OK on others. Most likely we have an environmental issue.
> OK:
> # publicagent01_03_9090
> # publicagent02_02_9090
> Not OK:
> # publicagent01_01_9090
> # publicagent01_02_9090
> # publicagent02_01_9090
> # publicagent02_03_9090
> Quick comparison of agent's configuration reveals only one difference -
> version of PowerShell. On "good" machines it is {{5.1.16299.15}}, on "bad"
> machines it is {{5.1.17134.1}}.
> PowerShell is essential part of build infrastructure so chances that some
> incorrect dependencies are linked at some point. I am not sure that this
> might be the root cause of failures, but at the very least we can try.
> Let's downgrade PowerShell on one of affected machines and see if it works.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14655) .NET: Improve DataStreamer API
[
https://issues.apache.org/jira/browse/IGNITE-14655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-14655:
Release Note: .NET: Improved DataStreamer API - added FlushAsync,
deprecated and replaced confusing methods and properties, fixed resource cleanup
> .NET: Improve DataStreamer API
> --
>
> Key: IGNITE-14655
> URL: https://issues.apache.org/jira/browse/IGNITE-14655
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.11
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently, all {{AddData}} methods return a Task, however, this task is not
> for an individual add/remove operation, but for the current batch.
> This is confusing: users often try to {{await}} the returned task, which is
> natural; but the task will never complete, because the batch is not yet full,
> and user code is stuck waiting.
> * Deprecate {{AddData}}, {{RemoveData}} methods
> * Add new {{void Add}} and {{void Remove}} methods
> * Add new {{BatchTask}} property to get the task for the current batch
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-14474) Improve error message in case rebalance fails
[
https://issues.apache.org/jira/browse/IGNITE-14474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17335430#comment-17335430
]
Denis Chudov edited comment on IGNITE-14474 at 4/29/21, 12:45 PM:
--
[~Smolnikov] LGTM, pls fix typo in test (you can just apply suggested change on
github) and proceed to commiter's review.
was (Author: denis chudov):
[~Smolnikov] LGTM, pls fix typo in test (you can just apply suggested change on
github) and proceed to core team review.
> Improve error message in case rebalance fails
> -
>
> Key: IGNITE-14474
> URL: https://issues.apache.org/jira/browse/IGNITE-14474
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Denis Chudov
>Assignee: Rodion
>Priority: Major
> Fix For: 2.9.2
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Currently we can get a message like this when rebalance fails with an
> exception (examples from ignite 2.5, in newer versions the log messages were
> changed but the problem is still actual):
> {code:java}
> 2019-11-27 13:41:14,504[WARN ][utility-#79%xxx%][GridDhtPartitionDemander]
> Rebalancing from node cancelled [grp=ignite-sys-cache,
> topVer=AffinityTopologyVersion [topVer=1932, minorTopVer=1],
> supplier=f014f30a-77f2-4459-aa5b-6c12907a7449, topic=0]. Supply message
> couldn't be unmarshalled: class o.a.i.IgniteCheckedException: Failed to
> unmarshal object with optimized marshaller
> 2019-11-27 13:41:14,504[INFO ][utility-#79%xxx%][GridDhtPartitionDemander]
> Cancelled rebalancing [grp=ignite-sys-cache,
> supplier=f014f30a-77f2-4459-aa5b-6c12907a7449, topVer=AffinityTopologyVersion
> [topVer=1932, minorTopVer=1], time=88 ms]
> 2019-11-27 13:41:14,508[WARN ][utility-#76%xxx%][GridDhtPartitionDemander]
> Rebalancing from node cancelled [grp=ignite-sys-cache,
> topVer=AffinityTopologyVersion [topVer=1932, minorTopVer=1],
> supplier=dfa5ee06-48c9-4458-ae55-48cc6ceda998, topic=0]. Supply message
> couldn't be unmarshalled: class o.a.i.IgniteCheckedException: Failed to
> unmarshal object with optimized marshaller
> {code}
> In the case above, a marshalling exception leads to rebalance failure which
> will never be resolved - i.e. the cluster enters into a erroneous state.
> We should report issues like this as ERROR. The message should explain that
> the rebalance has failed, data for the cache was not fully copied to the
> node, the backup factor is not recovered and the cluster may not work
> correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14474) Improve error message in case rebalance fails
[
https://issues.apache.org/jira/browse/IGNITE-14474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17335430#comment-17335430
]
Denis Chudov commented on IGNITE-14474:
---
[~Smolnikov] LGTM, pls fix typo in test (you can just apply suggested change on
github) and proceed to core team review.
> Improve error message in case rebalance fails
> -
>
> Key: IGNITE-14474
> URL: https://issues.apache.org/jira/browse/IGNITE-14474
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Denis Chudov
>Assignee: Rodion
>Priority: Major
> Fix For: 2.9.2
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Currently we can get a message like this when rebalance fails with an
> exception (examples from ignite 2.5, in newer versions the log messages were
> changed but the problem is still actual):
> {code:java}
> 2019-11-27 13:41:14,504[WARN ][utility-#79%xxx%][GridDhtPartitionDemander]
> Rebalancing from node cancelled [grp=ignite-sys-cache,
> topVer=AffinityTopologyVersion [topVer=1932, minorTopVer=1],
> supplier=f014f30a-77f2-4459-aa5b-6c12907a7449, topic=0]. Supply message
> couldn't be unmarshalled: class o.a.i.IgniteCheckedException: Failed to
> unmarshal object with optimized marshaller
> 2019-11-27 13:41:14,504[INFO ][utility-#79%xxx%][GridDhtPartitionDemander]
> Cancelled rebalancing [grp=ignite-sys-cache,
> supplier=f014f30a-77f2-4459-aa5b-6c12907a7449, topVer=AffinityTopologyVersion
> [topVer=1932, minorTopVer=1], time=88 ms]
> 2019-11-27 13:41:14,508[WARN ][utility-#76%xxx%][GridDhtPartitionDemander]
> Rebalancing from node cancelled [grp=ignite-sys-cache,
> topVer=AffinityTopologyVersion [topVer=1932, minorTopVer=1],
> supplier=dfa5ee06-48c9-4458-ae55-48cc6ceda998, topic=0]. Supply message
> couldn't be unmarshalled: class o.a.i.IgniteCheckedException: Failed to
> unmarshal object with optimized marshaller
> {code}
> In the case above, a marshalling exception leads to rebalance failure which
> will never be resolved - i.e. the cluster enters into a erroneous state.
> We should report issues like this as ERROR. The message should explain that
> the rebalance has failed, data for the cache was not fully copied to the
> node, the backup factor is not recovered and the cluster may not work
> correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14670) Update MetaStorageManager with invoke method for atomic multi-update
Kirill Gusakov created IGNITE-14670:
---
Summary: Update MetaStorageManager with invoke method for atomic
multi-update
Key: IGNITE-14670
URL: https://issues.apache.org/jira/browse/IGNITE-14670
Project: Ignite
Issue Type: Task
Reporter: Kirill Gusakov
Assignee: Kirill Gusakov
Configuration updates must be done as one atomic batch with one revision.
To implement this approach we need to update API of DMS manager with the
following method:
{code:java}
public @NotNull CompletableFuture invoke(@NotNull Condition cond,
@NotNull Collection success, @NotNull Collection
failure)
{code}
and update Condition with key parameter.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14655) .NET: Improve DataStreamer API
[
https://issues.apache.org/jira/browse/IGNITE-14655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17335428#comment-17335428
]
Pavel Tupitsyn commented on IGNITE-14655:
-
Merged to master: 85b52a0f298d737c0c3472405a25347fc2cbe6cc
> .NET: Improve DataStreamer API
> --
>
> Key: IGNITE-14655
> URL: https://issues.apache.org/jira/browse/IGNITE-14655
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.11
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Currently, all {{AddData}} methods return a Task, however, this task is not
> for an individual add/remove operation, but for the current batch.
> This is confusing: users often try to {{await}} the returned task, which is
> natural; but the task will never complete, because the batch is not yet full,
> and user code is stuck waiting.
> * Deprecate {{AddData}}, {{RemoveData}} methods
> * Add new {{void Add}} and {{void Remove}} methods
> * Add new {{BatchTask}} property to get the task for the current batch
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14238) Creating and destroying tables
[ https://issues.apache.org/jira/browse/IGNITE-14238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-14238: - Description: Need to implement a new cluster-wide procedure that will be responsible for creating and destroying tables. [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-54%3A+Schema-first+Approach was: Need to implement a new cluster-wide procedure that will be responsible for creating and destroying caches. [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-54%3A+Schema-first+Approach > Creating and destroying tables > -- > > Key: IGNITE-14238 > URL: https://issues.apache.org/jira/browse/IGNITE-14238 > Project: Ignite > Issue Type: Sub-task >Reporter: Vyacheslav Koptilin >Assignee: Vladislav Pyatkov >Priority: Major > Labels: iep-72, ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Need to implement a new cluster-wide procedure that will be responsible for > creating and destroying tables. > [1] > https://cwiki.apache.org/confluence/display/IGNITE/IEP-54%3A+Schema-first+Approach -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14543) Calcite engine. Aggregate functions fail on scalar values
[
https://issues.apache.org/jira/browse/IGNITE-14543?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-14543:
--
Summary: Calcite engine. Aggregate functions fail on scalar values (was:
Calcite engine. Agregate functions fail on scalar values)
> Calcite engine. Aggregate functions fail on scalar values
> -
>
> Key: IGNITE-14543
> URL: https://issues.apache.org/jira/browse/IGNITE-14543
> Project: Ignite
> Issue Type: Bug
>Reporter: Taras Ledkov
>Assignee: Konstantin Orlov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Failed queries:
> {{SELECT COUNT(*)}}
> {{SELECT COUNT(NULL)}}
> {{SELECT AVG(NULL)}}
> Tests:
> {{aggregate/aggregates/test_count.test_ignored}}
> {{aggregate/aggregates/test_aggregate_types_scalar.test_ignore}}
> {{aggregate/aggregates/test_avg.test}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-14655) .NET: Improve DataStreamer API
[
https://issues.apache.org/jira/browse/IGNITE-14655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-14655:
Comment: was deleted
(was: {panel:title=Branch: [pull/9058/head] Base: [master] : Possible Blockers
(10)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Control Utility{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5985728]]
{color:#d04437}Basic 1{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5985674]]
{color:#d04437}Cache 6{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5985695]]
{color:#d04437}Platform .NET (Core Linux){color} [[tests 1 TC_SERVICE_MESSAGE
|https://ci.ignite.apache.org/viewLog.html?buildId=5985710]]
* dll:
ContinuousQueryTest.TestIncludeExpiredIsFalseByDefaultAndExpiredEventsAreSkipped
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Java Client{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5985653]]
{color:#d04437}Cache 1{color} [[tests 1 TIMEOUT , Out Of Memory Error , Exit
Code |https://ci.ignite.apache.org/viewLog.html?buildId=5985690]]
* IgniteBinaryCacheTestSuite:
DataStreamProcessorPersistenceBinarySelfTest.testReplicatedIsolated - Test has
low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Platform C++ CMake (Win x64 / Release){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5985730]]
* IgniteCoreTest: ComputeTestSuite: IgniteCallAsyncLocalError - Test has low
fail rate in base branch 0,0% and is not flaky
{color:#d04437}Platform C++ CMake (Linux Clang){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5985726]]
* IgniteCoreTest: ComputeTestSuite: IgniteRunRemoteError - Test has low fail
rate in base branch 0,0% and is not flaky
{color:#d04437}Platform .NET (Inspections)*{color} [[tests 0 Failure on metric
|https://ci.ignite.apache.org/viewLog.html?buildId=5985711]]
{panel}
{panel:title=Branch: [pull/9058/head] Base: [master] : New Tests
(13)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Platform .NET (Core Linux){color} [[tests
7|https://ci.ignite.apache.org/viewLog.html?buildId=5985710]]
* {color:#013220}dll: DataStreamerTest.TestDestroyCacheObsolete - PASSED{color}
* {color:#013220}dll: DataStreamerTest.TestFlushAsync - PASSED{color}
* {color:#013220}dll: DataStreamerTest.TestAutoFlushObsolete - PASSED{color}
* {color:#013220}dll: DataStreamerTest.TestDestroyCache - PASSED{color}
* {color:#013220}dll: DataStreamerTest.TestStreamerAsyncAwait - PASSED{color}
* {color:#013220}dll: DataStreamerTest.TestTryFlushObsolete - PASSED{color}
* {color:#013220}dll: DataStreamerTest.TestAddRemoveObsolete - PASSED{color}
{color:#8b}Platform .NET{color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=5985709]]
* {color:#013220}exe: DataStreamerTest.TestFlushAsync - PASSED{color}
* {color:#013220}exe: DataStreamerTest.TestTryFlushObsolete - PASSED{color}
* {color:#013220}exe: DataStreamerTest.TestDestroyCache - PASSED{color}
* {color:#013220}exe: DataStreamerTest.TestDestroyCacheObsolete - PASSED{color}
* {color:#013220}exe: DataStreamerTest.TestAddRemoveObsolete - PASSED{color}
* {color:#013220}exe: DataStreamerTest.TestAutoFlushObsolete - PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5985736&buildTypeId=IgniteTests24Java8_RunAll])
> .NET: Improve DataStreamer API
> --
>
> Key: IGNITE-14655
> URL: https://issues.apache.org/jira/browse/IGNITE-14655
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, all {{AddData}} methods return a Task, however, this task is not
> for an individual add/remove operation, but for the current batch.
> This is confusing: users often try to {{await}} the returned task, which is
> natural; but the task will never complete, because the batch is not yet full,
> and user code is stuck waiting.
> * Deprecate {{AddData}}, {{RemoveData}} methods
> * Add new {{void Add}} and {{void Remove}} methods
> * Add new {{BatchTask}} property to get the task for the current batch
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14655) .NET: Improve DataStreamer API
[
https://issues.apache.org/jira/browse/IGNITE-14655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17335372#comment-17335372
]
Ignite TC Bot commented on IGNITE-14655:
{panel:title=Branch: [pull/9058/head] Base: [master] : Possible Blockers
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 6{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5986670]]
{color:#d04437}Cache 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5986676]]
* IgniteBinaryCacheTestSuite: IgniteCommunicationBalanceTest.testBalance2 -
Test has low fail rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/9058/head] Base: [master] : New Tests
(13)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Platform .NET (Core Linux){color} [[tests
7|https://ci.ignite.apache.org/viewLog.html?buildId=5986672]]
* {color:#013220}dll: DataStreamerTest.TestDestroyCacheObsolete - PASSED{color}
* {color:#013220}dll: DataStreamerTest.TestFlushAsync - PASSED{color}
* {color:#013220}dll: DataStreamerTest.TestAutoFlushObsolete - PASSED{color}
* {color:#013220}dll: DataStreamerTest.TestDestroyCache - PASSED{color}
* {color:#013220}dll: DataStreamerTest.TestStreamerAsyncAwait - PASSED{color}
* {color:#013220}dll: DataStreamerTest.TestTryFlushObsolete - PASSED{color}
* {color:#013220}dll: DataStreamerTest.TestAddRemoveObsolete - PASSED{color}
{color:#8b}Platform .NET{color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=5986678]]
* {color:#013220}exe: DataStreamerTest.TestFlushAsync - PASSED{color}
* {color:#013220}exe: DataStreamerTest.TestTryFlushObsolete - PASSED{color}
* {color:#013220}exe: DataStreamerTest.TestDestroyCache - PASSED{color}
* {color:#013220}exe: DataStreamerTest.TestDestroyCacheObsolete - PASSED{color}
* {color:#013220}exe: DataStreamerTest.TestAddRemoveObsolete - PASSED{color}
* {color:#013220}exe: DataStreamerTest.TestAutoFlushObsolete - PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5985736&buildTypeId=IgniteTests24Java8_RunAll]
> .NET: Improve DataStreamer API
> --
>
> Key: IGNITE-14655
> URL: https://issues.apache.org/jira/browse/IGNITE-14655
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.11
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, all {{AddData}} methods return a Task, however, this task is not
> for an individual add/remove operation, but for the current batch.
> This is confusing: users often try to {{await}} the returned task, which is
> natural; but the task will never complete, because the batch is not yet full,
> and user code is stuck waiting.
> * Deprecate {{AddData}}, {{RemoveData}} methods
> * Add new {{void Add}} and {{void Remove}} methods
> * Add new {{BatchTask}} property to get the task for the current batch
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-13710) Calcite integration. Fix or to union rule logic
[ https://issues.apache.org/jira/browse/IGNITE-13710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov reassigned IGNITE-13710: -- Assignee: (was: Aleksey Plekhanov) > Calcite integration. Fix or to union rule logic > --- > > Key: IGNITE-13710 > URL: https://issues.apache.org/jira/browse/IGNITE-13710 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Igor Seliverstov >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13710) Calcite integration. Fix or to union rule logic
[
https://issues.apache.org/jira/browse/IGNITE-13710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17335366#comment-17335366
]
Aleksey Plekhanov commented on IGNITE-13710:
Since Calcite version 1.26, {{OR}} operator on the same field replaced with
{{SEARCH}} operator. If we will try to replace each {{SEARCH}} by {{UNION}},
there will be too many plan variants, since other operators can also be
translated to search (for example {{a != n}} can be replaced by {{SEARCH}} with
two ranges {{[-infinity, n)}} and {{(n, infinity]}}). I think it's better to
add native {{SEARCH}} support with the ability to scan indexes using {{SEARCH}}
operator.
> Calcite integration. Fix or to union rule logic
> ---
>
> Key: IGNITE-13710
> URL: https://issues.apache.org/jira/browse/IGNITE-13710
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Igor Seliverstov
>Assignee: Aleksey Plekhanov
>Priority: Minor
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14669) NPE in GridCacheIoManager when sending GridCacheQueryResponse, target node left grid
[
https://issues.apache.org/jira/browse/IGNITE-14669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-14669:
-
Description:
{code:java}
ERROR o.a.i.i.p.cache.GridCacheIoManager - Failed to process message
java.lang.NullPointerException: null
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.sendOrderedMessage(GridCacheIoManager.java:1309)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processFailedMessage(GridCacheIoManager.java:932)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:589)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1721)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1328)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4600(GridIoManager.java:157)
at
org.apache.ignite.internal.managers.communication.GridIoManager$8.execute(GridIoManager.java:1213)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:54)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
{code}
was:
ERROR o.a.i.i.p.cache.GridCacheIoManager - Failed to process message
java.lang.NullPointerException: null
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.sendOrderedMessage(GridCacheIoManager.java:1309)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processFailedMessage(GridCacheIoManager.java:932)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:589)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1721)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1328)
at
org.apache.ignite.internal.managers.communication.GridIoManager.access$4600(GridIoManager.java:157)
at
org.apache.ignite.internal.managers.communication.GridIoManager$8.execute(GridIoManager.java:1213)
at
org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:54)
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)
> NPE in GridCacheIoManager when sending GridCacheQueryResponse, target node
> left grid
>
>
> Key: IGNITE-14669
> URL: https://issues.apache.org/jira/browse/IGNITE-14669
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.10
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> {code:java}
> ERROR o.a.i.i.p.cache.GridCacheIoManager - Failed to process message
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.sendOrderedMessage(GridCacheIoManager.java:1309)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processFailedMessage(GridCacheIoManager.java:932)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:589)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManage
[jira] [Created] (IGNITE-14669) NPE in GridCacheIoManager when sending GridCacheQueryResponse, target node left grid
Ilya Kasnacheev created IGNITE-14669: Summary: NPE in GridCacheIoManager when sending GridCacheQueryResponse, target node left grid Key: IGNITE-14669 URL: https://issues.apache.org/jira/browse/IGNITE-14669 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.10 Reporter: Ilya Kasnacheev Assignee: Ilya Kasnacheev ERROR o.a.i.i.p.cache.GridCacheIoManager - Failed to process message java.lang.NullPointerException: null at org.apache.ignite.internal.processors.cache.GridCacheIoManager.sendOrderedMessage(GridCacheIoManager.java:1309) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.processFailedMessage(GridCacheIoManager.java:932) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:589) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318) at org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109) at org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308) at org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1721) at org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1328) at org.apache.ignite.internal.managers.communication.GridIoManager.access$4600(GridIoManager.java:157) at org.apache.ignite.internal.managers.communication.GridIoManager$8.execute(GridIoManager.java:1213) at org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:54) at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128) at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628) at java.base/java.lang.Thread.run(Thread.java:834) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14625) Make DurableBackgroundTask return future
[ https://issues.apache.org/jira/browse/IGNITE-14625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-14625: - Reviewer: Ivan Bessonov (was: Denis Chudov) > Make DurableBackgroundTask return future > > > Key: IGNITE-14625 > URL: https://issues.apache.org/jira/browse/IGNITE-14625 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.11 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > While trying to implement rebuilding indexes on *DurableBackgroundTask*, I > encountered several problems: > * For each task, a new thread is created, which can be critical for > rebuilding indexes, since there can be many caches and this can create many > threads; > * Tasks can be completed close to the end of a checkpoint, and data may not > reach this checkpoint. > Therefore, I propose to slightly rework the *DurableBackgroundTask*. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14661) Broken validation of parts of compound PK
[
https://issues.apache.org/jira/browse/IGNITE-14661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-14661:
--
Fix Version/s: 2.11
> Broken validation of parts of compound PK
> -
>
> Key: IGNITE-14661
> URL: https://issues.apache.org/jira/browse/IGNITE-14661
> Project: Ignite
> Issue Type: Bug
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently it's possible to set {{null}} to column that is part of compound PK
> even if this field was declared as {{NOT NULL}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14666) Add proper listener handling in DistributedConfigurationStorage and LocalConfigurationStorage
[ https://issues.apache.org/jira/browse/IGNITE-14666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-14666: - Fix Version/s: 3.0.0-alpha2 > Add proper listener handling in DistributedConfigurationStorage and > LocalConfigurationStorage > - > > Key: IGNITE-14666 > URL: https://issues.apache.org/jira/browse/IGNITE-14666 > Project: Ignite > Issue Type: Task >Reporter: Mirza Aliev >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha2 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14406) Define interface for Vault
[ https://issues.apache.org/jira/browse/IGNITE-14406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-14406: - Fix Version/s: 3.0.0-alpha2 > Define interface for Vault > -- > > Key: IGNITE-14406 > URL: https://issues.apache.org/jira/browse/IGNITE-14406 > Project: Ignite > Issue Type: Sub-task >Reporter: Vyacheslav Koptilin >Assignee: Mirza Aliev >Priority: Major > Fix For: 3.0.0-alpha2 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Need to provide a simple API that can be easily used and takes into account > types of properties: user-level properties, system-level, system-level > properties that require appliedRevision. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14392) Remove the SQL Transactions page from Apache Ignite docs
[ https://issues.apache.org/jira/browse/IGNITE-14392?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17335267#comment-17335267 ] Igor Gusev commented on IGNITE-14392: - [~dma...@apache.org] can you review the PR? > Remove the SQL Transactions page from Apache Ignite docs > > > Key: IGNITE-14392 > URL: https://issues.apache.org/jira/browse/IGNITE-14392 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Nikita Safonov >Assignee: Igor Gusev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > The page: > [https://ignite.apache.org/docs/latest/SQL/sql-transactions|https://www.gridgain.com/docs/latest/developers-guide/SQL/sql-transactions] > * We should remove it from the menu (toc.yaml) > * We should make sure it's not indexed by Google -> need to update robot.txt > * We should check references to this page from other pages. The references > do exist. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14668) SSL certificates generation on parallel run
Mikhail Filatov created IGNITE-14668: Summary: SSL certificates generation on parallel run Key: IGNITE-14668 URL: https://issues.apache.org/jira/browse/IGNITE-14668 Project: Ignite Issue Type: Task Reporter: Mikhail Filatov Assignee: Mikhail Filatov If we run tests in parallel, certificates should be fully generated before any test run. To accomplish this, we need to wait for certificate generation process to finish -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14660) Flaky test GridSubqueryJoinOptimizerSelfTest#testOptimizationAppliedToUnion
[
https://issues.apache.org/jira/browse/IGNITE-14660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Taras Ledkov updated IGNITE-14660:
--
Fix Version/s: 2.11
> Flaky test GridSubqueryJoinOptimizerSelfTest#testOptimizationAppliedToUnion
> ---
>
> Key: IGNITE-14660
> URL: https://issues.apache.org/jira/browse/IGNITE-14660
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently
> {{GridSubqueryJoinOptimizerSelfTest#testOptimizationAppliedToUnion}} could
> fail because of lack of result sorting.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14474) Improve error message in case rebalance fails
[
https://issues.apache.org/jira/browse/IGNITE-14474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17335220#comment-17335220
]
Rodion commented on IGNITE-14474:
-
Sorry for double send bot visa. [~Denis Chudov] all conversations has been
resolved
> Improve error message in case rebalance fails
> -
>
> Key: IGNITE-14474
> URL: https://issues.apache.org/jira/browse/IGNITE-14474
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Denis Chudov
>Assignee: Rodion
>Priority: Major
> Fix For: 2.9.2
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently we can get a message like this when rebalance fails with an
> exception (examples from ignite 2.5, in newer versions the log messages were
> changed but the problem is still actual):
> {code:java}
> 2019-11-27 13:41:14,504[WARN ][utility-#79%xxx%][GridDhtPartitionDemander]
> Rebalancing from node cancelled [grp=ignite-sys-cache,
> topVer=AffinityTopologyVersion [topVer=1932, minorTopVer=1],
> supplier=f014f30a-77f2-4459-aa5b-6c12907a7449, topic=0]. Supply message
> couldn't be unmarshalled: class o.a.i.IgniteCheckedException: Failed to
> unmarshal object with optimized marshaller
> 2019-11-27 13:41:14,504[INFO ][utility-#79%xxx%][GridDhtPartitionDemander]
> Cancelled rebalancing [grp=ignite-sys-cache,
> supplier=f014f30a-77f2-4459-aa5b-6c12907a7449, topVer=AffinityTopologyVersion
> [topVer=1932, minorTopVer=1], time=88 ms]
> 2019-11-27 13:41:14,508[WARN ][utility-#76%xxx%][GridDhtPartitionDemander]
> Rebalancing from node cancelled [grp=ignite-sys-cache,
> topVer=AffinityTopologyVersion [topVer=1932, minorTopVer=1],
> supplier=dfa5ee06-48c9-4458-ae55-48cc6ceda998, topic=0]. Supply message
> couldn't be unmarshalled: class o.a.i.IgniteCheckedException: Failed to
> unmarshal object with optimized marshaller
> {code}
> In the case above, a marshalling exception leads to rebalance failure which
> will never be resolved - i.e. the cluster enters into a erroneous state.
> We should report issues like this as ERROR. The message should explain that
> the rebalance has failed, data for the cache was not fully copied to the
> node, the backup factor is not recovered and the cluster may not work
> correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14474) Improve error message in case rebalance fails
[
https://issues.apache.org/jira/browse/IGNITE-14474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17335206#comment-17335206
]
Ignite TC Bot commented on IGNITE-14474:
{panel:title=Branch: [pull/9004/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9004/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5982259&buildTypeId=IgniteTests24Java8_RunAll]
> Improve error message in case rebalance fails
> -
>
> Key: IGNITE-14474
> URL: https://issues.apache.org/jira/browse/IGNITE-14474
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Denis Chudov
>Assignee: Rodion
>Priority: Major
> Fix For: 2.9.2
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently we can get a message like this when rebalance fails with an
> exception (examples from ignite 2.5, in newer versions the log messages were
> changed but the problem is still actual):
> {code:java}
> 2019-11-27 13:41:14,504[WARN ][utility-#79%xxx%][GridDhtPartitionDemander]
> Rebalancing from node cancelled [grp=ignite-sys-cache,
> topVer=AffinityTopologyVersion [topVer=1932, minorTopVer=1],
> supplier=f014f30a-77f2-4459-aa5b-6c12907a7449, topic=0]. Supply message
> couldn't be unmarshalled: class o.a.i.IgniteCheckedException: Failed to
> unmarshal object with optimized marshaller
> 2019-11-27 13:41:14,504[INFO ][utility-#79%xxx%][GridDhtPartitionDemander]
> Cancelled rebalancing [grp=ignite-sys-cache,
> supplier=f014f30a-77f2-4459-aa5b-6c12907a7449, topVer=AffinityTopologyVersion
> [topVer=1932, minorTopVer=1], time=88 ms]
> 2019-11-27 13:41:14,508[WARN ][utility-#76%xxx%][GridDhtPartitionDemander]
> Rebalancing from node cancelled [grp=ignite-sys-cache,
> topVer=AffinityTopologyVersion [topVer=1932, minorTopVer=1],
> supplier=dfa5ee06-48c9-4458-ae55-48cc6ceda998, topic=0]. Supply message
> couldn't be unmarshalled: class o.a.i.IgniteCheckedException: Failed to
> unmarshal object with optimized marshaller
> {code}
> In the case above, a marshalling exception leads to rebalance failure which
> will never be resolved - i.e. the cluster enters into a erroneous state.
> We should report issues like this as ERROR. The message should explain that
> the rebalance has failed, data for the cache was not fully copied to the
> node, the backup factor is not recovered and the cluster may not work
> correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14474) Improve error message in case rebalance fails
[
https://issues.apache.org/jira/browse/IGNITE-14474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17335202#comment-17335202
]
Ignite TC Bot commented on IGNITE-14474:
{panel:title=Branch: [pull/9004/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9004/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5982259&buildTypeId=IgniteTests24Java8_RunAll]
> Improve error message in case rebalance fails
> -
>
> Key: IGNITE-14474
> URL: https://issues.apache.org/jira/browse/IGNITE-14474
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.5
>Reporter: Denis Chudov
>Assignee: Rodion
>Priority: Major
> Fix For: 2.9.2
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Currently we can get a message like this when rebalance fails with an
> exception (examples from ignite 2.5, in newer versions the log messages were
> changed but the problem is still actual):
> {code:java}
> 2019-11-27 13:41:14,504[WARN ][utility-#79%xxx%][GridDhtPartitionDemander]
> Rebalancing from node cancelled [grp=ignite-sys-cache,
> topVer=AffinityTopologyVersion [topVer=1932, minorTopVer=1],
> supplier=f014f30a-77f2-4459-aa5b-6c12907a7449, topic=0]. Supply message
> couldn't be unmarshalled: class o.a.i.IgniteCheckedException: Failed to
> unmarshal object with optimized marshaller
> 2019-11-27 13:41:14,504[INFO ][utility-#79%xxx%][GridDhtPartitionDemander]
> Cancelled rebalancing [grp=ignite-sys-cache,
> supplier=f014f30a-77f2-4459-aa5b-6c12907a7449, topVer=AffinityTopologyVersion
> [topVer=1932, minorTopVer=1], time=88 ms]
> 2019-11-27 13:41:14,508[WARN ][utility-#76%xxx%][GridDhtPartitionDemander]
> Rebalancing from node cancelled [grp=ignite-sys-cache,
> topVer=AffinityTopologyVersion [topVer=1932, minorTopVer=1],
> supplier=dfa5ee06-48c9-4458-ae55-48cc6ceda998, topic=0]. Supply message
> couldn't be unmarshalled: class o.a.i.IgniteCheckedException: Failed to
> unmarshal object with optimized marshaller
> {code}
> In the case above, a marshalling exception leads to rebalance failure which
> will never be resolved - i.e. the cluster enters into a erroneous state.
> We should report issues like this as ERROR. The message should explain that
> the rebalance has failed, data for the cache was not fully copied to the
> node, the backup factor is not recovered and the cluster may not work
> correctly.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-14541) Calcite engine. HAVING fails on scalar
[
https://issues.apache.org/jira/browse/IGNITE-14541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov reassigned IGNITE-14541:
-
Assignee: Konstantin Orlov
> Calcite engine. HAVING fails on scalar
> ---
>
> Key: IGNITE-14541
> URL: https://issues.apache.org/jira/browse/IGNITE-14541
> Project: Ignite
> Issue Type: Bug
>Reporter: Taras Ledkov
>Assignee: Konstantin Orlov
>Priority: Major
>
> Query to reproduce:
> {{SELECT 42 HAVING 42 > 20}}
> Test: {{aggregate/having/test_scalar_having.test_ignore}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-6324) Transactional cache data partially available after crash and further recovery.
[ https://issues.apache.org/jira/browse/IGNITE-6324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17335193#comment-17335193 ] Sergey Chugunov commented on IGNITE-6324: - [~zstan], Patch looks good to me now, I merged it to master branch in commit *d0da231c7e8891d9fd45be3a245612e41b464e60*. Thank you for contribution! > Transactional cache data partially available after crash and further recovery. > -- > > Key: IGNITE-6324 > URL: https://issues.apache.org/jira/browse/IGNITE-6324 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.10 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Critical > Fix For: 2.11 > > Attachments: InterruptCommitedThreadTest.java > > Time Spent: 50m > Remaining Estimate: 0h > > If InterruptedException raise in client code during pds store operations we > can obtain inconsistent cache after restart. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-6324) Transactional cache data partially available after crash and further recovery.
[ https://issues.apache.org/jira/browse/IGNITE-6324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-6324: Fix Version/s: 2.11 > Transactional cache data partially available after crash and further recovery. > -- > > Key: IGNITE-6324 > URL: https://issues.apache.org/jira/browse/IGNITE-6324 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.10 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Critical > Fix For: 2.11 > > Attachments: InterruptCommitedThreadTest.java > > Time Spent: 50m > Remaining Estimate: 0h > > If InterruptedException raise in client code during pds store operations we > can obtain inconsistent cache after restart. -- This message was sent by Atlassian Jira (v8.3.4#803005)
