[jira] [Comment Edited] (IGNITE-10444) MVCC: CacheMvccTxFastFinishTest fails.
[ https://issues.apache.org/jira/browse/IGNITE-10444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16751131#comment-16751131 ] Ivan Pavlukhin edited comment on IGNITE-10444 at 1/25/19 8:25 AM: -- Checked that failure reproduces on https://github.com/apache/ignite/commit/4ea443ceffa4445003aa5c8448017eb430cedff3 >From the first glance test in question checks prepare and finish futures at >specific stages of transaction execution. Perhaps, difference in flows makes >assertions invalid for MVCC transactions. was (Author: pavlukhin): Checked that failure reproduces on https://github.com/apache/ignite/commit/4ea443ceffa4445003aa5c8448017eb430cedff3 > MVCC: CacheMvccTxFastFinishTest fails. > -- > > Key: IGNITE-10444 > URL: https://issues.apache.org/jira/browse/IGNITE-10444 > Project: Ignite > Issue Type: Bug > Components: mvcc >Reporter: Andrew Mashenkov >Priority: Major > > Seems, read-only transaction doesn't creates prepare\finish future as classic > tx do. > Let's check correct invariants in mvcc version of CacheTxFastFinishTest test. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10451) .NET: Persistence does not work with custom affinity function
[
https://issues.apache.org/jira/browse/IGNITE-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752021#comment-16752021
]
Ignite TC Bot commented on IGNITE-10451:
{panel:title=--> Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache (Restarts) 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2903047]]
* IgniteCacheRestartTestSuite:
GridCachePartitionedNodeRestartTest.testRestartWithTxTwoNodesOneBackup - 0,3%
fails in last 396 master runs.
{color:#d04437}MVCC Queries{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=2903035]]
* IgniteCacheMvccSqlTestSuite:
CacheMvccPartitionedSqlTxQueriesTest.testAccountsTxDmlSql_WithRemoves_SingleNode_Persistence
- 0,0% fails in last 418 master runs.
{color:#d04437}Data Structures{color} [[tests
130|https://ci.ignite.apache.org/viewLog.html?buildId=2903062]]
* IgniteCacheDataStructuresSelfTestSuite:
GridCachePartitionedQueueCreateMultiNodeSelfTest.testTx - 0,0% fails in last
420 master runs.
* IgniteCacheDataStructuresSelfTestSuite:
GridCachePartitionedAtomicQueueCreateMultiNodeSelfTest.testQueueCreation - 0,0%
fails in last 420 master runs.
* IgniteCacheDataStructuresSelfTestSuite:
IgnitePartitionedQueueNoBackupsTest.testCollocation - 0,0% fails in last 420
master runs.
* IgniteCacheDataStructuresSelfTestSuite:
GridCachePartitionedQueueApiSelfTest.testCollectionMethods - 0,0% fails in last
420 master runs.
* IgniteCacheDataStructuresSelfTestSuite:
IgnitePartitionedQueueNoBackupsTest.testPutRemovePeekPollUnbounded - 0,0% fails
in last 420 master runs.
* IgniteCacheDataStructuresSelfTestSuite:
GridCachePartitionedQueueApiSelfTest.testPutGetUnbounded - 0,0% fails in last
420 master runs.
* IgniteCacheDataStructuresSelfTestSuite:
IgnitePartitionedQueueNoBackupsTest.testAddUnbounded - 0,0% fails in last 420
master runs.
* IgniteCacheDataStructuresSelfTestSuite:
IgnitePartitionedQueueNoBackupsTest.testPutGetMultithreadBounded - 0,0% fails
in last 420 master runs.
* IgniteCacheDataStructuresSelfTestSuite:
IgnitePartitionedQueueNoBackupsTest.testAffinityRun - 0,0% fails in last 420
master runs.
* IgniteCacheDataStructuresSelfTestSuite:
IgnitePartitionedQueueNoBackupsTest.testAffinityCall - 0,0% fails in last 420
master runs.
* IgniteCacheDataStructuresSelfTestSuite:
GridCachePartitionedQueueApiSelfTest.testReuseCache - 0,0% fails in last 420
master runs.
* IgniteCacheDataStructuresSelfTestSuite:
GridCachePartitionedQueueApiSelfTest.testAddDeleteUnbounded - 0,0% fails in
last 420 master runs.
* IgniteCacheDataStructuresSelfTestSuite:
GridCachePartitionedQueueApiSelfTest.testMultipleStructuresInDifferentGroups -
0,0% fails in last 420 master runs.
* IgniteCacheDataStructuresSelfTestSuite:
GridCachePartitionedQueueApiSelfTest.testRemovePeek - 0,0% fails in last 420
master runs.
* IgniteCacheDataStructuresSelfTestSuite:
GridCachePartitionedQueueApiSelfTest.testAddPollUnbounded - 0,0% fails in last
420 master runs.
* IgniteCacheDataStructuresSelfTestSuite:
GridCachePartitionedAtomicQueueApiSelfTest.testNotReuseCache - 0,0% fails in
last 420 master runs.
* IgniteCacheDataStructuresSelfTestSuite:
GridCachePartitionedQueueApiSelfTest.testIteratorCollocated - 0,0% fails in
last 420 master runs.
* IgniteCacheDataStructuresSelfTestSuite:
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithPutTenNodesTwoBackups
- 0,0% fails in last 420 master runs.
* IgniteCacheDataStructuresSelfTestSuite:
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithPutFourNodesNoBackups
- 0,0% fails in last 420 master runs.
* IgniteCacheDataStructuresSelfTestSuite:
GridCachePartitionedQueueApiSelfTest.testPutRemoveMultiThreadedUnbounded - 0,0%
fails in last 420 master runs.
* IgniteCacheDataStructuresSelfTestSuite:
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithTxPutAllTenNodesTwoBackups
- 0,0% fails in last 420 master runs.
* IgniteCacheDataStructuresSelfTestSuite:
GridCachePartitionedQueueApiSelfTest.testIsolation - 0,0% fails in last 420
master runs.
* IgniteCacheDataStructuresSelfTestSuite:
GridCachePartitionedQueueApiSelfTest.testPutRemoveUnbounded - 0,0% fails in
last 420 master runs.
* IgniteCacheDataStructuresSelfTestSuite:
GridCachePartitionedQueueApiSelfTest.testQueueRemoveMultithreadBounded - 0,0%
fails in last 420 master runs.
* IgniteCacheDataStructuresSelfTestSuite:
GridCachePartitionedQueueApiSelfTest.testNotReuseCache - 0,0% fails in last 420
master runs.
* IgniteCacheDataStructuresSelfTestSuite:
GridCachePartitionedQueueApiSelfTest.testPutGetMultithreadUnbounded - 0,0%
fails in last 420 master runs.
* IgniteCacheDataStructuresSelfTestSuite:
IgniteCacheAtomicReplicatedNodeRestartSelfTest.testRestartWithPutEightNodesTwoBackups
- 0,0% fails in last 420 master runs.
* IgniteCacheDataStructuresSelfTestSuite:
GridCacheP
[jira] [Assigned] (IGNITE-10455) MVCC: Tx timeout can cause update counters inconsistency.
[
https://issues.apache.org/jira/browse/IGNITE-10455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Pavlukhin reassigned IGNITE-10455:
---
Assignee: Ivan Pavlukhin
> MVCC: Tx timeout can cause update counters inconsistency.
> --
>
> Key: IGNITE-10455
> URL: https://issues.apache.org/jira/browse/IGNITE-10455
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Labels: mvcc_stabilization_stage_1, transactions
> Fix For: 2.8
>
>
> When transaction is rolled back on backup on prepare step, it could lead to
> update counters inconsistency between primary and backup. We need to fix
> backup counters update.
> Reproducer: {{TxWithSmallTimeoutAndContentionOneKeyTest#test}} with enabled
> MVCC.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10305) SQL: Optimize query execution if it targets only one or none partitions
[
https://issues.apache.org/jira/browse/IGNITE-10305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752024#comment-16752024
]
Ignite TC Bot commented on IGNITE-10305:
{panel:title=--> Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2884340&buildTypeId=IgniteTests24Java8_RunAll]
> SQL: Optimize query execution if it targets only one or none partitions
> ---
>
> Key: IGNITE-10305
> URL: https://issues.apache.org/jira/browse/IGNITE-10305
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Lapin
>Priority: Major
> Labels: iep-24
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is a part of "Partition Pruning" IEP [1].
> Currently we try to extract partitions from map queries and route requests
> accordingly. Several problems with this approach:
> 1) Individual map queries may target the same partition, but we never know
> that, so we may want to setup a merge table when it is not really needed.
> 2) Sometimes query may reduce to no partitions. In this case we should not
> execute anything at all and simply return empty result set.
> 3) If the whole query targets only one partition, we may skip the whole
> splitter phase!
> I propose to do the following:
> # Try to extract partition from "original" query.
> # If we see that exactly one partition is involved, then original query is a
> map query, and reduce should be performed in "skip merge table" mode
> # If we see that there are no partitions because query is invalid (e.g. {{id
> = 1 AND id = 2}}), then stop and return no results. This decision should be
> cached in two-step plan.
> # If we see that there are some partitions, then we should apply arguments
> and see the result. If result set is empty - return, but do not cache empty
> result set decision, as it may change for another set of arguments.
> # If none of above hold, then do pushdowns and split, and analyze partitions
> of individual map queries. For those of them where partition set is empty, we
> should return empty result set without executing anything.
> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-24%3A+SQL+Partition+Pruning
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9927) Fix flaky failures in CacheContinuousQueryOperationFromCallbackTest
[
https://issues.apache.org/jira/browse/IGNITE-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752020#comment-16752020
]
Ignite TC Bot commented on IGNITE-9927:
---
{panel:title=--> Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Spring{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=2899073]]
* GridServiceInjectionSpringResourceTest.testDeployServiceWithSpring (last
started)
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2896511&buildTypeId=IgniteTests24Java8_RunAll]
> Fix flaky failures in CacheContinuousQueryOperationFromCallbackTest
> ---
>
> Key: IGNITE-9927
> URL: https://issues.apache.org/jira/browse/IGNITE-9927
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: CQ, mvcc_stabilization_stage_1
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This test was reworked significantly as a part of IGNITE-7953. Unfortunately
> it led to a number of failures appearing from time to time. The goal of this
> ticket is to get rid of these failures.
> Changes from {{51a202a4c48220fa919f47147bd4889033cd35a8}} commit should be
> applied to the test before starting investigation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-9927) Fix flaky failures in CacheContinuousQueryOperationFromCallbackTest
[
https://issues.apache.org/jira/browse/IGNITE-9927?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752025#comment-16752025
]
Roman Kondakov commented on IGNITE-9927:
[~gvvinblade], patch is ready for review. Tests look good. Spring suite is not
a blocker - the same problems exist in the master branch.
> Fix flaky failures in CacheContinuousQueryOperationFromCallbackTest
> ---
>
> Key: IGNITE-9927
> URL: https://issues.apache.org/jira/browse/IGNITE-9927
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Vladimir Ozerov
>Assignee: Roman Kondakov
>Priority: Major
> Labels: CQ, mvcc_stabilization_stage_1
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This test was reworked significantly as a part of IGNITE-7953. Unfortunately
> it led to a number of failures appearing from time to time. The goal of this
> ticket is to get rid of these failures.
> Changes from {{51a202a4c48220fa919f47147bd4889033cd35a8}} commit should be
> applied to the test before starting investigation.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10451) .NET: Persistence does not work with custom affinity function
[
https://issues.apache.org/jira/browse/IGNITE-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Govorukhin updated IGNITE-10451:
Fix Version/s: 2.8
> .NET: Persistence does not work with custom affinity function
> -
>
> Key: IGNITE-10451
> URL: https://issues.apache.org/jira/browse/IGNITE-10451
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> To reproduce: assign custom affinity function in
> {{PersistenceTest.TestCacheDataSurvivesNodeRestart}}.
> As a result, node restart fails with the following exception:
> {code}
> Apache.Ignite.Core.Common.IgniteException : An error occurred during cache
> configuration loading from file
> [file=C:\Users\tps0\AppData\Local\Temp\Ignite_ihxso0zq.tw0\Store\node00-263cfb5e-ec70-4378-8cbb-62b6fcc8043b\cache-persistentCache\cache_data.dat]
> > Apache.Ignite.Core.Common.JavaException : class
> org.apache.ignite.IgniteException: An error occurred during cache
> configuration loading from file
> [file=C:\Users\tps0\AppData\Local\Temp\Ignite_ihxso0zq.tw0\Store\node00-263cfb5e-ec70-4378-8cbb-62b6fcc8043b\cache-persistentCache\cache_data.dat]
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1027)
> at
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:48)
> at
> org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:74)
> Caused by: class org.apache.ignite.IgniteCheckedException: An error occurred
> during cache configuration loading from file
> [file=C:\Users\tps0\AppData\Local\Temp\Ignite_ihxso0zq.tw0\Store\node00-263cfb5e-ec70-4378-8cbb-62b6fcc8043b\cache-persistentCache\cache_data.dat]
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:902)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheConfigurations(FilePageStoreManager.java:844)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.addCacheOnJoinFromConfig(GridCacheProcessor.java:891)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.restoreCacheConfigurations(GridCacheProcessor.java:756)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1300(GridCacheProcessor.java:204)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.onReadyForRead(GridCacheProcessor.java:5456)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:412)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:724)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:4473)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1047)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2040)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1732)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:656)
> at
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
> ... 1 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> deserialize object with given class loader:
> sun.misc.Launcher$AppClassLoader@18b4aac2
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:147)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:93)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:898)
> ... 15 more
> Caused by: java.lang.IllegalArgumentException: Ignite instance name thread
> local must be set or this method should be accessed under
> org.apache.ignite.thread.IgniteThread
> at
> org.apache.ignite.internal.IgnitionEx.localIgnite(IgnitionEx.java:1413)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.threadLocalContext(GridBinaryMarshaller.java:398)
>
[jira] [Commented] (IGNITE-10451) .NET: Persistence does not work with custom affinity function
[
https://issues.apache.org/jira/browse/IGNITE-10451?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752030#comment-16752030
]
Dmitriy Govorukhin commented on IGNITE-10451:
-
[~ptupitsyn] Looks good to me, please proceed to merge if TC status is OK.
> .NET: Persistence does not work with custom affinity function
> -
>
> Key: IGNITE-10451
> URL: https://issues.apache.org/jira/browse/IGNITE-10451
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Time Spent: 10m
> Remaining Estimate: 0h
>
> To reproduce: assign custom affinity function in
> {{PersistenceTest.TestCacheDataSurvivesNodeRestart}}.
> As a result, node restart fails with the following exception:
> {code}
> Apache.Ignite.Core.Common.IgniteException : An error occurred during cache
> configuration loading from file
> [file=C:\Users\tps0\AppData\Local\Temp\Ignite_ihxso0zq.tw0\Store\node00-263cfb5e-ec70-4378-8cbb-62b6fcc8043b\cache-persistentCache\cache_data.dat]
> > Apache.Ignite.Core.Common.JavaException : class
> org.apache.ignite.IgniteException: An error occurred during cache
> configuration loading from file
> [file=C:\Users\tps0\AppData\Local\Temp\Ignite_ihxso0zq.tw0\Store\node00-263cfb5e-ec70-4378-8cbb-62b6fcc8043b\cache-persistentCache\cache_data.dat]
> at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:1027)
> at
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:48)
> at
> org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:74)
> Caused by: class org.apache.ignite.IgniteCheckedException: An error occurred
> during cache configuration loading from file
> [file=C:\Users\tps0\AppData\Local\Temp\Ignite_ihxso0zq.tw0\Store\node00-263cfb5e-ec70-4378-8cbb-62b6fcc8043b\cache-persistentCache\cache_data.dat]
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:902)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheConfigurations(FilePageStoreManager.java:844)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.addCacheOnJoinFromConfig(GridCacheProcessor.java:891)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.restoreCacheConfigurations(GridCacheProcessor.java:756)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.access$1300(GridCacheProcessor.java:204)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor$CacheRecoveryLifecycle.onReadyForRead(GridCacheProcessor.java:5456)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:412)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:724)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:4473)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1047)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2040)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1732)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:656)
> at
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
> ... 1 more
> Caused by: class org.apache.ignite.IgniteCheckedException: Failed to
> deserialize object with given class loader:
> sun.misc.Launcher$AppClassLoader@18b4aac2
> at
> org.apache.ignite.marshaller.jdk.JdkMarshaller.unmarshal0(JdkMarshaller.java:147)
> at
> org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:93)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.readCacheData(FilePageStoreManager.java:898)
> ... 15 more
> Caused by: java.lang.IllegalArgumentException: Ignite instance name thread
> local must be set or this method should be accessed under
> org.apache.ignite.thread.IgniteThread
> at
> org.apache.ignite.internal.IgnitionEx.localIgnite(IgnitionEx.java:1413)
> at
> org.apache.ignite.interna
[jira] [Updated] (IGNITE-10649) Add documentation for control.sh about SSL
[
https://issues.apache.org/jira/browse/IGNITE-10649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-10649:
Description:
Control.sh help output:
{noformat}
Control.sh is used to execute admin commands on cluster or get common cluster
info. The command has the following syntax:
control.sh [--host HOST_OR_IP] [--port PORT] [--user USER] [--password
PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout PING_TIMEOUT]
[--ssl-protocol SSL_PROTOCOL[, SSL_PROTOCOL_2, ..., SSL_PROTOCOL_N]]
[--ssl-cipher-suites SSL_CIPHER_1[, SSL_CIPHER_2, ..., SSL_CIPHER_N]]
[--ssl-key-algorithm SSL_KEY_ALGORITHM] [--keystore-type KEYSTORE_TYPE]
[--keystore KEYSTORE_PATH] [--keystore-password KEYSTORE_PASSWORD]
[--truststore-type TRUSTSTORE_TYPE] [--truststore TRUSTSTORE_PATH]
[--truststore-password TRUSTSTORE_PASSWORD] [command]
This utility can do the following commands:
Activate cluster:
control.sh --activate
Deactivate cluster:
control.sh --deactivate [--yes]
Print current cluster state:
control.sh --state
Print cluster baseline topology:
control.sh --baseline
Add nodes into baseline topology:
control.sh --baseline add consistentId1[,consistentId2,,consistentIdN]
[--yes]
Remove nodes from baseline topology:
control.sh --baseline remove consistentId1[,consistentId2,,consistentIdN]
[--yes]
Set baseline topology:
control.sh --baseline set consistentId1[,consistentId2,,consistentIdN]
[--yes]
Set baseline topology based on version:
control.sh --baseline version topologyVersion [--yes]
List or kill transactions:
control.sh --tx [--xid XID] [--min-duration SECONDS] [--min-size SIZE] [--label
PATTERN_REGEX] [--servers|--clients] [--nodes
consistentId1[,consistentId2,,consistentIdN]] [--limit NUMBER] [--order
DURATION|SIZE|START_TIME] [--kill] [--yes]
Print absolute paths of unused archived wal segments on each node:
control.sh --wal print [consistentId1,consistentId2,,consistentIdN]
Delete unused archived wal segments on each node:
control.sh --wal delete [consistentId1,consistentId2,,consistentIdN] [--yes]
View caches information in a cluster. For more details type:
control.sh --cache help
By default commands affecting the cluster require interactive confirmation.
Use --yes option to disable it.
Default values:
HOST_OR_IP=127.0.0.1
PORT=11211
PING_INTERVAL=5000
PING_TIMEOUT=3
SSL_PROTOCOL=TLS
SSL_KEY_ALGORITHM=SunX509
KEYSTORE_TYPE=JKS
TRUSTSTORE_TYPE=JKS
Exit codes:
0 - successful execution.
1 - invalid arguments.
2 - connection failed.
3 - authentication failed.
4 - unexpected error.{noformat}
> Add documentation for control.sh about SSL
> --
>
> Key: IGNITE-10649
> URL: https://issues.apache.org/jira/browse/IGNITE-10649
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
>
> Control.sh help output:
> {noformat}
> Control.sh is used to execute admin commands on cluster or get common cluster
> info. The command has the following syntax:
> control.sh [--host HOST_OR_IP] [--port PORT] [--user USER] [--password
> PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout PING_TIMEOUT]
> [--ssl-protocol SSL_PROTOCOL[, SSL_PROTOCOL_2, ..., SSL_PROTOCOL_N]]
> [--ssl-cipher-suites SSL_CIPHER_1[, SSL_CIPHER_2, ..., SSL_CIPHER_N]]
> [--ssl-key-algorithm SSL_KEY_ALGORITHM] [--keystore-type KEYSTORE_TYPE]
> [--keystore KEYSTORE_PATH] [--keystore-password KEYSTORE_PASSWORD]
> [--truststore-type TRUSTSTORE_TYPE] [--truststore TRUSTSTORE_PATH]
> [--truststore-password TRUSTSTORE_PASSWORD] [command]
> This utility can do the following commands:
> Activate cluster:
> control.sh --activate
> Deactivate cluster:
> control.sh --deactivate [--yes]
> Print current cluster state:
> control.sh --state
> Print cluster baseline topology:
> control.sh --baseline
> Add nodes into baseline topology:
> control.sh --baseline add consistentId1[,consistentId2,,consistentIdN]
> [--yes]
> Remove nodes from baseline topology:
> control.sh --baseline remove consistentId1[,consistentId2,,consistentIdN]
> [--yes]
> Set baseline topology:
> control.sh --baseline set consistentId1[,consistentId2,,consistentIdN]
> [--yes]
> Set baseline topology based on version:
> control.sh --baseline version topologyVersion [--yes]
> List or kill transactions:
> control.sh --tx [--xid XID] [--min-duration SECONDS] [--min-size SIZE]
> [--label PATTERN_REGEX] [--servers|--clients] [--nodes
> consistentId1[,consistentId2,,consistentIdN]] [--limit NUMBER] [--order
> DURATION|SIZE|START_TIME] [--kill] [--yes]
> Print absolute paths of unused archived wal segments on each node:
> control.sh --wal print [consistentId1,consistentId2,,consistentIdN]
> Delete unused archived wal segments
[jira] [Assigned] (IGNITE-8841) MVCC TX: Read transactions remap when coordinator fails.
[ https://issues.apache.org/jira/browse/IGNITE-8841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Seliverstov reassigned IGNITE-8841: Assignee: Igor Seliverstov > MVCC TX: Read transactions remap when coordinator fails. > > > Key: IGNITE-8841 > URL: https://issues.apache.org/jira/browse/IGNITE-8841 > Project: Ignite > Issue Type: Bug > Components: mvcc, sql >Reporter: Roman Kondakov >Assignee: Igor Seliverstov >Priority: Major > Labels: failover > > At the moment read transactions that don't acquire topology lock will be > forcibly rolled back on topology change as read tx can be in fly while > topology being change. > This is done to prevent having active transaction with stale snapshots on > new topology in cases of TX coordinator or Near node were lost. > > It would be nice to remap it somehow until they locked a topology or at least > throw some meaningful exception to user. > For example, it is possible to obtain a new "write" mvcc version from the > new coordinator and use this version for all further writes while using "old" > version for reads. In this case we need to change visibility rules a little: > "old" version should see "own" updates made by "new" "write" version. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11076) Add documentation for control.sh idle_verify --exclude-caches
Sergey Antonov created IGNITE-11076:
---
Summary: Add documentation for control.sh idle_verify
--exclude-caches
Key: IGNITE-11076
URL: https://issues.apache.org/jira/browse/IGNITE-11076
Project: Ignite
Issue Type: Task
Components: documentation
Reporter: Sergey Antonov
Assignee: Artem Budnikov
Fix For: 2.8
control.sh cache --help output
{noformat}
The '--cache subcommand' is used to get information about and perform actions
with caches. The command has the following syntax:
control.sh [--host HOST_OR_IP] [--port PORT] [--user USER] [--password
PASSWORD] [--ping-interval PING_INTERVAL] [--ping-timeout PING_TIMEOUT]
[--ssl-protocol SSL_PROTOCOL[, SSL_PROTOCOL_2, ..., SSL_PROTOCOL_N]]
[--ssl-cipher-suites SSL_CIPHER_1[, SSL_CIPHER_2, ..., SSL_CIPHER_N]]
[--ssl-key-algorithm SSL_KEY_ALGORITHM] [--keystore-type KEYSTORE_TYPE]
[--keystore KEYSTORE_PATH] [--keystore-password KEYSTORE_PASSWORD]
[--truststore-type TRUSTSTORE_TYPE] [--truststore TRUSTSTORE_PATH]
[--truststore-password TRUSTSTORE_PASSWORD] --cache [subcommand]
The subcommands that take [nodeId] as an argument ('list', 'contention' and
'validate_indexes') will be executed on the given node or on all server nodes
if the option is not specified. Other commands will run on a random server node.
Subcommands:
--cache list regexPattern [--groups|--seq] [nodeId] [--config] [--output-format
multi-line]
Show information about caches, groups or sequences that match a regular
expression. When executed without parameters, this subcommand prints the list
of caches.
Parameters:
--config - print all configuration parameters for each cache.
--output-format multi-line - print configuration parameters per line. This
option has effect only when used with --config and without [--groups|--seq].
--groups - print information about groups.
--seq - print information about sequences.
--cache contention minQueueSize [nodeId] [maxPrint]
Show the keys that are point of contention for multiple transactions.
--cache idle_verify [--dump] [--skip-zeros] [--check-crc] [(--exclude-caches
cacheName1,...,cacheNameN)|(--cache-filter
ALL|SYSTEM|PERSISTENT|NOT_PERSISTENT)|cacheName1,...,cacheNameN]
Verify counters and hash sums of primary and backup partitions for the
specified caches on an idle cluster and print out the differences, if any.
Parameters:
--check-crc - check the CRC-sum of pages stored on disk before verifying data
consistency in partitions between primary and backup nodes.
--cache validate_indexes [cacheName1,...,cacheNameN] [nodeId] [--check-first
N|--check-through K]
Validate indexes on an idle cluster and print out the keys that are missing in
the indexes.
Parameters:
--check-first N - validate only the first N keys
--check-through K - validate every Kth key
--cache distribution nodeId|null [cacheName1,...,cacheNameN] [--user-attributes
attrName1,...,attrNameN]
Prints the information about partition distribution.
--cache reset_lost_partitions cacheName1,...,cacheNameN
Reset the state of lost partitions for the specified caches.{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-10865) [ML] [Umbrella] Integration with Spark ML
[ https://issues.apache.org/jira/browse/IGNITE-10865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev updated IGNITE-10865: -- Priority: Critical (was: Major) > [ML] [Umbrella] Integration with Spark ML > - > > Key: IGNITE-10865 > URL: https://issues.apache.org/jira/browse/IGNITE-10865 > Project: Ignite > Issue Type: New Feature > Components: ml >Affects Versions: 2.8 >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Critical > Fix For: 2.8 > > > Investigate how to load ML models from Spark -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11039) [ML] Add parser for Spark Decision tree regression
[ https://issues.apache.org/jira/browse/IGNITE-11039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev updated IGNITE-11039: -- Priority: Blocker (was: Major) > [ML] Add parser for Spark Decision tree regression > -- > > Key: IGNITE-11039 > URL: https://issues.apache.org/jira/browse/IGNITE-11039 > Project: Ignite > Issue Type: Sub-task > Components: ml >Affects Versions: 2.8 >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Blocker > Fix For: 2.8 > > > # Write Spark example producing Decision Tree Regressor > # Save model to parquet file > # Parse parquet file > # Add an example -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11037) [ML] Add parser for Spark KMeans clustering model
[ https://issues.apache.org/jira/browse/IGNITE-11037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev updated IGNITE-11037: -- Priority: Blocker (was: Major) > [ML] Add parser for Spark KMeans clustering model > - > > Key: IGNITE-11037 > URL: https://issues.apache.org/jira/browse/IGNITE-11037 > Project: Ignite > Issue Type: Sub-task > Components: ml >Affects Versions: 2.8 >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Blocker > Fix For: 2.8 > > > # Write Spark example producing KMeans clustering model > # Save model to parquet file > # Parse parquet file > # Add an example -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11040) [ML] Add parser for Spark Random forest regressor
[ https://issues.apache.org/jira/browse/IGNITE-11040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev updated IGNITE-11040: -- Priority: Blocker (was: Major) > [ML] Add parser for Spark Random forest regressor > - > > Key: IGNITE-11040 > URL: https://issues.apache.org/jira/browse/IGNITE-11040 > Project: Ignite > Issue Type: Sub-task > Components: ml >Affects Versions: 2.8 >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Blocker > Fix For: 2.8 > > > # Write Spark example producing Random Forest regressor > # Save model to parquet file > # Parse parquet file > # Add an example -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10865) [ML] [Umbrella] Integration with Spark ML
[ https://issues.apache.org/jira/browse/IGNITE-10865?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev updated IGNITE-10865: -- Priority: Blocker (was: Critical) > [ML] [Umbrella] Integration with Spark ML > - > > Key: IGNITE-10865 > URL: https://issues.apache.org/jira/browse/IGNITE-10865 > Project: Ignite > Issue Type: New Feature > Components: ml >Affects Versions: 2.8 >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Blocker > Fix For: 2.8 > > > Investigate how to load ML models from Spark -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11041) [ML] Add parser for Spark Gradient-boosted tree regressor
[ https://issues.apache.org/jira/browse/IGNITE-11041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev updated IGNITE-11041: -- Priority: Blocker (was: Major) > [ML] Add parser for Spark Gradient-boosted tree regressor > - > > Key: IGNITE-11041 > URL: https://issues.apache.org/jira/browse/IGNITE-11041 > Project: Ignite > Issue Type: Sub-task > Components: ml >Affects Versions: 2.8 >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Blocker > Fix For: 2.8 > > > # Write Spark example producing Gradient-boosted tree regressor > # Save model to parquet file > # Parse parquet file > # Add an example -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11012) [ML] Add model type validation during parsing parquet file
[ https://issues.apache.org/jira/browse/IGNITE-11012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev updated IGNITE-11012: -- Priority: Blocker (was: Major) > [ML] Add model type validation during parsing parquet file > -- > > Key: IGNITE-11012 > URL: https://issues.apache.org/jira/browse/IGNITE-11012 > Project: Ignite > Issue Type: Sub-task > Components: ml >Affects Versions: 2.8 >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Blocker > Fix For: 2.8 > > > After resolving ignite path, check special field in parquet file to validate > apropriate model loading. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11005) [ML] Add parser for Spark Gradient-boosted tree classifier
[ https://issues.apache.org/jira/browse/IGNITE-11005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Zinoviev updated IGNITE-11005: -- Priority: Blocker (was: Major) > [ML] Add parser for Spark Gradient-boosted tree classifier > -- > > Key: IGNITE-11005 > URL: https://issues.apache.org/jira/browse/IGNITE-11005 > Project: Ignite > Issue Type: Sub-task > Components: ml >Affects Versions: 2.8 >Reporter: Aleksey Zinoviev >Assignee: Aleksey Zinoviev >Priority: Blocker > > # Write Spark example producing Gradient-boosted tree classifier model > # Save model to parquet file > # Parse parquet file > # Add an example -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10976) MVCC: Sql API methods should throws proper TransactionExceptions in case of tx failure.
[
https://issues.apache.org/jira/browse/IGNITE-10976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752078#comment-16752078
]
Ignite TC Bot commented on IGNITE-10976:
{panel:title=--> Run :: All: Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform C++ (Win x64 | Release){color} [[tests 2
BuildFailureOnMessage
|https://ci.ignite.apache.org/viewLog.html?buildId=2900560]]
* IgniteCoreTest: CacheQueryTestSuite: TestFieldsQueryPagesSeveral - 4,1% fails
in last 844 master runs.
* IgniteCoreTest: CacheQueryTestSuite: TestFieldsQuerySeveral - 4,1% fails in
last 844 master runs.
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2899549&buildTypeId=IgniteTests24Java8_RunAll]
> MVCC: Sql API methods should throws proper TransactionExceptions in case of
> tx failure.
> ---
>
> Key: IGNITE-10976
> URL: https://issues.apache.org/jira/browse/IGNITE-10976
> Project: Ignite
> Issue Type: Bug
> Components: mvcc, sql
>Reporter: Andrew Mashenkov
>Assignee: Andrew Mashenkov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> For now Sql API can throws SqlException (without any actual Tx failure cause)
> or TransactionException wrapped into CacheException.
> Also, I've found we convert unchecked exceptions into checked ones and then
> back without any obvious reason.
> Let's make TransactionException thows properly and add it to Sql Api contract.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10305) SQL: Optimize query execution if it targets only one or none partitions
[
https://issues.apache.org/jira/browse/IGNITE-10305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752085#comment-16752085
]
Alexander Lapin commented on IGNITE-10305:
--
Ready for review, but not for merge, cause there's still no visa.
> SQL: Optimize query execution if it targets only one or none partitions
> ---
>
> Key: IGNITE-10305
> URL: https://issues.apache.org/jira/browse/IGNITE-10305
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Lapin
>Priority: Major
> Labels: iep-24
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is a part of "Partition Pruning" IEP [1].
> Currently we try to extract partitions from map queries and route requests
> accordingly. Several problems with this approach:
> 1) Individual map queries may target the same partition, but we never know
> that, so we may want to setup a merge table when it is not really needed.
> 2) Sometimes query may reduce to no partitions. In this case we should not
> execute anything at all and simply return empty result set.
> 3) If the whole query targets only one partition, we may skip the whole
> splitter phase!
> I propose to do the following:
> # Try to extract partition from "original" query.
> # If we see that exactly one partition is involved, then original query is a
> map query, and reduce should be performed in "skip merge table" mode
> # If we see that there are no partitions because query is invalid (e.g. {{id
> = 1 AND id = 2}}), then stop and return no results. This decision should be
> cached in two-step plan.
> # If we see that there are some partitions, then we should apply arguments
> and see the result. If result set is empty - return, but do not cache empty
> result set decision, as it may change for another set of arguments.
> # If none of above hold, then do pushdowns and split, and analyze partitions
> of individual map queries. For those of them where partition set is empty, we
> should return empty result set without executing anything.
> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-24%3A+SQL+Partition+Pruning
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11059) Print information about pending locks queue in case of dht local tx timeout.
[ https://issues.apache.org/jira/browse/IGNITE-11059?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy reassigned IGNITE-11059: - Assignee: Ivan Daschinskiy > Print information about pending locks queue in case of dht local tx timeout. > > > Key: IGNITE-11059 > URL: https://issues.apache.org/jira/browse/IGNITE-11059 > Project: Ignite > Issue Type: Improvement >Reporter: Alexei Scherbakov >Assignee: Ivan Daschinskiy >Priority: Major > Labels: newbie > Fix For: 2.8 > > > Currently in case of dht local tx timeout it's hard to understand which keys > was not locked. > Addtional information should be printed in log on timeout containing > information about pending keys: > key, tx info holding a lock (xid, label if present) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11034) Web console: update some dependencies
[ https://issues.apache.org/jira/browse/IGNITE-11034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-11034: -- Assignee: Alexander Kalinin (was: Ilya Borisov) > Web console: update some dependencies > - > > Key: IGNITE-11034 > URL: https://issues.apache.org/jira/browse/IGNITE-11034 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Alexander Kalinin >Priority: Minor > Original Estimate: 3h > Time Spent: 2h > Remaining Estimate: 1h > > We need to update: > 1. AngularJS to latest 1.7 release (1.7.6) in order to support lazy module > loading. > 2. typescript-eslint-parser has been deprecated in a favor of it's fork, see > details [here|https://eslint.org/blog/2019/01/future-typescript-eslint]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-11034) Web console: update some dependencies
[ https://issues.apache.org/jira/browse/IGNITE-11034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-11034: -- Assignee: Ilya Borisov (was: Alexander Kalinin) > Web console: update some dependencies > - > > Key: IGNITE-11034 > URL: https://issues.apache.org/jira/browse/IGNITE-11034 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Minor > Original Estimate: 3h > Time Spent: 2h > Remaining Estimate: 1h > > We need to update: > 1. AngularJS to latest 1.7 release (1.7.6) in order to support lazy module > loading. > 2. typescript-eslint-parser has been deprecated in a favor of it's fork, see > details [here|https://eslint.org/blog/2019/01/future-typescript-eslint]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10305) SQL: Optimize query execution if it targets only one or none partitions
[
https://issues.apache.org/jira/browse/IGNITE-10305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752085#comment-16752085
]
Alexander Lapin edited comment on IGNITE-10305 at 1/25/19 9:59 AM:
---
[~vozerov] All fixed.
Ready for review, but not for merge, cause there's still no visa.
was (Author: alapin):
Ready for review, but not for merge, cause there's still no visa.
> SQL: Optimize query execution if it targets only one or none partitions
> ---
>
> Key: IGNITE-10305
> URL: https://issues.apache.org/jira/browse/IGNITE-10305
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Alexander Lapin
>Priority: Major
> Labels: iep-24
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> This is a part of "Partition Pruning" IEP [1].
> Currently we try to extract partitions from map queries and route requests
> accordingly. Several problems with this approach:
> 1) Individual map queries may target the same partition, but we never know
> that, so we may want to setup a merge table when it is not really needed.
> 2) Sometimes query may reduce to no partitions. In this case we should not
> execute anything at all and simply return empty result set.
> 3) If the whole query targets only one partition, we may skip the whole
> splitter phase!
> I propose to do the following:
> # Try to extract partition from "original" query.
> # If we see that exactly one partition is involved, then original query is a
> map query, and reduce should be performed in "skip merge table" mode
> # If we see that there are no partitions because query is invalid (e.g. {{id
> = 1 AND id = 2}}), then stop and return no results. This decision should be
> cached in two-step plan.
> # If we see that there are some partitions, then we should apply arguments
> and see the result. If result set is empty - return, but do not cache empty
> result set decision, as it may change for another set of arguments.
> # If none of above hold, then do pushdowns and split, and analyze partitions
> of individual map queries. For those of them where partition set is empty, we
> should return empty result set without executing anything.
> [1]
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-24%3A+SQL+Partition+Pruning
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-10980) CPP: Create TC suite for Windows 64 Debug mode
[ https://issues.apache.org/jira/browse/IGNITE-10980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego closed IGNITE-10980. > CPP: Create TC suite for Windows 64 Debug mode > -- > > Key: IGNITE-10980 > URL: https://issues.apache.org/jira/browse/IGNITE-10980 > Project: Ignite > Issue Type: Task > Components: platforms >Affects Versions: 2.7 >Reporter: Igor Sapego >Assignee: Peter Ivanov >Priority: Major > Labels: cpp > > Currently, there is a [Platform C++ (Windows > x64)|https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PlatformCWindowsX64&tab=buildTypeStatusDiv&branch_IgniteTests24Java8=__all_branches__] > suite, which builds and runs tests in Release mode. It's OK, as we need to > test Release mode in the first place, as this is the mode, in which user uses > Ignite C++. But we also need to run tests in Debug mode, as in debug > additional errors (such as heap corruption and memory leaks) can be detected. > So it is proposed to rename "Platform C++ (Windows x64)" test suite to > "Platform C++ (Windows x64 Release)" and add another suite "Platform C++ > (Windows x64 Debug)", which will build and run tests in Debug mode. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10183) [Test Failed] IgniteClientReconnectCacheTest.testReconnectOperationInProgress flaky fails on TC.
[
https://issues.apache.org/jira/browse/IGNITE-10183?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752114#comment-16752114
]
Ivan Pavlukhin commented on IGNITE-10183:
-
[~rkondakov] well if result check becomes complex then it might not be a good
idea. Perhaps we still can make an improvement. I noticed that retry for MVCC
operations was already employed in number of places. May be we can extract
_operation with retry_ into common place?
Anyway it looks like that patch fixes the issue and can be merged.
> [Test Failed] IgniteClientReconnectCacheTest.testReconnectOperationInProgress
> flaky fails on TC.
>
>
> Key: IGNITE-10183
> URL: https://issues.apache.org/jira/browse/IGNITE-10183
> Project: Ignite
> Issue Type: Bug
> Components: cache, mvcc
>Affects Versions: 2.7
>Reporter: Pavel Pereslegin
>Assignee: Roman Kondakov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, failover,
> mvcc_stabilization_stage_1
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> IgniteClientReconnectCacheTest.testReconnectOperationInProgress fails
> sometimes in master (see [recent failures on
> TC|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&buildTypeId=&tab=testDetails&testNameId=-1285534571845460301&order=TEST_STATUS_DESC&branch_IgniteTests24Java8=%3Cdefault%3E&itemsCount=50]).
> Test fails only for cache with {{TRANSACTIONAL_SNAPSHOT}} atomicity mode.
> Typical output:
> {noformat}
> [2018-11-07 23:13:00,579][ERROR][main][root] Test failed.
> class org.apache.ignite.IgniteCheckedException: class
> org.apache.ignite.transactions.TransactionRollbackException: Transaction has
> been rolled back: 2e10370f661--0920-4f4e--0026
> at org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7425)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:261)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:191)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.checkOperationInProgressFails(IgniteClientReconnectCacheTest.java:1421)
> at
> org.apache.ignite.internal.IgniteClientReconnectCacheTest.testReconnectOperationInProgress(IgniteClientReconnectCacheTest.java:869)
> 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:2208)
> 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: javax.cache.CacheException: class
> org.apache.ignite.transactions.TransactionRollbackException: Transaction has
> been rolled back: 2e10370f661--0920-4f4e--0026
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1337)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1756)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1108)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:820)
> at
> org.apache.ignite.internal.IgniteClientReconnectCacheTest$10.apply(IgniteClientReconnectCacheTest.java:834)
> at
> org.apache.ignite.internal.IgniteClientReconnectCacheTest$10.apply(IgniteClientReconnectCacheTest.java:832)
> at
> org.apache.ignite.internal.IgniteClientReconnectCacheTest$25.call(IgniteClientReconnectCacheTest.java:1406)
> at
> org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$2(GridTestUtils.java:1003)
> at
> org.apache.ignite.testframework.GridTestUtils$7.call(GridTestUtils.java:1299)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84)
> Caused by: class org.apache.ignite.transactions.TransactionRollbackException:
> Transaction has been rolled back:
> 2e10370f661--0920-4f4e--0026
> at
> org.apache.ignite.internal.util.IgniteUtils$11.apply(
[jira] [Commented] (IGNITE-11034) Web console: update some dependencies
[ https://issues.apache.org/jira/browse/IGNITE-11034?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752107#comment-16752107 ] Alexander Kalinin commented on IGNITE-11034: [~Klaster_1] I've ipdated dependencies. Please review. > Web console: update some dependencies > - > > Key: IGNITE-11034 > URL: https://issues.apache.org/jira/browse/IGNITE-11034 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Minor > Original Estimate: 3h > Time Spent: 2h > Remaining Estimate: 1h > > We need to update: > 1. AngularJS to latest 1.7 release (1.7.6) in order to support lazy module > loading. > 2. typescript-eslint-parser has been deprecated in a favor of it's fork, see > details [here|https://eslint.org/blog/2019/01/future-typescript-eslint]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10764) MVCC: Transactions failed to acquire lock within timeout
[
https://issues.apache.org/jira/browse/IGNITE-10764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752116#comment-16752116
]
Ivan Pavlukhin commented on IGNITE-10764:
-
TC run of the suite containing problematic the test.
> MVCC: Transactions failed to acquire lock within timeout
>
>
> Key: IGNITE-10764
> URL: https://issues.apache.org/jira/browse/IGNITE-10764
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Labels: mvcc_stabilization_stage_1, transactions
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some tests failed sporadically due to a transaction timeout though they
> update unique keys and deadlocks are not expected. It should be investigated.
> Reproducers:
> {{CacheMvccPartitionedSqlTxQueriesTest.testQueryInsertMultithread}}
> {{CacheMvccReplicatedSqlTxQueriesTest.testQueryInsertMultithread}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-10764) MVCC: Transactions failed to acquire lock within timeout
[
https://issues.apache.org/jira/browse/IGNITE-10764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752116#comment-16752116
]
Ivan Pavlukhin edited comment on IGNITE-10764 at 1/25/19 10:12 AM:
---
TC run of the suite containing the problematic test
https://ci.ignite.apache.org/viewLog.html?buildId=2893878&buildTypeId=IgniteTests24Java8_MvccQueries&tab=buildResultsDiv&branch_IgniteTests24Java8=pull%2F5910%2Fhead
was (Author: pavlukhin):
TC run of the suite containing problematic the test.
> MVCC: Transactions failed to acquire lock within timeout
>
>
> Key: IGNITE-10764
> URL: https://issues.apache.org/jira/browse/IGNITE-10764
> Project: Ignite
> Issue Type: Bug
> Components: mvcc
>Reporter: Roman Kondakov
>Assignee: Ivan Pavlukhin
>Priority: Major
> Labels: mvcc_stabilization_stage_1, transactions
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Some tests failed sporadically due to a transaction timeout though they
> update unique keys and deadlocks are not expected. It should be investigated.
> Reproducers:
> {{CacheMvccPartitionedSqlTxQueriesTest.testQueryInsertMultithread}}
> {{CacheMvccReplicatedSqlTxQueriesTest.testQueryInsertMultithread}}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11078) MVCC: Tests fails sporadically with ConcurrentModificationException
Andrew Mashenkov created IGNITE-11078:
-
Summary: MVCC: Tests fails sporadically with
ConcurrentModificationException
Key: IGNITE-11078
URL: https://issues.apache.org/jira/browse/IGNITE-11078
Project: Ignite
Issue Type: Test
Components: mvcc
Reporter: Andrew Mashenkov
Next test failed on TC.
[CacheMvccReplicatedSqlCoordinatorFailoverTest.testCoordinatorChangeActiveQueryClientFails_Simple|https://ci.ignite.apache.org/viewLog.html?buildId=2902796&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_MvccQueries#testNameId3071204292938919018]
See TC run for details:
[TC
run|https://ci.ignite.apache.org/viewLog.html?buildId=2902796&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_MvccQueries#testNameId3071204292938919018]
Stacktrace example:
{code:java}
java.util.ConcurrentModificationException
at java.util.HashMap$HashIterator.nextNode(HashMap.java:1442)
at java.util.HashMap$KeyIterator.next(HashMap.java:1466)
at java.util.AbstractCollection.toString(AbstractCollection.java:461)
at java.lang.String.valueOf(String.java:2994)
at java.lang.StringBuilder.append(StringBuilder.java:131)
at
java.util.concurrent.ConcurrentHashMap.toString(ConcurrentHashMap.java:1321)
at java.lang.String.valueOf(String.java:2994)
at java.lang.StringBuilder.append(StringBuilder.java:131)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$12.apply(CacheMvccAbstractTest.java:1757)
at
org.apache.ignite.testframework.GridTestUtils.waitForCondition(GridTestUtils.java:1682)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest.checkActiveQueriesCleanup(CacheMvccAbstractTest.java:1750)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractBasicCoordinatorFailoverTest.checkCoordinatorChangeActiveQueryClientFails_Simple(CacheMvccAbstractBasicCoordinatorFailoverTest.java:689)
at
org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractSqlCoordinatorFailoverTest.testCoordinatorChangeActiveQueryClientFails_Simple(CacheMvccAbstractSqlCoordinatorFailoverTest.java:164)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
at java.lang.Thread.run(Thread.java:748)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11078) MVCC: Tests fails sporadically with ConcurrentModificationException
[
https://issues.apache.org/jira/browse/IGNITE-11078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11078:
--
Ignite Flags: (was: Docs Required)
> MVCC: Tests fails sporadically with ConcurrentModificationException
> ---
>
> Key: IGNITE-11078
> URL: https://issues.apache.org/jira/browse/IGNITE-11078
> Project: Ignite
> Issue Type: Test
> Components: mvcc
>Reporter: Andrew Mashenkov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, mvcc_stabilization_stage_1
>
> Next test failed on TC.
> [CacheMvccReplicatedSqlCoordinatorFailoverTest.testCoordinatorChangeActiveQueryClientFails_Simple|https://ci.ignite.apache.org/viewLog.html?buildId=2902796&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_MvccQueries#testNameId3071204292938919018]
> See TC run for details:
> [TC
> run|https://ci.ignite.apache.org/viewLog.html?buildId=2902796&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_MvccQueries#testNameId3071204292938919018]
> Stacktrace example:
> {code:java}
> java.util.ConcurrentModificationException
> at java.util.HashMap$HashIterator.nextNode(HashMap.java:1442)
> at java.util.HashMap$KeyIterator.next(HashMap.java:1466)
> at java.util.AbstractCollection.toString(AbstractCollection.java:461)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> java.util.concurrent.ConcurrentHashMap.toString(ConcurrentHashMap.java:1321)
> at java.lang.String.valueOf(String.java:2994)
> at java.lang.StringBuilder.append(StringBuilder.java:131)
> at
> org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest$12.apply(CacheMvccAbstractTest.java:1757)
> at
> org.apache.ignite.testframework.GridTestUtils.waitForCondition(GridTestUtils.java:1682)
> at
> org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractTest.checkActiveQueriesCleanup(CacheMvccAbstractTest.java:1750)
> at
> org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractBasicCoordinatorFailoverTest.checkCoordinatorChangeActiveQueryClientFails_Simple(CacheMvccAbstractBasicCoordinatorFailoverTest.java:689)
> at
> org.apache.ignite.internal.processors.cache.mvcc.CacheMvccAbstractSqlCoordinatorFailoverTest.testCoordinatorChangeActiveQueryClientFails_Simple(CacheMvccAbstractSqlCoordinatorFailoverTest.java:164)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
> at java.lang.Thread.run(Thread.java:748)
> {code}
>
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11079) MVCC: IgniteCacheContinuousQueryBackupQueueTest is flacky.
Andrew Mashenkov created IGNITE-11079:
-
Summary: MVCC: IgniteCacheContinuousQueryBackupQueueTest is flacky.
Key: IGNITE-11079
URL: https://issues.apache.org/jira/browse/IGNITE-11079
Project: Ignite
Issue Type: Test
Components: mvcc
Reporter: Andrew Mashenkov
See Tc run
[https://ci.ignite.apache.org/viewLog.html?buildId=2859831&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_MvccQueries#testNameId925274886589214180]
Test fails after series of long JVM pauses with stacktrace:
{code:java}
junit.framework.AssertionFailedError
at junit.framework.Assert.fail(Assert.java:55)
at junit.framework.Assert.assertTrue(Assert.java:22)
at junit.framework.Assert.assertTrue(Assert.java:31)
at
org.apache.ignite.internal.processors.cache.query.continuous.IgniteCacheContinuousQueryBackupQueueTest.testManyQueryBackupQueue(IgniteCacheContinuousQueryBackupQueueTest.java:175)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
at java.lang.Thread.run(Thread.java:748){code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11034) Web console: update some dependencies
[ https://issues.apache.org/jira/browse/IGNITE-11034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Kalinin reassigned IGNITE-11034: -- Assignee: Ilya Borisov (was: Alexander Kalinin) > Web console: update some dependencies > - > > Key: IGNITE-11034 > URL: https://issues.apache.org/jira/browse/IGNITE-11034 > Project: Ignite > Issue Type: Improvement > Components: wizards >Reporter: Ilya Borisov >Assignee: Ilya Borisov >Priority: Minor > Original Estimate: 3h > Time Spent: 2h > Remaining Estimate: 1h > > We need to update: > 1. AngularJS to latest 1.7 release (1.7.6) in order to support lazy module > loading. > 2. typescript-eslint-parser has been deprecated in a favor of it's fork, see > details [here|https://eslint.org/blog/2019/01/future-typescript-eslint]. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11077) Add information about SSL cipher suites to apacheignite.readme.io
Sergey Antonov created IGNITE-11077: --- Summary: Add information about SSL cipher suites to apacheignite.readme.io Key: IGNITE-11077 URL: https://issues.apache.org/jira/browse/IGNITE-11077 Project: Ignite Issue Type: Task Components: documentation Reporter: Sergey Antonov I didn't find information about ssl cipher suites on https://apacheignite.readme.io/docs/ssltls -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-8728) "IllegalStateException: Duplicate Key" on node join
[
https://issues.apache.org/jira/browse/IGNITE-8728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752127#comment-16752127
]
Ignite TC Bot commented on IGNITE-8728:
---
{panel:title=--> Run :: All: No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=2885542&buildTypeId=IgniteTests24Java8_RunAll]
> "IllegalStateException: Duplicate Key" on node join
> ---
>
> Key: IGNITE-8728
> URL: https://issues.apache.org/jira/browse/IGNITE-8728
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Mahesh Renduchintala
>Assignee: Stanislav Lukyanov
>Priority: Critical
> Attachments: NS1_ignite-9676df15.0.log, NS2_ignite-7cfc8008.0.log,
> node-config.xml
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I have two nodes on which we have 3 tables which are partitioned. Index are
> also built on these tables.
> For 24 hours caches work fine. The tables are definitely distributed across
> both the nodes
> Node 2 reboots due to some issue - goes out of the baseline - comes back and
> joins the baseline. Other baseline nodes crash and in the logs we see
> duplicate Key error
> [10:38:35,437][INFO][tcp-disco-srvr-#2|#2][TcpDiscoverySpi] TCP discovery
> accepted incoming connection [rmtAddr=/192.168.1.7, rmtPort=45102]
> [10:38:35,437][INFO][tcp-disco-srvr-#2|#2][TcpDiscoverySpi] TCP discovery
> spawning a new thread for connection [rmtAddr=/192.168.1.7, rmtPort=45102]
> [10:38:35,437][INFO][tcp-disco-sock-reader-#12|#12][TcpDiscoverySpi] Started
> serving remote node connection [rmtAddr=/192.168.1.7:45102, rmtPort=45102]
> [10:38:35,451][INFO][tcp-disco-sock-reader-#12|#12][TcpDiscoverySpi]
> Finished serving remote node connection [rmtAddr=/192.168.1.7:45102,
> rmtPort=45102
> [10:38:35,457][SEVERE][tcp-disco-msg-worker-#3|#3][TcpDiscoverySpi]
> TcpDiscoverSpi's message worker thread failed abnormally. Stopping the node
> in order to prevent cluster wide instability.
> *java.lang.IllegalStateException: Duplicate key*
> at org.apache.ignite.cache.QueryEntity.checkIndexes(QueryEntity.java:223)
> at org.apache.ignite.cache.QueryEntity.makePatch(QueryEntity.java:174)
> at
> org.apache.ignite.internal.processors.query.QuerySchema.makePatch(QuerySchema.java:114)
> at
> org.apache.ignite.internal.processors.cache.DynamicCacheDescriptor.makeSchemaPatch(DynamicCacheDescriptor.java:360)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.validateNode(GridCacheProcessor.java:2536)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter$1.validateNode(GridManagerAdapter.java:566)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processJoinRequestMessage(ServerImpl.java:3629)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2736)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621)
> at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)
> [10:38:35,459][SEVERE][tcp-disco-msg-worker-#3|#3][] Critical system error
> detected. Will be handled accordingly to configured handler [hnd=class
> o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException:
> Duplicate key]]
> java.lang.IllegalStateException: Duplicate key
> at org.apache.ignite.cache.QueryEntity.checkIndexes(QueryEntity.java:223)
> at org.apache.ignite.cache.QueryEntity.makePatch(QueryEntity.java:174)
> at
> org.apache.ignite.internal.processors.query.QuerySchema.makePatch(QuerySchema.java:114)
> at
> org.apache.ignite.internal.processors.cache.DynamicCacheDescriptor.makeSchemaPatch(DynamicCacheDescriptor.java:360)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.validateNode(GridCacheProcessor.java:2536)
> at
> org.apache.ignite.internal.managers.GridManagerAdapter$1.validateNode(GridManagerAdapter.java:566)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processJoinRequestMessage(ServerImpl.java:3629)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2736)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$Ring
[jira] [Updated] (IGNITE-8728) "IllegalStateException: Duplicate Key" on node join
[ https://issues.apache.org/jira/browse/IGNITE-8728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-8728: --- Component/s: sql > "IllegalStateException: Duplicate Key" on node join > --- > > Key: IGNITE-8728 > URL: https://issues.apache.org/jira/browse/IGNITE-8728 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.7 >Reporter: Mahesh Renduchintala >Assignee: Stanislav Lukyanov >Priority: Critical > Attachments: NS1_ignite-9676df15.0.log, NS2_ignite-7cfc8008.0.log, > node-config.xml > > Time Spent: 10m > Remaining Estimate: 0h > > I have two nodes on which we have 3 tables which are partitioned. Index are > also built on these tables. > For 24 hours caches work fine. The tables are definitely distributed across > both the nodes > Node 2 reboots due to some issue - goes out of the baseline - comes back and > joins the baseline. Other baseline nodes crash and in the logs we see > duplicate Key error > [10:38:35,437][INFO][tcp-disco-srvr-#2|#2][TcpDiscoverySpi] TCP discovery > accepted incoming connection [rmtAddr=/192.168.1.7, rmtPort=45102] > [10:38:35,437][INFO][tcp-disco-srvr-#2|#2][TcpDiscoverySpi] TCP discovery > spawning a new thread for connection [rmtAddr=/192.168.1.7, rmtPort=45102] > [10:38:35,437][INFO][tcp-disco-sock-reader-#12|#12][TcpDiscoverySpi] Started > serving remote node connection [rmtAddr=/192.168.1.7:45102, rmtPort=45102] > [10:38:35,451][INFO][tcp-disco-sock-reader-#12|#12][TcpDiscoverySpi] > Finished serving remote node connection [rmtAddr=/192.168.1.7:45102, > rmtPort=45102 > [10:38:35,457][SEVERE][tcp-disco-msg-worker-#3|#3][TcpDiscoverySpi] > TcpDiscoverSpi's message worker thread failed abnormally. Stopping the node > in order to prevent cluster wide instability. > *java.lang.IllegalStateException: Duplicate key* > at org.apache.ignite.cache.QueryEntity.checkIndexes(QueryEntity.java:223) > at org.apache.ignite.cache.QueryEntity.makePatch(QueryEntity.java:174) > at > org.apache.ignite.internal.processors.query.QuerySchema.makePatch(QuerySchema.java:114) > at > org.apache.ignite.internal.processors.cache.DynamicCacheDescriptor.makeSchemaPatch(DynamicCacheDescriptor.java:360) > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.validateNode(GridCacheProcessor.java:2536) > at > org.apache.ignite.internal.managers.GridManagerAdapter$1.validateNode(GridManagerAdapter.java:566) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processJoinRequestMessage(ServerImpl.java:3629) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2736) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621) > at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) > [10:38:35,459][SEVERE][tcp-disco-msg-worker-#3|#3][] Critical system error > detected. Will be handled accordingly to configured handler [hnd=class > o.a.i.failure.StopNodeOrHaltFailureHandler, failureCtx=FailureContext > [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: > Duplicate key]] > java.lang.IllegalStateException: Duplicate key > at org.apache.ignite.cache.QueryEntity.checkIndexes(QueryEntity.java:223) > at org.apache.ignite.cache.QueryEntity.makePatch(QueryEntity.java:174) > at > org.apache.ignite.internal.processors.query.QuerySchema.makePatch(QuerySchema.java:114) > at > org.apache.ignite.internal.processors.cache.DynamicCacheDescriptor.makeSchemaPatch(DynamicCacheDescriptor.java:360) > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.validateNode(GridCacheProcessor.java:2536) > at > org.apache.ignite.internal.managers.GridManagerAdapter$1.validateNode(GridManagerAdapter.java:566) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processJoinRequestMessage(ServerImpl.java:3629) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2736) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.processMessage(ServerImpl.java:2536) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerAdapter.body(ServerImpl.java:6775) > at > org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2621) > at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62) > [10:38:35,460][SEVERE][tcp-disco-msg-worker-#3|#3][] JVM will be halted > immediately due to the failure: [failureCtx=FailureConte
[jira] [Commented] (IGNITE-9879) Web console: split major features to modules - configuration
[
https://issues.apache.org/jira/browse/IGNITE-9879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752151#comment-16752151
]
Ilya Borisov commented on IGNITE-9879:
--
All done. About 130kb out of 1.04Mb JS bundle (gzipped) are now loaded lazily.
I also converted most of configuration module files to TypeScript.
> Web console: split major features to modules - configuration
>
>
> Key: IGNITE-9879
> URL: https://issues.apache.org/jira/browse/IGNITE-9879
> Project: Ignite
> Issue Type: Improvement
> Components: wizards
>Reporter: Ilya Borisov
>Assignee: Ilya Borisov
>Priority: Minor
> Original Estimate: 16h
> Time Spent: 7h
> Remaining Estimate: 9h
>
> The issue:
> 1. _app.js_ is massive, hard to maintain and often a source of various merge
> conflicts.
> 2. Even if some code is de facto separated by feature
> (configuration/queries/admin/profile), no agreement was made on how to
> structure directories, which leads to confusion and app.js growth.
> I propose to:
> 1. Reorganize source code file structure:
> {noformat}
> frontend
> app
> configuration
> queries
> profile
> admin
> common
> {noformat}
> 2. Slim _app.js_ down to something like this:
> {noformat}
> import common from './common'
> import configuration from './configuration'
> import queries from './queries'
> import profile from './profile'
> import admin from './admin'
> export default angular.module('ignite-console', [
> common.name,
> configuration.name,
> queries.name,
> profile.name,
> admin.name
> ])
> {noformat}
> Each directory inside app will follow the same module structure as agreed
> upon before (i.e. components/services/filters, etc).
> 3. In order to test water, update the configuration module first and if
> everything goes as expect proceed with other modules.
> [~kuaw26], [~anovikov] what do you think?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9879) Web console: split major features to modules - configuration
[
https://issues.apache.org/jira/browse/IGNITE-9879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752151#comment-16752151
]
Ilya Borisov edited comment on IGNITE-9879 at 1/25/19 11:00 AM:
All done. About 130kb out of 1.04Mb JS bundle (gzipped) are now loaded lazily.
I've also converted most of configuration module files to TypeScript.
[~anovikov] please review.
was (Author: klaster_1):
All done. About 130kb out of 1.04Mb JS bundle (gzipped) are now loaded lazily.
I also converted most of configuration module files to TypeScript.
[~anovikov] please review.
> Web console: split major features to modules - configuration
>
>
> Key: IGNITE-9879
> URL: https://issues.apache.org/jira/browse/IGNITE-9879
> Project: Ignite
> Issue Type: Improvement
> Components: wizards
>Reporter: Ilya Borisov
>Assignee: Andrey Novikov
>Priority: Minor
> Original Estimate: 16h
> Time Spent: 7h
> Remaining Estimate: 9h
>
> The issue:
> 1. _app.js_ is massive, hard to maintain and often a source of various merge
> conflicts.
> 2. Even if some code is de facto separated by feature
> (configuration/queries/admin/profile), no agreement was made on how to
> structure directories, which leads to confusion and app.js growth.
> I propose to:
> 1. Reorganize source code file structure:
> {noformat}
> frontend
> app
> configuration
> queries
> profile
> admin
> common
> {noformat}
> 2. Slim _app.js_ down to something like this:
> {noformat}
> import common from './common'
> import configuration from './configuration'
> import queries from './queries'
> import profile from './profile'
> import admin from './admin'
> export default angular.module('ignite-console', [
> common.name,
> configuration.name,
> queries.name,
> profile.name,
> admin.name
> ])
> {noformat}
> Each directory inside app will follow the same module structure as agreed
> upon before (i.e. components/services/filters, etc).
> 3. In order to test water, update the configuration module first and if
> everything goes as expect proceed with other modules.
> [~kuaw26], [~anovikov] what do you think?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9879) Web console: split major features to modules - configuration
[
https://issues.apache.org/jira/browse/IGNITE-9879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752151#comment-16752151
]
Ilya Borisov edited comment on IGNITE-9879 at 1/25/19 11:00 AM:
All done. About 130kb out of 1.04Mb JS bundle (gzipped) are now loaded lazily.
I've also converted most of configuration module files to TypeScript. I did not
encounter major issues, the process is very straightforward.
[~anovikov] please review.
was (Author: klaster_1):
All done. About 130kb out of 1.04Mb JS bundle (gzipped) are now loaded lazily.
I've also converted most of configuration module files to TypeScript.
[~anovikov] please review.
> Web console: split major features to modules - configuration
>
>
> Key: IGNITE-9879
> URL: https://issues.apache.org/jira/browse/IGNITE-9879
> Project: Ignite
> Issue Type: Improvement
> Components: wizards
>Reporter: Ilya Borisov
>Assignee: Andrey Novikov
>Priority: Minor
> Original Estimate: 16h
> Time Spent: 7h
> Remaining Estimate: 9h
>
> The issue:
> 1. _app.js_ is massive, hard to maintain and often a source of various merge
> conflicts.
> 2. Even if some code is de facto separated by feature
> (configuration/queries/admin/profile), no agreement was made on how to
> structure directories, which leads to confusion and app.js growth.
> I propose to:
> 1. Reorganize source code file structure:
> {noformat}
> frontend
> app
> configuration
> queries
> profile
> admin
> common
> {noformat}
> 2. Slim _app.js_ down to something like this:
> {noformat}
> import common from './common'
> import configuration from './configuration'
> import queries from './queries'
> import profile from './profile'
> import admin from './admin'
> export default angular.module('ignite-console', [
> common.name,
> configuration.name,
> queries.name,
> profile.name,
> admin.name
> ])
> {noformat}
> Each directory inside app will follow the same module structure as agreed
> upon before (i.e. components/services/filters, etc).
> 3. In order to test water, update the configuration module first and if
> everything goes as expect proceed with other modules.
> [~kuaw26], [~anovikov] what do you think?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-9879) Web console: split major features to modules - configuration
[
https://issues.apache.org/jira/browse/IGNITE-9879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Borisov reassigned IGNITE-9879:
Assignee: Andrey Novikov (was: Ilya Borisov)
> Web console: split major features to modules - configuration
>
>
> Key: IGNITE-9879
> URL: https://issues.apache.org/jira/browse/IGNITE-9879
> Project: Ignite
> Issue Type: Improvement
> Components: wizards
>Reporter: Ilya Borisov
>Assignee: Andrey Novikov
>Priority: Minor
> Original Estimate: 16h
> Time Spent: 7h
> Remaining Estimate: 9h
>
> The issue:
> 1. _app.js_ is massive, hard to maintain and often a source of various merge
> conflicts.
> 2. Even if some code is de facto separated by feature
> (configuration/queries/admin/profile), no agreement was made on how to
> structure directories, which leads to confusion and app.js growth.
> I propose to:
> 1. Reorganize source code file structure:
> {noformat}
> frontend
> app
> configuration
> queries
> profile
> admin
> common
> {noformat}
> 2. Slim _app.js_ down to something like this:
> {noformat}
> import common from './common'
> import configuration from './configuration'
> import queries from './queries'
> import profile from './profile'
> import admin from './admin'
> export default angular.module('ignite-console', [
> common.name,
> configuration.name,
> queries.name,
> profile.name,
> admin.name
> ])
> {noformat}
> Each directory inside app will follow the same module structure as agreed
> upon before (i.e. components/services/filters, etc).
> 3. In order to test water, update the configuration module first and if
> everything goes as expect proceed with other modules.
> [~kuaw26], [~anovikov] what do you think?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9879) Web console: split major features to modules - configuration
[
https://issues.apache.org/jira/browse/IGNITE-9879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752151#comment-16752151
]
Ilya Borisov edited comment on IGNITE-9879 at 1/25/19 11:00 AM:
All done. About 130kb out of 1.04Mb JS bundle (gzipped) are now loaded lazily.
I also converted most of configuration module files to TypeScript.
[~anovikov] please review.
was (Author: klaster_1):
All done. About 130kb out of 1.04Mb JS bundle (gzipped) are now loaded lazily.
I also converted most of configuration module files to TypeScript.
> Web console: split major features to modules - configuration
>
>
> Key: IGNITE-9879
> URL: https://issues.apache.org/jira/browse/IGNITE-9879
> Project: Ignite
> Issue Type: Improvement
> Components: wizards
>Reporter: Ilya Borisov
>Assignee: Ilya Borisov
>Priority: Minor
> Original Estimate: 16h
> Time Spent: 7h
> Remaining Estimate: 9h
>
> The issue:
> 1. _app.js_ is massive, hard to maintain and often a source of various merge
> conflicts.
> 2. Even if some code is de facto separated by feature
> (configuration/queries/admin/profile), no agreement was made on how to
> structure directories, which leads to confusion and app.js growth.
> I propose to:
> 1. Reorganize source code file structure:
> {noformat}
> frontend
> app
> configuration
> queries
> profile
> admin
> common
> {noformat}
> 2. Slim _app.js_ down to something like this:
> {noformat}
> import common from './common'
> import configuration from './configuration'
> import queries from './queries'
> import profile from './profile'
> import admin from './admin'
> export default angular.module('ignite-console', [
> common.name,
> configuration.name,
> queries.name,
> profile.name,
> admin.name
> ])
> {noformat}
> Each directory inside app will follow the same module structure as agreed
> upon before (i.e. components/services/filters, etc).
> 3. In order to test water, update the configuration module first and if
> everything goes as expect proceed with other modules.
> [~kuaw26], [~anovikov] what do you think?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-9879) Web console: split major features to modules - configuration
[
https://issues.apache.org/jira/browse/IGNITE-9879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752151#comment-16752151
]
Ilya Borisov edited comment on IGNITE-9879 at 1/25/19 11:02 AM:
All done. About 130kb out of 1.04Mb JS bundle (gzipped) are now loaded lazily.
I've also converted most of configuration module files to TypeScript. I did not
encounter major issues, the process is very straightforward.
[~anovikov] please review.
[~pkonstantinov] what to test:
1. No regressions in configuration screens.
was (Author: klaster_1):
All done. About 130kb out of 1.04Mb JS bundle (gzipped) are now loaded lazily.
I've also converted most of configuration module files to TypeScript. I did not
encounter major issues, the process is very straightforward.
[~anovikov] please review.
> Web console: split major features to modules - configuration
>
>
> Key: IGNITE-9879
> URL: https://issues.apache.org/jira/browse/IGNITE-9879
> Project: Ignite
> Issue Type: Improvement
> Components: wizards
>Reporter: Ilya Borisov
>Assignee: Andrey Novikov
>Priority: Minor
> Original Estimate: 16h
> Time Spent: 7h
> Remaining Estimate: 9h
>
> The issue:
> 1. _app.js_ is massive, hard to maintain and often a source of various merge
> conflicts.
> 2. Even if some code is de facto separated by feature
> (configuration/queries/admin/profile), no agreement was made on how to
> structure directories, which leads to confusion and app.js growth.
> I propose to:
> 1. Reorganize source code file structure:
> {noformat}
> frontend
> app
> configuration
> queries
> profile
> admin
> common
> {noformat}
> 2. Slim _app.js_ down to something like this:
> {noformat}
> import common from './common'
> import configuration from './configuration'
> import queries from './queries'
> import profile from './profile'
> import admin from './admin'
> export default angular.module('ignite-console', [
> common.name,
> configuration.name,
> queries.name,
> profile.name,
> admin.name
> ])
> {noformat}
> Each directory inside app will follow the same module structure as agreed
> upon before (i.e. components/services/filters, etc).
> 3. In order to test water, update the configuration module first and if
> everything goes as expect proceed with other modules.
> [~kuaw26], [~anovikov] what do you think?
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11080) Flacky test GridCacheDhtPreloadDelayedSelfTest.testManualPreload
Andrew Mashenkov created IGNITE-11080: - Summary: Flacky test GridCacheDhtPreloadDelayedSelfTest.testManualPreload Key: IGNITE-11080 URL: https://issues.apache.org/jira/browse/IGNITE-11080 Project: Ignite Issue Type: Test Reporter: Andrew Mashenkov Test is flacky on TC. Seems, we have to either add ScaleFactor support for those test or rework to make it finish in test timeout. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11080) Flacky test GridCacheDhtPreloadDelayedSelfTest.testManualPreload
[ https://issues.apache.org/jira/browse/IGNITE-11080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11080: -- Description: Test is flacky on TC. Seems, we have to either add ScaleFactor support for those test or rework to make it finish in test timeout. was: Test is flacky on TC. Seems, we have to either add ScaleFactor support for those test or rework to make it finish in test timeout. > Flacky test GridCacheDhtPreloadDelayedSelfTest.testManualPreload > > > Key: IGNITE-11080 > URL: https://issues.apache.org/jira/browse/IGNITE-11080 > Project: Ignite > Issue Type: Test >Reporter: Andrew Mashenkov >Priority: Major > Labels: MakeTeamcityGreenAgain > > Test is flacky on TC. > Seems, we have to either add ScaleFactor support for those test or rework to > make it finish in test timeout. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11080) Flacky test GridCacheDhtPreloadDelayedSelfTest.testManualPreload
[
https://issues.apache.org/jira/browse/IGNITE-11080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11080:
--
Description:
Test is flacky on TC.
Seems, we have to either add ScaleFactor support for those test or rework to
make it finish in test timeout.
Also,
[GridCacheDhtPreloadDelayedSelfTest.testDelayedPreload|https://ci.ignite.apache.org/viewLog.html?buildTypeId=IgniteTests24Java8_MvccCache2&buildId=2892228#testNameId-8999548876356035976]
fails due to same reason and same stacktrace.
{noformat}
java.lang.AssertionError
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheDhtPreloadDelayedSelfTest$5.applyx(GridCacheDhtPreloadDelayedSelfTest.java:469)
at
org.apache.ignite.internal.util.lang.GridAbsClosureX.apply(GridAbsClosureX.java:35)
at
org.apache.ignite.testframework.GridTestUtils.retryAssert(GridTestUtils.java:1608)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheDhtPreloadDelayedSelfTest.checkMaps(GridCacheDhtPreloadDelayedSelfTest.java:446)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheDhtPreloadDelayedSelfTest.testDelayedPreload(GridCacheDhtPreloadDelayedSelfTest.java:249)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
at java.lang.Thread.run(Thread.java:748)
{noformat}
was:
Test is flacky on TC.
Seems, we have to either add ScaleFactor support for those test or rework to
make it finish in test timeout.
> Flacky test GridCacheDhtPreloadDelayedSelfTest.testManualPreload
>
>
> Key: IGNITE-11080
> URL: https://issues.apache.org/jira/browse/IGNITE-11080
> Project: Ignite
> Issue Type: Test
>Reporter: Andrew Mashenkov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> Test is flacky on TC.
> Seems, we have to either add ScaleFactor support for those test or rework to
> make it finish in test timeout.
> Also,
> [GridCacheDhtPreloadDelayedSelfTest.testDelayedPreload|https://ci.ignite.apache.org/viewLog.html?buildTypeId=IgniteTests24Java8_MvccCache2&buildId=2892228#testNameId-8999548876356035976]
> fails due to same reason and same stacktrace.
>
> {noformat}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheDhtPreloadDelayedSelfTest$5.applyx(GridCacheDhtPreloadDelayedSelfTest.java:469)
> at
> org.apache.ignite.internal.util.lang.GridAbsClosureX.apply(GridAbsClosureX.java:35)
> at
> org.apache.ignite.testframework.GridTestUtils.retryAssert(GridTestUtils.java:1608)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheDhtPreloadDelayedSelfTest.checkMaps(GridCacheDhtPreloadDelayedSelfTest.java:446)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheDhtPreloadDelayedSelfTest.testDelayedPreload(GridCacheDhtPreloadDelayedSelfTest.java:249)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11080) Flacky test GridCacheDhtPreloadDelayedSelfTest.testManualPreload
[
https://issues.apache.org/jira/browse/IGNITE-11080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11080:
--
Ignite Flags: (was: Docs Required)
> Flacky test GridCacheDhtPreloadDelayedSelfTest.testManualPreload
>
>
> Key: IGNITE-11080
> URL: https://issues.apache.org/jira/browse/IGNITE-11080
> Project: Ignite
> Issue Type: Test
>Reporter: Andrew Mashenkov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> Test is flacky on TC.
> Seems, we have to either add ScaleFactor support for those test or rework to
> make it finish in test timeout.
> Also,
> [GridCacheDhtPreloadDelayedSelfTest.testDelayedPreload|https://ci.ignite.apache.org/viewLog.html?buildTypeId=IgniteTests24Java8_MvccCache2&buildId=2892228#testNameId-8999548876356035976]
> fails due to same reason and same stacktrace.
>
> {noformat}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheDhtPreloadDelayedSelfTest$5.applyx(GridCacheDhtPreloadDelayedSelfTest.java:469)
> at
> org.apache.ignite.internal.util.lang.GridAbsClosureX.apply(GridAbsClosureX.java:35)
> at
> org.apache.ignite.testframework.GridTestUtils.retryAssert(GridTestUtils.java:1608)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheDhtPreloadDelayedSelfTest.checkMaps(GridCacheDhtPreloadDelayedSelfTest.java:446)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheDhtPreloadDelayedSelfTest.testDelayedPreload(GridCacheDhtPreloadDelayedSelfTest.java:249)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10087) IgniteClientReconnectMassiveShutdownTest.testMassiveServersShutdown1 is flaky in master
[ https://issues.apache.org/jira/browse/IGNITE-10087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752172#comment-16752172 ] Sergey Chugunov commented on IGNITE-10087: -- [~NSAmelchev], I reviewed your change, it looks reasonable for me. All tests from test class are passing locally, so if there are no new failures on TC, please proceed with merging fix to master. Thanks! > IgniteClientReconnectMassiveShutdownTest.testMassiveServersShutdown1 is flaky > in master > --- > > Key: IGNITE-10087 > URL: https://issues.apache.org/jira/browse/IGNITE-10087 > Project: Ignite > Issue Type: Bug >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > > The IgniteClientReconnectMassiveShutdownTest.testMassiveServersShutdown1 test > is flaky in master. Sometimes the test fails on test timeout (5 min). > [Test > history.|https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8&testNameId=-6728945354254258306&branch=&tab=testDetails] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11080) Flacky test GridCacheDhtPreloadDelayedSelfTest.testManualPreload
[
https://issues.apache.org/jira/browse/IGNITE-11080?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11080:
--
Labels: MakeTeamcityGreenAgain newbie (was: MakeTeamcityGreenAgain)
> Flacky test GridCacheDhtPreloadDelayedSelfTest.testManualPreload
>
>
> Key: IGNITE-11080
> URL: https://issues.apache.org/jira/browse/IGNITE-11080
> Project: Ignite
> Issue Type: Test
>Reporter: Andrew Mashenkov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, newbie
>
> Test is flacky on TC.
> Seems, we have to either add ScaleFactor support for those test or rework to
> make it finish in test timeout.
> Also,
> [GridCacheDhtPreloadDelayedSelfTest.testDelayedPreload|https://ci.ignite.apache.org/viewLog.html?buildTypeId=IgniteTests24Java8_MvccCache2&buildId=2892228#testNameId-8999548876356035976]
> fails due to same reason and same stacktrace.
>
> {noformat}
> java.lang.AssertionError
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheDhtPreloadDelayedSelfTest$5.applyx(GridCacheDhtPreloadDelayedSelfTest.java:469)
> at
> org.apache.ignite.internal.util.lang.GridAbsClosureX.apply(GridAbsClosureX.java:35)
> at
> org.apache.ignite.testframework.GridTestUtils.retryAssert(GridTestUtils.java:1608)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheDhtPreloadDelayedSelfTest.checkMaps(GridCacheDhtPreloadDelayedSelfTest.java:446)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridCacheDhtPreloadDelayedSelfTest.testDelayedPreload(GridCacheDhtPreloadDelayedSelfTest.java:249)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Created] (IGNITE-11081) Flacky test CacheGetReadFromBackupFailoverTest.testFailover
Andrew Mashenkov created IGNITE-11081: - Summary: Flacky test CacheGetReadFromBackupFailoverTest.testFailover Key: IGNITE-11081 URL: https://issues.apache.org/jira/browse/IGNITE-11081 Project: Ignite Issue Type: Test Reporter: Andrew Mashenkov [CacheGetReadFromBackupFailoverTest.testFailover|https://ci.ignite.apache.org/viewLog.html?buildId=2899047&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_MvccCache2#testNameId1077882218748001125] fails on TC sporadically. Smth goes wrong on node stop. At first glance, test is broken. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10654) Report in case of creating index with already existing fields collection.
[
https://issues.apache.org/jira/browse/IGNITE-10654?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752175#comment-16752175
]
Stanilovsky Evgeny commented on IGNITE-10654:
-
[~vozerov] do i missed?
> Report in case of creating index with already existing fields collection.
> -
>
> Key: IGNITE-10654
> URL: https://issues.apache.org/jira/browse/IGNITE-10654
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 2.7
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Fix For: 2.8
>
>
> Report in log if new index creating with already existing fields collection.
> for example, need to log warn here:
> {code:java}
> cache.query(new SqlFieldsQuery("create index \"idx1\" on Val(keyStr,
> keyLong)"));
> cache.query(new SqlFieldsQuery("create index \"idx3\" on Val(keyStr,
> keyLong)"));
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11081) Flacky test CacheGetReadFromBackupFailoverTest.testFailover
[
https://issues.apache.org/jira/browse/IGNITE-11081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Mashenkov updated IGNITE-11081:
--
Description:
[CacheGetReadFromBackupFailoverTest.testFailover|https://ci.ignite.apache.org/viewLog.html?buildId=2899047&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_MvccCache2#testNameId1077882218748001125]
fails on TC sporadically.
Smth goes wrong on node stop. At first glance, test is broken.
See TC run:
[https://ci.ignite.apache.org/viewLog.html?buildId=2800383&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_Cache2#testNameId-9168781567832473160]
{noformat}
class org.apache.ignite.IgniteCheckedException: Grid is in invalid state to
perform this operation. It either not started yet or has already being or have
stopped [igniteInstanceName=dht.CacheGetReadFromBackupFailoverTest0,
state=STOPPING]
at
org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7294)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.resolve(GridFutureAdapter.java:260)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:209)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:160)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:152)
at
org.apache.ignite.internal.processors.cache.distributed.dht.CacheGetReadFromBackupFailoverTest.testFailover(CacheGetReadFromBackupFailoverTest.java:222)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2088)
at java.lang.Thread.run(Thread.java:748)
Caused by: java.lang.IllegalStateException: Grid is in invalid state to perform
this operation. It either not started yet or has already being or have stopped
[igniteInstanceName=dht.CacheGetReadFromBackupFailoverTest0, state=STOPPING]
at
org.apache.ignite.internal.GridKernalGatewayImpl.illegalState(GridKernalGatewayImpl.java:201)
at
org.apache.ignite.internal.GridKernalGatewayImpl.readLock(GridKernalGatewayImpl.java:95)
at org.apache.ignite.internal.IgniteKernal.guard(IgniteKernal.java:3947)
at
org.apache.ignite.internal.IgniteKernal.transactions(IgniteKernal.java:2913)
at
org.apache.ignite.internal.processors.cache.GridCacheGateway.checkAtomicOpsInTx(GridCacheGateway.java:357)
at
org.apache.ignite.internal.processors.cache.GridCacheGateway.onEnter(GridCacheGateway.java:256)
at
org.apache.ignite.internal.processors.cache.GridCacheGateway.enter(GridCacheGateway.java:173)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.onEnter(GatewayProtectedCacheProxy.java:1585)
at
org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.getAll(GatewayProtectedCacheProxy.java:683)
at
org.apache.ignite.internal.processors.cache.distributed.dht.CacheGetReadFromBackupFailoverTest.lambda$testFailover$0(CacheGetReadFromBackupFailoverTest.java:186)
at
org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$1(GridTestUtils.java:954)
at
org.apache.ignite.testframework.GridTestUtils.lambda$runAsync$2(GridTestUtils.java:1010)
at
org.apache.ignite.testframework.GridTestUtils$7.call(GridTestUtils.java:1306)
at
org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:84){noformat}
was:
[CacheGetReadFromBackupFailoverTest.testFailover|https://ci.ignite.apache.org/viewLog.html?buildId=2899047&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_MvccCache2#testNameId1077882218748001125]
fails on TC sporadically.
Smth goes wrong on node stop. At first glance, test is broken.
> Flacky test CacheGetReadFromBackupFailoverTest.testFailover
> ---
>
> Key: IGNITE-11081
> URL: https://issues.apache.org/jira/browse/IGNITE-11081
> Project: Ignite
> Issue Type: Test
>Reporter: Andrew Mashenkov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
>
> [CacheGetReadFromBackupFailoverTest.testFailover|https://ci.ignite.apache.o
[jira] [Updated] (IGNITE-10958) Migrate from Junit 4 to 5
[ https://issues.apache.org/jira/browse/IGNITE-10958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oleg Ignatenko updated IGNITE-10958: Fix Version/s: 2.8 > Migrate from Junit 4 to 5 > - > > Key: IGNITE-10958 > URL: https://issues.apache.org/jira/browse/IGNITE-10958 > Project: Ignite > Issue Type: Task >Reporter: Ivan Fedotov >Assignee: Ivan Fedotov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > Starting with maven-surefire-plugin version 2.22.0 there is full support for > JUnit 5 [1]. > Migration to the JUnit 5 includes multiple steps: > 1. adding new JUnit dependencies to pom files. By artifactId: > junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher, > junit-platform-runner > 2. Replace all imports of old JUnit annotations by the newest: from > org.junit.Test to org.junit.jupiter.api.Test > 3. Change annotations Before, After, BeforeClass, AfterClass, Ignore > 4. Replace concept rules by extension model where it is necessary: > ExpectedException to assertThrows > 5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension > 6. Update the Maven surefire plugin to make it work with JUnit 5 [1]. > Investigation about migration to JUnit5 is provided in the ticket > IGNITE-10180. > [1] > [https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10958) Migrate from Junit 4 to 5
[
https://issues.apache.org/jira/browse/IGNITE-10958?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752185#comment-16752185
]
Oleg Ignatenko commented on IGNITE-10958:
-
(i) Worth keeping in mind that as of now {{GridAbstractTest}} relies on
reflectively invoked JUnit 4-specific annotations {{org.junit.Test}} and
{{org.junit.Ignore}} when messing with test counters. Related ticket:
IGNITE-10179
> Migrate from Junit 4 to 5
> -
>
> Key: IGNITE-10958
> URL: https://issues.apache.org/jira/browse/IGNITE-10958
> Project: Ignite
> Issue Type: Task
>Reporter: Ivan Fedotov
>Assignee: Ivan Fedotov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Starting with maven-surefire-plugin version 2.22.0 there is full support for
> JUnit 5 [1].
> Migration to the JUnit 5 includes multiple steps:
> 1. adding new JUnit dependencies to pom files. By artifactId:
> junit-jupiter-engine, junit-vintage-engine, junit-platform-launcher,
> junit-platform-runner
> 2. Replace all imports of old JUnit annotations by the newest: from
> org.junit.Test to org.junit.jupiter.api.Test
> 3. Change annotations Before, After, BeforeClass, AfterClass, Ignore
> 4. Replace concept rules by extension model where it is necessary:
> ExpectedException to assertThrows
> 5. Migrate Mockito tests: MockitoJUnitRunner becomes MockitoExtension
> 6. Update the Maven surefire plugin to make it work with JUnit 5 [1].
> Investigation about migration to JUnit5 is provided in the ticket
> IGNITE-10180.
> [1]
> [https://maven.apache.org/surefire/maven-surefire-plugin/examples/junit-platform.html]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-11082) Test GridCacheDhtTxPreloadSelfTest.testLocalTxPreloadingPessimistic hangs on TC sporadically.
[ https://issues.apache.org/jira/browse/IGNITE-11082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrew Mashenkov updated IGNITE-11082: -- Labels: Hanging MakeTeamcityGreenAgain mvcc_stabilization_stage_1 (was: MakeTeamcityGreenAgain mvcc_stabilization_stage_1) > Test GridCacheDhtTxPreloadSelfTest.testLocalTxPreloadingPessimistic hangs on > TC sporadically. > - > > Key: IGNITE-11082 > URL: https://issues.apache.org/jira/browse/IGNITE-11082 > Project: Ignite > Issue Type: Test > Components: mvcc >Reporter: Andrew Mashenkov >Priority: Major > Labels: Hanging, MakeTeamcityGreenAgain, > mvcc_stabilization_stage_1 > > [GridCacheDhtTxPreloadSelfTest.testLocalTxPreloadingPessimistic|https://ci.ignite.apache.org/viewLog.html?buildId=2899049&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_MvccCache4#testNameId-815824464492790356] > hanged on TC. > I've saw no failures in non-mvcc 4 cache suite. Probably, the issue relates > to mvcc. > TC run: > https://ci.ignite.apache.org/viewLog.html?buildId=2899049&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_MvccCache4#testNameId-815824464492790356 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11082) Test GridCacheDhtTxPreloadSelfTest.testLocalTxPreloadingPessimistic hangs on TC sporadically.
Andrew Mashenkov created IGNITE-11082: - Summary: Test GridCacheDhtTxPreloadSelfTest.testLocalTxPreloadingPessimistic hangs on TC sporadically. Key: IGNITE-11082 URL: https://issues.apache.org/jira/browse/IGNITE-11082 Project: Ignite Issue Type: Test Components: mvcc Reporter: Andrew Mashenkov [GridCacheDhtTxPreloadSelfTest.testLocalTxPreloadingPessimistic|https://ci.ignite.apache.org/viewLog.html?buildId=2899049&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_MvccCache4#testNameId-815824464492790356] hanged on TC. I've saw no failures in non-mvcc 4 cache suite. Probably, the issue relates to mvcc. TC run: https://ci.ignite.apache.org/viewLog.html?buildId=2899049&tab=buildResultsDiv&buildTypeId=IgniteTests24Java8_MvccCache4#testNameId-815824464492790356 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-10645) SQL properties ownership flag should be set at configuration parsing, not query execution.
[
https://issues.apache.org/jira/browse/IGNITE-10645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752196#comment-16752196
]
Pavel Kuznetsov commented on IGNITE-10645:
--
Failed tests from {{IgniteCacheMergeSqlQuerySelfTest}} and
{{IgniteCacheUpdateSqlQuerySelfTest}} caused by master merge. Merged master
again, scheduled tests re-run to be 100% sure.
[~vozerov] think It's ready for review now.
> SQL properties ownership flag should be set at configuration parsing, not
> query execution.
> --
>
> Key: IGNITE-10645
> URL: https://issues.apache.org/jira/browse/IGNITE-10645
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Kuznetsov
>Assignee: Pavel Kuznetsov
>Priority: Major
> Fix For: 2.8
>
>
> At processing time, query entities are transformed and validated, table
> descriptors with properties are created.
> Now in some case (thre's no keyFields and key is of complex non-sql type),
> ownership flag of query property is calculated at execution time (for example
> at first put()):
> https://github.com/apache/ignite/blob/dcdb27a24a450f63487290360b265e1570534629/modules/core/src/main/java/org/apache/ignite/internal/processors/query/property/QueryBinaryProperty.java#L132
> So we can't access metadata, that uses this not-yet-initialized field before
> we put the data.
> But we already have all necessary info to set this field at processing time.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-4701) New SQL API
[
https://issues.apache.org/jira/browse/IGNITE-4701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-4701:
---
Assignee: (was: Vladimir Ozerov)
> New SQL API
>
>
> Key: IGNITE-4701
> URL: https://issues.apache.org/jira/browse/IGNITE-4701
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: important, usability
>
> Ticket is created as a result of the following discussion:
> http://apache-ignite-developers.2346864.n4.nabble.com/Rethink-native-SQL-API-in-Apache-Ignite-2-0-td14335.html
> We need new SQL API which will be able to handle new SQL features such as
> DML, DDL, batching, streaming, in a clean and consistent way. Old {{Query}}
> API is not suitable for this.
> Example of a usability issue the API can help to solve:
> http://apache-ignite-developers.2346864.n4.nabble.com/CREATE-TABLE-usage-from-Java-API-NET-C-td21455.html
> Final API design still to be proposed.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-3244) Custom arrays are not serialized properly by CacheObjectBinaryProcessorImpl
[
https://issues.apache.org/jira/browse/IGNITE-3244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-3244:
---
Assignee: (was: Vladimir Ozerov)
> Custom arrays are not serialized properly by CacheObjectBinaryProcessorImpl
> ---
>
> Key: IGNITE-3244
> URL: https://issues.apache.org/jira/browse/IGNITE-3244
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: ignite-1.4
>Reporter: Denis Magda
>Priority: Minor
> Attachments: tc3.png
>
>
> If to put a custom object array into a cache like this one
> {code}
> TestObject[] arr = new TestObject[] {new TestObject(i)};
> cache.put(0, arr);
> {code}
> then it will be serialized as Object[] array in
> {{CacheObjectBinaryProcessorImpl.marshallToBinary}} method.
> This leads to the situation when object's array type is lost and on cache.get
> the code below produces {{ClassCastException}}
> {code}
> TestObject[] obj = cache.get(i);
> {code}
> The full test is already added into
> {{GridCacheBinaryObjectsAbstractSelfTest.testCustomArrays}}.
> To fix the issue we have to revisit logic of
> {{CacheObjectBinaryProcessorImpl.marshallToBinary}} and
> {{CacheObjectContext.unwrapBinary}}.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-7442) Data load hangs with SQL on-heap cache enabled
[ https://issues.apache.org/jira/browse/IGNITE-7442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-7442: --- Assignee: (was: Vladimir Ozerov) > Data load hangs with SQL on-heap cache enabled > -- > > Key: IGNITE-7442 > URL: https://issues.apache.org/jira/browse/IGNITE-7442 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.4 >Reporter: Mikhail Cherkasov >Priority: Major > Labels: sql-stability > > The user uses putAll to load data into a cache, it loads data to Atomic cache > and all keys have unique values, so there can not be a deadlock due to key > order, but to be 200% sure about this, the user also uses TreeMap. > > In logs I can see 68 messages about pool starvation for the same thread: > > at o.a.i.i.processors.query.h2.database.H2Tree.compare(H2Tree.java:206) > at o.a.i.i.processors.query.h2.database.H2Tree.compare(H2Tree.java:44) > at > o.a.i.i.processors.cache.persistence.tree.BPlusTree.compare(BPlusTree.java:4359) > at > o.a.i.i.processors.cache.persistence.tree.BPlusTree.findInsertionPoint(BPlusTree.java:4279) > at > o.a.i.i.processors.cache.persistence.tree.BPlusTree.access$1500(BPlusTree.java:81) > at > o.a.i.i.processors.cache.persistence.tree.BPlusTree$Search.run0(BPlusTree.java:261) > at > o.a.i.i.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:4697) > at > o.a.i.i.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:4682) > at > o.a.i.i.processors.cache.persistence.tree.util.PageHandler.readPage(PageHandler.java:158) > at > o.a.i.i.processors.cache.persistence.DataStructure.read(DataStructure.java:319) > at > o.a.i.i.processors.cache.persistence.tree.BPlusTree.putDown(BPlusTree.java:2254) > at > o.a.i.i.processors.cache.persistence.tree.BPlusTree.putDown(BPlusTree.java:2266) > at > o.a.i.i.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2006) > at > o.a.i.i.processors.cache.persistence.tree.BPlusTree.put(BPlusTree.java:1977) > at o.a.i.i.processors.query.h2.database.H2TreeIndex.put(H2TreeIndex.java:220) > at > o.a.i.i.processors.query.h2.opt.GridH2Table.addToIndex(GridH2Table.java:568) > at o.a.i.i.processors.query.h2.opt.GridH2Table.doUpdate(GridH2Table.java:516) > at o.a.i.i.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:425) > at > o.a.i.i.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:566) > at > o.a.i.i.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:1731) > at > o.a.i.i.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:418) > at > o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:1363) > at > o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1218) > at > o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:352) > at > o.a.i.i.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1693) > at > o.a.i.i.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processDhtAtomicUpdateRequest(GridDhtAtomicCache.java:3222) > > A completed number always is the same: > Completed: 1826527 > > and furthermore, thread always has a runnable state. So it's in a runnable > state for 30 minutes. > > So looks like it was looping somewhere inside: > o.a.i.i.processors.cache.persistence.tree.BPlusTree.putDown > method. > The issue can be reproduced only with SQL on heap cache enabled. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7009) NPE when Ignite persistence is enabled for Hadoop accelerator
[
https://issues.apache.org/jira/browse/IGNITE-7009?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-7009:
---
Assignee: (was: Vladimir Ozerov)
> NPE when Ignite persistence is enabled for Hadoop accelerator
> -
>
> Key: IGNITE-7009
> URL: https://issues.apache.org/jira/browse/IGNITE-7009
> Project: Ignite
> Issue Type: Bug
> Components: hadoop
>Reporter: Denis Magda
>Priority: Major
> Labels: usability
>
> Reported from the user list. Print out a meaningful exception instead of the
> NPE.
> I have installed apache-ignite-hadoop-2.3.0-bin on CDH and able start it
> successfully. But when I try to enable persistence providing the config
> file, it fails.
> {code}
> [root@hdfc01gw01 ~]# echo $IGNITE_HOME
> /applocaldata/ce_project/apache_ignite/apache-ignite-hadoop-2.3.0-bin
> [ad_aagaiton@hdfc01gw01 ~]$ sudo su -
> [root@hdfc01gw01 ~]# $IGNITE_HOME/bin/ignite.sh
> /applocaldata/ce_project/apache_ignite/apache-ignite-fabric-2.3.0-bin/examples/config/persistentstore/example-persistent-store.xml
> [05:15:47]__
> [05:15:47] / _/ ___/ |/ / _/_ __/ __/
> [05:15:47] _/ // (7 7// / / / / _/
> [05:15:47] /___/\___/_/|_/___/ /_/ /___/
> [05:15:47]
> [05:15:47] ver. 2.3.0#20171027-sha1:8add7fd5
> [05:15:47] 2017 Copyright(C) Apache Software Foundation
> [05:15:47]
> [05:15:47] Ignite documentation: http://ignite.apache.org
> [05:15:47]
> [05:15:47] Quiet mode.
> [05:15:47] ^-- Logging to file
> '/applocaldata/ce_project/apache_ignite/apache-ignite-hadoop-2.3.0-bin/work/log/ignite-e570a3f7.log'
> [05:15:47] ^-- To see **FULL** console log here add -DIGNITE_QUIET=false
> or "-v" to ignite.{sh|bat}
> [05:15:47]
> [05:15:47] OS: Linux 2.6.32-504.3.3.el6.x86_64 amd64
> [05:15:47] VM information: Java(TM) SE Runtime Environment 1.7.0_67-b01
> Oracle Corporation Java HotSpot(TM) 64-Bit Server VM 24.65-b04
> [05:15:47] Configured plugins:
> [05:15:47] ^-- None
> [05:15:47]
> [05:15:47] Message queue limit is set to 0 which may lead to potential OOMEs
> when running cache operations in FULL_ASYNC or PRIMARY_SYNC modes due to
> message queues growth on sender and receiver sides.
> [05:15:47] Security status [authentication=off, tls/ssl=off]
> [05:15:48] HADOOP_HOME is set to
> /opt/cloudera/parcels/CDH-5.4.9-1.cdh5.4.9.p1230.998/lib/hadoop
> [05:15:48] Resolved Hadoop classpath locations:
> /opt/cloudera/parcels/CDH-5.4.9-1.cdh5.4.9.p1230.998/lib/hadoop,
> /opt/cloudera/parcels/CDH-5.4.9-1.cdh5.4.9.p1230.998/lib/hadoop-hdfs,
> /opt/cloudera/parcels/CDH-5.4.9-1.cdh5.4.9.p1230.998/lib/hadoop-mapreduce
> [2017-11-23 05:15:49,518][ERROR][main][IgniteKernal] Got exception while
> starting (will rollback startup routine).
> java.lang.NullPointerException
>at
> org.apache.ignite.internal.processors.hadoop.jobtracker.HadoopJobTracker.jobMetaCache(HadoopJobTracker.java:206)
>at
> org.apache.ignite.internal.processors.hadoop.jobtracker.HadoopJobTracker.onKernalStart(HadoopJobTracker.java:239)
>at
> org.apache.ignite.internal.processors.hadoop.HadoopProcessor.onKernalStart(HadoopProcessor.java:105)
>at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1060)
>at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1909)
>at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1652)
>at
> org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1080)
>at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:998)
>at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:884)
>at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:783)
>at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:653)
>at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:622)
>at org.apache.ignite.Ignition.start(Ignition.java:347)
>at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
> [05:15:49] Ignite node stopped OK [uptime=00:00:03.151]
> class org.apache.ignite.IgniteException: null
>at
> org.apache.ignite.internal.util.IgniteUtils.convertException(IgniteUtils.java:966)
>at org.apache.ignite.Ignition.start(Ignition.java:350)
>at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:302)
> Caused by: class org.apache.ignite.IgniteCheckedException: null
>at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1110)
>at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1909)
>at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(Igniti
[jira] [Assigned] (IGNITE-7051) SQL Rename table support
[ https://issues.apache.org/jira/browse/IGNITE-7051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-7051: --- Assignee: (was: Vladimir Ozerov) > SQL Rename table support > > > Key: IGNITE-7051 > URL: https://issues.apache.org/jira/browse/IGNITE-7051 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.3 >Reporter: Blackfield >Priority: Major > > Use case was discussed at length here: > http://apache-ignite-users.70518.x6.nabble.com/Continuous-update-Data-Grid-Cache-td2075.html#a17641 > Currently, we have to load data to second table, the client then has to > change their query to query this > new table. Drop the old table. > The latest suggestion in the above thread to "load new data set in the same > cache and remove old entries once preloading is finished" is not feasible > since for large table and table scan query (thus requires whole dataset to > be loaded), it will take a while to load everything - thus increasing the > downtime. > Table rename support will reduce the downtime greatly. > Ref: Postgresql and H2 syntax > ALTER TABLE TmpTable RENAME TO Table1; > Then, one would wrap it within transaction (It appears that this is slated > for 2.4/2.5?) to drop old table, rename temp table to original table. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-6804) Print a warning if HashMap is passed into bulk update operations
[ https://issues.apache.org/jira/browse/IGNITE-6804?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-6804: --- Assignee: (was: Vladimir Ozerov) > Print a warning if HashMap is passed into bulk update operations > > > Key: IGNITE-6804 > URL: https://issues.apache.org/jira/browse/IGNITE-6804 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Denis Magda >Priority: Critical > Labels: usability > > Ignite newcomers tend to stumble on deadlocks simply because the keys are > passed in an unordered HashMap. Propose to do the following: > * update bulk operations Java docs. > * print out a warning if not SortedMap (e.g. HashMap, > Weak/Identity/Concurrent/Linked HashMap etc) is passed into > a bulk method (instead of SortedMap) and contains more than 1 element. > However, we should make sure that we only print that warning once and not > every time the API is called. > * do not produce warning for explicit optimistic transactions > More details are here: > http://apache-ignite-developers.2346864.n4.nabble.com/Re-Ignite-2-0-0-GridUnsafe-unmonitor-td23706.html -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10937) Support data page scan for JDBC/ODBC
[ https://issues.apache.org/jira/browse/IGNITE-10937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-10937: - Component/s: sql > Support data page scan for JDBC/ODBC > > > Key: IGNITE-10937 > URL: https://issues.apache.org/jira/browse/IGNITE-10937 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Sergi Vladykin >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10991) SET STREAMING ALLOW_OVERWRITE DataStreamer fails to finish
[
https://issues.apache.org/jira/browse/IGNITE-10991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-10991:
Assignee: (was: Vladimir Ozerov)
> SET STREAMING ALLOW_OVERWRITE DataStreamer fails to finish
> --
>
> Key: IGNITE-10991
> URL: https://issues.apache.org/jira/browse/IGNITE-10991
> Project: Ignite
> Issue Type: Bug
> Components: jdbc, sql
>Affects Versions: 2.6
>Reporter: Ilya Kasnacheev
>Priority: Major
> Fix For: 2.8
>
> Attachments: CacheSqlStreamingAllowOverwriteTest.java
>
>
> Please see attached test. Repeatedly overwriting same cache entries over and
> over in streaming mode with ALLOW_OVERWRITE ON will cause either:
> {code}
> java.sql.BatchUpdateException: Failed to INSERT some keys because they are
> already in cache [keys=[2054...]
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection$StreamState.readResponses(JdbcThinConnection.java:1052)
> ... 1 more
> {code}
> or
> {code}
> WARNING: Exception during batch send on streamed connection close
> java.sql.BatchUpdateException: class
> org.apache.ignite.IgniteCheckedException: Data streamer has been closed.
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection$StreamState.readResponses(JdbcThinConnection.java:1016)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Expecter behavior - no failures, all records overwritten.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8448) C++: AffinityKey support
[ https://issues.apache.org/jira/browse/IGNITE-8448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-8448: --- Assignee: (was: Vladimir Ozerov) > C++: AffinityKey support > > > Key: IGNITE-8448 > URL: https://issues.apache.org/jira/browse/IGNITE-8448 > Project: Ignite > Issue Type: New Feature > Components: platforms >Affects Versions: 2.6 >Reporter: Ilya Kasnacheev >Priority: Major > > Add AffinityKey class and AffinityKeyMapped attribute to allow custom > affinity mapping. > This is crucial for SQL joins to work properly. > See org.apache.ignite.cache.affinity.AffinityKey and AffinityKeyMapped in > Java. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10937) Support data page scan for JDBC/ODBC
[ https://issues.apache.org/jira/browse/IGNITE-10937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-10937: - Ignite Flags: (was: Docs Required) > Support data page scan for JDBC/ODBC > > > Key: IGNITE-10937 > URL: https://issues.apache.org/jira/browse/IGNITE-10937 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Sergi Vladykin >Priority: Major > Labels: performance > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7906) Create languages comparison page
[ https://issues.apache.org/jira/browse/IGNITE-7906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-7906: --- Assignee: (was: Vladimir Ozerov) > Create languages comparison page > - > > Key: IGNITE-7906 > URL: https://issues.apache.org/jira/browse/IGNITE-7906 > Project: Ignite > Issue Type: New Feature > Components: documentation >Reporter: Denis Magda >Priority: Major > > In addition to Java, .NET and C++ thick clients, the community is going to > support a variety of thin client for many other languages such as Python, > Node.JS, etc. It will be beneficial to create a page that depicts > capabilities of every language like this one: > https://hazelcast.org/clients-languages/ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10937) Support data page scan for JDBC/ODBC
[ https://issues.apache.org/jira/browse/IGNITE-10937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-10937: - Labels: performance (was: ) > Support data page scan for JDBC/ODBC > > > Key: IGNITE-10937 > URL: https://issues.apache.org/jira/browse/IGNITE-10937 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Sergi Vladykin >Priority: Major > Labels: performance > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-10299) SQL: Extract SELECT and DML plan caches into single class
[ https://issues.apache.org/jira/browse/IGNITE-10299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-10299: - Comment: was deleted (was: Test failures. Need to fix.) > SQL: Extract SELECT and DML plan caches into single class > - > > Key: IGNITE-10299 > URL: https://issues.apache.org/jira/browse/IGNITE-10299 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > In future we will need to merge plans for both DML and SELECTs (both local > and distributed) into a single entity. This ticket is the first part of this > effort - let's just extract both plan caches into a single class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-10299) SQL: Extract SELECT and DML plan caches into single class
[ https://issues.apache.org/jira/browse/IGNITE-10299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-10299: Assignee: (was: Vladimir Ozerov) > SQL: Extract SELECT and DML plan caches into single class > - > > Key: IGNITE-10299 > URL: https://issues.apache.org/jira/browse/IGNITE-10299 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > In future we will need to merge plans for both DML and SELECTs (both local > and distributed) into a single entity. This ticket is the first part of this > effort - let's just extract both plan caches into a single class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-10299) SQL: Extract SELECT and DML plan caches into single class
[ https://issues.apache.org/jira/browse/IGNITE-10299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-10299: - Comment: was deleted (was: Test run: https://ci.ignite.apache.org/viewQueued.html?itemId=2333920) > SQL: Extract SELECT and DML plan caches into single class > - > > Key: IGNITE-10299 > URL: https://issues.apache.org/jira/browse/IGNITE-10299 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > In future we will need to merge plans for both DML and SELECTs (both local > and distributed) into a single entity. This ticket is the first part of this > effort - let's just extract both plan caches into a single class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-10299) SQL: Extract SELECT and DML plan caches into single class
[ https://issues.apache.org/jira/browse/IGNITE-10299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-10299: - Comment: was deleted (was: GitHub user devozerov opened a pull request: https://github.com/apache/ignite/pull/5414 IGNITE-10299 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10299 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5414.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 #5414 commit 68145c6eb0de4e4254a5804deb1b84f9a0a3be41 Author: devozerov Date: 2018-11-16T14:16:11Z DML. commit 0ab81dd184922eabb362a19c80757f67ea7763c3 Author: devozerov Date: 2018-11-16T14:24:54Z SQL. commit 02fe236eb1005ab9b7e0164bff9570c6b8612990 Author: devozerov Date: 2018-11-16T14:28:53Z Renames. commit 5f0dac97ca315aade75171bdd4d60932208106ca Author: devozerov Date: 2018-11-16T14:31:46Z WIP. commit b3ea9113de81a6d97d2a5acdf8881c966d186f3c Author: devozerov Date: 2018-11-16T14:35:48Z Minors. ) > SQL: Extract SELECT and DML plan caches into single class > - > > Key: IGNITE-10299 > URL: https://issues.apache.org/jira/browse/IGNITE-10299 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Fix For: 2.8 > > Time Spent: 10m > Remaining Estimate: 0h > > In future we will need to merge plans for both DML and SELECTs (both local > and distributed) into a single entity. This ticket is the first part of this > effort - let's just extract both plan caches into a single class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-10299) SQL: Extract SELECT and DML plan caches into single class
[
https://issues.apache.org/jira/browse/IGNITE-10299?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-10299:
-
Comment: was deleted
(was: {panel:title=Possible
Blockers|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Inspections: Core{color} [[tests 0 BuildFailureOnMetric
|https://ci.ignite.apache.org/viewLog.html?buildId=2333916]]
{color:#d04437}Queries (Binary Objects Simple Mapper){color} [[tests
23|https://ci.ignite.apache.org/viewLog.html?buildId=2333912]]
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
IndexingCachePartitionLossPolicySelfTest.testReadWriteSafeWithBackupsAfterKillCrd
- 0,0% fails in last 100 master runs.
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
IgniteCachelessQueriesSelfTest.testLocalTwoStepQueryOnSegmentedCachesWithReplicatedAndLocalFlag
- 0,0% fails in last 100 master runs.
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
IgniteCachelessQueriesSelfTest.testLocalQueryOnPartitionedCachesWithReplicatedAndLocalFlag
- 0,0% fails in last 100 master runs.
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
IgniteCachelessQueriesSelfTest.testDistributedQueryOnPartitionedAndReplicatedCacheWithReplicatedFlag
- 0,0% fails in last 100 master runs.
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
IgniteCachelessQueriesSelfTest.testLocalQueryOnPartitionedCachesWithLocalFlag -
0,0% fails in last 100 master runs.
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
IgniteCachelessQueriesSelfTest.testLocalQueryOnPartitionedAndReplicatedCacheWithLocalFlag
- 0,0% fails in last 100 master runs.
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
IgniteCachelessQueriesSelfTest.testLocalQueryOnReplicatedCachesWithReplicatedAndLocalFlag
- 0,0% fails in last 100 master runs.
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
IgniteCachelessQueriesSelfTest.testLocalTwoStepQueryOnReplicatedAndSegmentedCacheWithReplicatedAndLocalFlag
- 0,0% fails in last 100 master runs.
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
IgniteCachelessQueriesSelfTest.testLocalQueryOnPartitionedAndReplicatedCacheWithReplicatedAndLocalFlag
- 0,0% fails in last 100 master runs.
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
IgniteCachelessQueriesSelfTest.testLocalTwoStepQueryOnReplicatedAndSegmentedCacheWithLocalFlag
- 0,0% fails in last 100 master runs.
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
IgniteCachelessQueriesSelfTest.testLocalQueryOnReplicatedCachesWithLocalFlag -
0,0% fails in last 100 master runs.
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
IgniteCachelessQueriesSelfTest.testLocalTwoStepQueryOnSegmentedCachesWithLocalFlag
- 0,0% fails in last 100 master runs.
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
IgniteCachelessQueriesSelfTest.testDistributedQueryOnPartitionedAndReplicatedCache
- 0,0% fails in last 100 master runs.
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
DmlInsideTransactionTest.testDmlInTransactionInCompatibilityMode - 0,0% fails
in last 100 master runs.
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
IgniteCachelessQueriesSelfTest.testDistributedQueryOnPartitionedCachesWithReplicatedFlag
- 0,0% fails in last 100 master runs.
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
IgniteCachelessQueriesSelfTest.testDistributedQueryOnReplicatedAndSegmentedCache
- 0,0% fails in last 100 master runs.
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
IgniteCachelessQueriesSelfTest.testDistributedQueryOnPartitionedCaches - 0,0%
fails in last 100 master runs.
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
IgniteCachelessQueriesSelfTest.testDistributedQueryOnSegmentedCaches - 0,0%
fails in last 100 master runs.
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
IgniteCachelessQueriesSelfTest.testLocalQueryOnReplicatedCachesWithReplicatedFlag
- 0,0% fails in last 100 master runs.
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
IgniteCachelessQueriesSelfTest.testDistributedQueryOnSegmentedCachesWithReplicatedFlag
- 0,0% fails in last 100 master runs.
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
IgniteCachelessQueriesSelfTest.testDistributedQueryOnReplicatedCaches - 0,0%
fails in last 100 master runs.
* IgniteBinarySimpleNameMapperCacheQueryTestSuite:
IgniteCachelessQueriesSelfTest.testDistributedQueryOnReplicatedAndSegmentedCacheWithReplicatedFlag
- 0,0% fails in last 100 master runs.
{color:#d04437}ZooKeeper (Discovery) 3{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2333918]]
* ZookeeperDiscoverySpiTestSuite3:
GridCacheReplicatedNodeRestartSelfTest.testRestartWithTxPutAllTenNodesTwoBackups
- 0,0% fails in last 100 master runs.
{color:#d04437}JDBC Driver{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=2333837]]
* IgniteJdbcDriverTestSuite:
JdbcThinLocalQueriesSelfTest.testLocalThinJdbcQuery - 0,0% fails in last 100
master runs.
{color:#d
[jira] [Issue Comment Deleted] (IGNITE-10759) Disable implicit distributed joins when queryParallelizm>1.
[ https://issues.apache.org/jira/browse/IGNITE-10759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-10759: - Comment: was deleted (was: GitHub user devozerov opened a pull request: https://github.com/apache/ignite/pull/5728 IGNITE-10759 You can merge this pull request into a Git repository by running: $ git pull https://github.com/gridgain/apache-ignite ignite-10759 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/ignite/pull/5728.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 #5728 commit 35586e3955de133bfd1315e30eb60166c53bfa70 Author: devozerov Date: 2018-12-21T13:04:33Z Splitting. commit 7358f5a59c6041593db6e00c597399fcbc58f623 Author: devozerov Date: 2018-12-21T13:07:58Z WIP. commit 2460b95336e37dc54e3675ef0b2a78eb0c5e442e Author: devozerov Date: 2018-12-21T13:28:24Z WIP. commit fb29fc805bf637d11867e28b5f9ab6aa1b87adfe Author: devozerov Date: 2018-12-21T13:42:29Z WIP. commit 8c62ca73509f66058c0f097982440bbd6141241c Author: devozerov Date: 2018-12-21T13:44:24Z Moving classes. commit bc01350bd5c4f3c032d6242cdc40cd83cede824a Author: devozerov Date: 2018-12-21T13:52:48Z RangeStream. commit f8aab8effbfaa9e67748a5c7e7b6b9e176b41228 Author: devozerov Date: 2018-12-21T13:53:27Z UnicastCursor. commit cd577ac8fe2986c0ab95ab50db1562af84f32f53 Author: devozerov Date: 2018-12-21T13:55:44Z BroadcastCursor. commit 432b723bff73b37023581c80ed415864751c42e9 Author: devozerov Date: 2018-12-21T14:11:44Z WIP. commit 5e738904f36031ebfb17294cf0e96a04b45e8781 Author: devozerov Date: 2018-12-21T14:16:52Z WIP. commit 9fa48e5024453d4595f143d0040b7c030488d22d Author: devozerov Date: 2018-12-21T14:31:06Z Initial split done. commit 8dc78d795b03a97b93a829cac3b83eac2e5eb821 Author: devozerov Date: 2018-12-21T14:32:50Z WIP. commit 5c2085c91b893379e0104cdc9a8febda4a89fa3a Author: devozerov Date: 2018-12-21T14:53:33Z Minors. commit 3b90898b1da2633c48a0ac02c42c6618dca192f4 Author: devozerov Date: 2018-12-21T14:53:54Z Minors. commit 7027ef26e281ab93afe826ca8c309eb6500b2a94 Author: devozerov Date: 2018-12-21T14:57:38Z More refactoring. commit 0860542a2d33cb5b20c463cc7308a1fb84d5b946 Author: devozerov Date: 2018-12-21T14:57:57Z WIP. commit 192eb94f8becc21277d0e44833ac0dcd7328aa9f Author: devozerov Date: 2018-12-21T15:07:25Z More refactoring. commit de664052d17a652d816d0dda1369ab0108a4d2a6 Author: devozerov Date: 2018-12-21T15:08:26Z WIP. commit 09986434d9091dd44cde01e0870720dfd16be2fc Author: devozerov Date: 2018-12-21T15:20:08Z Done. commit e00479025c80109832674f61bbb31fd7c77ac3be Author: devozerov Date: 2018-12-21T15:21:24Z Minors. ) > Disable implicit distributed joins when queryParallelizm>1. > --- > > Key: IGNITE-10759 > URL: https://issues.apache.org/jira/browse/IGNITE-10759 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 1.9 >Reporter: Andrew Mashenkov >Priority: Major > Fix For: 2.8 > > > For now, local query with queryParallelizm>1 enables joins between partitions > on same even if distributedJoins flag is false. > This behaviour is unexpected and can't be disabled. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-10759) Disable implicit distributed joins when queryParallelizm>1.
[ https://issues.apache.org/jira/browse/IGNITE-10759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-10759: - Comment: was deleted (was: Prevented "local" + "distributedJoin" flag combination. Split distributed joins code into classes. SQL test run: https://ci.ignite.apache.org/viewQueued.html?itemId=2633910) > Disable implicit distributed joins when queryParallelizm>1. > --- > > Key: IGNITE-10759 > URL: https://issues.apache.org/jira/browse/IGNITE-10759 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 1.9 >Reporter: Andrew Mashenkov >Priority: Major > Fix For: 2.8 > > > For now, local query with queryParallelizm>1 enables joins between partitions > on same even if distributedJoins flag is false. > This behaviour is unexpected and can't be disabled. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8913) Uninformative SQL query cancellation message
[
https://issues.apache.org/jira/browse/IGNITE-8913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-8913:
---
Assignee: (was: Vladimir Ozerov)
> Uninformative SQL query cancellation message
>
>
> Key: IGNITE-8913
> URL: https://issues.apache.org/jira/browse/IGNITE-8913
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.5
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: iep-29, sql-stability
> Fix For: 2.8
>
> Attachments: sgrimstad_IGNITE_8913_Query_cancelled_me.patch
>
>
> When query timeouted or cancelled or other exception, we getting message:
> "The query was cancelled while executing".
> Need make message more clear - text of query, node which the cancelled,
> reason of cancel query e.t.c.
> {noformat}
> 2018-06-19
> 00:00:10.653[ERROR][query-#93192%DPL_GRID%DplGridNodeName%][o.a.i.i.p.q.h.t.GridMapQueryExecutor]
> Failed to execute local query.
> org.apache.ignite.cache.query.QueryCancelledException: The query was
> cancelled while executing.
> at
> org.apache.ignite.internal.processors.query.GridQueryCancel.set(GridQueryCancel.java:53)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:1115)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1207)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:1185)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest0(GridMapQueryExecutor.java:683)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest(GridMapQueryExecutor.java:527)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onMessage(GridMapQueryExecutor.java:218)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor$2.onMessage(GridMapQueryExecutor.java:178)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$ArrayListener.onMessage(GridIoManager.java:2333)
> 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.GridIoManager.access$4200(GridIoManager.java:125)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> 2018-06-19
> 00:00:11.629[ERROR][query-#93187%DPL_GRID%DplGridNodeName%][o.a.i.i.p.q.h.t.GridMapQueryExecutor]
> Failed to execute local query.
> org.apache.ignite.cache.query.QueryCancelledException: The query was
> cancelled while executing.
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest0(GridMapQueryExecutor.java:670)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onQueryRequest(GridMapQueryExecutor.java:527)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor.onMessage(GridMapQueryExecutor.java:218)
> at
> org.apache.ignite.internal.processors.query.h2.twostep.GridMapQueryExecutor$2.onMessage(GridMapQueryExecutor.java:178)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$ArrayListener.onMessage(GridIoManager.java:2333)
> 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.GridIoManager.access$4200(GridIoManager.java:125)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1091)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Issue Comment Deleted] (IGNITE-10759) Disable implicit distributed joins when queryParallelizm>1.
[ https://issues.apache.org/jira/browse/IGNITE-10759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-10759: - Comment: was deleted (was: Some failures after initial impl. Require investigation.) > Disable implicit distributed joins when queryParallelizm>1. > --- > > Key: IGNITE-10759 > URL: https://issues.apache.org/jira/browse/IGNITE-10759 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 1.9 >Reporter: Andrew Mashenkov >Priority: Major > Fix For: 2.8 > > > For now, local query with queryParallelizm>1 enables joins between partitions > on same even if distributedJoins flag is false. > This behaviour is unexpected and can't be disabled. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8152) Forbid empty sql schema name
[
https://issues.apache.org/jira/browse/IGNITE-8152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-8152:
---
Assignee: (was: Vladimir Ozerov)
> Forbid empty sql schema name
>
>
> Key: IGNITE-8152
> URL: https://issues.apache.org/jira/browse/IGNITE-8152
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Kuznetsov
>Priority: Major
>
> Currently we allow empty schema name (quoted) in cache configuration
> org.apache.ignite.configuration.CacheConfiguration#setSqlSchema :
> {noformat}
> When sqlSchema is not specified, quoted cacheName is used instead.
> sqlSchema could not be an empty string. Has to be "\"\"" instead.
> Params:
> sqlSchema - Schema name for current cache according to SQL ANSI-99. Should
> not be null.
> {noformat}
> Specifying schema \"\" results in empty string schema name.
> No schema in sql query is treated as PUBLIC, but \"\" is regular schema name.
> It's better to disallow usage of \"\" schema
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-7746) Failed to put data into cache if IndexedTypes configured.
[
https://issues.apache.org/jira/browse/IGNITE-7746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-7746:
---
Assignee: (was: Vladimir Ozerov)
> Failed to put data into cache if IndexedTypes configured.
> -
>
> Key: IGNITE-7746
> URL: https://issues.apache.org/jira/browse/IGNITE-7746
> Project: Ignite
> Issue Type: Bug
> Components: cache, sql
>Reporter: Alexey Kuznetsov
>Priority: Major
>
> reproducer
> {code}
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> public class Reproducer {
> /**
> * @param args Command line arguments.
> */
> public static void main(String[] args) {
> IgniteConfiguration cfg = new IgniteConfiguration();
> CacheConfiguration ccfg = new CacheConfiguration("test");
> ccfg.setIndexedTypes(String.class, String.class);
> cfg.setCacheConfiguration(ccfg);
> try(Ignite ignite = Ignition.start(cfg)) {
> IgniteCache cStr = ignite.cache("test");
> cStr.put("key", "value");
> IgniteCache cInt = ignite.cache("test");
> cInt.put(1, 2);
> IgniteCache cIntStr = ignite.cache("test");
> cIntStr.put(7, "test");
> }
> }
> }
> {code}
> {noformat}
> Exception in thread "main"
> org.apache.ignite.cache.CachePartialUpdateException: Failed to update keys
> (retry update if possible).: [7]
> at
> org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1278)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.cacheException(IgniteCacheProxyImpl.java:1731)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1087)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:886)
> at org.apache.ignite.Reproducer.main(Reproducer.java:26)
> Caused by: class
> org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException:
> Failed to update keys (retry update if possible).: [7]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:397)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.onPrimaryResponse(GridNearAtomicSingleUpdateFuture.java:253)
> 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:1805)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1628)
> 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.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:483)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:443)
> 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.update0(GridDhtAtomicCache.java:1117)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:606)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2369)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2346)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1084)
> ... 2 more
> Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to update
> keys.
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.UpdateErrors.addFailedKey(UpdateErrors.java:108)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateResponse.addFailedKey(GridNearAtomicUpdateResponse.java:329)
> at
> or
[jira] [Updated] (IGNITE-8384) SQL: Secondary indexes should sort entries by links rather than keys
[
https://issues.apache.org/jira/browse/IGNITE-8384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-8384:
Labels: performance (was: iep-19 performance)
> SQL: Secondary indexes should sort entries by links rather than keys
>
>
> Key: IGNITE-8384
> URL: https://issues.apache.org/jira/browse/IGNITE-8384
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.4
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: performance
>
> Currently we sort entries in secondary indexes as {{(idx_cols, KEY)}}. The
> key itself is not stored in the index in general case. It means that we need
> to perform a lookup to data page to find correct insertion point for index
> entry.
> This could be fixed easily by sorting entries a bit differently - {{idx_cols,
> link}}. This is all we need.
> UPD: If we have an affinity keys, then affinity column will be added to
> secondary index as well.
> So, we'll have secondary index as {{(idx_cols, KEY, AFF_COL)}}
> Comparison occur here:
> {{org.apache.ignite.internal.processors.query.h2.database.H2Tree#compare}}
> What we need is to avoid adding PK and affinity key columns to every
> secondary index and compare links instead in this method.
> Probably we need to preserve old behavior for compatibility purposes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Resolved] (IGNITE-8384) SQL: Secondary indexes should sort entries by links rather than keys
[
https://issues.apache.org/jira/browse/IGNITE-8384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov resolved IGNITE-8384.
-
Resolution: Won't Fix
Closing as "Won't Fix". Links do not work here because they are not unique. New
unique row ID is needed.
> SQL: Secondary indexes should sort entries by links rather than keys
>
>
> Key: IGNITE-8384
> URL: https://issues.apache.org/jira/browse/IGNITE-8384
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: iep-19, performance
>
> Currently we sort entries in secondary indexes as {{(idx_cols, KEY)}}. The
> key itself is not stored in the index in general case. It means that we need
> to perform a lookup to data page to find correct insertion point for index
> entry.
> This could be fixed easily by sorting entries a bit differently - {{idx_cols,
> link}}. This is all we need.
> UPD: If we have an affinity keys, then affinity column will be added to
> secondary index as well.
> So, we'll have secondary index as {{(idx_cols, KEY, AFF_COL)}}
> Comparison occur here:
> {{org.apache.ignite.internal.processors.query.h2.database.H2Tree#compare}}
> What we need is to avoid adding PK and affinity key columns to every
> secondary index and compare links instead in this method.
> Probably we need to preserve old behavior for compatibility purposes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-8384) SQL: Secondary indexes should sort entries by links rather than keys
[
https://issues.apache.org/jira/browse/IGNITE-8384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov closed IGNITE-8384.
---
> SQL: Secondary indexes should sort entries by links rather than keys
>
>
> Key: IGNITE-8384
> URL: https://issues.apache.org/jira/browse/IGNITE-8384
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.4
>Reporter: Vladimir Ozerov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: iep-19, performance
>
> Currently we sort entries in secondary indexes as {{(idx_cols, KEY)}}. The
> key itself is not stored in the index in general case. It means that we need
> to perform a lookup to data page to find correct insertion point for index
> entry.
> This could be fixed easily by sorting entries a bit differently - {{idx_cols,
> link}}. This is all we need.
> UPD: If we have an affinity keys, then affinity column will be added to
> secondary index as well.
> So, we'll have secondary index as {{(idx_cols, KEY, AFF_COL)}}
> Comparison occur here:
> {{org.apache.ignite.internal.processors.query.h2.database.H2Tree#compare}}
> What we need is to avoid adding PK and affinity key columns to every
> secondary index and compare links instead in this method.
> Probably we need to preserve old behavior for compatibility purposes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8591) SQL: Sort links on index pages in physical page order before row access
[ https://issues.apache.org/jira/browse/IGNITE-8591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-8591: --- Assignee: (was: Vladimir Ozerov) > SQL: Sort links on index pages in physical page order before row access > --- > > Key: IGNITE-8591 > URL: https://issues.apache.org/jira/browse/IGNITE-8591 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.5 >Reporter: Vladimir Ozerov >Priority: Major > Labels: performance > > When index page match condition, we eagerly read all matched data rows. This > leads to a number of random disk reads.as Ignite use heap-organized storage. > We can pre-sort all matched row links in accordance to their physical > location, and then read them in batch. This will give us two important > advantages: > 1) Data reads will be more sequential, this is especially important for HDDs > 2) This could decrease number of page reads in case of dense data placement, > because there will be less evictions. > In future we should expand this optimization to several index pages in the > same way it is done in major databases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8591) SQL: Sort links on index pages in physical page order before row access
[ https://issues.apache.org/jira/browse/IGNITE-8591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-8591: --- Assignee: Vladimir Ozerov > SQL: Sort links on index pages in physical page order before row access > --- > > Key: IGNITE-8591 > URL: https://issues.apache.org/jira/browse/IGNITE-8591 > Project: Ignite > Issue Type: Task > Components: sql >Affects Versions: 2.5 >Reporter: Vladimir Ozerov >Assignee: Vladimir Ozerov >Priority: Major > Labels: performance > > When index page match condition, we eagerly read all matched data rows. This > leads to a number of random disk reads.as Ignite use heap-organized storage. > We can pre-sort all matched row links in accordance to their physical > location, and then read them in batch. This will give us two important > advantages: > 1) Data reads will be more sequential, this is especially important for HDDs > 2) This could decrease number of page reads in case of dense data placement, > because there will be less evictions. > In future we should expand this optimization to several index pages in the > same way it is done in major databases. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8384) SQL: Secondary indexes should sort entries by links rather than keys
[
https://issues.apache.org/jira/browse/IGNITE-8384?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-8384:
---
Assignee: (was: Vladimir Ozerov)
> SQL: Secondary indexes should sort entries by links rather than keys
>
>
> Key: IGNITE-8384
> URL: https://issues.apache.org/jira/browse/IGNITE-8384
> Project: Ignite
> Issue Type: Task
> Components: sql
>Affects Versions: 2.4
>Reporter: Vladimir Ozerov
>Priority: Major
> Labels: iep-19, performance
>
> Currently we sort entries in secondary indexes as {{(idx_cols, KEY)}}. The
> key itself is not stored in the index in general case. It means that we need
> to perform a lookup to data page to find correct insertion point for index
> entry.
> This could be fixed easily by sorting entries a bit differently - {{idx_cols,
> link}}. This is all we need.
> UPD: If we have an affinity keys, then affinity column will be added to
> secondary index as well.
> So, we'll have secondary index as {{(idx_cols, KEY, AFF_COL)}}
> Comparison occur here:
> {{org.apache.ignite.internal.processors.query.h2.database.H2Tree#compare}}
> What we need is to avoid adding PK and affinity key columns to every
> secondary index and compare links instead in this method.
> Probably we need to preserve old behavior for compatibility purposes.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-7715) If client cannot find dml entity in local storage, it should ask server for updates
[ https://issues.apache.org/jira/browse/IGNITE-7715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-7715: --- Assignee: (was: Vladimir Ozerov) > If client cannot find dml entity in local storage, it should ask server for > updates > --- > > Key: IGNITE-7715 > URL: https://issues.apache.org/jira/browse/IGNITE-7715 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Kuznetsov >Priority: Major > > Assume we have n servers and at least 2 clients > client 1 creates table (via thin driver) > after that (in global time) client 2 tries to insert data in that table > Currently, if client 2 didn't received from server that table is created, it > rejects query execution > But in this case client 2 could ask connected server for updates before > rejection -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7688) DDL does not work properly on sql queries.
[ https://issues.apache.org/jira/browse/IGNITE-7688?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-7688: --- Assignee: (was: Vladimir Ozerov) > DDL does not work properly on sql queries. > -- > > Key: IGNITE-7688 > URL: https://issues.apache.org/jira/browse/IGNITE-7688 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.3 > Environment: we have 5 node running on Ubuntu 16.04(VM). we > donwloaded binary dist. from download page. >Reporter: Muratcan TUKSAL >Priority: Critical > Labels: persistant, persistence, persistence.xml > Attachments: buggy-config.xml > > > * start ignite cluster persistent enabled mode (tried on 5 node) > * activate cluster via ignitevisor > * Create a table through jdbc > * kill all nodes > * start all nodes again > * activate cluster via ignitevisor > * drop that specific table > * deactivate cluster(doesnt matter via top -deactivate or kill all nodes) > * activate cluster > * dropped table still there with no data -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7740) IGFS caches returned by cache.context().queries().sqlMetadata()
[
https://issues.apache.org/jira/browse/IGNITE-7740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-7740:
---
Assignee: (was: Vladimir Ozerov)
> IGFS caches returned by cache.context().queries().sqlMetadata()
>
>
> Key: IGNITE-7740
> URL: https://issues.apache.org/jira/browse/IGNITE-7740
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexey Kuznetsov
>Priority: Major
>
> IGFS are special caches not related to queries and should not returned by
> {code}
> cache.context().queries().sqlMetadata();
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10937) Support data page scan for JDBC/ODBC
[ https://issues.apache.org/jira/browse/IGNITE-10937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-10937: Assignee: (was: Vladimir Ozerov) > Support data page scan for JDBC/ODBC > > > Key: IGNITE-10937 > URL: https://issues.apache.org/jira/browse/IGNITE-10937 > Project: Ignite > Issue Type: Improvement >Reporter: Sergi Vladykin >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Closed] (IGNITE-7715) If client cannot find dml entity in local storage, it should ask server for updates
[ https://issues.apache.org/jira/browse/IGNITE-7715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov closed IGNITE-7715. --- > If client cannot find dml entity in local storage, it should ask server for > updates > --- > > Key: IGNITE-7715 > URL: https://issues.apache.org/jira/browse/IGNITE-7715 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Kuznetsov >Priority: Major > > Assume we have n servers and at least 2 clients > client 1 creates table (via thin driver) > after that (in global time) client 2 tries to insert data in that table > Currently, if client 2 didn't received from server that table is created, it > rejects query execution > But in this case client 2 could ask connected server for updates before > rejection -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-7715) If client cannot find dml entity in local storage, it should ask server for updates
[ https://issues.apache.org/jira/browse/IGNITE-7715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov resolved IGNITE-7715. - Resolution: Won't Fix Doesn't seem to be relevant for now. We guarantee session-level consistency which should be enough for majority cases. > If client cannot find dml entity in local storage, it should ask server for > updates > --- > > Key: IGNITE-7715 > URL: https://issues.apache.org/jira/browse/IGNITE-7715 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Pavel Kuznetsov >Priority: Major > > Assume we have n servers and at least 2 clients > client 1 creates table (via thin driver) > after that (in global time) client 2 tries to insert data in that table > Currently, if client 2 didn't received from server that table is created, it > rejects query execution > But in this case client 2 could ask connected server for updates before > rejection -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8047) SQL: optimize simple COUNT with DISTINCT query.
[ https://issues.apache.org/jira/browse/IGNITE-8047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-8047: Labels: performance (was: ) > SQL: optimize simple COUNT with DISTINCT query. > --- > > Key: IGNITE-8047 > URL: https://issues.apache.org/jira/browse/IGNITE-8047 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrew Mashenkov >Assignee: Vladimir Ozerov >Priority: Major > Labels: performance > > "Select COUNT(DISTINCT ) From table;" will fetch full data set to > reduce node. > Looks like we can add group by ''- push down DISTINCT into map query > to reduce network pressure. > See details on nabble [1]. > [1] > [http://apache-ignite-users.70518.x6.nabble.com/COUNT-DISTINCT-could-push-down-group-expressions-tt20782.html] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9156) SQL: Impossible to specify equality condition on sub-select field
[
https://issues.apache.org/jira/browse/IGNITE-9156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-9156:
---
Assignee: (was: Vladimir Ozerov)
> SQL: Impossible to specify equality condition on sub-select field
> -
>
> Key: IGNITE-9156
> URL: https://issues.apache.org/jira/browse/IGNITE-9156
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.6
>Reporter: Denis Mekhanikov
>Priority: Critical
>
> Execution of the following sequence of SQL statements leads to an exception:
> {code:sql}
> CREATE TABLE PEOPLE (id int PRIMARY KEY, name varchar);
> INSERT INTO PEOPLE(id, name) VALUES(1, 'Mike');
> SELECT * FROM (SELECT * FROM People p) tmp WHERE tmp.name='Mike';{code}
> Exception:
> {noformat}
> java.lang.ClassCastException: org.h2.table.TableView cannot be cast to
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.extractPartitionFromEquality(GridSqlQuerySplitter.java:2340)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.extractPartition(GridSqlQuerySplitter.java:2272)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.derivePartitionsFromQuery(GridSqlQuerySplitter.java:2254)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.splitSelect(GridSqlQuerySplitter.java:1539)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.splitQueryModel(GridSqlQuerySplitter.java:1227)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.splitQuery(GridSqlQuerySplitter.java:306)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.sql.GridSqlQuerySplitter.split(GridSqlQuerySplitter.java:224)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.split(IgniteH2Indexing.java:1991)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.parseAndSplit(IgniteH2Indexing.java:1953)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1702)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2107)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$4.applyx(GridQueryProcessor.java:2102)
> ~[classes/:?]
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:2650)
> ~[classes/:?]
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2116)
> ~[classes/:?]
> ... 12 more
> {noformat}
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-8047) SQL: optimize simple COUNT with DISTINCT query.
[
https://issues.apache.org/jira/browse/IGNITE-8047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-8047:
Description:
{{SELECT COUNT(DISTINCT ) FROM table}} will fetch full data set to reduce
node.
Looks like we can add group by ''- push down DISTINCT into map query to
reduce network pressure.
See details on nabble [1].
[1]
[http://apache-ignite-users.70518.x6.nabble.com/COUNT-DISTINCT-could-push-down-group-expressions-tt20782.html]
was:
"Select COUNT(DISTINCT ) From table;" will fetch full data set to reduce
node.
Looks like we can add group by ''- push down DISTINCT into map query to
reduce network pressure.
See details on nabble [1].
[1]
[http://apache-ignite-users.70518.x6.nabble.com/COUNT-DISTINCT-could-push-down-group-expressions-tt20782.html]
> SQL: optimize simple COUNT with DISTINCT query.
> ---
>
> Key: IGNITE-8047
> URL: https://issues.apache.org/jira/browse/IGNITE-8047
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Andrew Mashenkov
>Assignee: Vladimir Ozerov
>Priority: Major
> Labels: performance
>
> {{SELECT COUNT(DISTINCT ) FROM table}} will fetch full data set to
> reduce node.
> Looks like we can add group by ''- push down DISTINCT into map query to
> reduce network pressure.
> See details on nabble [1].
> [1]
> [http://apache-ignite-users.70518.x6.nabble.com/COUNT-DISTINCT-could-push-down-group-expressions-tt20782.html]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8309) Cannot change WAL mode from client node
[
https://issues.apache.org/jira/browse/IGNITE-8309?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-8309:
---
Assignee: (was: Vladimir Ozerov)
> Cannot change WAL mode from client node
> ---
>
> Key: IGNITE-8309
> URL: https://issues.apache.org/jira/browse/IGNITE-8309
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.5
>Reporter: Ilya Kasnacheev
>Priority: Major
>
> I have cluster of a few nodes with persistence region, and a few clients,
> obviously without persistence region.
> When I try to do disableWal(cacheName) on client node, I observe the
> following exception:
> {code}
> Caused by: org.apache.ignite.IgniteCheckedException: Cannot change WAL mode
> because persistence is not enabled for cache(s) [caches=[data0],
> dataRegion=null]
> at
> org.apache.ignite.internal.processors.cache.WalStateManager.errorFuture(WalStateManager.java:759)
> ~[ignite-core-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.WalStateManager.init(WalStateManager.java:292)
> ~[ignite-core-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.changeWalMode(GridCacheProcessor.java:3045)
> ~[ignite-core-2.5.0-SNAPSHOT.jar:2.5.0-SNAPSHOT]
> {code}
> From server node I can disable and enable WAL without problems. Since it's a
> cluster-wide operations, I expect it to be doable from client also.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-8786) session.removeAttribute does not work as expected
[ https://issues.apache.org/jira/browse/IGNITE-8786?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov reassigned IGNITE-8786: --- Assignee: (was: Vladimir Ozerov) > session.removeAttribute does not work as expected > - > > Key: IGNITE-8786 > URL: https://issues.apache.org/jira/browse/IGNITE-8786 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.4, 2.5 > Environment: Java 8, Java 9, Java 10 > Ignite 2.4 and Ignite 2.5 >Reporter: Dana Shaw >Priority: Major > Attachments: server-config.xml > > > Simple Maven project: [https://github.com/gromtech/ignite-web-session-example] > What I'm noticing is that session.removeAttribute doesn't really remove the > attribute, it only sets the value to null. I'm not sure if this is a setup > issue on my end or what. I thought this might be related to jsf, removed jsf > and the issue persists. > Environment: > - Ignite 2.5.0 (1 server node [^server-config.xml]) > - Java 8 -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-8047) SQL: optimize simple COUNT with DISTINCT query.
[ https://issues.apache.org/jira/browse/IGNITE-8047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Ozerov updated IGNITE-8047: Description: "Select COUNT(DISTINCT ) From table;" will fetch full data set to reduce node. Looks like we can add group by ''- push down DISTINCT into map query to reduce network pressure. See details on nabble [1]. [1] [http://apache-ignite-users.70518.x6.nabble.com/COUNT-DISTINCT-could-push-down-group-expressions-tt20782.html] was: "Select COUNT(DISTINCT ) From table;" will fetch full data set to reduce node. Looks like we can -add group by ''- push down DISTINCT into map query to reduce network pressure. See details on nabble [1]. [1] [http://apache-ignite-users.70518.x6.nabble.com/COUNT-DISTINCT-could-push-down-group-expressions-tt20782.html] > SQL: optimize simple COUNT with DISTINCT query. > --- > > Key: IGNITE-8047 > URL: https://issues.apache.org/jira/browse/IGNITE-8047 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrew Mashenkov >Assignee: Vladimir Ozerov >Priority: Major > > "Select COUNT(DISTINCT ) From table;" will fetch full data set to > reduce node. > Looks like we can add group by ''- push down DISTINCT into map query > to reduce network pressure. > See details on nabble [1]. > [1] > [http://apache-ignite-users.70518.x6.nabble.com/COUNT-DISTINCT-could-push-down-group-expressions-tt20782.html] -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-8047) SQL: optimize simple COUNT with DISTINCT query.
[
https://issues.apache.org/jira/browse/IGNITE-8047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov reassigned IGNITE-8047:
---
Assignee: (was: Vladimir Ozerov)
> SQL: optimize simple COUNT with DISTINCT query.
> ---
>
> Key: IGNITE-8047
> URL: https://issues.apache.org/jira/browse/IGNITE-8047
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Andrew Mashenkov
>Priority: Major
> Labels: performance
>
> {{SELECT COUNT(DISTINCT ) FROM table}} will fetch full data set to
> reduce node.
> Looks like we can add group by ''- push down DISTINCT into map query to
> reduce network pressure.
> See details on nabble [1].
> [1]
> [http://apache-ignite-users.70518.x6.nabble.com/COUNT-DISTINCT-could-push-down-group-expressions-tt20782.html]
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-10179) Change new tests root to use @BeforeClass and @AfterClass instead of isFirstTest() and isLastTest()
[
https://issues.apache.org/jira/browse/IGNITE-10179?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16752214#comment-16752214
]
Oleg Ignatenko commented on IGNITE-10179:
-
(i) I decided to drop originally attempted approach ([PR
5878|https://github.com/apache/ignite/pull/5878]) in favor of {{ClassRule}}
based alternative proposed by [~Pavlukhin] - [PR
5925|https://github.com/apache/ignite/pull/5925] which looks simpler and much
more reliable
> Change new tests root to use @BeforeClass and @AfterClass instead of
> isFirstTest() and isLastTest()
> ---
>
> Key: IGNITE-10179
> URL: https://issues.apache.org/jira/browse/IGNITE-10179
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Oleg Ignatenko
>Assignee: Oleg Ignatenko
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> If needed, refer parent task for more details.
> isFirstTest() and isLastTest() homebrew methods seem to be in
> GridAbstractTest only because Junit 3 lacked necessary functionality; after
> migration to Junit 4 these would better changed to use standard API of this
> framework.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
