[jira] [Created] (IGNITE-10057) SQL queries hang during rebalance if there are LOST partitions
Stanislav Lukyanov created IGNITE-10057:
---
Summary: SQL queries hang during rebalance if there are LOST
partitions
Key: IGNITE-10057
URL: https://issues.apache.org/jira/browse/IGNITE-10057
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Stanislav Lukyanov
When there are both LOST and MOVING partitions in the cluster, SQL queries will
hang until rebalance has completed and there aren't any MOVING partitions.
During that time the reducer node keeps printing
{code}
[2018-10-30 10:26:06,787][INFO
][test-runner-#1%cache.IndexingCachePartitionLossPolicySelfTest%][GridReduceQueryExecutor]
Failed to calculate nodes for SQL query (partition has no owners, but
corresponding cache group has data nodes) [qryId=13, cacheIds=[1254100233],
cacheName=partitioned, cacheId=1254100233, part=0, cacheGroupId=1254100233]
[2018-10-30 10:26:06,798][INFO
][test-runner-#1%cache.IndexingCachePartitionLossPolicySelfTest%][GridReduceQueryExecutor]
Failed to calculate nodes for SQL query (partition has no owners, but
corresponding cache group has data nodes) [qryId=14, cacheIds=[1254100233],
cacheName=partitioned, cacheId=1254100233, part=0, cacheGroupId=1254100233]
[2018-10-30 10:26:06,818][INFO
][test-runner-#1%cache.IndexingCachePartitionLossPolicySelfTest%][GridReduceQueryExecutor]
Failed to calculate nodes for SQL query (partition has no owners, but
corresponding cache group has data nodes) [qryId=15, cacheIds=[1254100233],
cacheName=partitioned, cacheId=1254100233, part=0, cacheGroupId=1254100233]
[2018-10-30 10:26:06,849][INFO
][test-runner-#1%cache.IndexingCachePartitionLossPolicySelfTest%][GridReduceQueryExecutor]
Failed to calculate nodes for SQL query (partition has no owners, but
corresponding cache group has data nodes) [qryId=16, cacheIds=[1254100233],
cacheName=partitioned, cacheId=1254100233, part=0, cacheGroupId=1254100233]
[2018-10-30 10:26:06,889][INFO
][test-runner-#1%cache.IndexingCachePartitionLossPolicySelfTest%][GridReduceQueryExecutor]
Failed to calculate nodes for SQL query (partition has no owners, but
corresponding cache group has data nodes) [qryId=17, cacheIds=[1254100233],
cacheName=partitioned, cacheId=1254100233, part=0, cacheGroupId=1254100233]
[2018-10-30 10:26:06,940][INFO
][test-runner-#1%cache.IndexingCachePartitionLossPolicySelfTest%][GridReduceQueryExecutor]
Failed to calculate nodes for SQL query (partition has no owners, but
corresponding cache group has data nodes) [qryId=18, cacheIds=[1254100233],
cacheName=partitioned, cacheId=1254100233, part=0, cacheGroupId=1254100233]
[2018-10-30 10:26:07,001][INFO
][test-runner-#1%cache.IndexingCachePartitionLossPolicySelfTest%][GridReduceQueryExecutor]
Failed to calculate nodes for SQL query (partition has no owners, but
corresponding cache group has data nodes) [qryId=19, cacheIds=[1254100233],
cacheName=partitioned, cacheId=1254100233, part=0, cacheGroupId=1254100233]
[2018-10-30 10:26:07,072][INFO
][test-runner-#1%cache.IndexingCachePartitionLossPolicySelfTest%][GridReduceQueryExecutor]
Failed to calculate nodes for SQL query (partition has no owners, but
corresponding cache group has data nodes) [qryId=20, cacheIds=[1254100233],
cacheName=partitioned, cacheId=1254100233, part=0, cacheGroupId=1254100233]
[2018-10-30 10:26:07,152][INFO
][test-runner-#1%cache.IndexingCachePartitionLossPolicySelfTest%][GridReduceQueryExecutor]
Failed to calculate nodes for SQL query (partition has no owners, but
corresponding cache group has data nodes) [qryId=21, cacheIds=[1254100233],
cacheName=partitioned, cacheId=1254100233, part=0, cacheGroupId=1254100233]
[2018-10-30 10:26:07,243][INFO
][test-runner-#1%cache.IndexingCachePartitionLossPolicySelfTest%][GridReduceQueryExecutor]
Failed to calculate nodes for SQL query (partition has no owners, but
corresponding cache group has data nodes) [qryId=22, cacheIds=[1254100233],
cacheName=partitioned, cacheId=1254100233, part=0, cacheGroupId=1254100233]
[2018-10-30 10:26:07,343][INFO
][test-runner-#1%cache.IndexingCachePartitionLossPolicySelfTest%][GridReduceQueryExecutor]
Failed to calculate nodes for SQL query (partition has no owners, but
corresponding cache group has data nodes) [qryId=23, cacheIds=[1254100233],
cacheName=partitioned, cacheId=1254100233, part=0, cacheGroupId=1254100233]
[2018-10-30 10:26:07,454][INFO
][test-runner-#1%cache.IndexingCachePartitionLossPolicySelfTest%][GridReduceQueryExecutor]
Failed to calculate nodes for SQL query (partition has no owners, but
corresponding cache group has data nodes) [qryId=24, cacheIds=[1254100233],
cacheName=partitioned, cacheId=1254100233, part=0, cacheGroupId=1254100233]
[2018-10-30 10:26:07,575][INFO
][test-runner-#1%cache.IndexingCachePartitionLossPolicySelfTest%][GridReduceQueryExecutor]
Failed to calculate nodes for SQL query (partition has no owners, but
correspondi
[jira] [Commented] (IGNITE-9828) MVCC: Continuous query failover.
[
https://issues.apache.org/jira/browse/IGNITE-9828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668280#comment-16668280
]
Ignite TC Bot commented on IGNITE-9828:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}SPI{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2192798]]
* IgniteSpiTestSuite: TcpDiscoverySslSelfTest.testNonSharedIpFinder - 0,0%
fails in last 100 master runs.
{color:#d04437}Queries (Binary Objects Simple Mapper){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2192865]]
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
GridCacheFullTextQuerySelfTest.testLocalTextQueryWithKeepBinary - 0,0% fails in
last 100 master runs.
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
H2DynamicIndexingComplexClientTransactionalReplicatedTest.testOperations - 0,0%
fails in last 100 master runs.
{color:#d04437}Cache (Deadlock Detection){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2192821]]
* TxDeadlockDetectionTestSuite:
TxPessimisticDeadlockDetectionTest.testDeadlocksPartitioned - 0,0% fails in
last 100 master runs.
{color:#d04437}Binary Objects (Simple Mapper Cache Full API){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2192765]]
* IgniteBinarySimpleNameMapperCacheFullApiTestSuite:
GridCacheAtomicFullApiSelfTest.testTtlNoTxOldEntry - 0,0% fails in last 100
master runs.
{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2192871&buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: Continuous query failover.
>
>
> Key: IGNITE-9828
> URL: https://issues.apache.org/jira/browse/IGNITE-9828
> Project: Ignite
> Issue Type: Task
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Fix For: 2.7
>
>
> We need to implement failover procedure for CQ with MVCC caches. Thoughts:
> * CQ failover tests should be adopted for mvcc scenarios. See
> {{IgniteCacheQuerySelfTestSuite4}}
> * We need to ensure the correctness of CQ and partition counters consistency
> in cases when some of TX participants are in prepared state and others are
> marked as rollback only. It looks like it doesn't work properly now.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9828) MVCC: Continuous query failover.
[
https://issues.apache.org/jira/browse/IGNITE-9828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668286#comment-16668286
]
Roman Kondakov commented on IGNITE-9828:
[~vozerov], [~gvvinblade], patch is ready for review. TC run is OK.
> MVCC: Continuous query failover.
>
>
> Key: IGNITE-9828
> URL: https://issues.apache.org/jira/browse/IGNITE-9828
> Project: Ignite
> Issue Type: Task
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Roman Kondakov
>Priority: Major
> Fix For: 2.7
>
>
> We need to implement failover procedure for CQ with MVCC caches. Thoughts:
> * CQ failover tests should be adopted for mvcc scenarios. See
> {{IgniteCacheQuerySelfTestSuite4}}
> * We need to ensure the correctness of CQ and partition counters consistency
> in cases when some of TX participants are in prepared state and others are
> marked as rollback only. It looks like it doesn't work properly now.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10058) resetLostPartitions() leaves an additional copy of a partition in the cluster
Stanislav Lukyanov created IGNITE-10058: --- Summary: resetLostPartitions() leaves an additional copy of a partition in the cluster Key: IGNITE-10058 URL: https://issues.apache.org/jira/browse/IGNITE-10058 Project: Ignite Issue Type: Bug Reporter: Stanislav Lukyanov If there are several copies of a LOST partition, resetLostPartitions() will leave all of them in the cluster as OWNING. Scenario: 1) Start 4 nodes, a cache with backups=0 and READ_WRITE_SAFE, fill the cache 2) Stop one node - some partitions are recreated on the remaining nodes as LOST 3) Start one node - the LOST partitions are being rebalanced to the new node from the existing ones 4) Wait for rebalance to complete 5) Call resetLostPartitions() After that the partitions that were LOST become OWNING on all nodes that had them. Eviction of these partitions doesn't start. Need to correctly evict additional copies of LOST partitions either after rebalance on step 4 or after resetLostPartitions() call on step 5. Current resetLostPartitions() implementation does call checkEvictions(), but the ready affinity assignment contains several nodes per partition for some reason. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9841) SQL doesn't take lost partitions into account when persistence is enabled
[ https://issues.apache.org/jira/browse/IGNITE-9841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668306#comment-16668306 ] Stanislav Lukyanov commented on IGNITE-9841: PR: https://github.com/apache/ignite/pull/5069 > SQL doesn't take lost partitions into account when persistence is enabled > - > > Key: IGNITE-9841 > URL: https://issues.apache.org/jira/browse/IGNITE-9841 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Stanislav Lukyanov >Assignee: Stanislav Lukyanov >Priority: Major > Attachments: IgniteSqlQueryWithLostPartitionsTest.java > > > IGNITE-8927 changed SQL queries to honor lost partitions. However, it doesn't > work if persistence is enabled. E.g. if there are lost partitions then > `select * from T` fails for in-memory caches (good) and silently ignores the > lost partitions for persistent caches (bad). > See attached reproducer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9841) SQL doesn't take lost partitions into account when persistence is enabled
[ https://issues.apache.org/jira/browse/IGNITE-9841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668308#comment-16668308 ] Stanislav Lukyanov commented on IGNITE-9841: Pushed a bunch of TODOs after the TC Bot run, but no actual code changes, so not restarting Run All - checked the build locally. > SQL doesn't take lost partitions into account when persistence is enabled > - > > Key: IGNITE-9841 > URL: https://issues.apache.org/jira/browse/IGNITE-9841 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Stanislav Lukyanov >Assignee: Stanislav Lukyanov >Priority: Major > Attachments: IgniteSqlQueryWithLostPartitionsTest.java > > > IGNITE-8927 changed SQL queries to honor lost partitions. However, it doesn't > work if persistence is enabled. E.g. if there are lost partitions then > `select * from T` fails for in-memory caches (good) and silently ignores the > lost partitions for persistent caches (bad). > See attached reproducer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10028) Incorrect handling of page on replacement
[ https://issues.apache.org/jira/browse/IGNITE-10028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-10028: -- Ignite Flags: (was: Docs Required) > Incorrect handling of page on replacement > - > > Key: IGNITE-10028 > URL: https://issues.apache.org/jira/browse/IGNITE-10028 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Blocker > Fix For: 2.8 > > > We can to pass incorrect page version to IgniteCacheSnapshotManager. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10028) Incorrect handling of page on replacement
[ https://issues.apache.org/jira/browse/IGNITE-10028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-10028: -- Fix Version/s: 2.8 > Incorrect handling of page on replacement > - > > Key: IGNITE-10028 > URL: https://issues.apache.org/jira/browse/IGNITE-10028 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Blocker > Fix For: 2.8 > > > We can to pass incorrect page version to IgniteCacheSnapshotManager. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9939) [TC Bot] Add visa cahing and monitoring
[ https://issues.apache.org/jira/browse/IGNITE-9939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] PetrovMikhail updated IGNITE-9939: -- Description: Add visa cahing and monitoring. Handle situation within BuildObserver when build status is "UNKNOWN" Summary: [TC Bot] Add visa cahing and monitoring (was: [TC Bot] Handle situation within BuildObserver when build status is "UNKNOWN") > [TC Bot] Add visa cahing and monitoring > --- > > Key: IGNITE-9939 > URL: https://issues.apache.org/jira/browse/IGNITE-9939 > Project: Ignite > Issue Type: Task >Reporter: PetrovMikhail >Assignee: PetrovMikhail >Priority: Minor > > Add visa cahing and monitoring. Handle situation within BuildObserver when > build status is "UNKNOWN" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10028) Incorrect handling of page on replacement
[ https://issues.apache.org/jira/browse/IGNITE-10028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-10028: -- Description: We can pass an incorrect page version to IgniteCacheSnapshotManager. (was: We can to pass incorrect page version to IgniteCacheSnapshotManager.) > Incorrect handling of page on replacement > - > > Key: IGNITE-10028 > URL: https://issues.apache.org/jira/browse/IGNITE-10028 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Fix For: 2.8 > > > We can pass an incorrect page version to IgniteCacheSnapshotManager. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10028) Incorrect handling of page on replacement
[ https://issues.apache.org/jira/browse/IGNITE-10028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Goncharuk updated IGNITE-10028: -- Priority: Major (was: Blocker) > Incorrect handling of page on replacement > - > > Key: IGNITE-10028 > URL: https://issues.apache.org/jira/browse/IGNITE-10028 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Fix For: 2.8 > > > We can to pass incorrect page version to IgniteCacheSnapshotManager. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9841) SQL doesn't take lost partitions into account when persistence is enabled
[ https://issues.apache.org/jira/browse/IGNITE-9841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668312#comment-16668312 ] Stanislav Lukyanov commented on IGNITE-9841: The PR adds a bunch of test cases to the IgniteCachePartitionLossPolicySelfTest, including a persistence and ScanQuery test cases. Some of the test cases or individual checks fail due to various issues - added the links to the JIRAs. > SQL doesn't take lost partitions into account when persistence is enabled > - > > Key: IGNITE-9841 > URL: https://issues.apache.org/jira/browse/IGNITE-9841 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Stanislav Lukyanov >Assignee: Stanislav Lukyanov >Priority: Major > Attachments: IgniteSqlQueryWithLostPartitionsTest.java > > > IGNITE-8927 changed SQL queries to honor lost partitions. However, it doesn't > work if persistence is enabled. E.g. if there are lost partitions then > `select * from T` fails for in-memory caches (good) and silently ignores the > lost partitions for persistent caches (bad). > See attached reproducer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10059) Local scan query against LOST partition fails
Stanislav Lukyanov created IGNITE-10059:
---
Summary: Local scan query against LOST partition fails
Key: IGNITE-10059
URL: https://issues.apache.org/jira/browse/IGNITE-10059
Project: Ignite
Issue Type: Bug
Reporter: Stanislav Lukyanov
Local scan queries executed against a LOST partition always fail.
Stack trace:
{code}
javax.cache.CacheException: No queryable nodes for partition 0 [forced local
query=GridCacheQueryAdapter [type=SCAN, clsName=null, clause=null, filter=null,
transform=null, part=0, incMeta=false, metrics=GridCacheQueryMetricsAdapter
[minTime=9223372036854775807, maxTime=0, sumTime=0, avgTime=0.0, execs=0,
completed=0, fails=0], pageSize=1024, timeout=0, incBackups=false,
forceLocal=true, dedup=false,
prj=org.apache.ignite.internal.cluster.ClusterGroupAdapter@3a806080,
keepBinary=false, subjId=null, taskHash=0, mvccSnapshot=null]]
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:697)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:376)
at
org.apache.ignite.internal.processors.cache.distributed.IgniteCachePartitionLossPolicySelfTest.checkQueryPasses(IgniteCachePartitionLossPolicySelfTest.java:767)
at
org.apache.ignite.internal.processors.cache.distributed.IgniteCachePartitionLossPolicySelfTest.validateQuery0(IgniteCachePartitionLossPolicySelfTest.java:720)
at
org.apache.ignite.internal.processors.cache.distributed.IgniteCachePartitionLossPolicySelfTest.validateQuery(IgniteCachePartitionLossPolicySelfTest.java:691)
at
org.apache.ignite.internal.processors.cache.distributed.IgniteCachePartitionLossPolicySelfTest.checkLostPartition(IgniteCachePartitionLossPolicySelfTest.java:497)
at
org.apache.ignite.internal.processors.cache.distributed.IgniteCachePartitionLossPolicySelfTest.testReadOnlyAll(IgniteCachePartitionLossPolicySelfTest.java:185)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at junit.framework.TestCase.runTest(TestCase.java:176)
at
org.apache.ignite.testframework.junits.GridAbstractTest.runTestInternal(GridAbstractTest.java:2209)
at
org.apache.ignite.testframework.junits.GridAbstractTest.access$000(GridAbstractTest.java:144)
at
org.apache.ignite.testframework.junits.GridAbstractTest$5.run(GridAbstractTest.java:2124)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.IgniteCheckedException: No queryable nodes
for partition 0 [forced local query=GridCacheQueryAdapter [type=SCAN,
clsName=null, clause=null, filter=null, transform=null, part=0, incMeta=false,
metrics=GridCacheQueryMetricsAdapter [minTime=9223372036854775807, maxTime=0,
sumTime=0, avgTime=0.0, execs=0, completed=0, fails=0], pageSize=1024,
timeout=0, incBackups=false, forceLocal=true, dedup=false,
prj=org.apache.ignite.internal.cluster.ClusterGroupAdapter@3a806080,
keepBinary=false, subjId=null, taskHash=0, mvccSnapshot=null]]
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryAdapter.executeScanQuery(GridCacheQueryAdapter.java:541)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl$1.applyx(IgniteCacheProxyImpl.java:410)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl$1.applyx(IgniteCacheProxyImpl.java:408)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2713)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:407)
at
org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:689)
... 15 more
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9841) SQL doesn't take lost partitions into account when persistence is enabled
[ https://issues.apache.org/jira/browse/IGNITE-9841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-9841: --- Ignite Flags: (was: Docs Required) > SQL doesn't take lost partitions into account when persistence is enabled > - > > Key: IGNITE-9841 > URL: https://issues.apache.org/jira/browse/IGNITE-9841 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Stanislav Lukyanov >Assignee: Stanislav Lukyanov >Priority: Major > Fix For: 2.8 > > Attachments: IgniteSqlQueryWithLostPartitionsTest.java > > > IGNITE-8927 changed SQL queries to honor lost partitions. However, it doesn't > work if persistence is enabled. E.g. if there are lost partitions then > `select * from T` fails for in-memory caches (good) and silently ignores the > lost partitions for persistent caches (bad). > See attached reproducer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9939) [TC Bot] Add visa's cahing and monitoring
[ https://issues.apache.org/jira/browse/IGNITE-9939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] PetrovMikhail updated IGNITE-9939: -- Summary: [TC Bot] Add visa's cahing and monitoring (was: [TC Bot] Add visa cahing and monitoring) > [TC Bot] Add visa's cahing and monitoring > - > > Key: IGNITE-9939 > URL: https://issues.apache.org/jira/browse/IGNITE-9939 > Project: Ignite > Issue Type: Task >Reporter: PetrovMikhail >Assignee: PetrovMikhail >Priority: Minor > > Add visa cahing and monitoring. Handle situation within BuildObserver when > build status is "UNKNOWN" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9841) SQL doesn't take lost partitions into account when persistence is enabled
[ https://issues.apache.org/jira/browse/IGNITE-9841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-9841: --- Fix Version/s: 2.8 > SQL doesn't take lost partitions into account when persistence is enabled > - > > Key: IGNITE-9841 > URL: https://issues.apache.org/jira/browse/IGNITE-9841 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Stanislav Lukyanov >Assignee: Stanislav Lukyanov >Priority: Major > Fix For: 2.8 > > Attachments: IgniteSqlQueryWithLostPartitionsTest.java > > > IGNITE-8927 changed SQL queries to honor lost partitions. However, it doesn't > work if persistence is enabled. E.g. if there are lost partitions then > `select * from T` fails for in-memory caches (good) and silently ignores the > lost partitions for persistent caches (bad). > See attached reproducer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9841) SQL doesn't take lost partitions into account when persistence is enabled
[ https://issues.apache.org/jira/browse/IGNITE-9841?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668318#comment-16668318 ] Stanislav Lukyanov commented on IGNITE-9841: [~vozerov], please review. > SQL doesn't take lost partitions into account when persistence is enabled > - > > Key: IGNITE-9841 > URL: https://issues.apache.org/jira/browse/IGNITE-9841 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Stanislav Lukyanov >Assignee: Stanislav Lukyanov >Priority: Major > Fix For: 2.8 > > Attachments: IgniteSqlQueryWithLostPartitionsTest.java > > > IGNITE-8927 changed SQL queries to honor lost partitions. However, it doesn't > work if persistence is enabled. E.g. if there are lost partitions then > `select * from T` fails for in-memory caches (good) and silently ignores the > lost partitions for persistent caches (bad). > See attached reproducer. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8639) Query with a lot of nesting causes NPE in org.h2.util.StringUtils.indent
[
https://issues.apache.org/jira/browse/IGNITE-8639?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668320#comment-16668320
]
Ignite TC Bot commented on IGNITE-8639:
---
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}SPI{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2191483]]
* IgniteSpiTestSuite: TcpDiscoverySslSelfTest.testFailedNodes3 - 0,0% fails in
last 100 master runs.
{color:#d04437}Cache 5{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2191523]]
* IgniteCacheWithIndexingTestSuite:
CacheTtlAtomicPartitionedSelfTest.testTimeToLiveTtl - 0,0% fails in last 100
master runs.
{color:#d04437}Binary Objects (Simple Mapper Basic){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2191449]]
* IgniteBinarySimpleNameMapperBasicTestSuite:
MarshallerContextLockingSelfTest.testMultithreadedUpdate - 0,0% fails in last
100 master runs.
{color:#d04437}Cache 8{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=2191526]]
* IgniteCacheTestSuite8:
GridCacheAtomicPartitionedTckMetricsSelfTestImpl.testGetMetricsDisable - 0,0%
fails in last 100 master runs.
{color:#d04437}PDS (Direct IO) 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2191535]]
* IgnitePdsNativeIoTestSuite:
IgnitePdsDestroyCacheWithoutCheckpointsTest.testDestroyCachesAbruptlyWithoutCheckpoints
- 0,0% fails in last 100 master runs.
{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2191556&buildTypeId=IgniteTests24Java8_RunAll]
> Query with a lot of nesting causes NPE in org.h2.util.StringUtils.indent
>
>
> Key: IGNITE-8639
> URL: https://issues.apache.org/jira/browse/IGNITE-8639
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.6
>Reporter: Ilya Kasnacheev
>Assignee: Taras Ledkov
>Priority: Minor
> Labels: test
> Fix For: 2.8
>
> Attachments: SqlNestedQuerySelfTest.java
>
>
> Worked in 1.7!
> But now:
> {code}
> sql("WITH cacheJoin (txId, stage, tStamp)" +
> " AS (SELECT t.txId, o.stage, o.tStamp FROM txs t INNER JOIN
> ops o ON t.txId = o.txId)" +
> " SELECT ou.stage, COUNT(*) as cou, SUM(CASE WHEN ou.stage =
> in.stage THEN 1 ELSE 0 END) AS ttl" +
> " FROM (SELECT txId, stage FROM cacheJoin cte GROUP BY txId,
> stage) ou" +
> " INNER JOIN (SELECT mx.txId, mx.stage FROM (SELECT txId,
> tStamp, stage FROM cacheJoin cte) mx" +
> " INNER JOIN (SELECT txId, MAX(tStamp) AS maxTStamp FROM
> cacheJoin cte GROUP BY txId) mix" +
> " ON mx.txId = mix.txId AND mx.tStamp = mix.maxTStamp) in
> ON ou.txId = in.txId" +
> " GROUP BY ou.stage");
> {code}
> {code}
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed
> to parse query. Внутренняя ошибка: "java.lang.NullPointerException"
> General error: "java.lang.NullPointerException" [5-195]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.prepareStatementAndCaches(IgniteH2Indexing.java:2026)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.parseAndSplit(IgniteH2Indexing.java:1796)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1652)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2035)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2030)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2578)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2044)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:1990)
> at
> org.apache.ignite.internal.processors.query.SqlNestedQuerySelfTest.sql(SqlNestedQuerySelfTest.java:73)
> at
> org.apache.ignite.internal.processors.query.SqlNestedQuerySelfTest.testNestingQuery(SqlNestedQuerySelfTest.java:54)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at junit.framework.TestCase.runTest(TestCase.java:17
[jira] [Updated] (IGNITE-10056) Attempt to create MVCC cache with TTL causes full cluster halt
[
https://issues.apache.org/jira/browse/IGNITE-10056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-10056:
-
Fix Version/s: (was: 2.7)
2.8
> Attempt to create MVCC cache with TTL causes full cluster halt
> --
>
> Key: IGNITE-10056
> URL: https://issues.apache.org/jira/browse/IGNITE-10056
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Affects Versions: 2.7
> Environment:
>Reporter: Sergey Kozlov
>Priority: Critical
> Fix For: 2.8
>
>
> 1. Start cluster with cache template and activate:
> {code:xml}
>
>
> value="TRANSACTIONAL_SNAPSHOT"/>
>
>
>
>
>
>factory-method="factoryOf">
>
>
>
>
>
>
>
>
>
> {code}
> 2. Try to create cache via {{sqlline}}
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> create table t1(a int, b varchar, primary
> key(a)) with "template=tmpl";
> Error: class org.apache.ignite.IgniteCheckedException: Grid configuration
> parameter invalid: expiry policy cannot be used with TRANSACTIONAL_SNAPSHOT
> atomicity mode (state=5,code=1)
> java.sql.SQLException: class org.apache.ignite.IgniteCheckedException: Grid
> configuration parameter invalid: expiry policy cannot be used with
> TRANSACTIONAL_SNAPSHOT atomicity mode
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> {noformat}
> That's fine but all nodes stopped by failure handler:
> {noformat}
> [21:40:03,657][SEVERE][exchange-worker-#43][CacheAffinitySharedManager]
> Failed to initialize cache. Will try to rollback cache start routine.
> [cacheName=SQL_PUBLIC_T1]
> class org.apache.ignite.IgniteCheckedException: Grid configuration parameter
> invalid: expiry policy cannot be used with TRANSACTIONAL_SNAPSHOT atomicity
> mode
> at
> org.apache.ignite.internal.processors.GridProcessorAdapter.assertParameter(GridProcessorAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.validate(GridCacheProcessor.java:521)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCache(GridCacheProcessor.java:1560)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:2146)
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processCacheStartRequests(CacheAffinitySharedManager.java:898)
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:798)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:1231)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:738)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2667)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2539)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> [21:40:03,660][INFO][exchange-worker-#43][GridCacheProcessor] Can not finish
> proxy initialization because proxy does not exist, cacheName=SQL_PUBLIC_T1,
> localNodeId=0c6a653d-b151-46b5-bd0c-7fea4b94ca26
> [21:40:03,662][INFO][exchange-worker-#43][CacheAffinitySharedManager] Caches
> starting performed in 66 ms.
> [21:40:03,667][INFO][exchange-worker-#43][CacheAffinitySharedManager]
> Affinity initialization for started caches performed in 5 ms.
> [21:40:03,673][INFO][exchange-worker-#43][GridDhtPartitionsExchangeFuture]
> F
[jira] [Updated] (IGNITE-10056) Attempt to create MVCC cache with TTL causes full cluster halt
[
https://issues.apache.org/jira/browse/IGNITE-10056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-10056:
-
Fix Version/s: (was: 2.8)
> Attempt to create MVCC cache with TTL causes full cluster halt
> --
>
> Key: IGNITE-10056
> URL: https://issues.apache.org/jira/browse/IGNITE-10056
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Affects Versions: 2.7
> Environment:
>Reporter: Sergey Kozlov
>Priority: Critical
>
> 1. Start cluster with cache template and activate:
> {code:xml}
>
>
> value="TRANSACTIONAL_SNAPSHOT"/>
>
>
>
>
>
>factory-method="factoryOf">
>
>
>
>
>
>
>
>
>
> {code}
> 2. Try to create cache via {{sqlline}}
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> create table t1(a int, b varchar, primary
> key(a)) with "template=tmpl";
> Error: class org.apache.ignite.IgniteCheckedException: Grid configuration
> parameter invalid: expiry policy cannot be used with TRANSACTIONAL_SNAPSHOT
> atomicity mode (state=5,code=1)
> java.sql.SQLException: class org.apache.ignite.IgniteCheckedException: Grid
> configuration parameter invalid: expiry policy cannot be used with
> TRANSACTIONAL_SNAPSHOT atomicity mode
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> {noformat}
> That's fine but all nodes stopped by failure handler:
> {noformat}
> [21:40:03,657][SEVERE][exchange-worker-#43][CacheAffinitySharedManager]
> Failed to initialize cache. Will try to rollback cache start routine.
> [cacheName=SQL_PUBLIC_T1]
> class org.apache.ignite.IgniteCheckedException: Grid configuration parameter
> invalid: expiry policy cannot be used with TRANSACTIONAL_SNAPSHOT atomicity
> mode
> at
> org.apache.ignite.internal.processors.GridProcessorAdapter.assertParameter(GridProcessorAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.validate(GridCacheProcessor.java:521)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCache(GridCacheProcessor.java:1560)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:2146)
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processCacheStartRequests(CacheAffinitySharedManager.java:898)
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:798)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:1231)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:738)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2667)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2539)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> [21:40:03,660][INFO][exchange-worker-#43][GridCacheProcessor] Can not finish
> proxy initialization because proxy does not exist, cacheName=SQL_PUBLIC_T1,
> localNodeId=0c6a653d-b151-46b5-bd0c-7fea4b94ca26
> [21:40:03,662][INFO][exchange-worker-#43][CacheAffinitySharedManager] Caches
> starting performed in 66 ms.
> [21:40:03,667][INFO][exchange-worker-#43][CacheAffinitySharedManager]
> Affinity initialization for started caches performed in 5 ms.
> [21:40:03,673][INFO][exchange-worker-#43][GridDhtPartitionsExchangeFuture]
> Finished waiting for partition release future [topVer
[jira] [Closed] (IGNITE-10056) Attempt to create MVCC cache with TTL causes full cluster halt
[
https://issues.apache.org/jira/browse/IGNITE-10056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-10056.
> Attempt to create MVCC cache with TTL causes full cluster halt
> --
>
> Key: IGNITE-10056
> URL: https://issues.apache.org/jira/browse/IGNITE-10056
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Affects Versions: 2.7
> Environment:
>Reporter: Sergey Kozlov
>Priority: Critical
>
> 1. Start cluster with cache template and activate:
> {code:xml}
>
>
> value="TRANSACTIONAL_SNAPSHOT"/>
>
>
>
>
>
>factory-method="factoryOf">
>
>
>
>
>
>
>
>
>
> {code}
> 2. Try to create cache via {{sqlline}}
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> create table t1(a int, b varchar, primary
> key(a)) with "template=tmpl";
> Error: class org.apache.ignite.IgniteCheckedException: Grid configuration
> parameter invalid: expiry policy cannot be used with TRANSACTIONAL_SNAPSHOT
> atomicity mode (state=5,code=1)
> java.sql.SQLException: class org.apache.ignite.IgniteCheckedException: Grid
> configuration parameter invalid: expiry policy cannot be used with
> TRANSACTIONAL_SNAPSHOT atomicity mode
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> {noformat}
> That's fine but all nodes stopped by failure handler:
> {noformat}
> [21:40:03,657][SEVERE][exchange-worker-#43][CacheAffinitySharedManager]
> Failed to initialize cache. Will try to rollback cache start routine.
> [cacheName=SQL_PUBLIC_T1]
> class org.apache.ignite.IgniteCheckedException: Grid configuration parameter
> invalid: expiry policy cannot be used with TRANSACTIONAL_SNAPSHOT atomicity
> mode
> at
> org.apache.ignite.internal.processors.GridProcessorAdapter.assertParameter(GridProcessorAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.validate(GridCacheProcessor.java:521)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCache(GridCacheProcessor.java:1560)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:2146)
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processCacheStartRequests(CacheAffinitySharedManager.java:898)
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:798)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:1231)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:738)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2667)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2539)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> [21:40:03,660][INFO][exchange-worker-#43][GridCacheProcessor] Can not finish
> proxy initialization because proxy does not exist, cacheName=SQL_PUBLIC_T1,
> localNodeId=0c6a653d-b151-46b5-bd0c-7fea4b94ca26
> [21:40:03,662][INFO][exchange-worker-#43][CacheAffinitySharedManager] Caches
> starting performed in 66 ms.
> [21:40:03,667][INFO][exchange-worker-#43][CacheAffinitySharedManager]
> Affinity initialization for started caches performed in 5 ms.
> [21:40:03,673][INFO][exchange-worker-#43][GridDhtPartitionsExchangeFuture]
> Finished waiting for partition release future [topVer=AffinityTopologyVersion
> [topVer=
[jira] [Resolved] (IGNITE-10056) Attempt to create MVCC cache with TTL causes full cluster halt
[
https://issues.apache.org/jira/browse/IGNITE-10056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-10056.
--
Resolution: Duplicate
> Attempt to create MVCC cache with TTL causes full cluster halt
> --
>
> Key: IGNITE-10056
> URL: https://issues.apache.org/jira/browse/IGNITE-10056
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Affects Versions: 2.7
> Environment:
>Reporter: Sergey Kozlov
>Priority: Critical
>
> 1. Start cluster with cache template and activate:
> {code:xml}
>
>
> value="TRANSACTIONAL_SNAPSHOT"/>
>
>
>
>
>
>factory-method="factoryOf">
>
>
>
>
>
>
>
>
>
> {code}
> 2. Try to create cache via {{sqlline}}
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> create table t1(a int, b varchar, primary
> key(a)) with "template=tmpl";
> Error: class org.apache.ignite.IgniteCheckedException: Grid configuration
> parameter invalid: expiry policy cannot be used with TRANSACTIONAL_SNAPSHOT
> atomicity mode (state=5,code=1)
> java.sql.SQLException: class org.apache.ignite.IgniteCheckedException: Grid
> configuration parameter invalid: expiry policy cannot be used with
> TRANSACTIONAL_SNAPSHOT atomicity mode
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> {noformat}
> That's fine but all nodes stopped by failure handler:
> {noformat}
> [21:40:03,657][SEVERE][exchange-worker-#43][CacheAffinitySharedManager]
> Failed to initialize cache. Will try to rollback cache start routine.
> [cacheName=SQL_PUBLIC_T1]
> class org.apache.ignite.IgniteCheckedException: Grid configuration parameter
> invalid: expiry policy cannot be used with TRANSACTIONAL_SNAPSHOT atomicity
> mode
> at
> org.apache.ignite.internal.processors.GridProcessorAdapter.assertParameter(GridProcessorAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.validate(GridCacheProcessor.java:521)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCache(GridCacheProcessor.java:1560)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:2146)
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processCacheStartRequests(CacheAffinitySharedManager.java:898)
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:798)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:1231)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:738)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2667)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2539)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> [21:40:03,660][INFO][exchange-worker-#43][GridCacheProcessor] Can not finish
> proxy initialization because proxy does not exist, cacheName=SQL_PUBLIC_T1,
> localNodeId=0c6a653d-b151-46b5-bd0c-7fea4b94ca26
> [21:40:03,662][INFO][exchange-worker-#43][CacheAffinitySharedManager] Caches
> starting performed in 66 ms.
> [21:40:03,667][INFO][exchange-worker-#43][CacheAffinitySharedManager]
> Affinity initialization for started caches performed in 5 ms.
> [21:40:03,673][INFO][exchange-worker-#43][GridDhtPartitionsExchangeFuture]
> Finished waiting for partition release future [topVer=Affin
[jira] [Commented] (IGNITE-10056) Attempt to create MVCC cache with TTL causes full cluster halt
[
https://issues.apache.org/jira/browse/IGNITE-10056?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668326#comment-16668326
]
Vladimir Ozerov commented on IGNITE-10056:
--
[~skozlov], duplicate to IGNITE-8640
> Attempt to create MVCC cache with TTL causes full cluster halt
> --
>
> Key: IGNITE-10056
> URL: https://issues.apache.org/jira/browse/IGNITE-10056
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Affects Versions: 2.7
> Environment:
>Reporter: Sergey Kozlov
>Priority: Critical
>
> 1. Start cluster with cache template and activate:
> {code:xml}
>
>
> value="TRANSACTIONAL_SNAPSHOT"/>
>
>
>
>
>
>factory-method="factoryOf">
>
>
>
>
>
>
>
>
>
> {code}
> 2. Try to create cache via {{sqlline}}
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> create table t1(a int, b varchar, primary
> key(a)) with "template=tmpl";
> Error: class org.apache.ignite.IgniteCheckedException: Grid configuration
> parameter invalid: expiry policy cannot be used with TRANSACTIONAL_SNAPSHOT
> atomicity mode (state=5,code=1)
> java.sql.SQLException: class org.apache.ignite.IgniteCheckedException: Grid
> configuration parameter invalid: expiry policy cannot be used with
> TRANSACTIONAL_SNAPSHOT atomicity mode
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> {noformat}
> That's fine but all nodes stopped by failure handler:
> {noformat}
> [21:40:03,657][SEVERE][exchange-worker-#43][CacheAffinitySharedManager]
> Failed to initialize cache. Will try to rollback cache start routine.
> [cacheName=SQL_PUBLIC_T1]
> class org.apache.ignite.IgniteCheckedException: Grid configuration parameter
> invalid: expiry policy cannot be used with TRANSACTIONAL_SNAPSHOT atomicity
> mode
> at
> org.apache.ignite.internal.processors.GridProcessorAdapter.assertParameter(GridProcessorAdapter.java:140)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.validate(GridCacheProcessor.java:521)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.createCache(GridCacheProcessor.java:1560)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:2146)
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processCacheStartRequests(CacheAffinitySharedManager.java:898)
> at
> org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:798)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:1231)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:738)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:2667)
> at
> org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:2539)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> [21:40:03,660][INFO][exchange-worker-#43][GridCacheProcessor] Can not finish
> proxy initialization because proxy does not exist, cacheName=SQL_PUBLIC_T1,
> localNodeId=0c6a653d-b151-46b5-bd0c-7fea4b94ca26
> [21:40:03,662][INFO][exchange-worker-#43][CacheAffinitySharedManager] Caches
> starting performed in 66 ms.
> [21:40:03,667][INFO][exchange-worker-#43][CacheAffinitySharedManager]
> Affinity initialization for started caches performed in 5 ms.
> [21:40:03,673][INFO][exchange-worker-#43][GridDhtPartitionsExchangeFut
[jira] [Resolved] (IGNITE-9708) Node didn't detect corrupt of file index.bin in FS
[ https://issues.apache.org/jira/browse/IGNITE-9708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy resolved IGNITE-9708. -- Resolution: Duplicate > Node didn't detect corrupt of file index.bin in FS > -- > > Key: IGNITE-9708 > URL: https://issues.apache.org/jira/browse/IGNITE-9708 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.5 >Reporter: ARomantsov >Assignee: Ivan Daschinskiy >Priority: Critical > Fix For: 2.8 > > > I run two tests > In first, i break part.bin file and node correctly find that > In second, i break index.bin file and all command (select, idle_verify, etc) > not detected problem with it. > All corrupts run on correct stop node, and checks after node start > command - printf "\\x31\\xc0\\xc3" | dd > of=/storage/ssd../cacheGroup/index.bin bs=1 seek=16150 count=3 conv=notrunc -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-9471) Failed to validate indexes by control.sh utility.
[
https://issues.apache.org/jira/browse/IGNITE-9471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy closed IGNITE-9471.
> Failed to validate indexes by control.sh utility.
> -
>
> Key: IGNITE-9471
> URL: https://issues.apache.org/jira/browse/IGNITE-9471
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitriy Gladkikh
>Assignee: Ivan Daschinskiy
>Priority: Major
>
> During the validation of the indexes, an error occurs:
> {noformat}
> 2018-08-31 17:18:40.356 [WARN
> ][pool-19-thread-1][o.a.i.i.v.v.ValidateIndexesClosure] Current progress of
> ValidateIndexesClosure: processed 0 of 0 partitions, 0 of 0 SQL indexes
> 2018-08-31 17:18:40.625
> [ERROR][pool-19-thread-1][o.a.i.i.v.v.ValidateIndexesClosure] Failed to
> invoke typeByValue
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.typeByValue(GridQueryProcessor.java:1901)
> at sun.reflect.GeneratedMethodAccessor77.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.ignite.internal.visor.verify.ValidateIndexesClosure.processPartition(ValidateIndexesClosure.java:375)
> at
> org.apache.ignite.internal.visor.verify.ValidateIndexesClosure.access$000(ValidateIndexesClosure.java:77)
> at
> org.apache.ignite.internal.visor.verify.ValidateIndexesClosure$1.call(ValidateIndexesClosure.java:282)
> at
> org.apache.ignite.internal.visor.verify.ValidateIndexesClosure$1.call(ValidateIndexesClosure.java:280)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 2018-08-31 17:18:40.638
> [ERROR][mgmt-#717%DPL_GRID%DplGridNodeName%][o.a.i.i.processors.job.GridJobWorker]
> Failed to execute job
> [jobId=1ebe4309561-6878f409-b4fd-4f51-9f74-5f5c2241059a,
> ses=GridJobSessionImpl [ses=GridTaskSessionImpl
> [taskName=o.a.i.i.v.verify.VisorValidateIndexesTask, dep=GridDeployment
> [ts=1535721804597, depMode=SHARED,
> clsLdr=union-module-impl:com.sbt.core.envelope.container.loader.ImplClassLoader@1b1d1738,
> clsLdrId=b3ac6209561-64663e4a-48d0-468f-999f-ade455ad6a4a, userVer=0,
> loc=true, sampleClsName=o.a.i.i.v.misc.VisorResolveHostNameTask,
> pendingUndeploy=false, undeployed=false, usage=1],
> taskClsName=o.a.i.i.v.verify.VisorValidateIndexesTask,
> sesId=edbe4309561-6878f409-b4fd-4f51-9f74-5f5c2241059a,
> startTime=1535725120340, endTime=9223372036854775807,
> taskNodeId=6878f409-b4fd-4f51-9f74-5f5c2241059a,
> clsLdr=union-module-impl:com.sbt.core.envelope.container.loader.ImplClassLoader@1b1d1738,
> closed=false, cpSpi=null, failSpi=null, loadSpi=null, usage=1,
> fullSup=false, internal=true, topPred=null,
> subjId=6878f409-b4fd-4f51-9f74-5f5c2241059a, mapFut=IgniteFuture
> [orig=GridFutureAdapter [ignoreInterrupts=false, state=INIT, res=null,
> hash=2010820403]], execName=null],
> jobId=1ebe4309561-6878f409-b4fd-4f51-9f74-5f5c2241059a]]
> org.apache.ignite.IgniteException: null
> at
> org.apache.ignite.internal.visor.verify.VisorValidateIndexesTask$VisorValidateIndexesJob.run(VisorValidateIndexesTask.java:86)
> at
> org.apache.ignite.internal.visor.verify.VisorValidateIndexesTask$VisorValidateIndexesJob.run(VisorValidateIndexesTask.java:64)
> at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:568)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6695)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:562)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:491)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1123)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1921)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at
> org.apache.ignite.internal.managers.communication.
[jira] [Resolved] (IGNITE-9471) Failed to validate indexes by control.sh utility.
[
https://issues.apache.org/jira/browse/IGNITE-9471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy resolved IGNITE-9471.
--
Resolution: Duplicate
> Failed to validate indexes by control.sh utility.
> -
>
> Key: IGNITE-9471
> URL: https://issues.apache.org/jira/browse/IGNITE-9471
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Dmitriy Gladkikh
>Assignee: Ivan Daschinskiy
>Priority: Major
>
> During the validation of the indexes, an error occurs:
> {noformat}
> 2018-08-31 17:18:40.356 [WARN
> ][pool-19-thread-1][o.a.i.i.v.v.ValidateIndexesClosure] Current progress of
> ValidateIndexesClosure: processed 0 of 0 partitions, 0 of 0 SQL indexes
> 2018-08-31 17:18:40.625
> [ERROR][pool-19-thread-1][o.a.i.i.v.v.ValidateIndexesClosure] Failed to
> invoke typeByValue
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.typeByValue(GridQueryProcessor.java:1901)
> at sun.reflect.GeneratedMethodAccessor77.invoke(Unknown Source)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.apache.ignite.internal.visor.verify.ValidateIndexesClosure.processPartition(ValidateIndexesClosure.java:375)
> at
> org.apache.ignite.internal.visor.verify.ValidateIndexesClosure.access$000(ValidateIndexesClosure.java:77)
> at
> org.apache.ignite.internal.visor.verify.ValidateIndexesClosure$1.call(ValidateIndexesClosure.java:282)
> at
> org.apache.ignite.internal.visor.verify.ValidateIndexesClosure$1.call(ValidateIndexesClosure.java:280)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> 2018-08-31 17:18:40.638
> [ERROR][mgmt-#717%DPL_GRID%DplGridNodeName%][o.a.i.i.processors.job.GridJobWorker]
> Failed to execute job
> [jobId=1ebe4309561-6878f409-b4fd-4f51-9f74-5f5c2241059a,
> ses=GridJobSessionImpl [ses=GridTaskSessionImpl
> [taskName=o.a.i.i.v.verify.VisorValidateIndexesTask, dep=GridDeployment
> [ts=1535721804597, depMode=SHARED,
> clsLdr=union-module-impl:com.sbt.core.envelope.container.loader.ImplClassLoader@1b1d1738,
> clsLdrId=b3ac6209561-64663e4a-48d0-468f-999f-ade455ad6a4a, userVer=0,
> loc=true, sampleClsName=o.a.i.i.v.misc.VisorResolveHostNameTask,
> pendingUndeploy=false, undeployed=false, usage=1],
> taskClsName=o.a.i.i.v.verify.VisorValidateIndexesTask,
> sesId=edbe4309561-6878f409-b4fd-4f51-9f74-5f5c2241059a,
> startTime=1535725120340, endTime=9223372036854775807,
> taskNodeId=6878f409-b4fd-4f51-9f74-5f5c2241059a,
> clsLdr=union-module-impl:com.sbt.core.envelope.container.loader.ImplClassLoader@1b1d1738,
> closed=false, cpSpi=null, failSpi=null, loadSpi=null, usage=1,
> fullSup=false, internal=true, topPred=null,
> subjId=6878f409-b4fd-4f51-9f74-5f5c2241059a, mapFut=IgniteFuture
> [orig=GridFutureAdapter [ignoreInterrupts=false, state=INIT, res=null,
> hash=2010820403]], execName=null],
> jobId=1ebe4309561-6878f409-b4fd-4f51-9f74-5f5c2241059a]]
> org.apache.ignite.IgniteException: null
> at
> org.apache.ignite.internal.visor.verify.VisorValidateIndexesTask$VisorValidateIndexesJob.run(VisorValidateIndexesTask.java:86)
> at
> org.apache.ignite.internal.visor.verify.VisorValidateIndexesTask$VisorValidateIndexesJob.run(VisorValidateIndexesTask.java:64)
> at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:568)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:6695)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:562)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:491)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:110)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1123)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:1921)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1556)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1184)
> at
> org.apache.ignite.in
[jira] [Closed] (IGNITE-9708) Node didn't detect corrupt of file index.bin in FS
[ https://issues.apache.org/jira/browse/IGNITE-9708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy closed IGNITE-9708. > Node didn't detect corrupt of file index.bin in FS > -- > > Key: IGNITE-9708 > URL: https://issues.apache.org/jira/browse/IGNITE-9708 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.5 >Reporter: ARomantsov >Assignee: Ivan Daschinskiy >Priority: Critical > Fix For: 2.8 > > > I run two tests > In first, i break part.bin file and node correctly find that > In second, i break index.bin file and all command (select, idle_verify, etc) > not detected problem with it. > All corrupts run on correct stop node, and checks after node start > command - printf "\\x31\\xc0\\xc3" | dd > of=/storage/ssd../cacheGroup/index.bin bs=1 seek=16150 count=3 conv=notrunc -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10055) MVCC: incorrect fields count in PartitionUpdateCountersMessage
[
https://issues.apache.org/jira/browse/IGNITE-10055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668337#comment-16668337
]
Ignite TC Bot commented on IGNITE-10055:
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Basic 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2194902]]
* IgniteBasicTestSuite:
GridServiceProcessorBatchDeploySelfTest.testDeployAllTopologyChange - 0,0%
fails in last 100 master runs.
{color:#d04437}Binary Objects (Simple Mapper Basic){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2194855]]
* IgniteBinarySimpleNameMapperBasicTestSuite:
DataRegionMetricsSelfTest.testAllocationRateSingleThreaded - 0,0% fails in last
100 master runs.
{color:#d04437}SPI (URI Deploy){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2194890]]
* IgniteUriDeploymentTestSuite:
GridUriDeploymentMd5CheckSelfTest.testMd5DirectoryCheck - 0,0% fails in last
100 master runs.
{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2194962&buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: incorrect fields count in PartitionUpdateCountersMessage
> --
>
> Key: IGNITE-10055
> URL: https://issues.apache.org/jira/browse/IGNITE-10055
> Project: Ignite
> Issue Type: Task
> Components: mvcc
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.7
>
>
> Should be 2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10055) MVCC: incorrect fields count in PartitionUpdateCountersMessage
[
https://issues.apache.org/jira/browse/IGNITE-10055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668336#comment-16668336
]
Ignite TC Bot commented on IGNITE-10055:
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Basic 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2194902]]
* IgniteBasicTestSuite:
GridServiceProcessorBatchDeploySelfTest.testDeployAllTopologyChange - 0,0%
fails in last 100 master runs.
{color:#d04437}Binary Objects (Simple Mapper Basic){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2194855]]
* IgniteBinarySimpleNameMapperBasicTestSuite:
DataRegionMetricsSelfTest.testAllocationRateSingleThreaded - 0,0% fails in last
100 master runs.
{color:#d04437}SPI (URI Deploy){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2194890]]
* IgniteUriDeploymentTestSuite:
GridUriDeploymentMd5CheckSelfTest.testMd5DirectoryCheck - 0,0% fails in last
100 master runs.
{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2194962&buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: incorrect fields count in PartitionUpdateCountersMessage
> --
>
> Key: IGNITE-10055
> URL: https://issues.apache.org/jira/browse/IGNITE-10055
> Project: Ignite
> Issue Type: Task
> Components: mvcc
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.7
>
>
> Should be 2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-9985) MVCC TX: fix backup mappings
[ https://issues.apache.org/jira/browse/IGNITE-9985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov resolved IGNITE-9985. -- Resolution: Invalid All works will be done in scope of IGNITE-9928 > MVCC TX: fix backup mappings > > > Key: IGNITE-9985 > URL: https://issues.apache.org/jira/browse/IGNITE-9985 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Igor Seliverstov >Assignee: Igor Seliverstov >Priority: Major > Fix For: 2.7 > > > Fix mappings to update going to be evicted partitions as well to maintain > consistency during rebalance -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-10055) MVCC: incorrect fields count in PartitionUpdateCountersMessage
[
https://issues.apache.org/jira/browse/IGNITE-10055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-10055:
-
Comment: was deleted
(was: {panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Basic 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2194902]]
* IgniteBasicTestSuite:
GridServiceProcessorBatchDeploySelfTest.testDeployAllTopologyChange - 0,0%
fails in last 100 master runs.
{color:#d04437}Binary Objects (Simple Mapper Basic){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2194855]]
* IgniteBinarySimpleNameMapperBasicTestSuite:
DataRegionMetricsSelfTest.testAllocationRateSingleThreaded - 0,0% fails in last
100 master runs.
{color:#d04437}SPI (URI Deploy){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2194890]]
* IgniteUriDeploymentTestSuite:
GridUriDeploymentMd5CheckSelfTest.testMd5DirectoryCheck - 0,0% fails in last
100 master runs.
{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2194962&buildTypeId=IgniteTests24Java8_RunAll])
> MVCC: incorrect fields count in PartitionUpdateCountersMessage
> --
>
> Key: IGNITE-10055
> URL: https://issues.apache.org/jira/browse/IGNITE-10055
> Project: Ignite
> Issue Type: Task
> Components: mvcc
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Fix For: 2.7
>
>
> Should be 2.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10015) Sporadic JVM crash due to restart nodes
[
https://issues.apache.org/jira/browse/IGNITE-10015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Kozlov reassigned IGNITE-10015:
--
Assignee: Sergey Kozlov (was: Alexey Goncharuk)
> Sporadic JVM crash due to restart nodes
>
>
> Key: IGNITE-10015
> URL: https://issues.apache.org/jira/browse/IGNITE-10015
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Assignee: Sergey Kozlov
>Priority: Critical
> Fix For: 2.7
>
> Attachments: hs_err_pid9126.log
>
>
> 1. Start 4 node cluster with pre-configured TTL caches.
> 2. Some 4 node may crash:
> {noformat}
> [22:43:01,485][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_002,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_013,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_001,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_012,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_004,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_015,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_003,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,006][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_014,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,007][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=ignite-sys-cache,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,007][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_011,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,007][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_010,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_009,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_006,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_005,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_016,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_008,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_007,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,012][INFO][db-checkpoint-thread-#68][GridCacheDatabaseSharedManager]
> Checkpoint started [checkpointId=214d43f2-6096-4b42-ab0f-52b7f98078f4,
> startPtr=FileWALPointer [idx=0, fileOff=513096, len=16483],
> checkpointLockWait=0ms, checkpointLockHoldTime=23ms,
> walCpRecordFsyncDuration=880ms, pages=238, reason='timeout']
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGBUS (0x7) at pc=0x7f0aa29d8522, pid=12344, tid=0x7f08b15f5700
> #
> # JRE version: Java(TM) SE Runtime Environment (8.0_161-b12) (build
> 1.8.0_161-b12)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.161-b12 mixed mode
> linux-amd64 compressed oops)
> # Problematic frame:
> # C [libzip.so+0x12522] newEntry+0x62
> #
> # Core dump written. Default location:
> /var/lib/teamcity/data/work/dd4d79acf76cc870/i2test/suites/core or core.12344
> #
> # An error report file with more information is saved as:
> #
> /var/lib/teamcity/data/work/dd4d79acf76cc870/i2test/suites/hs_err_pid12344.log
> Compiled method (nm)7845 558 n 0
> java.util.zip.ZipFile::getEntry (native)
> total in heap [0x7f0a8d3d1850,0x7f0a8d3d1bc0] = 880
> relocation [0x7f0a8d3d1978,0x7f0a8d3d19c0] = 72
> main code [0x7f0a8d3d19c0,0x7f0a8d3d1bc0] = 512
> [thread 139675315439360 also had an error]
> #
> # If you would like to submit a bug report, please visit:
> # http://bugreport.java.com/bugreport/cr
[jira] [Created] (IGNITE-10060) Optimize IncSnapshotNearbyFullSnapshotTest#test use seconds instead of minutes
Alexand Polyakov created IGNITE-10060: - Summary: Optimize IncSnapshotNearbyFullSnapshotTest#test use seconds instead of minutes Key: IGNITE-10060 URL: https://issues.apache.org/jira/browse/IGNITE-10060 Project: Ignite Issue Type: Test Reporter: Alexand Polyakov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10015) Sporadic JVM crash due to restart nodes
[
https://issues.apache.org/jira/browse/IGNITE-10015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668357#comment-16668357
]
Sergey Kozlov commented on IGNITE-10015:
Looks like the classpath is corrupted, I'll provide more details
> Sporadic JVM crash due to restart nodes
>
>
> Key: IGNITE-10015
> URL: https://issues.apache.org/jira/browse/IGNITE-10015
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Assignee: Sergey Kozlov
>Priority: Critical
> Fix For: 2.7
>
> Attachments: hs_err_pid9126.log
>
>
> 1. Start 4 node cluster with pre-configured TTL caches.
> 2. Some 4 node may crash:
> {noformat}
> [22:43:01,485][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_002,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_013,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_001,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_012,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_004,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_015,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,005][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_003,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,006][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_014,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,007][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=ignite-sys-cache,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,007][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_011,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,007][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_010,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_009,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_006,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_005,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_016,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_008,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,008][INFO][sys-#73][GridCacheProcessor] Finish proxy
> initialization, cacheName=cache_007,
> localNodeId=e8ad11f2-c6dd-4683-b449-44a726d715fd
> [22:43:02,012][INFO][db-checkpoint-thread-#68][GridCacheDatabaseSharedManager]
> Checkpoint started [checkpointId=214d43f2-6096-4b42-ab0f-52b7f98078f4,
> startPtr=FileWALPointer [idx=0, fileOff=513096, len=16483],
> checkpointLockWait=0ms, checkpointLockHoldTime=23ms,
> walCpRecordFsyncDuration=880ms, pages=238, reason='timeout']
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> # SIGBUS (0x7) at pc=0x7f0aa29d8522, pid=12344, tid=0x7f08b15f5700
> #
> # JRE version: Java(TM) SE Runtime Environment (8.0_161-b12) (build
> 1.8.0_161-b12)
> # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.161-b12 mixed mode
> linux-amd64 compressed oops)
> # Problematic frame:
> # C [libzip.so+0x12522] newEntry+0x62
> #
> # Core dump written. Default location:
> /var/lib/teamcity/data/work/dd4d79acf76cc870/i2test/suites/core or core.12344
> #
> # An error report file with more information is saved as:
> #
> /var/lib/teamcity/data/work/dd4d79acf76cc870/i2test/suites/hs_err_pid12344.log
> Compiled method (nm)7845 558 n 0
> java.util.zip.ZipFile::getEntry (native)
> total in heap [0x7f0a8d3d1850,0x7f0a8d3d1bc0] = 880
> relocation [0x7f0a8d3d1978,0x7f0a8d3d19c0] = 72
> main code [0x7f0a8d3d19c0,0x7f0a8d3d1bc0] = 512
> [thread 139675315439360 also had an error]
> #
> # If you would like to submit a bug rep
[jira] [Commented] (IGNITE-10023) Improve ListeningTestLogger for wait conditions.
[
https://issues.apache.org/jira/browse/IGNITE-10023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668358#comment-16668358
]
Pavel Pereslegin commented on IGNITE-10023:
---
[~NSAmelchev], looks good to me, thank you!
> Improve ListeningTestLogger for wait conditions.
>
>
> Key: IGNITE-10023
> URL: https://issues.apache.org/jira/browse/IGNITE-10023
> Project: Ignite
> Issue Type: Improvement
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Fix For: 2.8
>
>
> [Dev-list
> discussion.|http://apache-ignite-developers.2346864.n4.nabble.com/Unreliable-checks-in-tests-for-string-presence-in-GridStringLogger-contents-td30802.html]
> Method LogListener.check() should be boolean type.
> It'll be useful for wait for conditions and code readability:
> For now:
> {code:java}
> waitForCondition(() -> {
> try {
> lsnr.check();
> return true;
> }
> catch (AssertionError ignored) {
> return false;
> }
> }, timeout);
> {code}
> After improvement:
> {code:java}
> waitForCondition(lsnr::check, timeout);
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10060) Optimize test use seconds instead of minutes
[ https://issues.apache.org/jira/browse/IGNITE-10060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexand Polyakov updated IGNITE-10060: -- Summary: Optimize test use seconds instead of minutes (was: Optimize IncSnapshotNearbyFullSnapshotTest#test use seconds instead of minutes) > Optimize test use seconds instead of minutes > > > Key: IGNITE-10060 > URL: https://issues.apache.org/jira/browse/IGNITE-10060 > Project: Ignite > Issue Type: Test >Reporter: Alexand Polyakov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-10060) Optimize test use seconds instead of minutes
[ https://issues.apache.org/jira/browse/IGNITE-10060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexand Polyakov resolved IGNITE-10060. --- Resolution: Invalid > Optimize test use seconds instead of minutes > > > Key: IGNITE-10060 > URL: https://issues.apache.org/jira/browse/IGNITE-10060 > Project: Ignite > Issue Type: Test >Reporter: Alexand Polyakov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10007) Deactivation hangs if an open transaction exists
[
https://issues.apache.org/jira/browse/IGNITE-10007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668362#comment-16668362
]
Ivan Pavlukhin commented on IGNITE-10007:
-
{{COMMIT}} statement inside a line with multiple statements is not processed
properly. An example line:
{code:sql}UPDATE t1 SET b = '2'; COMMIT{code}
> Deactivation hangs if an open transaction exists
>
>
> Key: IGNITE-10007
> URL: https://issues.apache.org/jira/browse/IGNITE-10007
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.7
>
> Attachments:
> PersistenceDeactivationWIthActiveMvccTransactionSelfTest.java,
> stacktrace_18308.txt, stacktrace_7808.txt
>
>
> 1. Start 2 node with PDS
> 2. Activate cluster
> 3. Connect sqlline
> 4. Create table {{create table t1(a int, b varchar, primary key(a)) with
> "ATOMICITY=TRANSACTIONAL_SNAPSHOT,backups=1";}}
> 3.Start TX and execute a DML commnd:
> {noformat}
> begin;
> insert into t1 values (1, '1');
> {noformat}
> 4. Try deactivate cluster {{bin/control.bat --deactivate}}. The scripts
> doesn't return control.
> 5. Show LRT:
> {noformat}
> c:\Work\apache-ignite-2.7.0-SNAPSHOT-bin>bin\control.bat --tx
> Control utility [ver. 2.7.0-SNAPSHOT#19700101-sha1:DEV]
> 2018 Copyright(C) Apache Software Foundation
> User:
>
> Matching transactions:
> TcpDiscoveryNode [id=5d3e8936-174d-42e2-a47f-c70ec02bccab, addrs=[127.0.0.1],
> order=1, ver=2.7.0#19700101-sha1:,
> isClient=false, consistentId=1]
> Tx: [xid=74bc1aba661--090e-b121--0001, label=null,
> state=ACTIVE, startTime=2018-10-25 17:34:35.5
> 22, duration=352, isolation=REPEATABLE_READ, concurrency=PESSIMISTIC,
> topVer=AffinityTopologyVersion [topVer=2, minorTop
> Ver=6], timeout=0, size=0, dhtNodes=[41ff88d2],
> nearXid=74bc1aba661--090e-b121--0001, parentNodeIds=
> [5d3e8936]]
> {noformat}
> 6. Complete TX:
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> commit;
> Error: class org.apache.ignite.IgniteException: Can not perform the operation
> because the cluster is inactive. Note, tha
> t the cluster is considered inactive by default if Ignite Persistent Store is
> used to let all the nodes join the cluster
> . To activate the cluster call Ignite.active(true). (state=5,code=1)
> java.sql.SQLException: class org.apache.ignite.IgniteException: Can not
> perform the operation because the cluster is ina
> ctive. Note, that the cluster is considered inactive by default if Ignite
> Persistent Store is used to let all the nodes
> join the cluster. To activate the cluster call Ignite.active(true).
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> 0: jdbc:ignite:thin://127.0.0.1/>
> {noformat}
> It.s ok but LRT is still presented and deactivation script doesn't return
> control back to user:
> {noformat}
> c:\Work\apache-ignite-2.7.0-SNAPSHOT-bin>bin\control.bat --tx
> Control utility [ver. 2.7.0-SNAPSHOT#19700101-sha1:DEV]
> 2018 Copyright(C) Apache Software Foundation
> User:
>
> Matching transactions:
> TcpDiscoveryNode [id=5d3e8936-174d-42e2-a47f-c70ec02bccab, addrs=[127.0.0.1],
> order=1, ver=2.7.0#19700101-sha1:,
> isClient=false, consistentId=1]
> Tx: [xid=74bc1aba661--090e-b121--0001, label=null,
> state=ACTIVE, startTime=2018-10-25 17:34:35.5
> 22, duration=510, isolation=REPEATABLE_READ, concurrency=PESSIMISTIC,
> topVer=AffinityTopologyVersion [topVer=2, minorTop
> Ver=6], timeout=0, size=0, dhtNodes=[41ff88d2],
> nearXid=74bc1aba661--090e-b121--0001, parentNodeIds=
> [5d3e8936]]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10007) Deactivation hangs if an open transaction exists
[
https://issues.apache.org/jira/browse/IGNITE-10007?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668362#comment-16668362
]
Ivan Pavlukhin edited comment on IGNITE-10007 at 10/30/18 8:48 AM:
---
{{COMMIT}} command inside a line with multiple statements is not processed
properly. An example line:
{code:sql}UPDATE t1 SET b = '2'; COMMIT{code}
was (Author: pavlukhin):
{{COMMIT}} statement inside a line with multiple statements is not processed
properly. An example line:
{code:sql}UPDATE t1 SET b = '2'; COMMIT{code}
> Deactivation hangs if an open transaction exists
>
>
> Key: IGNITE-10007
> URL: https://issues.apache.org/jira/browse/IGNITE-10007
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.7
>
> Attachments:
> PersistenceDeactivationWIthActiveMvccTransactionSelfTest.java,
> stacktrace_18308.txt, stacktrace_7808.txt
>
>
> 1. Start 2 node with PDS
> 2. Activate cluster
> 3. Connect sqlline
> 4. Create table {{create table t1(a int, b varchar, primary key(a)) with
> "ATOMICITY=TRANSACTIONAL_SNAPSHOT,backups=1";}}
> 3.Start TX and execute a DML commnd:
> {noformat}
> begin;
> insert into t1 values (1, '1');
> {noformat}
> 4. Try deactivate cluster {{bin/control.bat --deactivate}}. The scripts
> doesn't return control.
> 5. Show LRT:
> {noformat}
> c:\Work\apache-ignite-2.7.0-SNAPSHOT-bin>bin\control.bat --tx
> Control utility [ver. 2.7.0-SNAPSHOT#19700101-sha1:DEV]
> 2018 Copyright(C) Apache Software Foundation
> User:
>
> Matching transactions:
> TcpDiscoveryNode [id=5d3e8936-174d-42e2-a47f-c70ec02bccab, addrs=[127.0.0.1],
> order=1, ver=2.7.0#19700101-sha1:,
> isClient=false, consistentId=1]
> Tx: [xid=74bc1aba661--090e-b121--0001, label=null,
> state=ACTIVE, startTime=2018-10-25 17:34:35.5
> 22, duration=352, isolation=REPEATABLE_READ, concurrency=PESSIMISTIC,
> topVer=AffinityTopologyVersion [topVer=2, minorTop
> Ver=6], timeout=0, size=0, dhtNodes=[41ff88d2],
> nearXid=74bc1aba661--090e-b121--0001, parentNodeIds=
> [5d3e8936]]
> {noformat}
> 6. Complete TX:
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> commit;
> Error: class org.apache.ignite.IgniteException: Can not perform the operation
> because the cluster is inactive. Note, tha
> t the cluster is considered inactive by default if Ignite Persistent Store is
> used to let all the nodes join the cluster
> . To activate the cluster call Ignite.active(true). (state=5,code=1)
> java.sql.SQLException: class org.apache.ignite.IgniteException: Can not
> perform the operation because the cluster is ina
> ctive. Note, that the cluster is considered inactive by default if Ignite
> Persistent Store is used to let all the nodes
> join the cluster. To activate the cluster call Ignite.active(true).
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> 0: jdbc:ignite:thin://127.0.0.1/>
> {noformat}
> It.s ok but LRT is still presented and deactivation script doesn't return
> control back to user:
> {noformat}
> c:\Work\apache-ignite-2.7.0-SNAPSHOT-bin>bin\control.bat --tx
> Control utility [ver. 2.7.0-SNAPSHOT#19700101-sha1:DEV]
> 2018 Copyright(C) Apache Software Foundation
> User:
>
> Matching transactions:
> TcpDiscoveryNode [id=5d3e8936-174d-42e2-a47f-c70ec02bccab, addrs=[127.0.0.1],
> order=1, ver=2.7.0#19700101-sha1:,
> isClient=false, consistentId=1]
> Tx: [xid=74bc1aba661--090e-b121--0001, label=null,
> state=ACTIVE, startTime=2018-10-25 17:34:35.5
> 22, duration=510, isolation=REPEATABLE_READ, concurrency=PESSIMISTIC,
> topVer=AffinityTopologyVersion [topVer=2, minorTop
> Ver=6], timeout=0, size=0, dhtNodes=[41ff88d2],
> nearXid=74bc1aba661--090e-b121--0001, parentNodeIds=
> [5d3e8936]]
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10055) MVCC: incorrect fields count in PartitionUpdateCountersMessage
[ https://issues.apache.org/jira/browse/IGNITE-10055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668374#comment-16668374 ] ASF GitHub Bot commented on IGNITE-10055: - Github user devozerov closed the pull request at: https://github.com/apache/ignite/pull/5202 > MVCC: incorrect fields count in PartitionUpdateCountersMessage > -- > > Key: IGNITE-10055 > URL: https://issues.apache.org/jira/browse/IGNITE-10055 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.7 > > > Should be 2. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10042) Wrong TxLog root page type.
[ https://issues.apache.org/jira/browse/IGNITE-10042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668385#comment-16668385 ] Vladimir Ozerov commented on IGNITE-10042: -- Not a blocker. > Wrong TxLog root page type. > --- > > Key: IGNITE-10042 > URL: https://issues.apache.org/jira/browse/IGNITE-10042 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Blocker > Fix For: 2.7 > > > TxLog tries root pages has 'data page' type. > This is a bug as tree structures root pages has to be a type of 'index page'. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10055) MVCC: incorrect fields count in PartitionUpdateCountersMessage
[ https://issues.apache.org/jira/browse/IGNITE-10055?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668383#comment-16668383 ] Vladimir Ozerov commented on IGNITE-10055: -- Blockers are false-positive. > MVCC: incorrect fields count in PartitionUpdateCountersMessage > -- > > Key: IGNITE-10055 > URL: https://issues.apache.org/jira/browse/IGNITE-10055 > Project: Ignite > Issue Type: Task > Components: mvcc >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.7 > > > Should be 2. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10042) Wrong TxLog root page type.
[ https://issues.apache.org/jira/browse/IGNITE-10042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668392#comment-16668392 ] Vladimir Ozerov commented on IGNITE-10042: -- Merged to master. > Wrong TxLog root page type. > --- > > Key: IGNITE-10042 > URL: https://issues.apache.org/jira/browse/IGNITE-10042 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Blocker > Fix For: 2.7 > > > TxLog tries root pages has 'data page' type. > This is a bug as tree structures root pages has to be a type of 'index page'. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9558) Avoid changing AffinityTopologyVersion on client connect when possible
[ https://issues.apache.org/jira/browse/IGNITE-9558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668394#comment-16668394 ] Alexey Goncharuk commented on IGNITE-9558: -- [~ilantukh], we've got a performance drop of 3-4% on atomic-put benchmark. We need to investigate and check if this can be fixed, then re-run a more thorough set of benchmarks. > Avoid changing AffinityTopologyVersion on client connect when possible > -- > > Key: IGNITE-9558 > URL: https://issues.apache.org/jira/browse/IGNITE-9558 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.0 >Reporter: Alexey Goncharuk >Assignee: Ilya Lantukh >Priority: Major > Fix For: 2.8 > > > Currently a client join event changes discovery topology version which, in > turn, changes AffinityTopologyVersion. > When a client maps transaction on new AffinityTopologyVersion, corresponding > message is not processed on remote node until remote node receives the > corresponding discovery event. If discovery event delivery is delayed for > some reason, this will result in transaction stalls on client joins. > Since the client node does not change partition affinity, we can safely map > transactions on the previous topology version and do not change the affinity > topology version at all. > Some cases need special care and probably do not qualify for this > optimization, such as when client has near cache or client hosts partition > for REPLICATED cache. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9962) Unhandled exception during BatchCacheChangeRequest
[ https://issues.apache.org/jira/browse/IGNITE-9962?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Govorukhin updated IGNITE-9962: --- Fix Version/s: 2.8 > Unhandled exception during BatchCacheChangeRequest > -- > > Key: IGNITE-9962 > URL: https://issues.apache.org/jira/browse/IGNITE-9962 > Project: Ignite > Issue Type: Bug >Reporter: Anton Kalashnikov >Assignee: Anton Kalashnikov >Priority: Major > Fix For: 2.8 > > > Node hangs if exception in GridQueryProcessor#onCacheChangeRequested throw. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10042) Wrong TxLog root page type.
[ https://issues.apache.org/jira/browse/IGNITE-10042?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668396#comment-16668396 ] ASF GitHub Bot commented on IGNITE-10042: - Github user asfgit closed the pull request at: https://github.com/apache/ignite/pull/5193 > Wrong TxLog root page type. > --- > > Key: IGNITE-10042 > URL: https://issues.apache.org/jira/browse/IGNITE-10042 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Blocker > Fix For: 2.7 > > > TxLog tries root pages has 'data page' type. > This is a bug as tree structures root pages has to be a type of 'index page'. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9308) Add baseline topology command to REST API
[ https://issues.apache.org/jira/browse/IGNITE-9308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668404#comment-16668404 ] Andrey Novikov commented on IGNITE-9308: [~kuaw26], Fixed notes. > Add baseline topology command to REST API > -- > > Key: IGNITE-9308 > URL: https://issues.apache.org/jira/browse/IGNITE-9308 > Project: Ignite > Issue Type: Bug > Components: rest >Affects Versions: 2.6 >Reporter: ARomantsov >Assignee: Andrey Novikov >Priority: Major > Fix For: 2.8 > > > Not found in https://apacheignite.readme.io/docs/rest-api info about baseline > command https://apacheignite.readme.io/docs/baseline-topology -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9308) Add baseline topology command to REST API
[ https://issues.apache.org/jira/browse/IGNITE-9308?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668404#comment-16668404 ] Andrey Novikov edited comment on IGNITE-9308 at 10/30/18 9:20 AM: -- [~kuaw26], Fixed notes, please review. was (Author: anovikov): [~kuaw26], Fixed notes. > Add baseline topology command to REST API > -- > > Key: IGNITE-9308 > URL: https://issues.apache.org/jira/browse/IGNITE-9308 > Project: Ignite > Issue Type: Bug > Components: rest >Affects Versions: 2.6 >Reporter: ARomantsov >Assignee: Andrey Novikov >Priority: Major > Fix For: 2.8 > > > Not found in https://apacheignite.readme.io/docs/rest-api info about baseline > command https://apacheignite.readme.io/docs/baseline-topology -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10061) Improvement: warning or debug message is required in case if some data in SQL join requests isn't collocated.
Andrey Aleksandrov created IGNITE-10061: --- Summary: Improvement: warning or debug message is required in case if some data in SQL join requests isn't collocated. Key: IGNITE-10061 URL: https://issues.apache.org/jira/browse/IGNITE-10061 Project: Ignite Issue Type: Improvement Components: sql Affects Versions: 2.6 Reporter: Andrey Aleksandrov Fix For: 2.8 When data isn't collocated then during executing of the join request will be great to get for some warning like "your data isn't collocated" -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8626) ODBC: Can not compile ODBC with OpenSSL 1.1
[ https://issues.apache.org/jira/browse/IGNITE-8626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-8626: Labels: (was: newbie) > ODBC: Can not compile ODBC with OpenSSL 1.1 > --- > > Key: IGNITE-8626 > URL: https://issues.apache.org/jira/browse/IGNITE-8626 > Project: Ignite > Issue Type: Bug > Components: odbc >Affects Versions: 2.4 >Reporter: Igor Sapego >Priority: Major > Fix For: 2.8 > > Attachments: 01(1).patch > > > Can not compile ODBC with OpenSSL 1.1. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9221) Uncomment 25 test classes in various Indexing test suites
[
https://issues.apache.org/jira/browse/IGNITE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668412#comment-16668412
]
ASF GitHub Bot commented on IGNITE-9221:
GitHub user alamar opened a pull request:
https://github.com/apache/ignite/pull/5206
IGNITE-9221 Uncomment Cache Query tests, delete duplicating suites to
simplify layout.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9221a
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5206.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #5206
commit 6c28d2c4a5075ab7b261c7bd0b8cce3d5ce6de41
Author: Ilya Kasnacheev
Date: 2018-10-29T13:33:45Z
IGNITE-9221 Uncomment Cache Query tests, delete and rename suites to
simplify layout.
> Uncomment 25 test classes in various Indexing test suites
> -
>
> Key: IGNITE-9221
> URL: https://issues.apache.org/jira/browse/IGNITE-9221
> Project: Ignite
> Issue Type: Sub-task
> Components: binary, sql
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> modules/indexing/src/test/java/org/apache/ignite/testsuites/IgniteCacheQuerySelfTestSuite.java
> {code}
> // suite.addTest(new TestSuite(QueryEntityValidationSelfTest.class));
> // suite.addTest(new TestSuite(GridH2TableSelfTest.class));
> //suite.addTestSuite(IgniteCacheUnionDuplicatesTest.class);
> //suite.addTestSuite(IgniteCacheConfigVariationsQueryTest.class);
>
> //suite.addTestSuite(IgniteCacheJoinPartitionedAndReplicatedCollocationTest.class);
>
> //suite.addTestSuite(IgniteClientReconnectCacheQueriesFailoverTest.class);
> //suite.addTestSuite(IgniteErrorOnRebalanceTest.class);
> //suite.addTestSuite(CacheQueryBuildValueTest.class);
> //suite.addTestSuite(CacheOffheapBatchIndexingMultiTypeTest.class);
> //suite.addTestSuite(CacheOffheapBatchIndexingBaseTest.class);
> //suite.addTestSuite(GridCircularQueueTest.class);
> //suite.addTestSuite(IndexingSpiQueryWithH2IndexingSelfTest.class);
> //suite.addTestSuite(H2DynamicIndexingComplexAbstractTest.class);
>
> //suite.addTestSuite(H2DynamicIndexingComplexClientAtomicPartitionedNoBackupsTest.class);
>
> //suite.addTestSuite(H2DynamicIndexingComplexClientTransactionalPartitionedNoBackupsTest.class);
>
> //suite.addTestSuite(H2DynamicIndexingComplexServerAtomicPartitionedNoBackupsTest.class);
>
> //suite.addTestSuite(H2DynamicIndexingComplexServerTransactionalPartitionedNoBackupsTest.class);
> {code}
> modules/indexing/src/test/java/org/apache/ignite/testsuites/IgniteCacheQuerySelfTestSuite3.java
> {code}
>
> //suite.addTestSuite(CacheContinuousQueryCounterPartitionedAtomicTest.class);
>
> //suite.addTestSuite(CacheContinuousQueryCounterPartitionedTxTest.class);
>
> //suite.addTestSuite(CacheContinuousQueryCounterReplicatedAtomicTest.class);
>
> //suite.addTestSuite(CacheContinuousQueryCounterReplicatedTxTest.class);
>
> //suite.addTestSuite(CacheContinuousQueryFailoverAtomicNearEnabledSelfSelfTest.class);
> {code}
> modules/indexing/src/test/java/org/apache/ignite/testsuites/IgniteBinaryCacheQueryTestSuite.java
> {code}
> //suite.addTestSuite(GridCacheBinarySwapScanQuerySelfTest.class);
> //suite.addTestSuite(IgniteSqlSchemaIndexingTest.class);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10052) Restart node during TX causes vacuum error
[
https://issues.apache.org/jira/browse/IGNITE-10052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-10052:
Assignee: Andrew Mashenkov
> Restart node during TX causes vacuum error
> --
>
> Key: IGNITE-10052
> URL: https://issues.apache.org/jira/browse/IGNITE-10052
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Assignee: Andrew Mashenkov
>Priority: Major
> Fix For: 2.7
>
>
> 1. Start 2 nodes with PDS, activate , start {{sqlline}}
> 2. Create table
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> create table t1 (a int, b int, primary
> key(a)) with "atomicity=TRANSACTIONAL_SNAPSHOT,
> backups=1";
> No rows affected (0,294 seconds)
> {noformat}
> 3. Open TX:
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> begin;
> No rows affected (0,007 seconds)
> 0: jdbc:ignite:thin://127.0.0.1/> insert into t1 values (1,1);
> 1 row affected (0,112 seconds)
> {noformat}
> 4. Stop and then start 2nd node
> 5. Rollback TX and check the table data (no rows added):
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> rollback;
> No rows affected (0,011 seconds)
> 0: jdbc:ignite:thin://127.0.0.1/> select * from t1;
> +++
> | A| B|
> +++
> +++
> No rows selected (0,067 seconds)
> {noformat}
> 6. Start second TX that throws the exception:
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> begin;
> No rows affected (0,001 seconds)
> 0: jdbc:ignite:thin://127.0.0.1/> insert into t1 values (1,1);
> Error: Failed to run update. Runtime failure on bounds:
> [lower=MvccMaxSearchRow [], upper=MvccMinSearchRow []] (state=50
> 000,code=1)
> java.sql.SQLException: Failed to run update. Runtime failure on bounds:
> [lower=MvccMaxSearchRow [], upper=MvccMinSearchR
> ow []]
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> 0: jdbc:ignite:thin://127.0.0.1/>
> {noformat}
> The server nodes print out:
> {noformat}
> [18:46:32,136][SEVERE][jdbc-request-handler-worker-#62][DmlStatementsProcessor]
> Error during update [localNodeId=319a2fda-1315-4bdf-8647-7ddee2d3342e]
> class org.apache.ignite.IgniteCheckedException: Runtime failure on bounds:
> [lower=MvccMaxSearchRow [], upper=MvccMinSearchRow []]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.visit(BPlusTree.java:1061)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:1919)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.mvccUpdate(GridCacheOffheapManager.java:1840)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:530)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.mvccSet(GridCacheMapEntry.java:1104)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.continueLoop(GridDhtTxAbstractEnlistFuture.java:460)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.init(GridDhtTxAbstractEnlistFuture.java:368)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processNearTxQueryResultsEnlistRequest(GridDhtTransactionalCacheAdapter.java:2000)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$700(GridDhtTransactionalCacheAdapter.java:112)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$12.apply(GridDhtTransactionalCacheAdapter.java:215)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$12.apply(GridDhtTransactionalCacheAdapter.java:213)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIo
[jira] [Commented] (IGNITE-10037) Cache 2 tests optimization
[ https://issues.apache.org/jira/browse/IGNITE-10037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668430#comment-16668430 ] ASF GitHub Bot commented on IGNITE-10037: - GitHub user avplatonov opened a pull request: https://github.com/apache/ignite/pull/5207 IGNITE-10037: Cache 2 tests optimization You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10037 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5207.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5207 commit 4e85c11c3a5781b88cf2e3ae2a70b033f66e6e5d Author: Alexey Platonov Date: 2018-10-29T13:59:05Z init commit commit 45076feec0dc4a26172eb79acb9dabcd1a8bab73 Author: Alexey Platonov Date: 2018-10-30T09:37:14Z add scale factor > Cache 2 tests optimization > -- > > Key: IGNITE-10037 > URL: https://issues.apache.org/jira/browse/IGNITE-10037 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Platonov >Assignee: Alexey Platonov >Priority: Major > Labels: MakeTeamcityGreenAgain > > We need to investigate how to optimize these tests: > GridCachePartitionNotLoadedEventSelfTest.testPrimaryAndBackupDead > > CacheTxLoadingConcurrentGridStartSelfTestAllowOverwrite.testLoadCacheWithDataStreamerSequentialWithConfigAndRestarts > IgniteCacheEntryProcessorNodeJoinTest.testEntryProcessorNodeLeave > > CacheTxLoadingConcurrentGridStartSelfTestAllowOverwrite.testLoadCacheWithDataStreamerSequentialWithConfig > > CacheTxLoadingConcurrentGridStartSelfTestAllowOverwrite.testLoadCacheWithDataStreamerSequentialClientWithConfig > > and optimize them. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9455) Total allocated size memory metric is always zero for metastore data region.
[ https://issues.apache.org/jira/browse/IGNITE-9455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668436#comment-16668436 ] Pavel Pereslegin commented on IGNITE-9455: -- [~alex_pl], can you review this small patch? > Total allocated size memory metric is always zero for metastore data region. > > > Key: IGNITE-9455 > URL: https://issues.apache.org/jira/browse/IGNITE-9455 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Fix For: 2.8 > > Attachments: Reproducer.java > > > Persistence enabled and metrics for all regions enabled, but total allocated > size is always zero for metastore data region > Even if we change NO_OP allocated page tracker to a real page tracker in > CacheStoreHolder this metric counts incorrectly, because this region is > recreated, > Reproducer attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9455) Total allocated size memory metric is always zero for metastore data region.
[ https://issues.apache.org/jira/browse/IGNITE-9455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668435#comment-16668435 ] Pavel Pereslegin commented on IGNITE-9455: -- [~Mmuzaf], thank you for fixing it! > Total allocated size memory metric is always zero for metastore data region. > > > Key: IGNITE-9455 > URL: https://issues.apache.org/jira/browse/IGNITE-9455 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.6 >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Major > Fix For: 2.8 > > Attachments: Reproducer.java > > > Persistence enabled and metrics for all regions enabled, but total allocated > size is always zero for metastore data region > Even if we change NO_OP allocated page tracker to a real page tracker in > CacheStoreHolder this metric counts incorrectly, because this region is > recreated, > Reproducer attached. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9010) Move web-console build to dedicated root directory
[
https://issues.apache.org/jira/browse/IGNITE-9010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668446#comment-16668446
]
Peter Ivanov commented on IGNITE-9010:
--
[~anovikov] -- is there any other objections / questions about this change?
> Move web-console build to dedicated root directory
> --
>
> Key: IGNITE-9010
> URL: https://issues.apache.org/jira/browse/IGNITE-9010
> Project: Ignite
> Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Ilya Murchenko
>Priority: Major
> Fix For: 2.8
>
>
> # Move web-console docker image build (web-console, frontend and backend) to
> {{/docker}} directory.
> # Prepare README.md file in root of {{/docker}} directory with instructions
> on how to build corresponding image. Remove obsolete per-image README's from
> Dockerfile directories.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9698) Add tests to control.sh with ssl authentication
[ https://issues.apache.org/jira/browse/IGNITE-9698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668462#comment-16668462 ] Alexand Polyakov commented on IGNITE-9698: -- https://issues.apache.org/jira/browse/IGNITE-9298 has 2 implementations community planed to take implementation of Paul Anderson and this ticket add test from my implementation > Add tests to control.sh with ssl authentication > > > Key: IGNITE-9698 > URL: https://issues.apache.org/jira/browse/IGNITE-9698 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Kosarev >Assignee: Alexand Polyakov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10011) Pages leak suspicion in PDS
[
https://issues.apache.org/jira/browse/IGNITE-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668479#comment-16668479
]
Alexey Goncharuk commented on IGNITE-10011:
---
The second source of the "leak" is having multiple {{Stripe}}s per bucket. In
this case, a page is returned to a different stripe compared to the one it was
borrowed. In the long run it stabilizes.
This can be confirmed either by setting IGNITE_PAGES_LIST_STRIPES_PER_BUCKET=1
or changing {{removeAll}} to element-by-element remove (removes multithreading).
> Pages leak suspicion in PDS
> ---
>
> Key: IGNITE-10011
> URL: https://issues.apache.org/jira/browse/IGNITE-10011
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Ilya Kasnacheev
>Assignee: Alexey Goncharuk
>Priority: Major
> Labels: performance
> Fix For: 2.8
>
> Attachments: Main.java
>
>
> See the attached Main which adds 500k records to 3 caches, then clears them,
> rinse, repeat.
> When ran with default settings, totalAllocatedSize will slowly double over
> the course of a few hours and then continue to grow.
> When ran with 2 FreeList buckets, it will double every time, 600M -> 1200M ->
> 1800M -> etc.
> See the userlist discussion
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10034) Metastore read-only mode reduces the node start time
[
https://issues.apache.org/jira/browse/IGNITE-10034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin updated IGNITE-10034:
Fix Version/s: 2.8
> Metastore read-only mode reduces the node start time
>
>
> Key: IGNITE-10034
> URL: https://issues.apache.org/jira/browse/IGNITE-10034
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7, 2.8
>Reporter: Maxim Muzafarov
>Priority: Critical
> Fix For: 2.8
>
>
> Currently, note startup routine performs 2-times reading WAL:
> * read WAL to restore Metastore in read-only mode
> ({{GridCacheDatabaseSharedManager#readMetastore}})
> * read WAL to perform binary memory
> recovery({{GridCacheDatabaseSharedManager#restoreBinaryMemory}})
> In the case of huge WAL it dramatically reduces the node stat time. We should
> restore Metastorage in read-only mode and binary memory consistency within
> single WAL iteration.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9010) Move web-console build to dedicated root directory
[
https://issues.apache.org/jira/browse/IGNITE-9010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668507#comment-16668507
]
Andrey Novikov commented on IGNITE-9010:
[~vveider] Is this volumes really needed?
> Move web-console build to dedicated root directory
> --
>
> Key: IGNITE-9010
> URL: https://issues.apache.org/jira/browse/IGNITE-9010
> Project: Ignite
> Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Ilya Murchenko
>Priority: Major
> Fix For: 2.8
>
>
> # Move web-console docker image build (web-console, frontend and backend) to
> {{/docker}} directory.
> # Prepare README.md file in root of {{/docker}} directory with instructions
> on how to build corresponding image. Remove obsolete per-image README's from
> Dockerfile directories.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9010) Move web-console build to dedicated root directory
[
https://issues.apache.org/jira/browse/IGNITE-9010?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668507#comment-16668507
]
Andrey Novikov edited comment on IGNITE-9010 at 10/30/18 10:41 AM:
---
[~vveider] Is volumes in image really needed?
was (Author: anovikov):
[~vveider] Is this volumes really needed?
> Move web-console build to dedicated root directory
> --
>
> Key: IGNITE-9010
> URL: https://issues.apache.org/jira/browse/IGNITE-9010
> Project: Ignite
> Issue Type: Task
>Reporter: Peter Ivanov
>Assignee: Ilya Murchenko
>Priority: Major
> Fix For: 2.8
>
>
> # Move web-console docker image build (web-console, frontend and backend) to
> {{/docker}} directory.
> # Prepare README.md file in root of {{/docker}} directory with instructions
> on how to build corresponding image. Remove obsolete per-image README's from
> Dockerfile directories.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10011) Pages leak suspicion in PDS
[ https://issues.apache.org/jira/browse/IGNITE-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668511#comment-16668511 ] ASF GitHub Bot commented on IGNITE-10011: - GitHub user agoncharuk opened a pull request: https://github.com/apache/ignite/pull/5208 IGNITE-10011 Fixed pages leak You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10011 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5208.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5208 commit c4d52c527050e006767850e04bdde653463ae9fe Author: Alexey Goncharuk Date: 2018-10-30T10:42:01Z IGNITE-10011 Fixed pages leak > Pages leak suspicion in PDS > --- > > Key: IGNITE-10011 > URL: https://issues.apache.org/jira/browse/IGNITE-10011 > Project: Ignite > Issue Type: Bug > Components: persistence >Reporter: Ilya Kasnacheev >Assignee: Alexey Goncharuk >Priority: Major > Labels: performance > Fix For: 2.8 > > Attachments: Main.java > > > See the attached Main which adds 500k records to 3 caches, then clears them, > rinse, repeat. > When ran with default settings, totalAllocatedSize will slowly double over > the course of a few hours and then continue to grow. > When ran with 2 FreeList buckets, it will double every time, 600M -> 1200M -> > 1800M -> etc. > See the userlist discussion -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9289) Document CPP thin client
[ https://issues.apache.org/jira/browse/IGNITE-9289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-9289: Component/s: (was: thin client) > Document CPP thin client > > > Key: IGNITE-9289 > URL: https://issues.apache.org/jira/browse/IGNITE-9289 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Vladimir Ozerov >Assignee: Igor Sapego >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-9289) Document CPP thin client
[ https://issues.apache.org/jira/browse/IGNITE-9289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-9289: Ignite Flags: (was: Docs Required) > Document CPP thin client > > > Key: IGNITE-9289 > URL: https://issues.apache.org/jira/browse/IGNITE-9289 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Vladimir Ozerov >Assignee: Igor Sapego >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7730) Improve WAL history size documentation
[
https://issues.apache.org/jira/browse/IGNITE-7730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov resolved IGNITE-7730.
Resolution: Done
According there is a new approach to specify WAL history size in bytes
IGNITE-6552
there is no need to deep specification calculation algorithm.
The algorithm is specified in wiki
https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStore-underthehood-Estimatingdiskspace
for an advanced user/Ignite developer
> Improve WAL history size documentation
> --
>
> Key: IGNITE-7730
> URL: https://issues.apache.org/jira/browse/IGNITE-7730
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Affects Versions: 2.1
>Reporter: Dmitriy Pavlov
>Assignee: Dmitriy Pavlov
>Priority: Major
> Fix For: 2.7
>
>
> Until IGNITE-6552 is not implemented, we have only ability to configure WAL
> hist. size in checkpoints.
> It is needed to improve description for this parameter.
> I've added draft notes to wiki
> [https://cwiki.apache.org/confluence/display/IGNITE/Ignite+Persistent+Store+-+under+the+hood#IgnitePersistentStore-underthehood-Estimatingdiskspace]
> about ways how wer can estimate WAL sizes without exact bytes/time
> specification:
> {panel}
> WAL Work max used size: walSegmentSize * walSegments = 640Mb (default)
> in case Default WAL mode - this size is used always,
> in case other modes best case is 1 segment * walSegmentSize
> WAL Work+WAL Archive max size may be estimated by
> 1. average load or
> 2. by maximum size.
> 1st way is applicable if checkpoints are triggered mostly by timer trigger.
> Wal size = 2*Average load(bytes/sec) * trigger interval (sec) * walHistSize
> (number of checkpoints)
> Where 2 multiplier coming from physical & logical WAL Records.
> 2nd way: Checkpoint is triggered by segments max dirty pages percent. Use
> persisted data regions max sizes:
> sum(Max configured DataRegionConfiguration.maxSize) * 75% - est. maximum
> data volume to be writen on 1 checkpoint.
> Overall WAL size (before archiving) = 2* est. data volume * walHistSize =
> 1,5 * sum(DataRegionConfiguration.maxSize) * walHistSize
> Note applying WAL compressor may significiantly reduce archive size.
> {panel}
> One more note from [~ivan.glukos] on dev.list we need to include. It is
> answer to question how user can determine if segment from archive folder can
> be safely removed:
> {quote}By the way: WAL compression is already implemented that way. If there
> are any ".zip" segments in archive dir, they are free to delete.
> This can be a safe workaround for users who experience lack of free
> space - just delete compressed segments. We should mention it in
> documentation for 2.4 release.
> {quote}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9769) IgniteCacheAtomicProtocolTest.testPutReaderUpdate1 is flaky
[
https://issues.apache.org/jira/browse/IGNITE-9769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668555#comment-16668555
]
Ignite TC Bot commented on IGNITE-9769:
---
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2189229&buildTypeId=IgniteTests24Java8_RunAll]
> IgniteCacheAtomicProtocolTest.testPutReaderUpdate1 is flaky
> ---
>
> Key: IGNITE-9769
> URL: https://issues.apache.org/jira/browse/IGNITE-9769
> Project: Ignite
> Issue Type: Task
>Reporter: Ryabov Dmitrii
>Assignee: Ryabov Dmitrii
>Priority: Trivial
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> {{IgniteCacheAtomicProtocolTest.testPutReaderUpdate1}} and
> {{IgniteCacheAtomicProtocolTest.testPutReaderUpdate2}} are flaky.
> In the {{#readerUpdateDhtFails}} method we blocks
> {{GridDhtAtomicNearResponse}} messages and do put operation. Put should hangs
> always, but sometimes it doesn't.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9435) Document MVCC
[ https://issues.apache.org/jira/browse/IGNITE-9435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Artem Budnikov reassigned IGNITE-9435: -- Assignee: Artem Budnikov (was: Igor Seliverstov) > Document MVCC > - > > Key: IGNITE-9435 > URL: https://issues.apache.org/jira/browse/IGNITE-9435 > Project: Ignite > Issue Type: Task > Components: documentation, mvcc >Reporter: Vladimir Ozerov >Assignee: Artem Budnikov >Priority: Major > Fix For: 2.7 > > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9769) IgniteCacheAtomicProtocolTest.testPutReaderUpdate1 is flaky
[
https://issues.apache.org/jira/browse/IGNITE-9769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668560#comment-16668560
]
Ryabov Dmitrii commented on IGNITE-9769:
[~ilantukh], done.
> IgniteCacheAtomicProtocolTest.testPutReaderUpdate1 is flaky
> ---
>
> Key: IGNITE-9769
> URL: https://issues.apache.org/jira/browse/IGNITE-9769
> Project: Ignite
> Issue Type: Task
>Reporter: Ryabov Dmitrii
>Assignee: Ryabov Dmitrii
>Priority: Trivial
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> {{IgniteCacheAtomicProtocolTest.testPutReaderUpdate1}} and
> {{IgniteCacheAtomicProtocolTest.testPutReaderUpdate2}} are flaky.
> In the {{#readerUpdateDhtFails}} method we blocks
> {{GridDhtAtomicNearResponse}} messages and do put operation. Put should hangs
> always, but sometimes it doesn't.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9221) Uncomment 25 test classes in various Indexing test suites
[
https://issues.apache.org/jira/browse/IGNITE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668589#comment-16668589
]
ASF GitHub Bot commented on IGNITE-9221:
GitHub user alamar opened a pull request:
https://github.com/apache/ignite/pull/5209
IGNITE-9221 Rename classes to avoid changing suites on TC.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9221b
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5209.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #5209
commit b5d3cec3bcdcf1153d53aa2c562928afff6cf024
Author: Ilya Kasnacheev
Date: 2018-10-26T15:08:56Z
IGNITE-9221 Rename classes to avoid changing suites on TC.
> Uncomment 25 test classes in various Indexing test suites
> -
>
> Key: IGNITE-9221
> URL: https://issues.apache.org/jira/browse/IGNITE-9221
> Project: Ignite
> Issue Type: Sub-task
> Components: binary, sql
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> modules/indexing/src/test/java/org/apache/ignite/testsuites/IgniteCacheQuerySelfTestSuite.java
> {code}
> // suite.addTest(new TestSuite(QueryEntityValidationSelfTest.class));
> // suite.addTest(new TestSuite(GridH2TableSelfTest.class));
> //suite.addTestSuite(IgniteCacheUnionDuplicatesTest.class);
> //suite.addTestSuite(IgniteCacheConfigVariationsQueryTest.class);
>
> //suite.addTestSuite(IgniteCacheJoinPartitionedAndReplicatedCollocationTest.class);
>
> //suite.addTestSuite(IgniteClientReconnectCacheQueriesFailoverTest.class);
> //suite.addTestSuite(IgniteErrorOnRebalanceTest.class);
> //suite.addTestSuite(CacheQueryBuildValueTest.class);
> //suite.addTestSuite(CacheOffheapBatchIndexingMultiTypeTest.class);
> //suite.addTestSuite(CacheOffheapBatchIndexingBaseTest.class);
> //suite.addTestSuite(GridCircularQueueTest.class);
> //suite.addTestSuite(IndexingSpiQueryWithH2IndexingSelfTest.class);
> //suite.addTestSuite(H2DynamicIndexingComplexAbstractTest.class);
>
> //suite.addTestSuite(H2DynamicIndexingComplexClientAtomicPartitionedNoBackupsTest.class);
>
> //suite.addTestSuite(H2DynamicIndexingComplexClientTransactionalPartitionedNoBackupsTest.class);
>
> //suite.addTestSuite(H2DynamicIndexingComplexServerAtomicPartitionedNoBackupsTest.class);
>
> //suite.addTestSuite(H2DynamicIndexingComplexServerTransactionalPartitionedNoBackupsTest.class);
> {code}
> modules/indexing/src/test/java/org/apache/ignite/testsuites/IgniteCacheQuerySelfTestSuite3.java
> {code}
>
> //suite.addTestSuite(CacheContinuousQueryCounterPartitionedAtomicTest.class);
>
> //suite.addTestSuite(CacheContinuousQueryCounterPartitionedTxTest.class);
>
> //suite.addTestSuite(CacheContinuousQueryCounterReplicatedAtomicTest.class);
>
> //suite.addTestSuite(CacheContinuousQueryCounterReplicatedTxTest.class);
>
> //suite.addTestSuite(CacheContinuousQueryFailoverAtomicNearEnabledSelfSelfTest.class);
> {code}
> modules/indexing/src/test/java/org/apache/ignite/testsuites/IgniteBinaryCacheQueryTestSuite.java
> {code}
> //suite.addTestSuite(GridCacheBinarySwapScanQuerySelfTest.class);
> //suite.addTestSuite(IgniteSqlSchemaIndexingTest.class);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9221) Uncomment 25 test classes in various Indexing test suites
[
https://issues.apache.org/jira/browse/IGNITE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668595#comment-16668595
]
ASF GitHub Bot commented on IGNITE-9221:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5206
> Uncomment 25 test classes in various Indexing test suites
> -
>
> Key: IGNITE-9221
> URL: https://issues.apache.org/jira/browse/IGNITE-9221
> Project: Ignite
> Issue Type: Sub-task
> Components: binary, sql
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> modules/indexing/src/test/java/org/apache/ignite/testsuites/IgniteCacheQuerySelfTestSuite.java
> {code}
> // suite.addTest(new TestSuite(QueryEntityValidationSelfTest.class));
> // suite.addTest(new TestSuite(GridH2TableSelfTest.class));
> //suite.addTestSuite(IgniteCacheUnionDuplicatesTest.class);
> //suite.addTestSuite(IgniteCacheConfigVariationsQueryTest.class);
>
> //suite.addTestSuite(IgniteCacheJoinPartitionedAndReplicatedCollocationTest.class);
>
> //suite.addTestSuite(IgniteClientReconnectCacheQueriesFailoverTest.class);
> //suite.addTestSuite(IgniteErrorOnRebalanceTest.class);
> //suite.addTestSuite(CacheQueryBuildValueTest.class);
> //suite.addTestSuite(CacheOffheapBatchIndexingMultiTypeTest.class);
> //suite.addTestSuite(CacheOffheapBatchIndexingBaseTest.class);
> //suite.addTestSuite(GridCircularQueueTest.class);
> //suite.addTestSuite(IndexingSpiQueryWithH2IndexingSelfTest.class);
> //suite.addTestSuite(H2DynamicIndexingComplexAbstractTest.class);
>
> //suite.addTestSuite(H2DynamicIndexingComplexClientAtomicPartitionedNoBackupsTest.class);
>
> //suite.addTestSuite(H2DynamicIndexingComplexClientTransactionalPartitionedNoBackupsTest.class);
>
> //suite.addTestSuite(H2DynamicIndexingComplexServerAtomicPartitionedNoBackupsTest.class);
>
> //suite.addTestSuite(H2DynamicIndexingComplexServerTransactionalPartitionedNoBackupsTest.class);
> {code}
> modules/indexing/src/test/java/org/apache/ignite/testsuites/IgniteCacheQuerySelfTestSuite3.java
> {code}
>
> //suite.addTestSuite(CacheContinuousQueryCounterPartitionedAtomicTest.class);
>
> //suite.addTestSuite(CacheContinuousQueryCounterPartitionedTxTest.class);
>
> //suite.addTestSuite(CacheContinuousQueryCounterReplicatedAtomicTest.class);
>
> //suite.addTestSuite(CacheContinuousQueryCounterReplicatedTxTest.class);
>
> //suite.addTestSuite(CacheContinuousQueryFailoverAtomicNearEnabledSelfSelfTest.class);
> {code}
> modules/indexing/src/test/java/org/apache/ignite/testsuites/IgniteBinaryCacheQueryTestSuite.java
> {code}
> //suite.addTestSuite(GridCacheBinarySwapScanQuerySelfTest.class);
> //suite.addTestSuite(IgniteSqlSchemaIndexingTest.class);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9842) IgniteErrorOnRebalanceTest fails: errors in indexing cause grid to stall
[
https://issues.apache.org/jira/browse/IGNITE-9842?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668600#comment-16668600
]
ASF GitHub Bot commented on IGNITE-9842:
GitHub user alamar opened a pull request:
https://github.com/apache/ignite/pull/5210
IGNITE-9842 Avoid stopping rebalance on Indexing SPI errors.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/gridgain/apache-ignite ignite-9842
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/ignite/pull/5210.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #5210
commit 7f7663fc1738a563796d710ecf22a87c06d08d30
Author: Ilya Kasnacheev
Date: 2018-10-30T11:40:28Z
IGNITE-9842 Avoid stopping rebalance on Indexing SPI errors.
> IgniteErrorOnRebalanceTest fails: errors in indexing cause grid to stall
> -
>
> Key: IGNITE-9842
> URL: https://issues.apache.org/jira/browse/IGNITE-9842
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Kasnacheev
>Priority: Minor
>
> https://ci.ignite.apache.org/viewLog.html?buildId=2052100&#testNameId3682030486973860249
> {code}
> org.apache.ignite.IgniteException: Timeout of waiting for topology map update
> [igniteInstanceName=cache.IgniteErrorOnRebalanceTest0, cache=default,
> cacheId=1544803905, topVer=AffinityTopologyVersion [topVer=4, minorTopVer=1],
> p=0, readVer=AffinityTopologyVersion [topVer=4, minorTopVer=1],
> locNode=TcpDiscoveryNode [id=e35c1f95-2e5c-406a-9266-7f6e4360,
> addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47500],
> discPort=47500, order=4, intOrder=3, lastExchangeTime=1539180230507,
> loc=true, ver=2.7.0#20181010-sha1:9d1a551c, isClient=false]]
> at
> org.apache.ignite.internal.processors.cache.IgniteErrorOnRebalanceTest.testErrorOnRebalance(IgniteErrorOnRebalanceTest.java:129)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9221) Uncomment 25 test classes in various Indexing test suites
[
https://issues.apache.org/jira/browse/IGNITE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668602#comment-16668602
]
ASF GitHub Bot commented on IGNITE-9221:
Github user asfgit closed the pull request at:
https://github.com/apache/ignite/pull/5209
> Uncomment 25 test classes in various Indexing test suites
> -
>
> Key: IGNITE-9221
> URL: https://issues.apache.org/jira/browse/IGNITE-9221
> Project: Ignite
> Issue Type: Sub-task
> Components: binary, sql
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
>
> modules/indexing/src/test/java/org/apache/ignite/testsuites/IgniteCacheQuerySelfTestSuite.java
> {code}
> // suite.addTest(new TestSuite(QueryEntityValidationSelfTest.class));
> // suite.addTest(new TestSuite(GridH2TableSelfTest.class));
> //suite.addTestSuite(IgniteCacheUnionDuplicatesTest.class);
> //suite.addTestSuite(IgniteCacheConfigVariationsQueryTest.class);
>
> //suite.addTestSuite(IgniteCacheJoinPartitionedAndReplicatedCollocationTest.class);
>
> //suite.addTestSuite(IgniteClientReconnectCacheQueriesFailoverTest.class);
> //suite.addTestSuite(IgniteErrorOnRebalanceTest.class);
> //suite.addTestSuite(CacheQueryBuildValueTest.class);
> //suite.addTestSuite(CacheOffheapBatchIndexingMultiTypeTest.class);
> //suite.addTestSuite(CacheOffheapBatchIndexingBaseTest.class);
> //suite.addTestSuite(GridCircularQueueTest.class);
> //suite.addTestSuite(IndexingSpiQueryWithH2IndexingSelfTest.class);
> //suite.addTestSuite(H2DynamicIndexingComplexAbstractTest.class);
>
> //suite.addTestSuite(H2DynamicIndexingComplexClientAtomicPartitionedNoBackupsTest.class);
>
> //suite.addTestSuite(H2DynamicIndexingComplexClientTransactionalPartitionedNoBackupsTest.class);
>
> //suite.addTestSuite(H2DynamicIndexingComplexServerAtomicPartitionedNoBackupsTest.class);
>
> //suite.addTestSuite(H2DynamicIndexingComplexServerTransactionalPartitionedNoBackupsTest.class);
> {code}
> modules/indexing/src/test/java/org/apache/ignite/testsuites/IgniteCacheQuerySelfTestSuite3.java
> {code}
>
> //suite.addTestSuite(CacheContinuousQueryCounterPartitionedAtomicTest.class);
>
> //suite.addTestSuite(CacheContinuousQueryCounterPartitionedTxTest.class);
>
> //suite.addTestSuite(CacheContinuousQueryCounterReplicatedAtomicTest.class);
>
> //suite.addTestSuite(CacheContinuousQueryCounterReplicatedTxTest.class);
>
> //suite.addTestSuite(CacheContinuousQueryFailoverAtomicNearEnabledSelfSelfTest.class);
> {code}
> modules/indexing/src/test/java/org/apache/ignite/testsuites/IgniteBinaryCacheQueryTestSuite.java
> {code}
> //suite.addTestSuite(GridCacheBinarySwapScanQuerySelfTest.class);
> //suite.addTestSuite(IgniteSqlSchemaIndexingTest.class);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10048) Bounded iteration in standalone WAL iterator with compaction enabled may skip records
[
https://issues.apache.org/jira/browse/IGNITE-10048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668597#comment-16668597
]
Ignite TC Bot commented on IGNITE-10048:
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}MVCC Queries{color} [[tests
5|https://ci.ignite.apache.org/viewLog.html?buildId=2193049]]
* IgniteCacheMvccSqlTestSuite:
CacheMvccReplicatedSqlTxQueriesTest.testQueryInsertMultithread - 0,0% fails in
last 100 master runs.
{color:#d04437}PDS (Direct IO) 2{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2193083]]
* IgnitePdsNativeIoTestSuite2: IgniteWalIteratorExceptionDuringReadTest.test -
0,0% fails in last 100 master runs.
{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests
5|https://ci.ignite.apache.org/viewLog.html?buildId=2193038]]
* ZookeeperDiscoverySpiTestSuite2: GridEventConsumeSelfTest.testEventsByFilter
- 1,0% fails in last 100 master runs.
{color:#d04437}PDS 2{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2193088]]
* IgnitePdsTestSuite2: IgniteWalIteratorExceptionDuringReadTest.test - 0,0%
fails in last 100 master runs.
{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2193103&buildTypeId=IgniteTests24Java8_RunAll]
> Bounded iteration in standalone WAL iterator with compaction enabled may skip
> records
> -
>
> Key: IGNITE-10048
> URL: https://issues.apache.org/jira/browse/IGNITE-10048
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>Priority: Major
> Fix For: 2.8
>
>
> Bounded iteration with non-zero start/end offsets may skip some records in
> intermediate segments. Reproducer (wal compaction should be enabled):
> {noformat}
> /**
> *
> */
> public void testBoundedIterationOverSeveralSegments() throws Exception {
> walCompactionEnabled = true;
> IgniteEx ig = (IgniteEx)startGrid();
> String archiveWalDir = getArchiveWalDirPath(ig);
> ig.cluster().active(true);
> IgniteCache cache = ig.getOrCreateCache(
> new CacheConfiguration<>().setName("c-n").setAffinity(new
> RendezvousAffinityFunction(false, 32)));
> IgniteCacheDatabaseSharedManager sharedMgr =
> ig.context().cache().context().database();
> IgniteWriteAheadLogManager walMgr =
> ig.context().cache().context().wal();
> WALPointer fromPtr = null;
> int recordsCnt = WAL_SEGMENT_SIZE / 8 /* record size */ * 5;
> for (int i = 0; i < recordsCnt; i++) {
> WALPointer ptr = walMgr.log(new PartitionDestroyRecord(i, i));
> if (i == 100)
> fromPtr = ptr;
> }
> assertNotNull(fromPtr);
> cache.put(1, 1);
> forceCheckpoint();
> // Generate WAL segments for filling WAL archive folder.
> for (int i = 0; i < 2 *
> ig.configuration().getDataStorageConfiguration().getWalSegments(); i++) {
> sharedMgr.checkpointReadLock();
> try {
> walMgr.log(new SnapshotRecord(i, false),
> RolloverType.NEXT_SEGMENT);
> }
> finally {
> sharedMgr.checkpointReadUnlock();
> }
> }
> cache.put(2, 2);
> forceCheckpoint();
> U.sleep(5000);
> stopGrid();
> WALIterator it = new IgniteWalIteratorFactory(log)
> .iterator(new
> IteratorParametersBuilder().from((FileWALPointer)fromPtr).filesOrDirs(archiveWalDir));
> TreeSet foundCounters = new TreeSet<>();
> it.forEach(x -> {
> WALRecord rec = x.get2();
> if (rec instanceof PartitionDestroyRecord)
> foundCounters.add(((WalRecordCacheGroupAware)rec).groupId());
> });
> assertEquals(new Integer(100), foundCounters.first());
> assertEquals(new Integer(recordsCnt - 1), foundCounters.last());
> assertEquals(recordsCnt - 100, foundCounters.size());
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9842) IgniteErrorOnRebalanceTest fails: errors in indexing cause grid to stall
[
https://issues.apache.org/jira/browse/IGNITE-9842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev reassigned IGNITE-9842:
---
Assignee: Ilya Kasnacheev
> IgniteErrorOnRebalanceTest fails: errors in indexing cause grid to stall
> -
>
> Key: IGNITE-9842
> URL: https://issues.apache.org/jira/browse/IGNITE-9842
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Minor
>
> https://ci.ignite.apache.org/viewLog.html?buildId=2052100&#testNameId3682030486973860249
> {code}
> org.apache.ignite.IgniteException: Timeout of waiting for topology map update
> [igniteInstanceName=cache.IgniteErrorOnRebalanceTest0, cache=default,
> cacheId=1544803905, topVer=AffinityTopologyVersion [topVer=4, minorTopVer=1],
> p=0, readVer=AffinityTopologyVersion [topVer=4, minorTopVer=1],
> locNode=TcpDiscoveryNode [id=e35c1f95-2e5c-406a-9266-7f6e4360,
> addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47500],
> discPort=47500, order=4, intOrder=3, lastExchangeTime=1539180230507,
> loc=true, ver=2.7.0#20181010-sha1:9d1a551c, isClient=false]]
> at
> org.apache.ignite.internal.processors.cache.IgniteErrorOnRebalanceTest.testErrorOnRebalance(IgniteErrorOnRebalanceTest.java:129)
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9221) Uncomment 25 test classes in various Indexing test suites
[
https://issues.apache.org/jira/browse/IGNITE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-9221:
---
Fix Version/s: 2.8
> Uncomment 25 test classes in various Indexing test suites
> -
>
> Key: IGNITE-9221
> URL: https://issues.apache.org/jira/browse/IGNITE-9221
> Project: Ignite
> Issue Type: Sub-task
> Components: binary, sql
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Fix For: 2.8
>
>
> modules/indexing/src/test/java/org/apache/ignite/testsuites/IgniteCacheQuerySelfTestSuite.java
> {code}
> // suite.addTest(new TestSuite(QueryEntityValidationSelfTest.class));
> // suite.addTest(new TestSuite(GridH2TableSelfTest.class));
> //suite.addTestSuite(IgniteCacheUnionDuplicatesTest.class);
> //suite.addTestSuite(IgniteCacheConfigVariationsQueryTest.class);
>
> //suite.addTestSuite(IgniteCacheJoinPartitionedAndReplicatedCollocationTest.class);
>
> //suite.addTestSuite(IgniteClientReconnectCacheQueriesFailoverTest.class);
> //suite.addTestSuite(IgniteErrorOnRebalanceTest.class);
> //suite.addTestSuite(CacheQueryBuildValueTest.class);
> //suite.addTestSuite(CacheOffheapBatchIndexingMultiTypeTest.class);
> //suite.addTestSuite(CacheOffheapBatchIndexingBaseTest.class);
> //suite.addTestSuite(GridCircularQueueTest.class);
> //suite.addTestSuite(IndexingSpiQueryWithH2IndexingSelfTest.class);
> //suite.addTestSuite(H2DynamicIndexingComplexAbstractTest.class);
>
> //suite.addTestSuite(H2DynamicIndexingComplexClientAtomicPartitionedNoBackupsTest.class);
>
> //suite.addTestSuite(H2DynamicIndexingComplexClientTransactionalPartitionedNoBackupsTest.class);
>
> //suite.addTestSuite(H2DynamicIndexingComplexServerAtomicPartitionedNoBackupsTest.class);
>
> //suite.addTestSuite(H2DynamicIndexingComplexServerTransactionalPartitionedNoBackupsTest.class);
> {code}
> modules/indexing/src/test/java/org/apache/ignite/testsuites/IgniteCacheQuerySelfTestSuite3.java
> {code}
>
> //suite.addTestSuite(CacheContinuousQueryCounterPartitionedAtomicTest.class);
>
> //suite.addTestSuite(CacheContinuousQueryCounterPartitionedTxTest.class);
>
> //suite.addTestSuite(CacheContinuousQueryCounterReplicatedAtomicTest.class);
>
> //suite.addTestSuite(CacheContinuousQueryCounterReplicatedTxTest.class);
>
> //suite.addTestSuite(CacheContinuousQueryFailoverAtomicNearEnabledSelfSelfTest.class);
> {code}
> modules/indexing/src/test/java/org/apache/ignite/testsuites/IgniteBinaryCacheQueryTestSuite.java
> {code}
> //suite.addTestSuite(GridCacheBinarySwapScanQuerySelfTest.class);
> //suite.addTestSuite(IgniteSqlSchemaIndexingTest.class);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9221) Uncomment 25 test classes in various Indexing test suites
[
https://issues.apache.org/jira/browse/IGNITE-9221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668609#comment-16668609
]
ASF GitHub Bot commented on IGNITE-9221:
Github user alamar closed the pull request at:
https://github.com/apache/ignite/pull/4932
> Uncomment 25 test classes in various Indexing test suites
> -
>
> Key: IGNITE-9221
> URL: https://issues.apache.org/jira/browse/IGNITE-9221
> Project: Ignite
> Issue Type: Sub-task
> Components: binary, sql
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Fix For: 2.8
>
>
> modules/indexing/src/test/java/org/apache/ignite/testsuites/IgniteCacheQuerySelfTestSuite.java
> {code}
> // suite.addTest(new TestSuite(QueryEntityValidationSelfTest.class));
> // suite.addTest(new TestSuite(GridH2TableSelfTest.class));
> //suite.addTestSuite(IgniteCacheUnionDuplicatesTest.class);
> //suite.addTestSuite(IgniteCacheConfigVariationsQueryTest.class);
>
> //suite.addTestSuite(IgniteCacheJoinPartitionedAndReplicatedCollocationTest.class);
>
> //suite.addTestSuite(IgniteClientReconnectCacheQueriesFailoverTest.class);
> //suite.addTestSuite(IgniteErrorOnRebalanceTest.class);
> //suite.addTestSuite(CacheQueryBuildValueTest.class);
> //suite.addTestSuite(CacheOffheapBatchIndexingMultiTypeTest.class);
> //suite.addTestSuite(CacheOffheapBatchIndexingBaseTest.class);
> //suite.addTestSuite(GridCircularQueueTest.class);
> //suite.addTestSuite(IndexingSpiQueryWithH2IndexingSelfTest.class);
> //suite.addTestSuite(H2DynamicIndexingComplexAbstractTest.class);
>
> //suite.addTestSuite(H2DynamicIndexingComplexClientAtomicPartitionedNoBackupsTest.class);
>
> //suite.addTestSuite(H2DynamicIndexingComplexClientTransactionalPartitionedNoBackupsTest.class);
>
> //suite.addTestSuite(H2DynamicIndexingComplexServerAtomicPartitionedNoBackupsTest.class);
>
> //suite.addTestSuite(H2DynamicIndexingComplexServerTransactionalPartitionedNoBackupsTest.class);
> {code}
> modules/indexing/src/test/java/org/apache/ignite/testsuites/IgniteCacheQuerySelfTestSuite3.java
> {code}
>
> //suite.addTestSuite(CacheContinuousQueryCounterPartitionedAtomicTest.class);
>
> //suite.addTestSuite(CacheContinuousQueryCounterPartitionedTxTest.class);
>
> //suite.addTestSuite(CacheContinuousQueryCounterReplicatedAtomicTest.class);
>
> //suite.addTestSuite(CacheContinuousQueryCounterReplicatedTxTest.class);
>
> //suite.addTestSuite(CacheContinuousQueryFailoverAtomicNearEnabledSelfSelfTest.class);
> {code}
> modules/indexing/src/test/java/org/apache/ignite/testsuites/IgniteBinaryCacheQueryTestSuite.java
> {code}
> //suite.addTestSuite(GridCacheBinarySwapScanQuerySelfTest.class);
> //suite.addTestSuite(IgniteSqlSchemaIndexingTest.class);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9937) Primary response error info can be lost due to unwrapping a key
[
https://issues.apache.org/jira/browse/IGNITE-9937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668613#comment-16668613
]
Ignite TC Bot commented on IGNITE-9937:
---
{panel:title=No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2198666&buildTypeId=IgniteTests24Java8_RunAll]
> Primary response error info can be lost due to unwrapping a key
> ---
>
> Key: IGNITE-9937
> URL: https://issues.apache.org/jira/browse/IGNITE-9937
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
>
> It can happen when we use SQL DDL to create a table or some dummy values for
> QueryEntity.keyType. Without using Cache API (only SQL), key and value should
> not be deserialized/unwrapped.
> If primary update error happens onPrimaryError call may try to unwrap keys,
> get ClassNotFoundException and hide the original error.
> Here is a stack trace example:
> {code:java}
> Caused by: class org.apache.ignite.binary.BinaryInvalidTypeException:
> TestTableKey
>at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:706)
>at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1755)
>at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:797)
>at
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:143)
>at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:177)
>at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinaryIfNeeded(CacheObjectUtils.java:67)
>at
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:125)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:404)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.onPrimaryResponse(GridNearAtomicUpdateFuture.java:416)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture$1.apply(GridNearAtomicAbstractUpdateFuture.java:303)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture$1.apply(GridNearAtomicAbstractUpdateFuture.java:300)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.map(GridDhtAtomicAbstractUpdateFuture.java:390)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1832)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1633)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.map(GridNearAtomicUpdateFuture.java:812)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapOnTopology(GridNearAtomicUpdateFuture.java:664)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$25.apply(GridDhtAtomicCache.java:1067)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$25.apply(GridDhtAtomicCache.java:1065)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:761)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAll0(GridDhtAtomicCache.java:1065)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putAllConflictAsync(GridDhtAtomicCache.java:687)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putAllConflict(GridDhtAtomicCache.java:680)
>at
> org.apache.ignite.internal.processors.dr.IgniteDrDataStreamerCacheUpdater.receive(IgniteDrDataStreamerCacheUpda
[jira] [Updated] (IGNITE-2049) Add to GridProductVersionSelfTest new tests for new naming strategy
[ https://issues.apache.org/jira/browse/IGNITE-2049?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-2049: Issue Type: Test (was: Bug) > Add to GridProductVersionSelfTest new tests for new naming strategy > --- > > Key: IGNITE-2049 > URL: https://issues.apache.org/jira/browse/IGNITE-2049 > Project: Ignite > Issue Type: Test > Components: general >Affects Versions: 1.5.0.final >Reporter: Alexey Kuznetsov >Priority: Trivial > Labels: newbie > > See > http://apache-ignite-developers.2346864.n4.nabble.com/EA-versioning-td5381.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-2337) SSL & TLS use distinguished name of the certificate (DN)
[ https://issues.apache.org/jira/browse/IGNITE-2337?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-2337: Labels: community (was: community newbie) > SSL & TLS use distinguished name of the certificate (DN) > > > Key: IGNITE-2337 > URL: https://issues.apache.org/jira/browse/IGNITE-2337 > Project: Ignite > Issue Type: New Feature > Components: security >Reporter: Andrey Kartashov >Priority: Major > Labels: community > > Can you add the use of SSLPEERNAME for SslContextFactory parameter to check > distinguished name of the certificate. It is necessary to use certificates > signed by the certification authority. To get rid of certificate exchange. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9298) control.sh does not support SSL (org.apache.ignite.internal.commandline.CommandHandler)
[ https://issues.apache.org/jira/browse/IGNITE-9298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668621#comment-16668621 ] Dmitriy Pavlov commented on IGNITE-9298: [~deviljelly] kindly reminder :) Are you interested in finalizing this contribution? > control.sh does not support SSL > (org.apache.ignite.internal.commandline.CommandHandler) > --- > > Key: IGNITE-9298 > URL: https://issues.apache.org/jira/browse/IGNITE-9298 > Project: Ignite > Issue Type: Bug > Components: clients >Affects Versions: 2.6 >Reporter: Paul Anderson >Assignee: Paul Anderson >Priority: Major > Fix For: 2.8 > > Attachments: Arguments.patch, CommandHandler.patch > > > We required SSL on the connector port and to use control.sh to work with the > baseline configuration. > This morning I added support, see attached patches against 2.6.0 for > org/apache/ignite/internal/commandline/CommandHandler.java > org/apache/ignite/internal/commandline/Arguments.java > No tests, no docs. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10045) Add fail-fast mode to bounded iteration of StandaloneWalRecordsIterator
[ https://issues.apache.org/jira/browse/IGNITE-10045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668624#comment-16668624 ] Alexey Stelmak commented on IGNITE-10045: - TC: https://ci.ignite.apache.org/viewLog.html?buildId=2194724&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_RunAll > Add fail-fast mode to bounded iteration of StandaloneWalRecordsIterator > --- > > Key: IGNITE-10045 > URL: https://issues.apache.org/jira/browse/IGNITE-10045 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Rakov >Assignee: Alexey Stelmak >Priority: Major > Fix For: 2.8 > > > Since IGNITE-9294 StandaloneWalRecordsIterator supports bounded iteration. > That means we can specify "from" and "to" WAL pointers and iterator will > return records only between given bounds. > The problem is that in current implementation StandaloneWalRecordsIterator > just skips segments if they are missing. For example: if we'll specify > fromIdx=0, toIdx = 10 and segments with indexes=[9, 10] will be missing, > we'll just silently finish iteration on idx=8. > To prevent that, we should be able to switch on fail-fast mode, in which > StandaloneWalRecordsIterator will throw error unless iteration is really > started from left bound and ended on right bound. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9769) IgniteCacheAtomicProtocolTest.testPutReaderUpdate1 is flaky
[
https://issues.apache.org/jira/browse/IGNITE-9769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668625#comment-16668625
]
Ilya Lantukh commented on IGNITE-9769:
--
[~SomeFire],
Do we still need changes in IgniteCacheAtomicProtocolTest to resolve this
ticket?
> IgniteCacheAtomicProtocolTest.testPutReaderUpdate1 is flaky
> ---
>
> Key: IGNITE-9769
> URL: https://issues.apache.org/jira/browse/IGNITE-9769
> Project: Ignite
> Issue Type: Task
>Reporter: Ryabov Dmitrii
>Assignee: Ryabov Dmitrii
>Priority: Trivial
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> {{IgniteCacheAtomicProtocolTest.testPutReaderUpdate1}} and
> {{IgniteCacheAtomicProtocolTest.testPutReaderUpdate2}} are flaky.
> In the {{#readerUpdateDhtFails}} method we blocks
> {{GridDhtAtomicNearResponse}} messages and do put operation. Put should hangs
> always, but sometimes it doesn't.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-10062) Ambiguous warn message on binary memory restore and reading Metastore
Maxim Muzafarov created IGNITE-10062: Summary: Ambiguous warn message on binary memory restore and reading Metastore Key: IGNITE-10062 URL: https://issues.apache.org/jira/browse/IGNITE-10062 Project: Ignite Issue Type: Bug Reporter: Maxim Muzafarov Fix For: 2.8 Currently, there is no difference between logging message on restore binary memory and reading Metastore for read-only mode. We have to fix it to avoid ambiguous logging. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10062) Ambiguous warn message on binary memory restore and reading Metastore
[ https://issues.apache.org/jira/browse/IGNITE-10062?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov reassigned IGNITE-10062: Assignee: Maxim Muzafarov > Ambiguous warn message on binary memory restore and reading Metastore > - > > Key: IGNITE-10062 > URL: https://issues.apache.org/jira/browse/IGNITE-10062 > Project: Ignite > Issue Type: Bug >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Minor > Fix For: 2.8 > > > Currently, there is no difference between logging message on restore binary > memory and reading Metastore for read-only mode. > We have to fix it to avoid ambiguous logging. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9848) [TC Bot] Background upload of all builds from TC to the bot DB
[ https://issues.apache.org/jira/browse/IGNITE-9848?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668639#comment-16668639 ] ASF GitHub Bot commented on IGNITE-9848: asfgit closed pull request #54: IGNITE-9848 Chain run report using pre-fetched builds instead of REST-cache URL: https://github.com/apache/ignite-teamcity-bot/pull/54 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > [TC Bot] Background upload of all builds from TC to the bot DB > --- > > Key: IGNITE-9848 > URL: https://issues.apache.org/jira/browse/IGNITE-9848 > Project: Ignite > Issue Type: Task >Reporter: Dmitriy Pavlov >Assignee: Dmitriy Pavlov >Priority: Major > > To fix slow loading of PR report and Master trends page. > Upload all tracked and observed branches related builds into TC Bot's Ignite > DB. > Prepare compacted entities to reduce storage size. > Implement idea of having fat build, which will represent replies from a > number of REST services. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9769) IgniteCacheAtomicProtocolTest.testPutReaderUpdate1 is flaky
[
https://issues.apache.org/jira/browse/IGNITE-9769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668640#comment-16668640
]
Ryabov Dmitrii commented on IGNITE-9769:
[~ilantukh], yes, because we must wait for PME and generate key only after
cache was started.
> IgniteCacheAtomicProtocolTest.testPutReaderUpdate1 is flaky
> ---
>
> Key: IGNITE-9769
> URL: https://issues.apache.org/jira/browse/IGNITE-9769
> Project: Ignite
> Issue Type: Task
>Reporter: Ryabov Dmitrii
>Assignee: Ryabov Dmitrii
>Priority: Trivial
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> {{IgniteCacheAtomicProtocolTest.testPutReaderUpdate1}} and
> {{IgniteCacheAtomicProtocolTest.testPutReaderUpdate2}} are flaky.
> In the {{#readerUpdateDhtFails}} method we blocks
> {{GridDhtAtomicNearResponse}} messages and do put operation. Put should hangs
> always, but sometimes it doesn't.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10062) Ambiguous warn message on binary memory restore and reading Metastore
[ https://issues.apache.org/jira/browse/IGNITE-10062?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668641#comment-16668641 ] ASF GitHub Bot commented on IGNITE-10062: - GitHub user Mmuzaf opened a pull request: https://github.com/apache/ignite/pull/5211 IGNITE-10062: improve logging on binary recovery You can merge this pull request into a Git repository by running: $ git pull https://github.com/Mmuzaf/ignite ignite-10062 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5211.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #5211 commit b6f5e5acec13013ab8b3e35b55980f695f7f9a65 Author: Maxim Muzafarov Date: 2018-10-30T12:27:17Z IGNITE-10062: improve message logging on binary memory recovery commit 9ee45f1ecf16107185681de5aed26522c5e080a3 Author: Maxim Muzafarov Date: 2018-10-30T12:30:05Z Merge branch 'master' into ignite-10062 # Conflicts: # modules/core/src/main/java/org/apache/ignite/internal/processors/cache/persistence/GridCacheDatabaseSharedManager.java commit 9e144c7b46d910b8b68a24602bb0e5f8f2772784 Author: Maxim Muzafarov Date: 2018-10-30T12:31:20Z IGNITE-10062: minor logging changes commit 470fed8b031c49589d415d74bf25ea36b73783bb Author: Maxim Muzafarov Date: 2018-10-30T12:33:05Z IGNITE-10062: fix message style > Ambiguous warn message on binary memory restore and reading Metastore > - > > Key: IGNITE-10062 > URL: https://issues.apache.org/jira/browse/IGNITE-10062 > Project: Ignite > Issue Type: Bug >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Minor > Fix For: 2.8 > > > Currently, there is no difference between logging message on restore binary > memory and reading Metastore for read-only mode. > We have to fix it to avoid ambiguous logging. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9769) IgniteCacheAtomicProtocolTest.testPutReaderUpdate1 is flaky
[
https://issues.apache.org/jira/browse/IGNITE-9769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668642#comment-16668642
]
Ilya Lantukh commented on IGNITE-9769:
--
OK, patch looks good to me. Thanks for the contribution!
> IgniteCacheAtomicProtocolTest.testPutReaderUpdate1 is flaky
> ---
>
> Key: IGNITE-9769
> URL: https://issues.apache.org/jira/browse/IGNITE-9769
> Project: Ignite
> Issue Type: Task
>Reporter: Ryabov Dmitrii
>Assignee: Ryabov Dmitrii
>Priority: Trivial
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> {{IgniteCacheAtomicProtocolTest.testPutReaderUpdate1}} and
> {{IgniteCacheAtomicProtocolTest.testPutReaderUpdate2}} are flaky.
> In the {{#readerUpdateDhtFails}} method we blocks
> {{GridDhtAtomicNearResponse}} messages and do put operation. Put should hangs
> always, but sometimes it doesn't.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10002) MVCC: Create "Cache 2" test suite for MVCC mode.
[ https://issues.apache.org/jira/browse/IGNITE-10002?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668662#comment-16668662 ] Andrew Mashenkov commented on IGNITE-10002: --- Added test suite IgniteCacheMvccTestSuite2. Non-relevant tests were excluded, non-supported cases are muted. New " ~[Excluded] Mvcc Cache 2" suite added on TC. > MVCC: Create "Cache 2" test suite for MVCC mode. > > > Key: IGNITE-10002 > URL: https://issues.apache.org/jira/browse/IGNITE-10002 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Andrew Mashenkov >Assignee: Andrew Mashenkov >Priority: Major > > Create MVCC version of IgniteCacheTestSuite2 and add it to TC. > All non-relevant tests should be marked as ignored. > Failed tests should be muted and tickets should be created for unknown > failure reasons. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10052) Restart node during TX causes vacuum error
[
https://issues.apache.org/jira/browse/IGNITE-10052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-10052:
--
Priority: Blocker (was: Major)
> Restart node during TX causes vacuum error
> --
>
> Key: IGNITE-10052
> URL: https://issues.apache.org/jira/browse/IGNITE-10052
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Assignee: Andrew Mashenkov
>Priority: Blocker
> Fix For: 2.7
>
>
> 1. Start 2 nodes with PDS, activate , start {{sqlline}}
> 2. Create table
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> create table t1 (a int, b int, primary
> key(a)) with "atomicity=TRANSACTIONAL_SNAPSHOT,
> backups=1";
> No rows affected (0,294 seconds)
> {noformat}
> 3. Open TX:
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> begin;
> No rows affected (0,007 seconds)
> 0: jdbc:ignite:thin://127.0.0.1/> insert into t1 values (1,1);
> 1 row affected (0,112 seconds)
> {noformat}
> 4. Stop and then start 2nd node
> 5. Rollback TX and check the table data (no rows added):
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> rollback;
> No rows affected (0,011 seconds)
> 0: jdbc:ignite:thin://127.0.0.1/> select * from t1;
> +++
> | A| B|
> +++
> +++
> No rows selected (0,067 seconds)
> {noformat}
> 6. Start second TX that throws the exception:
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> begin;
> No rows affected (0,001 seconds)
> 0: jdbc:ignite:thin://127.0.0.1/> insert into t1 values (1,1);
> Error: Failed to run update. Runtime failure on bounds:
> [lower=MvccMaxSearchRow [], upper=MvccMinSearchRow []] (state=50
> 000,code=1)
> java.sql.SQLException: Failed to run update. Runtime failure on bounds:
> [lower=MvccMaxSearchRow [], upper=MvccMinSearchR
> ow []]
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> 0: jdbc:ignite:thin://127.0.0.1/>
> {noformat}
> The server nodes print out:
> {noformat}
> [18:46:32,136][SEVERE][jdbc-request-handler-worker-#62][DmlStatementsProcessor]
> Error during update [localNodeId=319a2fda-1315-4bdf-8647-7ddee2d3342e]
> class org.apache.ignite.IgniteCheckedException: Runtime failure on bounds:
> [lower=MvccMaxSearchRow [], upper=MvccMinSearchRow []]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.visit(BPlusTree.java:1061)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:1919)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.mvccUpdate(GridCacheOffheapManager.java:1840)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:530)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.mvccSet(GridCacheMapEntry.java:1104)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.continueLoop(GridDhtTxAbstractEnlistFuture.java:460)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.init(GridDhtTxAbstractEnlistFuture.java:368)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processNearTxQueryResultsEnlistRequest(GridDhtTransactionalCacheAdapter.java:2000)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$700(GridDhtTransactionalCacheAdapter.java:112)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$12.apply(GridDhtTransactionalCacheAdapter.java:215)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$12.apply(GridDhtTransactionalCacheAdapter.java:213)
> at
> org.apache.ignite.internal.processors.cache.GridCache
[jira] [Updated] (IGNITE-10052) Restart node during TX causes vacuum error
[
https://issues.apache.org/jira/browse/IGNITE-10052?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-10052:
--
Ignite Flags: (was: Docs Required)
> Restart node during TX causes vacuum error
> --
>
> Key: IGNITE-10052
> URL: https://issues.apache.org/jira/browse/IGNITE-10052
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Assignee: Andrew Mashenkov
>Priority: Blocker
> Fix For: 2.7
>
>
> 1. Start 2 nodes with PDS, activate , start {{sqlline}}
> 2. Create table
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> create table t1 (a int, b int, primary
> key(a)) with "atomicity=TRANSACTIONAL_SNAPSHOT,
> backups=1";
> No rows affected (0,294 seconds)
> {noformat}
> 3. Open TX:
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> begin;
> No rows affected (0,007 seconds)
> 0: jdbc:ignite:thin://127.0.0.1/> insert into t1 values (1,1);
> 1 row affected (0,112 seconds)
> {noformat}
> 4. Stop and then start 2nd node
> 5. Rollback TX and check the table data (no rows added):
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> rollback;
> No rows affected (0,011 seconds)
> 0: jdbc:ignite:thin://127.0.0.1/> select * from t1;
> +++
> | A| B|
> +++
> +++
> No rows selected (0,067 seconds)
> {noformat}
> 6. Start second TX that throws the exception:
> {noformat}
> 0: jdbc:ignite:thin://127.0.0.1/> begin;
> No rows affected (0,001 seconds)
> 0: jdbc:ignite:thin://127.0.0.1/> insert into t1 values (1,1);
> Error: Failed to run update. Runtime failure on bounds:
> [lower=MvccMaxSearchRow [], upper=MvccMinSearchRow []] (state=50
> 000,code=1)
> java.sql.SQLException: Failed to run update. Runtime failure on bounds:
> [lower=MvccMaxSearchRow [], upper=MvccMinSearchR
> ow []]
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:750)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:212)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:475)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.begin(SqlLine.java:668)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> 0: jdbc:ignite:thin://127.0.0.1/>
> {noformat}
> The server nodes print out:
> {noformat}
> [18:46:32,136][SEVERE][jdbc-request-handler-worker-#62][DmlStatementsProcessor]
> Error during update [localNodeId=319a2fda-1315-4bdf-8647-7ddee2d3342e]
> class org.apache.ignite.IgniteCheckedException: Runtime failure on bounds:
> [lower=MvccMaxSearchRow [], upper=MvccMinSearchRow []]
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.visit(BPlusTree.java:1061)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:1919)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.mvccUpdate(GridCacheOffheapManager.java:1840)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.mvccUpdate(IgniteCacheOffheapManagerImpl.java:530)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.mvccSet(GridCacheMapEntry.java:1104)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.continueLoop(GridDhtTxAbstractEnlistFuture.java:460)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxAbstractEnlistFuture.init(GridDhtTxAbstractEnlistFuture.java:368)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processNearTxQueryResultsEnlistRequest(GridDhtTransactionalCacheAdapter.java:2000)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.access$700(GridDhtTransactionalCacheAdapter.java:112)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$12.apply(GridDhtTransactionalCacheAdapter.java:215)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter$12.apply(GridDhtTransactionalCacheAdapter.java:213)
> at
> org.apache.ignite.internal.processors.cache.Grid
[jira] [Updated] (IGNITE-7164) SQL TX: Remap protocol
[ https://issues.apache.org/jira/browse/IGNITE-7164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-7164: - Fix Version/s: 2.8 > SQL TX: Remap protocol > -- > > Key: IGNITE-7164 > URL: https://issues.apache.org/jira/browse/IGNITE-7164 > Project: Ignite > Issue Type: Task > Components: mvcc, sql >Reporter: Igor Seliverstov >Assignee: Andrew Mashenkov >Priority: Major > Fix For: 2.8 > > > We need to provide remap protocol on topology changes -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9893) add hibernate-5.2 module
[ https://issues.apache.org/jira/browse/IGNITE-9893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668680#comment-16668680 ] Ilya Kasnacheev commented on IGNITE-9893: - [~scottmf] Does it make sense to include hibernate 5.2 when 5.3 is already out? I ask this because we can only ship hibernate 5.2 as a part of Ignite 2.8 now, and it will not be out until 2019. Will not hibernate 5.2 irrelevant by then? Everybody will be wanting 5.3. I have checked your code with 5.3 and it seems there are massive SPI changes. Maybe you could fix it to support 5.3? Is support of 5.3 even feasible? If not, we could reconsider 5.2. Your patch seems to be somewhat behind master, by the way - there are compilation errors. > add hibernate-5.2 module > > > Key: IGNITE-9893 > URL: https://issues.apache.org/jira/browse/IGNITE-9893 > Project: Ignite > Issue Type: New Feature > Components: hibernate >Reporter: Scott Feldstein >Priority: Major > > hi, > I have ported hibernate-5.2 to ignite 2.7.0-SNAPSHOT HEAD. > commit: > [https://github.com/scottmf/ignite/commit/4f2caafb8c433e3f840d14f91c2d83da1052afd9] > All tests pass except > CacheHibernateBlobStoreSelfTest.testSimpleMultithreading which is carryover > from the hibernate-5.1 implementation. There is a bug already associated with > the failure: > https://issues.apache.org/jira/browse/IGNITE-1757 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10048) Bounded iteration in standalone WAL iterator with compaction enabled may skip records
[
https://issues.apache.org/jira/browse/IGNITE-10048?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668693#comment-16668693
]
Ignite TC Bot commented on IGNITE-10048:
{panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Direct IO) 2{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2200459]]
* IgnitePdsNativeIoTestSuite2: IgniteWalIteratorExceptionDuringReadTest.test -
0,0% fails in last 100 master runs.
{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests
5|https://ci.ignite.apache.org/viewLog.html?buildId=2200461]]
* ZookeeperDiscoverySpiTestSuite2: GridEventConsumeSelfTest.testEventsByFilter
- 1,0% fails in last 100 master runs.
{color:#d04437}PDS 2{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2200463]]
* IgnitePdsTestSuite2: IgniteWalIteratorExceptionDuringReadTest.test - 0,0%
fails in last 100 master runs.
{panel}
[TeamCity Run All
Results|http://ci.ignite.apache.org/viewLog.html?buildId=2193103&buildTypeId=IgniteTests24Java8_RunAll]
> Bounded iteration in standalone WAL iterator with compaction enabled may skip
> records
> -
>
> Key: IGNITE-10048
> URL: https://issues.apache.org/jira/browse/IGNITE-10048
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Rakov
>Assignee: Ivan Rakov
>Priority: Major
> Fix For: 2.8
>
>
> Bounded iteration with non-zero start/end offsets may skip some records in
> intermediate segments. Reproducer (wal compaction should be enabled):
> {noformat}
> /**
> *
> */
> public void testBoundedIterationOverSeveralSegments() throws Exception {
> walCompactionEnabled = true;
> IgniteEx ig = (IgniteEx)startGrid();
> String archiveWalDir = getArchiveWalDirPath(ig);
> ig.cluster().active(true);
> IgniteCache cache = ig.getOrCreateCache(
> new CacheConfiguration<>().setName("c-n").setAffinity(new
> RendezvousAffinityFunction(false, 32)));
> IgniteCacheDatabaseSharedManager sharedMgr =
> ig.context().cache().context().database();
> IgniteWriteAheadLogManager walMgr =
> ig.context().cache().context().wal();
> WALPointer fromPtr = null;
> int recordsCnt = WAL_SEGMENT_SIZE / 8 /* record size */ * 5;
> for (int i = 0; i < recordsCnt; i++) {
> WALPointer ptr = walMgr.log(new PartitionDestroyRecord(i, i));
> if (i == 100)
> fromPtr = ptr;
> }
> assertNotNull(fromPtr);
> cache.put(1, 1);
> forceCheckpoint();
> // Generate WAL segments for filling WAL archive folder.
> for (int i = 0; i < 2 *
> ig.configuration().getDataStorageConfiguration().getWalSegments(); i++) {
> sharedMgr.checkpointReadLock();
> try {
> walMgr.log(new SnapshotRecord(i, false),
> RolloverType.NEXT_SEGMENT);
> }
> finally {
> sharedMgr.checkpointReadUnlock();
> }
> }
> cache.put(2, 2);
> forceCheckpoint();
> U.sleep(5000);
> stopGrid();
> WALIterator it = new IgniteWalIteratorFactory(log)
> .iterator(new
> IteratorParametersBuilder().from((FileWALPointer)fromPtr).filesOrDirs(archiveWalDir));
> TreeSet foundCounters = new TreeSet<>();
> it.forEach(x -> {
> WALRecord rec = x.get2();
> if (rec instanceof PartitionDestroyRecord)
> foundCounters.add(((WalRecordCacheGroupAware)rec).groupId());
> });
> assertEquals(new Integer(100), foundCounters.first());
> assertEquals(new Integer(recordsCnt - 1), foundCounters.last());
> assertEquals(recordsCnt - 100, foundCounters.size());
> }
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9937) Primary response error info can be lost due to unwrapping a key
[
https://issues.apache.org/jira/browse/IGNITE-9937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16668696#comment-16668696
]
Ilya Kasnacheev commented on IGNITE-9937:
-
[~guseinov] I suggest an alternative take:
{code}
+keys.add(cctx.toCacheKeyObject(key));
{code}
I have checked other uses of this exception, and they all do this instead of
.unwrapBinaryIfNeeded().
> Primary response error info can be lost due to unwrapping a key
> ---
>
> Key: IGNITE-9937
> URL: https://issues.apache.org/jira/browse/IGNITE-9937
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.6
>Reporter: Roman Guseinov
>Assignee: Roman Guseinov
>Priority: Major
>
> It can happen when we use SQL DDL to create a table or some dummy values for
> QueryEntity.keyType. Without using Cache API (only SQL), key and value should
> not be deserialized/unwrapped.
> If primary update error happens onPrimaryError call may try to unwrap keys,
> get ClassNotFoundException and hide the original error.
> Here is a stack trace example:
> {code:java}
> Caused by: class org.apache.ignite.binary.BinaryInvalidTypeException:
> TestTableKey
>at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:706)
>at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1755)
>at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
>at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:797)
>at
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:143)
>at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:177)
>at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinaryIfNeeded(CacheObjectUtils.java:67)
>at
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:125)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:404)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.onPrimaryResponse(GridNearAtomicUpdateFuture.java:416)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture$1.apply(GridNearAtomicAbstractUpdateFuture.java:303)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture$1.apply(GridNearAtomicAbstractUpdateFuture.java:300)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicAbstractUpdateFuture.map(GridDhtAtomicAbstractUpdateFuture.java:390)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1832)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1633)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:299)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.map(GridNearAtomicUpdateFuture.java:812)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.mapOnTopology(GridNearAtomicUpdateFuture.java:664)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:248)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$25.apply(GridDhtAtomicCache.java:1067)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$25.apply(GridDhtAtomicCache.java:1065)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.asyncOp(GridDhtAtomicCache.java:761)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAll0(GridDhtAtomicCache.java:1065)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putAllConflictAsync(GridDhtAtomicCache.java:687)
>at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.putAllConflict(GridDhtAtomicCache.java:680)
>at
> org.apache.ignite.internal.processors.dr.IgniteDrDataStreamerCacheUpdater.receive(IgniteDrDataStreamerCacheUpdater.j
[jira] [Created] (IGNITE-10063) MVCC SQL: Tx SQL commands are not supported in multistatements
Ivan Pavlukhin created IGNITE-10063:
---
Summary: MVCC SQL: Tx SQL commands are not supported in
multistatements
Key: IGNITE-10063
URL: https://issues.apache.org/jira/browse/IGNITE-10063
Project: Ignite
Issue Type: Bug
Reporter: Ivan Pavlukhin
Is is possible to execute multiple statements in single JDBC call like:
{code:sql}UPDATE t1 SET b = '2'; COMMIT{code}
Currently tx commands fail to execute if passed in such multistatement. Tx
commands are e.g. {{BEGIN}}, {{COMMIT}}, {{ROLLBACK}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9893) add hibernate-5.2 module
[ https://issues.apache.org/jira/browse/IGNITE-9893?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Pavlov reassigned IGNITE-9893: -- Assignee: Scott Feldstein > add hibernate-5.2 module > > > Key: IGNITE-9893 > URL: https://issues.apache.org/jira/browse/IGNITE-9893 > Project: Ignite > Issue Type: New Feature > Components: hibernate >Reporter: Scott Feldstein >Assignee: Scott Feldstein >Priority: Major > > hi, > I have ported hibernate-5.2 to ignite 2.7.0-SNAPSHOT HEAD. > commit: > [https://github.com/scottmf/ignite/commit/4f2caafb8c433e3f840d14f91c2d83da1052afd9] > All tests pass except > CacheHibernateBlobStoreSelfTest.testSimpleMultithreading which is carryover > from the hibernate-5.1 implementation. There is a bug already associated with > the failure: > https://issues.apache.org/jira/browse/IGNITE-1757 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10063) MVCC SQL: Tx SQL commands are not supported in multistatements
[
https://issues.apache.org/jira/browse/IGNITE-10063?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin updated IGNITE-10063:
Fix Version/s: 2.8
Component/s: mvcc
> MVCC SQL: Tx SQL commands are not supported in multistatements
> --
>
> Key: IGNITE-10063
> URL: https://issues.apache.org/jira/browse/IGNITE-10063
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.8
>
>
> Is is possible to execute multiple statements in single JDBC call like:
> {code:sql}UPDATE t1 SET b = '2'; COMMIT{code}
> Currently tx commands fail to execute if passed in such multistatement. Tx
> commands are e.g. {{BEGIN}}, {{COMMIT}}, {{ROLLBACK}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9897) Quering with PDO returns null for all column values except the 1st one
[
https://issues.apache.org/jira/browse/IGNITE-9897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-9897:
Description:
Using _odbc_connect_ returns all column values, but with _PDO_ only the 1st one
– all the rest are null.
Reproduced on CentOS.
# Start a server node with Ignite CPP
# Run odbc-example (which will create two tables)
# Run a simple PHP script
{{setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);}}
{{ $sql = 'SELECT * FROM "Person".Person';}}
{{ $data = $dbh->query($sql);}}
{{ foreach($data as $row) {}}
{{ var_export($row);}}
{{ echo PHP_EOL,PHP_EOL,"# Using odbc_*( ) Functions",PHP_EOL;}}
{{ $conn = odbc_connect('ApacheIgnite','','');}}
{{ $rs = odbc_exec($conn, $sql);}}
{{ while($row = odbc_fetch_array($rs)){}}
{{ var_export($row);}}
{{ } }}
{{} catch (PDOException $e) {}}
{{ print "Error!: " . $e->getMessage() . "\n";}}
{{ die();}}
{{}}}
{{?>}}
was:
Using _odbc_connect_ returns all column values, but with _PDO_ only the 1st one
– all the rest are null.
Reproduced on CentOS.
# Start a server node with Ignite CPP
# Run odbc-example (which will create two tables)
# Run a simple PHP script
{{setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);}}
{{ $sql = 'SELECT * FROM "Person".Person';}}
{{ $data = $dbh->query($sql);}}
{{ foreach($data as $row) {}}
{{ var_export($row);}}
{{ echo PHP_EOL,PHP_EOL,"# Using odbc_*( ) Functions",PHP_EOL;}}
{{ $conn = odbc_connect('ApacheIgnite','','');}}
{{ $rs = odbc_exec($conn, $sql);}}
{{ while($row = odbc_fetch_array($rs)){}}
{{ var_export($row);}}
{{ \} }}
{{} catch (PDOException $e) {}}
{{ print "Error!: " . $e->getMessage() . "\n";}}
{{ die();}}
{{}}}
{{?>}}
> Quering with PDO returns null for all column values except the 1st one
> --
>
> Key: IGNITE-9897
> URL: https://issues.apache.org/jira/browse/IGNITE-9897
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.6
> Environment: CentOS
>Reporter: Roman Shtykh
>Assignee: Igor Sapego
>Priority: Major
>
> Using _odbc_connect_ returns all column values, but with _PDO_ only the 1st
> one – all the rest are null.
> Reproduced on CentOS.
> # Start a server node with Ignite CPP
> # Run odbc-example (which will create two tables)
> # Run a simple PHP script
> {{ {{try {}}
> {{ echo PHP_EOL,PHP_EOL,"# Using PDO",PHP_EOL;}}
> {{ $dbh = new PDO('odbc:ApacheIgnite');}}
> {{ $dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);}}
> {{ $sql = 'SELECT * FROM "Person".Person';}}
> {{ $data = $dbh->query($sql);}}
> {{ foreach($data as $row) {}}
> {{ var_export($row);}}
> {{ echo PHP_EOL,PHP_EOL,"# Using odbc_*( ) Functions",PHP_EOL;}}
> {{ $conn = odbc_connect('ApacheIgnite','','');}}
> {{ $rs = odbc_exec($conn, $sql);}}
> {{ while($row = odbc_fetch_array($rs)){}}
> {{ var_export($row);}}
> {{ } }}
> {{} catch (PDOException $e) {}}
> {{ print "Error!: " . $e->getMessage() . "\n";}}
> {{ die();}}
> {{}}}
> {{?>}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9897) Quering with PDO returns null for all column values except the 1st one
[
https://issues.apache.org/jira/browse/IGNITE-9897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego updated IGNITE-9897:
Description:
Using _odbc_connect_ returns all column values, but with _PDO_ only the 1st one
– all the rest are null.
Reproduced on CentOS.
# Start a server node with Ignite CPP
# Run odbc-example (which will create two tables)
# Run a simple PHP script
{{setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);}}
{{ $sql = 'SELECT * FROM "Person".Person';}}
{{ $data = $dbh->query($sql);}}
{{ foreach($data as $row) {}}
{{ var_export($row);}}
{{ echo PHP_EOL,PHP_EOL,"# Using odbc_*( ) Functions",PHP_EOL;}}
{{ $conn = odbc_connect('ApacheIgnite','','');}}
{{ $rs = odbc_exec($conn, $sql);}}
{{ while($row = odbc_fetch_array($rs)){}}
{{ var_export($row);}}
{{ \} }}
{{} catch (PDOException $e) {}}
{{ print "Error!: " . $e->getMessage() . "\n";}}
{{ die();}}
{{}}}
{{?>}}
was:
Using _odbc_connect_ returns all column values, but with _PDO_ only the 1st one
– all the rest are null.
Reproduced on CentOS.
# Start a server node with Ignite CPP
# Run odbc-example (which will create two tables)
# Run a simple PHP script
{{setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);}}
{{ $sql = 'SELECT * FROM "Person".Person';}}
{{ $data = $dbh->query($sql);}}
{{ foreach($data as $row) {}}
{{ var_export($row);}}
{{ echo PHP_EOL,PHP_EOL,"# Using odbc_*( ) Functions",PHP_EOL;}}
{{ $conn = odbc_connect('ApacheIgnite','','');}}
{{ $rs = odbc_exec($conn, $sql);}}
{{ while($row = odbc_fetch_array($rs)){}}
{{ var_export($row);}}
{{} catch (PDOException $e) {}}
{{ print "Error!: " . $e->getMessage() . "\n";}}
{{ die();}}
{{}}}
{{?>}}
> Quering with PDO returns null for all column values except the 1st one
> --
>
> Key: IGNITE-9897
> URL: https://issues.apache.org/jira/browse/IGNITE-9897
> Project: Ignite
> Issue Type: Bug
> Components: odbc
>Affects Versions: 2.6
> Environment: CentOS
>Reporter: Roman Shtykh
>Assignee: Igor Sapego
>Priority: Major
>
> Using _odbc_connect_ returns all column values, but with _PDO_ only the 1st
> one – all the rest are null.
> Reproduced on CentOS.
> # Start a server node with Ignite CPP
> # Run odbc-example (which will create two tables)
> # Run a simple PHP script
> {{ {{try {}}
> {{ echo PHP_EOL,PHP_EOL,"# Using PDO",PHP_EOL;}}
> {{ $dbh = new PDO('odbc:ApacheIgnite');}}
> {{ $dbh->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);}}
> {{ $sql = 'SELECT * FROM "Person".Person';}}
> {{ $data = $dbh->query($sql);}}
> {{ foreach($data as $row) {}}
> {{ var_export($row);}}
> {{ echo PHP_EOL,PHP_EOL,"# Using odbc_*( ) Functions",PHP_EOL;}}
> {{ $conn = odbc_connect('ApacheIgnite','','');}}
> {{ $rs = odbc_exec($conn, $sql);}}
> {{ while($row = odbc_fetch_array($rs)){}}
> {{ var_export($row);}}
> {{ \} }}
> {{} catch (PDOException $e) {}}
> {{ print "Error!: " . $e->getMessage() . "\n";}}
> {{ die();}}
> {{}}}
> {{?>}}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
