[jira] [Commented] (IGNITE-14151) Set up commit status publisher on TC
[ https://issues.apache.org/jira/browse/IGNITE-14151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17290669#comment-17290669 ] Peter Ivanov commented on IGNITE-14151: --- No restrictions as soon as account with token has access to target repository for push. > Set up commit status publisher on TC > > > Key: IGNITE-14151 > URL: https://issues.apache.org/jira/browse/IGNITE-14151 > Project: Ignite > Issue Type: Task >Reporter: Valentin Kulichenko >Assignee: Peter Ivanov >Priority: Major > Labels: teamcity > Time Spent: 0.25h > Remaining Estimate: 0h > > 'Run All' build should publish the status to the appropriate PR on GitHub. We > will then update the process to allow merges only with successful builds. > See here: https://www.jetbrains.com/help/teamcity/commit-status-publisher.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14166) Fix javadocs of pulic monitoring API which refer to internal classes
[ https://issues.apache.org/jira/browse/IGNITE-14166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-14166: - Ignite Flags: (was: Docs Required,Release Notes Required) > Fix javadocs of pulic monitoring API which refer to internal classes > > > Key: IGNITE-14166 > URL: https://issues.apache.org/jira/browse/IGNITE-14166 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.11 > > Time Spent: 4.5h > Remaining Estimate: 0h > > Currently, for the public monitoring API, some of javadocs still refer to the > internal implementation GridMetricManager (e.g. CacheGroupMetricsMXBean). > The right links must be the following: > - ReadOnlyMetricRegistry > - ReadOnlyMetricManager > - MetricExporterSpi -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14166) Fix javadocs of pulic monitoring API which refer to internal classes
[ https://issues.apache.org/jira/browse/IGNITE-14166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17290569#comment-17290569 ] Maxim Muzafarov commented on IGNITE-14166: -- Merged to the master branch. [~nizhikov] thank you for the review! > Fix javadocs of pulic monitoring API which refer to internal classes > > > Key: IGNITE-14166 > URL: https://issues.apache.org/jira/browse/IGNITE-14166 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.11 > > Time Spent: 4.5h > Remaining Estimate: 0h > > Currently, for the public monitoring API, some of javadocs still refer to the > internal implementation GridMetricManager (e.g. CacheGroupMetricsMXBean). > The right links must be the following: > - ReadOnlyMetricRegistry > - ReadOnlyMetricManager > - MetricExporterSpi -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14166) Fix javadocs of pulic monitoring API which refer to internal classes
[ https://issues.apache.org/jira/browse/IGNITE-14166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17290568#comment-17290568 ] Maxim Muzafarov commented on IGNITE-14166: -- https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_Javadoc=buildTypeStatusDiv_IgniteTests24Java8=pull%2F8796%2Fhead > Fix javadocs of pulic monitoring API which refer to internal classes > > > Key: IGNITE-14166 > URL: https://issues.apache.org/jira/browse/IGNITE-14166 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.11 > > Time Spent: 4h 20m > Remaining Estimate: 0h > > Currently, for the public monitoring API, some of javadocs still refer to the > internal implementation GridMetricManager (e.g. CacheGroupMetricsMXBean). > The right links must be the following: > - ReadOnlyMetricRegistry > - ReadOnlyMetricManager > - MetricExporterSpi -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14151) Set up commit status publisher on TC
[ https://issues.apache.org/jira/browse/IGNITE-14151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17290550#comment-17290550 ] Valentin Kulichenko commented on IGNITE-14151: -- [~vveider], are there any restrictions on the token that we can use? Can it be your personal token (or mine)? Or we need to do smth different? > Set up commit status publisher on TC > > > Key: IGNITE-14151 > URL: https://issues.apache.org/jira/browse/IGNITE-14151 > Project: Ignite > Issue Type: Task >Reporter: Valentin Kulichenko >Assignee: Peter Ivanov >Priority: Major > Labels: teamcity > Time Spent: 0.25h > Remaining Estimate: 0h > > 'Run All' build should publish the status to the appropriate PR on GitHub. We > will then update the process to allow merges only with successful builds. > See here: https://www.jetbrains.com/help/teamcity/commit-status-publisher.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14240) Handle authentication error on python thin client properly
[ https://issues.apache.org/jira/browse/IGNITE-14240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17290256#comment-17290256 ] Ivan Daschinskiy commented on IGNITE-14240: --- It's ok that build is failed, some steps need to be removed after merging this fix. (unrecognized options due to removal of these options, no ssl suite run separately) > Handle authentication error on python thin client properly > -- > > Key: IGNITE-14240 > URL: https://issues.apache.org/jira/browse/IGNITE-14240 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently, connect succeeded with invalid creds, only after first cache > operation error appears -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14240) Handle authentication error on python thin client properly
[ https://issues.apache.org/jira/browse/IGNITE-14240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17290257#comment-17290257 ] Ivan Daschinskiy commented on IGNITE-14240: --- [~isapego] Patch is ready for review > Handle authentication error on python thin client properly > -- > > Key: IGNITE-14240 > URL: https://issues.apache.org/jira/browse/IGNITE-14240 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently, connect succeeded with invalid creds, only after first cache > operation error appears -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14240) Handle authentication error on python thin client properly
[ https://issues.apache.org/jira/browse/IGNITE-14240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy reassigned IGNITE-14240: - Assignee: Ivan Daschinskiy > Handle authentication error on python thin client properly > -- > > Key: IGNITE-14240 > URL: https://issues.apache.org/jira/browse/IGNITE-14240 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Reporter: Ivan Daschinskiy >Assignee: Ivan Daschinskiy >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently, connect succeeded with invalid creds, only after first cache > operation error appears -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14241) IgniteCacheAbstractQuerySelfTest#testClientQueryExecutedEventsIncludeSensitive broken
[
https://issues.apache.org/jira/browse/IGNITE-14241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-14241:
-
Description:
After 2ed8e7c641f8b57986cd50dca55ff4e5026c9fc3
{{IgniteCacheAbstractQuerySelfTest#testClientQueryExecutedEventsIncludeSensitive}}
is broken.
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-67455213630528885=%3Cdefault%3E=testDetails
was:After 2ed8e7c641f8b57986cd50dca55ff4e5026c9fc3
{{IgniteCacheAbstractQuerySelfTest#testClientQueryExecutedEventsIncludeSensitive}}
is broken.
> IgniteCacheAbstractQuerySelfTest#testClientQueryExecutedEventsIncludeSensitive
> broken
> -
>
> Key: IGNITE-14241
> URL: https://issues.apache.org/jira/browse/IGNITE-14241
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.11
>
>
> After 2ed8e7c641f8b57986cd50dca55ff4e5026c9fc3
> {{IgniteCacheAbstractQuerySelfTest#testClientQueryExecutedEventsIncludeSensitive}}
> is broken.
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-67455213630528885=%3Cdefault%3E=testDetails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14241) IgniteCacheAbstractQuerySelfTest#testClientQueryExecutedEventsIncludeSensitive broken
Nikolay Izhikov created IGNITE-14241:
Summary:
IgniteCacheAbstractQuerySelfTest#testClientQueryExecutedEventsIncludeSensitive
broken
Key: IGNITE-14241
URL: https://issues.apache.org/jira/browse/IGNITE-14241
Project: Ignite
Issue Type: Improvement
Reporter: Nikolay Izhikov
Assignee: Nikolay Izhikov
After 2ed8e7c641f8b57986cd50dca55ff4e5026c9fc3
{{IgniteCacheAbstractQuerySelfTest#testClientQueryExecutedEventsIncludeSensitive}}
is broken.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14241) IgniteCacheAbstractQuerySelfTest#testClientQueryExecutedEventsIncludeSensitive broken
[
https://issues.apache.org/jira/browse/IGNITE-14241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov updated IGNITE-14241:
-
Fix Version/s: 2.11
> IgniteCacheAbstractQuerySelfTest#testClientQueryExecutedEventsIncludeSensitive
> broken
> -
>
> Key: IGNITE-14241
> URL: https://issues.apache.org/jira/browse/IGNITE-14241
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.11
>
>
> After 2ed8e7c641f8b57986cd50dca55ff4e5026c9fc3
> {{IgniteCacheAbstractQuerySelfTest#testClientQueryExecutedEventsIncludeSensitive}}
> is broken.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14240) Handle authentication error on python thin client properly
[ https://issues.apache.org/jira/browse/IGNITE-14240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinskiy updated IGNITE-14240: -- Description: Currently, connect succeeded with invalid creds, only after first cache operation error appears > Handle authentication error on python thin client properly > -- > > Key: IGNITE-14240 > URL: https://issues.apache.org/jira/browse/IGNITE-14240 > Project: Ignite > Issue Type: Bug > Components: python, thin client >Reporter: Ivan Daschinskiy >Priority: Major > > Currently, connect succeeded with invalid creds, only after first cache > operation error appears -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14240) Handle authentication error on python thin client properly
Ivan Daschinskiy created IGNITE-14240: - Summary: Handle authentication error on python thin client properly Key: IGNITE-14240 URL: https://issues.apache.org/jira/browse/IGNITE-14240 Project: Ignite Issue Type: Bug Components: python, thin client Reporter: Ivan Daschinskiy -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14078) Deadlock on GridCacheSharedTtlCleanupManager#mgrs if cache is created when ttl cleanup is running
[
https://issues.apache.org/jira/browse/IGNITE-14078?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-14078:
-
Fix Version/s: (was: 2.11)
2.10
> Deadlock on GridCacheSharedTtlCleanupManager#mgrs if cache is created when
> ttl cleanup is running
> -
>
> Key: IGNITE-14078
> URL: https://issues.apache.org/jira/browse/IGNITE-14078
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> ttl-cleanup-worker does a block of work in ConcurrentHashMap.compute() and
> tries to acquire checkpoint read lock:
> {code:java}
> Thread [name="ttl-cleanup-worker-#120%1%", id=225, state=WAITING, blockCnt=0,
> waitCnt=81486]
> Lock
> [object=java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync@35608c45,
> ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
> at
> o.a.i.i.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1730)
> at
> o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl.expireInternal(IgniteCacheOffheapManagerImpl.java:1346)
> at
> o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl.expire(IgniteCacheOffheapManagerImpl.java:1323)
> at
> o.a.i.i.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:242)
> at
> o.a.i.i.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.lambda$body$0(GridCacheSharedTtlCleanupManager.java:178)
> at
> o.a.i.i.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker$$Lambda$619/1960552474.apply(Unknown
> Source)
> at
> java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769)
> - locked java.util.concurrent.ConcurrentHashMap$Node@4f66c754
> at
> o.a.i.i.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.body(GridCacheSharedTtlCleanupManager.java:177)
> at o.a.i.i.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Meanwhile, exchange thread is waiting on the same ConcurrentHashMap node:
> {code:java}
> Thread [name="exchange-worker-#93%1%", id=193, state=BLOCKED, blockCnt=8,
> waitCnt=1669]
> Lock [object=java.util.concurrent.ConcurrentHashMap$Node@4f66c754,
> ownerName=ttl-cleanup-worker-#120%1%, ownerId=225]
> at
> java.util.concurrent.ConcurrentHashMap.transfer(ConcurrentHashMap.java:2426)
> at
> java.util.concurrent.ConcurrentHashMap.addCount(ConcurrentHashMap.java:2288)
> at
> java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1070)
> at
> java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1006)
> at
> o.a.i.i.processors.cache.GridCacheSharedTtlCleanupManager.register(GridCacheSharedTtlCleanupManager.java:68)
> at
> o.a.i.i.processors.cache.GridCacheTtlManager.start0(GridCacheTtlManager.java:107)
> at
> o.a.i.i.processors.cache.GridCacheManagerAdapter.start(GridCacheManagerAdapter.java:49)
> at
> o.a.i.i.processors.cache.GridCacheProcessor.initCacheContext(GridCacheProcessor.java:2176)
> at
> o.a.i.i.processors.cache.GridCacheProcessor.prepareCacheContext(GridCacheProcessor.java:1964)
> at
> o.a.i.i.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1883)
> at
> o.a.i.i.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$55a0e703$1(GridCacheProcessor.java:1758)
> at
> o.a.i.i.processors.cache.GridCacheProcessor$$Lambda$527/649205444.apply(Unknown
> Source)
> at
> o.a.i.i.processors.cache.GridCacheProcessor.lambda$prepareStartCachesIfPossible$14(GridCacheProcessor.java:1728)
> at
> o.a.i.i.processors.cache.GridCacheProcessor$$Lambda$526/1117407359.handle(Unknown
> Source)
> at
> o.a.i.i.processors.cache.GridCacheProcessor.prepareStartCaches(GridCacheProcessor.java:1755)
> at
>
[jira] [Commented] (IGNITE-13472) JDBC bulkload operations are processed with wrong security context
[
https://issues.apache.org/jira/browse/IGNITE-13472?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17290074#comment-17290074
]
Maxim Muzafarov commented on IGNITE-13472:
--
Cherry-picked to 2.10
> JDBC bulkload operations are processed with wrong security context
> --
>
> Key: IGNITE-13472
> URL: https://issues.apache.org/jira/browse/IGNITE-13472
> Project: Ignite
> Issue Type: Bug
>Reporter: Ryabov Dmitrii
>Assignee: Ryabov Dmitrii
>Priority: Minor
> Fix For: 2.10
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> {{JdbcAuthorizationTest.testCopyFrom()}} have many exceptions like
> {code:java}
> [12:02:56] (err) Failed to execute compound future reducer:
> GridCompoundFuture [rdc=null, initFlag=1, lsnrCalls=0, done=false,
> cancelled=false, err=null, futs=TransformCollectionView [true]]class
> org.apache.ignite.IgniteCheckedException: Authorization failed
> [perm=CACHE_PUT, name=test-bulkload-cache,
> subject=TestSecuritySubject{id=ca0e2ed9-f877-4c49-a80e-11a1c7a0,
> type=REMOTE_NODE, login=jdbc.JdbcAuthorizationTest0}]
> at
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7589)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:979)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:569)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.plugin.security.SecurityException:
> Authorization failed [perm=CACHE_PUT, name=test-bulkload-cache,
> subject=TestSecuritySubject{id=ca0e2ed9-f877-4c49-a80e-11a1c7a0,
> type=REMOTE_NODE, login=jdbc.JdbcAuthorizationTest0}]
> at
> org.apache.ignite.internal.processors.security.impl.TestSecurityProcessor.authorize(TestSecurityProcessor.java:153)
> at
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.authorize(IgniteSecurityProcessor.java:207)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerUpdateJob.checkSecurityPermission(DataStreamerUpdateJob.java:170)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerUpdateJob.call(DataStreamerUpdateJob.java:123)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7087)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:971)
> ... 4 more
> {code}
> This exception means the put operation is processed with node context instead
> of user. Also, operation doesn't finish successfully.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14078) Deadlock on GridCacheSharedTtlCleanupManager#mgrs if cache is created when ttl cleanup is running
[
https://issues.apache.org/jira/browse/IGNITE-14078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17290075#comment-17290075
]
Maxim Muzafarov commented on IGNITE-14078:
--
Cherry-picked to 2.10
> Deadlock on GridCacheSharedTtlCleanupManager#mgrs if cache is created when
> ttl cleanup is running
> -
>
> Key: IGNITE-14078
> URL: https://issues.apache.org/jira/browse/IGNITE-14078
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> ttl-cleanup-worker does a block of work in ConcurrentHashMap.compute() and
> tries to acquire checkpoint read lock:
> {code:java}
> Thread [name="ttl-cleanup-worker-#120%1%", id=225, state=WAITING, blockCnt=0,
> waitCnt=81486]
> Lock
> [object=java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync@35608c45,
> ownerName=null, ownerId=-1]
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireShared(AbstractQueuedSynchronizer.java:967)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireShared(AbstractQueuedSynchronizer.java:1283)
> at
> java.util.concurrent.locks.ReentrantReadWriteLock$ReadLock.lock(ReentrantReadWriteLock.java:727)
> at
> o.a.i.i.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1730)
> at
> o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl.expireInternal(IgniteCacheOffheapManagerImpl.java:1346)
> at
> o.a.i.i.processors.cache.IgniteCacheOffheapManagerImpl.expire(IgniteCacheOffheapManagerImpl.java:1323)
> at
> o.a.i.i.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:242)
> at
> o.a.i.i.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.lambda$body$0(GridCacheSharedTtlCleanupManager.java:178)
> at
> o.a.i.i.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker$$Lambda$619/1960552474.apply(Unknown
> Source)
> at
> java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769)
> - locked java.util.concurrent.ConcurrentHashMap$Node@4f66c754
> at
> o.a.i.i.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.body(GridCacheSharedTtlCleanupManager.java:177)
> at o.a.i.i.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Meanwhile, exchange thread is waiting on the same ConcurrentHashMap node:
> {code:java}
> Thread [name="exchange-worker-#93%1%", id=193, state=BLOCKED, blockCnt=8,
> waitCnt=1669]
> Lock [object=java.util.concurrent.ConcurrentHashMap$Node@4f66c754,
> ownerName=ttl-cleanup-worker-#120%1%, ownerId=225]
> at
> java.util.concurrent.ConcurrentHashMap.transfer(ConcurrentHashMap.java:2426)
> at
> java.util.concurrent.ConcurrentHashMap.addCount(ConcurrentHashMap.java:2288)
> at
> java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1070)
> at
> java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1006)
> at
> o.a.i.i.processors.cache.GridCacheSharedTtlCleanupManager.register(GridCacheSharedTtlCleanupManager.java:68)
> at
> o.a.i.i.processors.cache.GridCacheTtlManager.start0(GridCacheTtlManager.java:107)
> at
> o.a.i.i.processors.cache.GridCacheManagerAdapter.start(GridCacheManagerAdapter.java:49)
> at
> o.a.i.i.processors.cache.GridCacheProcessor.initCacheContext(GridCacheProcessor.java:2176)
> at
> o.a.i.i.processors.cache.GridCacheProcessor.prepareCacheContext(GridCacheProcessor.java:1964)
> at
> o.a.i.i.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1883)
> at
> o.a.i.i.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$55a0e703$1(GridCacheProcessor.java:1758)
> at
> o.a.i.i.processors.cache.GridCacheProcessor$$Lambda$527/649205444.apply(Unknown
> Source)
> at
> o.a.i.i.processors.cache.GridCacheProcessor.lambda$prepareStartCachesIfPossible$14(GridCacheProcessor.java:1728)
> at
> o.a.i.i.processors.cache.GridCacheProcessor$$Lambda$526/1117407359.handle(Unknown
> Source)
> at
> o.a.i.i.processors.cache.GridCacheProcessor.prepareStartCaches(GridCacheProcessor.java:1755)
> at
>
[jira] [Updated] (IGNITE-13472) JDBC bulkload operations are processed with wrong security context
[
https://issues.apache.org/jira/browse/IGNITE-13472?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-13472:
-
Fix Version/s: (was: 2.11)
2.10
> JDBC bulkload operations are processed with wrong security context
> --
>
> Key: IGNITE-13472
> URL: https://issues.apache.org/jira/browse/IGNITE-13472
> Project: Ignite
> Issue Type: Bug
>Reporter: Ryabov Dmitrii
>Assignee: Ryabov Dmitrii
>Priority: Minor
> Fix For: 2.10
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> {{JdbcAuthorizationTest.testCopyFrom()}} have many exceptions like
> {code:java}
> [12:02:56] (err) Failed to execute compound future reducer:
> GridCompoundFuture [rdc=null, initFlag=1, lsnrCalls=0, done=false,
> cancelled=false, err=null, futs=TransformCollectionView [true]]class
> org.apache.ignite.IgniteCheckedException: Authorization failed
> [perm=CACHE_PUT, name=test-bulkload-cache,
> subject=TestSecuritySubject{id=ca0e2ed9-f877-4c49-a80e-11a1c7a0,
> type=REMOTE_NODE, login=jdbc.JdbcAuthorizationTest0}]
> at
> org.apache.ignite.internal.util.IgniteUtils.cast(IgniteUtils.java:7589)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:979)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:569)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> Caused by: class org.apache.ignite.plugin.security.SecurityException:
> Authorization failed [perm=CACHE_PUT, name=test-bulkload-cache,
> subject=TestSecuritySubject{id=ca0e2ed9-f877-4c49-a80e-11a1c7a0,
> type=REMOTE_NODE, login=jdbc.JdbcAuthorizationTest0}]
> at
> org.apache.ignite.internal.processors.security.impl.TestSecurityProcessor.authorize(TestSecurityProcessor.java:153)
> at
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.authorize(IgniteSecurityProcessor.java:207)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerUpdateJob.checkSecurityPermission(DataStreamerUpdateJob.java:170)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamerUpdateJob.call(DataStreamerUpdateJob.java:123)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7087)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$2.body(GridClosureProcessor.java:971)
> ... 4 more
> {code}
> This exception means the put operation is processed with node context instead
> of user. Also, operation doesn't finish successfully.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14239) Raft based implementation of atomic protocol
Vyacheslav Koptilin created IGNITE-14239: Summary: Raft based implementation of atomic protocol Key: IGNITE-14239 URL: https://issues.apache.org/jira/browse/IGNITE-14239 Project: Ignite Issue Type: Sub-task Reporter: Vyacheslav Koptilin Implement a new atomic protocol based on raft client api [1] [1] IGNITE-14149 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14151) Set up commit status publisher on TC
[ https://issues.apache.org/jira/browse/IGNITE-14151?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17290050#comment-17290050 ] Peter Ivanov commented on IGNITE-14151: --- [~vkulichenko], according to setup instructions, we need token with *_public_repo_* or *_repo_* scope. After that, I will be able to setup publishing integration. However, please, be advised, that this publishing is one way only and PR will receive any status only after build is completed (pending build is not shown AFAIK). > Set up commit status publisher on TC > > > Key: IGNITE-14151 > URL: https://issues.apache.org/jira/browse/IGNITE-14151 > Project: Ignite > Issue Type: Task >Reporter: Valentin Kulichenko >Assignee: Peter Ivanov >Priority: Major > Labels: teamcity > > 'Run All' build should publish the status to the appropriate PR on GitHub. We > will then update the process to allow merges only with successful builds. > See here: https://www.jetbrains.com/help/teamcity/commit-status-publisher.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14238) Creating and destroying caches
[ https://issues.apache.org/jira/browse/IGNITE-14238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-14238: - Parent: IGNITE-14199 Issue Type: Sub-task (was: Bug) > Creating and destroying caches > -- > > Key: IGNITE-14238 > URL: https://issues.apache.org/jira/browse/IGNITE-14238 > Project: Ignite > Issue Type: Sub-task >Reporter: Vyacheslav Koptilin >Priority: Major > > Need to implement a new cluster-wide procedure that will be responsible for > creating and destroying caches. > [1] > https://cwiki.apache.org/confluence/display/IGNITE/IEP-54%3A+Schema-first+Approach -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14236) Provide a new version of cache API
[
https://issues.apache.org/jira/browse/IGNITE-14236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17290049#comment-17290049
]
Atri Sharma commented on IGNITE-14236:
--
[~slava.koptilin] This looks like a fun one! Is this something I can help with?
> Provide a new version of cache API
> --
>
> Key: IGNITE-14236
> URL: https://issues.apache.org/jira/browse/IGNITE-14236
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vyacheslav Koptilin
>Priority: Major
> Labels: ignite-3
>
> Need to provide a minimal cache API that includes at least the following
> methods:
> - reading a value for a given key
> - writing a new value for a given key
> - remove a value for a given key
> - method that determines if the cache contains an entry for the specified
> key.
> - a way to iterate all key/value pairs
> - cache/table size (this method is questionable)
> Additionally, it can be considered adding a way to execute the user's code
> for the specified key - something like {{Cache#invoke()}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14238) Creating and destroying caches
Vyacheslav Koptilin created IGNITE-14238: Summary: Creating and destroying caches Key: IGNITE-14238 URL: https://issues.apache.org/jira/browse/IGNITE-14238 Project: Ignite Issue Type: Bug Reporter: Vyacheslav Koptilin Need to implement a new cluster-wide procedure that will be responsible for creating and destroying caches. [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-54%3A+Schema-first+Approach -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14237) Affinity function
Vyacheslav Koptilin created IGNITE-14237: Summary: Affinity function Key: IGNITE-14237 URL: https://issues.apache.org/jira/browse/IGNITE-14237 Project: Ignite Issue Type: Sub-task Reporter: Vyacheslav Koptilin It seems that we need to adopt a well-known rendezvous affinity function to AI-3.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14236) Provide a new version of cache API
Vyacheslav Koptilin created IGNITE-14236:
Summary: Provide a new version of cache API
Key: IGNITE-14236
URL: https://issues.apache.org/jira/browse/IGNITE-14236
Project: Ignite
Issue Type: Sub-task
Reporter: Vyacheslav Koptilin
Need to provide a minimal cache API that includes at least the following
methods:
- reading a value for a given key
- writing a new value for a given key
- remove a value for a given key
- method that determines if the cache contains an entry for the specified key.
- a way to iterate all key/value pairs
- cache/table size (this method is questionable)
Additionally, it can be considered adding a way to execute the user's code for
the specified key - something like {{Cache#invoke()}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14016) Prepare an RPM package for Ignite 3.0
[ https://issues.apache.org/jira/browse/IGNITE-14016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Peter Ivanov updated IGNITE-14016: -- Attachment: apache-ignite-3.0.0-1.noarch.rpm > Prepare an RPM package for Ignite 3.0 > - > > Key: IGNITE-14016 > URL: https://issues.apache.org/jira/browse/IGNITE-14016 > Project: Ignite > Issue Type: Task >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > Attachments: apache-ignite-3.0.0-1.noarch.rpm, rhel.log > > Time Spent: 0.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14235) Provide a minimal cache/table configuration
Vyacheslav Koptilin created IGNITE-14235: Summary: Provide a minimal cache/table configuration Key: IGNITE-14235 URL: https://issues.apache.org/jira/browse/IGNITE-14235 Project: Ignite Issue Type: Sub-task Reporter: Vyacheslav Koptilin Need to provide a way to configure a cache/table in accordance with IEP-55 Unified Configuration [1] and IEP-54 Schema first approach. [1] https://cwiki.apache.org/confluence/display/IGNITE/IEP-55+Unified+Configuration [2] https://cwiki.apache.org/confluence/display/IGNITE/IEP-54%3A+Schema-first+Approach -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14234) Tracing framework
Vyacheslav Koptilin created IGNITE-14234: Summary: Tracing framework Key: IGNITE-14234 URL: https://issues.apache.org/jira/browse/IGNITE-14234 Project: Ignite Issue Type: New Feature Reporter: Vyacheslav Koptilin Need to port and adapt tracing framework from AI2.x to AI3.0. It would be nice to add a new integration with OpenTelemetry. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14233) Metrics framework
Vyacheslav Koptilin created IGNITE-14233: Summary: Metrics framework Key: IGNITE-14233 URL: https://issues.apache.org/jira/browse/IGNITE-14233 Project: Ignite Issue Type: New Feature Reporter: Vyacheslav Koptilin Need to adapt and port metrics framework from AI2.x to AI3.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14232) IgniteCliInterfaceTest and ProgressBarTest fails in some terminals
Kirill Gusakov created IGNITE-14232: --- Summary: IgniteCliInterfaceTest and ProgressBarTest fails in some terminals Key: IGNITE-14232 URL: https://issues.apache.org/jira/browse/IGNITE-14232 Project: Ignite Issue Type: Task Reporter: Kirill Gusakov Assignee: Kirill Gusakov In Cygwin/Git Bash terminals under the Windows all tests with ANSI symbols are failing. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14231) IGNITE_ENABLE_FORCIBLE_NODE_KILL flag is not supported in inverse connection request scenario
[ https://issues.apache.org/jira/browse/IGNITE-14231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-14231: - Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > IGNITE_ENABLE_FORCIBLE_NODE_KILL flag is not supported in inverse connection > request scenario > - > > Key: IGNITE-14231 > URL: https://issues.apache.org/jira/browse/IGNITE-14231 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.9.1 >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.11 > > > IGNITE_ENABLE_FORCIBLE_NODE_KILL flag enables server nodes to forcibly kill > clients visible via Discovery but unreachable by Communication protocol. > This leads to infinite loops when server tries to establish communication > connection to unreachable client fails and tries again effectively ignoring > the flag. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14231) IGNITE_ENABLE_FORCIBLE_NODE_KILL flag is not supported in inverse connection request scenario
[ https://issues.apache.org/jira/browse/IGNITE-14231?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-14231: - Component/s: networking > IGNITE_ENABLE_FORCIBLE_NODE_KILL flag is not supported in inverse connection > request scenario > - > > Key: IGNITE-14231 > URL: https://issues.apache.org/jira/browse/IGNITE-14231 > Project: Ignite > Issue Type: Bug > Components: networking >Affects Versions: 2.9.1 >Reporter: Sergey Chugunov >Assignee: Sergey Chugunov >Priority: Major > Fix For: 2.11 > > > IGNITE_ENABLE_FORCIBLE_NODE_KILL flag enables server nodes to forcibly kill > clients visible via Discovery but unreachable by Communication protocol. > This leads to infinite loops when server tries to establish communication > connection to unreachable client fails and tries again effectively ignoring > the flag. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14231) IGNITE_ENABLE_FORCIBLE_NODE_KILL flag is not supported in inverse connection request scenario
Sergey Chugunov created IGNITE-14231: Summary: IGNITE_ENABLE_FORCIBLE_NODE_KILL flag is not supported in inverse connection request scenario Key: IGNITE-14231 URL: https://issues.apache.org/jira/browse/IGNITE-14231 Project: Ignite Issue Type: Bug Affects Versions: 2.9.1 Reporter: Sergey Chugunov Assignee: Sergey Chugunov Fix For: 2.11 IGNITE_ENABLE_FORCIBLE_NODE_KILL flag enables server nodes to forcibly kill clients visible via Discovery but unreachable by Communication protocol. This leads to infinite loops when server tries to establish communication connection to unreachable client fails and tries again effectively ignoring the flag. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14230) Port DynamicConfiguration to new underlying configuration framework.
Ivan Bessonov created IGNITE-14230: -- Summary: Port DynamicConfiguration to new underlying configuration framework. Key: IGNITE-14230 URL: https://issues.apache.org/jira/browse/IGNITE-14230 Project: Ignite Issue Type: Sub-task Reporter: Ivan Bessonov Assignee: Ivan Bessonov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14221) SQL Constants not hidden in IGNITE_TO_STRING_INCLUDE_SENSITIVE=false
[
https://issues.apache.org/jira/browse/IGNITE-14221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17289965#comment-17289965
]
Stanilovsky Evgeny commented on IGNITE-14221:
-
overall looks good to me.
> SQL Constants not hidden in IGNITE_TO_STRING_INCLUDE_SENSITIVE=false
>
>
> Key: IGNITE-14221
> URL: https://issues.apache.org/jira/browse/IGNITE-14221
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Time Spent: 6h 10m
> Remaining Estimate: 0h
>
> Currently, SQL constants not hidden if
> {{IGNITE_TO_STRING_INCLUDE_SENSITIVE=false}}.
> This can lead to security incidents when some applications don't use SQL
> parameters and send constant in query body.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14229) Calcite bug. Engine can hangs
Yury Gerzhedovich created IGNITE-14229:
--
Summary: Calcite bug. Engine can hangs
Key: IGNITE-14229
URL: https://issues.apache.org/jira/browse/IGNITE-14229
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Yury Gerzhedovich
The Calcite SQL engine can hang during query execution due to some Exception
which not properly handled.
For example, try to execute query 'select reverse('NAME') from person'. As
result will be following exception and hangs execution.
{code:java}
java.lang.NullPointerException
at
org.apache.calcite.rex.RexBuilder.deriveReturnType(RexBuilder.java:283)
at
org.apache.ignite.internal.processors.query.calcite.externalize.RelJson.toRex(RelJson.java:444)
at
org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader$RelInputImpl.getExpressionList(RelJsonReader.java:239)
at
org.apache.ignite.internal.processors.query.calcite.trait.TraitUtils$1.getExpressionList(TraitUtils.java:308)
at
org.apache.ignite.internal.processors.query.calcite.rel.ProjectableFilterableTableScan.(ProjectableFilterableTableScan.java:85)
at
org.apache.ignite.internal.processors.query.calcite.rel.IgniteTableScan.(IgniteTableScan.java:46)
at SC.apply(Unknown Source)
at
org.apache.ignite.internal.processors.query.calcite.externalize.RelJson$RelFactory.apply(RelJson.java:115)
at
org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader.readRel(RelJsonReader.java:112)
at
org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader.readRels(RelJsonReader.java:104)
at
org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader.read(RelJsonReader.java:93)
at
org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader.fromJson(RelJsonReader.java:78)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareFragment(ExecutionServiceImpl.java:528)
at
org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.queryPlan(QueryPlanCacheImpl.java:84)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.onMessage(ExecutionServiceImpl.java:847)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.lambda$init$1(ExecutionServiceImpl.java:440)
at
org.apache.ignite.internal.processors.query.calcite.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:276)
at
org.apache.ignite.internal.processors.query.calcite.message.MessageServiceImpl.lambda$onMessage$0(MessageServiceImpl.java:256)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
[2021-02-24
17:04:40,816][ERROR][calciteQry-#265%calcite.AggregatesIntegrationTest1%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
[type=CRITICAL_ERROR, err=java.lang.NullPointerException]]
java.lang.NullPointerException
at
org.apache.calcite.rex.RexBuilder.deriveReturnType(RexBuilder.java:283)
at
org.apache.ignite.internal.processors.query.calcite.externalize.RelJson.toRex(RelJson.java:444)
at
org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader$RelInputImpl.getExpressionList(RelJsonReader.java:239)
at
org.apache.ignite.internal.processors.query.calcite.trait.TraitUtils$1.getExpressionList(TraitUtils.java:308)
at
org.apache.ignite.internal.processors.query.calcite.rel.ProjectableFilterableTableScan.(ProjectableFilterableTableScan.java:85)
at
org.apache.ignite.internal.processors.query.calcite.rel.IgniteTableScan.(IgniteTableScan.java:46)
at SC.apply(Unknown Source)
at
org.apache.ignite.internal.processors.query.calcite.externalize.RelJson$RelFactory.apply(RelJson.java:115)
at
org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader.readRel(RelJsonReader.java:112)
at
org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader.readRels(RelJsonReader.java:104)
at
org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader.read(RelJsonReader.java:93)
at
org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader.fromJson(RelJsonReader.java:78)
at
org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareFragment(ExecutionServiceImpl.java:528)
[jira] [Commented] (IGNITE-14175) Update metric for loaded keys through rebalance once at the demand message
[
https://issues.apache.org/jira/browse/IGNITE-14175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17289924#comment-17289924
]
Vyacheslav Koptilin commented on IGNITE-14175:
--
Hello [~ktkale...@gridgain.com],
Thanks for your contribution. Merged to master branch.
> Update metric for loaded keys through rebalance once at the demand message
> --
>
> Key: IGNITE-14175
> URL: https://issues.apache.org/jira/browse/IGNITE-14175
> Project: Ignite
> Issue Type: Improvement
> Components: cache
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We are consuming more than half of all rebalance time to updating metrics,
> even if the statistic does not enable in the cache.
> The problem is here:
> {code:java}
> //TODO: IGNITE-11330: Update metrics for touched cache only.
> for (GridCacheContext ctx : grp.caches()) {
> if (ctx.statisticsEnabled())
> ctx.cache().metrics0().onRebalanceKeyReceived();
> }
> {code}
> It needs to update once for one demand message and only if the statistic
> enabled on the cache.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14228) Ducktape test of rebalance for in-memory mode
Dmitriy Sorokin created IGNITE-14228: Summary: Ducktape test of rebalance for in-memory mode Key: IGNITE-14228 URL: https://issues.apache.org/jira/browse/IGNITE-14228 Project: Ignite Issue Type: Sub-task Reporter: Dmitriy Sorokin Assignee: Dmitriy Sorokin This test should check the rebalance on in-memory caches in basic scenario. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14223) Remove FilePageStoreFactory internal interface
[ https://issues.apache.org/jira/browse/IGNITE-14223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17289845#comment-17289845 ] Maxim Muzafarov commented on IGNITE-14223: -- Merged to the master branch, thank you for the review! > Remove FilePageStoreFactory internal interface > -- > > Key: IGNITE-14223 > URL: https://issues.apache.org/jira/browse/IGNITE-14223 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.11 > > Time Spent: 20m > Remaining Estimate: 0h > > The FilePageStoreFactory can be simplified since this factory has a single > implementation that produces FilePageStore's. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14227) Partition map exchange may hang if the cluster is deactivated during cache start failure handling.
ntOrder=1, lastExchangeTime=1614163031766, loc=false, ver=2.11.0#20210224-sha1:, isClient=false], topVer=2, msgTemplate=null, span=o.a.i.i.processors.tracing.NoopSpan@7e02a8f5, nodeId8=02c46b75, msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1614163031926]], nodeId=b05182d2, evt=DISCOVERY_CUSTOM_EVT], caches=[o.a.i.i.processors.cache.ExchangeActions$CacheGroupActionData@50838b34]] class org.apache.ignite.IgniteCheckedException: Requested DataRegion is not configured: absent at org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.dataRegion(IgniteCacheDatabaseSharedManager.java:911) at org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheGroup(GridCacheProcessor.java:2467) at org.apache.ignite.internal.processors.cache.GridCacheProcessor.getOrCreateCacheGroupContext(GridCacheProcessor.java:2205) at org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheContext(GridCacheProcessor.java:2012) at org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1946) at org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$55a0e703$1(GridCacheProcessor.java:1821) at org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCachesIfPossible$14(GridCacheProcessor.java:1791) at org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareStartCaches(GridCacheProcessor.java:1818) at org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareStartCachesIfPossible(GridCacheProcessor.java:1789) at org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processCacheStartRequests(CacheAffinitySharedManager.java:996) at org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:882) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:1450) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:948) at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3387) at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:3209) at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) at java.lang.Thread.run(Thread.java:748) [2021-02-24 13:37:11,945][ERROR][exchange-worker-#61%cache.DynamicCacheStartFailTest0%][GridDhtPartitionsExchangeFuture] Failed to initialize cache(s) (will try to rollback) [exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=2, minorTopVer=2], discoEvt=DiscoveryCustomEvent [customMsg=DynamicCacheChangeBatch [id=af52d93d771-bd608b2d-8308-4556-9f9f-91bae6049b7c, reqs=ArrayList [DynamicCacheChangeRequest [cacheName=cache1, hasCfg=true, nodeId=b05182d2-c6e8-4b5b-bde2-576e1e70, clientStartOnly=false, stop=false, destroy=false, disabledAfterStartfalse]], exchangeActions=ExchangeActions [startCaches=[cache1], stopCaches=null, startGrps=[cache1], stopGrps=[], resetParts=null, stateChangeRequest=null], startCaches=false], affTopVer=AffinityTopologyVersion [topVer=2, minorTopVer=2], super=DiscoveryEvent [evtNode=TcpDiscoveryNode [id=b05182d2-c6e8-4b5b-bde2-576e1e70, consistentId=9bc35ede-4ab7-44cb-9d15-0d7215350ed3, addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, lastExchangeTime=1614163031926, loc=true, ver=2.11.0#20210224-sha1:, isClient=false], topVer=2, msgTemplate=null, span=o.a.i.i.processors.tracing.NoopSpan@7e02a8f5, nodeId8=b05182d2, msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1614163031926]], nodeId=b05182d2, evt=DISCOVERY_CUSTOM_EVT], caches=[o.a.i.i.processors.cache.ExchangeActions$CacheGroupActionData@cc19771]] class org.apache.ignite.IgniteCheckedException: Requested DataRegion is not configured: absent at org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.dataRegion(IgniteCacheDatabaseSharedManager.java:911) at org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheGroup(GridCacheProcessor.java:2467) at org.apache.ignite.internal.processors.cache.GridCacheProcessor.getOrCreateCacheGroupContext(GridCacheProcessor.java:2205) at org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheContext(GridCacheProcessor.java:2012) at org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1946) at org.apache.
[jira] [Commented] (IGNITE-14223) Remove FilePageStoreFactory internal interface
[
https://issues.apache.org/jira/browse/IGNITE-14223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17289844#comment-17289844
]
Ignite TC Bot commented on IGNITE-14223:
{panel:title=Branch: [pull/8823/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8823/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5889113buildTypeId=IgniteTests24Java8_RunAll]
> Remove FilePageStoreFactory internal interface
> --
>
> Key: IGNITE-14223
> URL: https://issues.apache.org/jira/browse/IGNITE-14223
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.11
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The FilePageStoreFactory can be simplified since this factory has a single
> implementation that produces FilePageStore's.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-14227) Partition map exchange may hang if the cluster is deactivated during cache start failure handling.
b-bde2-576e1e70, consistentId=9bc35ede-4ab7-44cb-9d15-0d7215350ed3, addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, lastExchangeTime=1614163031766, loc=false, ver=2.11.0#20210224-sha1:, isClient=false], topVer=2, msgTemplate=null, span=o.a.i.i.processors.tracing.NoopSpan@7e02a8f5, nodeId8=02c46b75, msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1614163031926]], nodeId=b05182d2, evt=DISCOVERY_CUSTOM_EVT], caches=[o.a.i.i.processors.cache.ExchangeActions$CacheGroupActionData@50838b34]] class org.apache.ignite.IgniteCheckedException: Requested DataRegion is not configured: absent at org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.dataRegion(IgniteCacheDatabaseSharedManager.java:911) at org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheGroup(GridCacheProcessor.java:2467) at org.apache.ignite.internal.processors.cache.GridCacheProcessor.getOrCreateCacheGroupContext(GridCacheProcessor.java:2205) at org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheContext(GridCacheProcessor.java:2012) at org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStart(GridCacheProcessor.java:1946) at org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCaches$55a0e703$1(GridCacheProcessor.java:1821) at org.apache.ignite.internal.processors.cache.GridCacheProcessor.lambda$prepareStartCachesIfPossible$14(GridCacheProcessor.java:1791) at org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareStartCaches(GridCacheProcessor.java:1818) at org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareStartCachesIfPossible(GridCacheProcessor.java:1789) at org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.processCacheStartRequests(CacheAffinitySharedManager.java:996) at org.apache.ignite.internal.processors.cache.CacheAffinitySharedManager.onCacheChangeRequest(CacheAffinitySharedManager.java:882) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.onCacheChangeRequest(GridDhtPartitionsExchangeFuture.java:1450) at org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture.init(GridDhtPartitionsExchangeFuture.java:948) at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body0(GridCachePartitionExchangeManager.java:3387) at org.apache.ignite.internal.processors.cache.GridCachePartitionExchangeManager$ExchangeWorker.body(GridCachePartitionExchangeManager.java:3209) at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) at java.lang.Thread.run(Thread.java:748) [2021-02-24 13:37:11,945][ERROR][exchange-worker-#61%cache.DynamicCacheStartFailTest0%][GridDhtPartitionsExchangeFuture] Failed to initialize cache(s) (will try to rollback) [exchId=GridDhtPartitionExchangeId [topVer=AffinityTopologyVersion [topVer=2, minorTopVer=2], discoEvt=DiscoveryCustomEvent [customMsg=DynamicCacheChangeBatch [id=af52d93d771-bd608b2d-8308-4556-9f9f-91bae6049b7c, reqs=ArrayList [DynamicCacheChangeRequest [cacheName=cache1, hasCfg=true, nodeId=b05182d2-c6e8-4b5b-bde2-576e1e70, clientStartOnly=false, stop=false, destroy=false, disabledAfterStartfalse]], exchangeActions=ExchangeActions [startCaches=[cache1], stopCaches=null, startGrps=[cache1], stopGrps=[], resetParts=null, stateChangeRequest=null], startCaches=false], affTopVer=AffinityTopologyVersion [topVer=2, minorTopVer=2], super=DiscoveryEvent [evtNode=TcpDiscoveryNode [id=b05182d2-c6e8-4b5b-bde2-576e1e70, consistentId=9bc35ede-4ab7-44cb-9d15-0d7215350ed3, addrs=ArrayList [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47500], discPort=47500, order=1, intOrder=1, lastExchangeTime=1614163031926, loc=true, ver=2.11.0#20210224-sha1:, isClient=false], topVer=2, msgTemplate=null, span=o.a.i.i.processors.tracing.NoopSpan@7e02a8f5, nodeId8=b05182d2, msg=null, type=DISCOVERY_CUSTOM_EVT, tstamp=1614163031926]], nodeId=b05182d2, evt=DISCOVERY_CUSTOM_EVT], caches=[o.a.i.i.processors.cache.ExchangeActions$CacheGroupActionData@cc19771]] class org.apache.ignite.IgniteCheckedException: Requested DataRegion is not configured: absent at org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.dataRegion(IgniteCacheDatabaseSharedManager.java:911) at org.apache.ignite.internal.processors.cache.GridCacheProcessor.startCacheGroup(GridCacheProcessor.java:2467) at org.apache.ignite.internal.processors.cache.GridCacheProcessor.getOrCreateCacheGroupContext(GridCacheProcessor.java:2205) at org.apache.ignite.internal.processors.cache.GridCache
[jira] [Commented] (IGNITE-14221) SQL Constants not hidden in IGNITE_TO_STRING_INCLUDE_SENSITIVE=false
[
https://issues.apache.org/jira/browse/IGNITE-14221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17289826#comment-17289826
]
Nikolay Izhikov commented on IGNITE-14221:
--
Hello, [~ktkale...@gridgain.com]
Thanks for the feedback.
Not yet.
The review is in the progress, so I get the visa once it's over.
> SQL Constants not hidden in IGNITE_TO_STRING_INCLUDE_SENSITIVE=false
>
>
> Key: IGNITE-14221
> URL: https://issues.apache.org/jira/browse/IGNITE-14221
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Currently, SQL constants not hidden if
> {{IGNITE_TO_STRING_INCLUDE_SENSITIVE=false}}.
> This can lead to security incidents when some applications don't use SQL
> parameters and send constant in query body.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-14221) SQL Constants not hidden in IGNITE_TO_STRING_INCLUDE_SENSITIVE=false
[
https://issues.apache.org/jira/browse/IGNITE-14221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17289824#comment-17289824
]
Kirill Tkalenko commented on IGNITE-14221:
--
[~nizhikov] Hi! Is there a visa?
> SQL Constants not hidden in IGNITE_TO_STRING_INCLUDE_SENSITIVE=false
>
>
> Key: IGNITE-14221
> URL: https://issues.apache.org/jira/browse/IGNITE-14221
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> Currently, SQL constants not hidden if
> {{IGNITE_TO_STRING_INCLUDE_SENSITIVE=false}}.
> This can lead to security incidents when some applications don't use SQL
> parameters and send constant in query body.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14226) Ducktape test of rebalance
[ https://issues.apache.org/jira/browse/IGNITE-14226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin updated IGNITE-14226: - Description: The test should check the rebalance on both in-memory caches and persistent caches. In case of persistent caches, the test also should check both modes of rebalance: full and historical (asserts is needed that the proper mode of rebalance was worked). Basic scenario: Testing of rebalance triggered by two event types: node enter and node leave (baseline change in persistent mode). Extended scenario: Node entering or leaving during rebalance process. Test parameters: # Initial node count; # Cache count; # Cache entry count; # Cache entry size; # Mode: in-memory or persistence; # Rebalance trigger event: node enter or node leave. Test result: time taken to rebalance process. was: The test should check the rebalance on both in-memory caches and persistent caches. In case of persistent caches, the test also should check both modes of rebalance: full and the historical (asserts is needed that the proper mode of rebalance was worked). Basic scenario: Testing of rebalance triggered by two event types: node enter and node leave (baseline change if persistent mode). Extended scenario: Node entering or leaving during rebalance process. Test parameters: # Initial node count; # Cache count; # Cache entry count; # Cache entry size; # Mode: in-memory or persistence; # Rebalance trigger event: node enter or node leave. Test result: time taken to rebalance process. > Ducktape test of rebalance > -- > > Key: IGNITE-14226 > URL: https://issues.apache.org/jira/browse/IGNITE-14226 > Project: Ignite > Issue Type: Test >Reporter: Dmitriy Sorokin >Assignee: Dmitriy Sorokin >Priority: Major > > The test should check the rebalance on both in-memory caches and persistent > caches. > In case of persistent caches, the test also should check both modes of > rebalance: full and historical (asserts is needed that the proper mode of > rebalance was worked). > Basic scenario: > Testing of rebalance triggered by two event types: node enter and node leave > (baseline change in persistent mode). > Extended scenario: > Node entering or leaving during rebalance process. > Test parameters: > # Initial node count; > # Cache count; > # Cache entry count; > # Cache entry size; > # Mode: in-memory or persistence; > # Rebalance trigger event: node enter or node leave. > Test result: time taken to rebalance process. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13994) Rebalance huge cache in the case of in-memory cluster
[ https://issues.apache.org/jira/browse/IGNITE-13994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-13994: -- Sprint: Ducktape Sprint 3 (was: Ducktape Sprint 3, Ducktape Sprint 4) > Rebalance huge cache in the case of in-memory cluster > - > > Key: IGNITE-13994 > URL: https://issues.apache.org/jira/browse/IGNITE-13994 > Project: Ignite > Issue Type: Test >Reporter: Ivan Daschinskiy >Priority: Major > > There are some evidence, that rebalancing huge cache without rebalance > throttling can cause OOM on supplier. We need to cover this scenario. > Scenario: > 1. Start two nodes and 1 replicated cache with data region much more than > heap. > 2. Stop one of the node. > 3. Load data to cache almost equal to size of data region. > 4. Start node. > Goal is to run experiments with parameters > 1. Heap size > 2. Cache size > 3. Rebalance batch size. > 4. Rebalance throttle -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14204) cpp thin client transaction :Transaction with id 1 not found.
[
https://issues.apache.org/jira/browse/IGNITE-14204?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Sapego reassigned IGNITE-14204:
Assignee: Igor Sapego
> cpp thin client transaction :Transaction with id 1 not found.
> -
>
> Key: IGNITE-14204
> URL: https://issues.apache.org/jira/browse/IGNITE-14204
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.10
>Reporter: YuJue Li
>Assignee: Igor Sapego
>Priority: Critical
> Labels: c++
> Fix For: 2.10
>
>
> Using the 2.10 branch code and the transaction function of cpp thin client,
> the transaction with id 1 not found error will be throw. the reproduce steps
> are as follows:
> 1.start two nodes on two hosts use the following config file:
> {color:#808080} version{color}{color:#d4d4d4}={color}{color:#ce9178}"1.0"{color}{color:#9cdcfe}
>
> encoding{color}{color:#d4d4d4}={color}{color:#ce9178}"UTF-8"{color}{color:#808080}?>{color}
> {color:#808080}<{color}{color:#569cd6}beans{color}
> {color:#9cdcfe}xmlns{color}{color:#d4d4d4}={color}{color:#ce9178}["http://www.springframework.org/schema/beans;|http://www.springframework.org/schema/beans]{color}
> {color:#9cdcfe}xmlns:xsi{color}{color:#d4d4d4}={color}{color:#ce9178}["http://www.w3.org/2001/XMLSchema-instance;|http://www.w3.org/2001/XMLSchema-instance]{color}
> {color:#9cdcfe}xsi:schemaLocation{color}{color:#d4d4d4}={color}{color:#ce9178}"{color}
> {color:#ce9178} [http://www.springframework.org/schema/beans]{color}
> {color:#ce9178}
> [http://www.springframework.org/schema/beans/spring-beans.xsd]"{color}{color:#808080}>{color}
> {color:#808080}<{color}{color:#569cd6}bean{color}
> {color:#9cdcfe}id{color}{color:#d4d4d4}={color}{color:#ce9178}"grid.cfg"{color}
>
> {color:#9cdcfe}class{color}{color:#d4d4d4}={color}{color:#ce9178}"org.apache.ignite.configuration.IgniteConfiguration"{color}{color:#808080}>{color}
> {color:#808080}<{color}{color:#569cd6}property{color}
> {color:#9cdcfe}name{color}{color:#d4d4d4}={color}{color:#ce9178}"clientMode"{color}
>
> {color:#9cdcfe}value{color}{color:#d4d4d4}={color}{color:#ce9178}"false"{color}
> {color:#808080}/>{color}
> {color:#808080}<{color}{color:#569cd6}property{color}
> {color:#9cdcfe}name{color}{color:#d4d4d4}={color}{color:#ce9178}"peerClassLoadingEnabled"{color}
>
> {color:#9cdcfe}value{color}{color:#d4d4d4}={color}{color:#ce9178}"true"{color}{color:#808080}/>{color}
> {color:#808080}<{color}{color:#569cd6}property{color}
> {color:#9cdcfe}name{color}{color:#d4d4d4}={color}{color:#ce9178}"binaryConfiguration"{color}{color:#808080}>{color}
> {color:#808080}<{color}{color:#569cd6}bean{color}
> {color:#9cdcfe}class{color}{color:#d4d4d4}={color}{color:#ce9178}"org.apache.ignite.configuration.BinaryConfiguration"{color}{color:#808080}>{color}
> {color:#808080}<{color}{color:#569cd6}property{color}
> {color:#9cdcfe}name{color}{color:#d4d4d4}={color}{color:#ce9178}"compactFooter"{color}
>
> {color:#9cdcfe}value{color}{color:#d4d4d4}={color}{color:#ce9178}"false"{color}
> {color:#808080}/>{color}
> {color:#808080}<{color}{color:#569cd6}property{color}
> {color:#9cdcfe}name{color}{color:#d4d4d4}={color}{color:#ce9178}"idMapper"{color}{color:#808080}>{color}
> {color:#808080}<{color}{color:#569cd6}bean{color}
> {color:#9cdcfe}class{color}{color:#d4d4d4}={color}{color:#ce9178}"org.apache.ignite.binary.BinaryBasicIdMapper"{color}{color:#808080}>{color}
> {color:#808080}<{color}{color:#569cd6}property{color}
> {color:#9cdcfe}name{color}{color:#d4d4d4}={color}{color:#ce9178}"lowerCase"{color}
>
> {color:#9cdcfe}value{color}{color:#d4d4d4}={color}{color:#ce9178}"true"{color}
> {color:#808080}/>{color}
> {color:#808080}{color}
> {color:#808080}{color}
> {color:#808080}{color}
> {color:#808080}{color}
> {color:#808080}<{color}{color:#569cd6}property{color}
> {color:#9cdcfe}name{color}{color:#d4d4d4}={color}{color:#ce9178}"dataStorageConfiguration"{color}{color:#808080}>{color}
> {color:#808080}<{color}{color:#569cd6}bean{color}
> {color:#9cdcfe}class{color}{color:#d4d4d4}={color}{color:#ce9178}"org.apache.ignite.configuration.DataStorageConfiguration"{color}{color:#808080}>{color}
> {color:#808080}<{color}{color:#569cd6}property{color}
> {color:#9cdcfe}name{color}{color:#d4d4d4}={color}{color:#ce9178}"defaultDataRegionConfiguration"{color}{color:#808080}>{color}
> {color:#808080}<{color}{color:#569cd6}bean{color}
> {color:#9cdcfe}class{color}{color:#d4d4d4}={color}{color:#ce9178}"org.apache.ignite.configuration.DataRegionConfiguration"{color}{color:#808080}>{color}
> {color:#808080}<{color}{color:#569cd6}property{color}
> {color:#9cdcfe}name{color}{color:#d4d4d4}={color}{color:#ce9178}"name"{color}
>
[jira] [Assigned] (IGNITE-14165) C++ Thin Client bug with transactions larger than 1GB
[ https://issues.apache.org/jira/browse/IGNITE-14165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego reassigned IGNITE-14165: Assignee: Igor Sapego > C++ Thin Client bug with transactions larger than 1GB > - > > Key: IGNITE-14165 > URL: https://issues.apache.org/jira/browse/IGNITE-14165 > Project: Ignite > Issue Type: Bug > Components: platforms, thin client >Affects Versions: 2.9.1 >Reporter: José Mª Jimeno >Assignee: Igor Sapego >Priority: Major > Labels: c++ > > http://apache-ignite-users.70518.x6.nabble.com/Long-transaction-suspended-tp35368p35419.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14137) Detect and fix failures reasons (nightly runs fails)
[ https://issues.apache.org/jira/browse/IGNITE-14137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-14137: -- Sprint: Ducktape Sprint 3 (was: Ducktape Sprint 3, Ducktape Sprint 4) > Detect and fix failures reasons (nightly runs fails) > > > Key: IGNITE-14137 > URL: https://issues.apache.org/jira/browse/IGNITE-14137 > Project: Ignite > Issue Type: Bug >Reporter: Anton Vinogradov >Assignee: Mikhail Filatov >Priority: Blocker > > Jenkins runs fails, 1-4 ... 60 tests affected. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13994) Rebalance huge cache in the case of in-memory cluster
[ https://issues.apache.org/jira/browse/IGNITE-13994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin reassigned IGNITE-13994: Assignee: (was: Dmitriy Sorokin) > Rebalance huge cache in the case of in-memory cluster > - > > Key: IGNITE-13994 > URL: https://issues.apache.org/jira/browse/IGNITE-13994 > Project: Ignite > Issue Type: Test >Reporter: Ivan Daschinskiy >Priority: Major > > There are some evidence, that rebalancing huge cache without rebalance > throttling can cause OOM on supplier. We need to cover this scenario. > Scenario: > 1. Start two nodes and 1 replicated cache with data region much more than > heap. > 2. Stop one of the node. > 3. Load data to cache almost equal to size of data region. > 4. Start node. > Goal is to run experiments with parameters > 1. Heap size > 2. Cache size > 3. Rebalance batch size. > 4. Rebalance throttle -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14023) Password based authentication support in ducktape tests
[
https://issues.apache.org/jira/browse/IGNITE-14023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Filatov updated IGNITE-14023:
-
Description:
There are users with authentication enabled on the cluster
Ducktape tests should work on such clusters.
Tests should work if authentication is enabled on the cluster via a third-party
plugin
Running Ignite node and application with third-party authentication plugin
remains to be implemented by the developers of that plugin.
In this PR we will only implement the ability to tell control.sh how to
connect to the cluster.
connection parameters should be passed through globals with structure like that.
{
"use_ssl": True,
"admin": {
"credentials": ["username", "qwerty_123"],
"ssl": {
"key_store_jks":
}
}
}
was:
There are users with authentication enabled on the cluster
Ducktape tests should work on such clusters.
Tests should work if authentication is enabled on the cluster via a third-party
plugin
Running Ignite node and application with third-party authentication plugin
remains to be implemented by the developers of that plugin.
In this PR we will only implement the ability to tell control.sh how to
connect to the cluster.
connection parameters should be passed through globals
for default parameters: -gj '\{"use_auth":"True"}'
to pass parameters explicitly: -gj '{"use_auth":"True","admin":{"creds":
{"login":"admin1","password":"qwe123"}
}}'
for a cluster with enabled ssl and authentication: -gj
'\{"use_ssl":"True","use_auth":"True"}'
for a cluster with enabled ssl and authentication: -gj
'{"use_ssl":"True","use_auth":"True","admin":{"creds":
{"login":"admin1","password":"qwe123"}
,"ssl":\{"key_store_jks":"admin1.jks","key_store_password":"qwe123","trust_store_jks":"truststore.jks","trust_store_password":"qwe123"}}}'
> Password based authentication support in ducktape tests
> ---
>
> Key: IGNITE-14023
> URL: https://issues.apache.org/jira/browse/IGNITE-14023
> Project: Ignite
> Issue Type: Task
>Reporter: Mikhail Filatov
>Assignee: Mikhail Filatov
>Priority: Minor
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> There are users with authentication enabled on the cluster
> Ducktape tests should work on such clusters.
> Tests should work if authentication is enabled on the cluster via a
> third-party plugin
> Running Ignite node and application with third-party authentication plugin
> remains to be implemented by the developers of that plugin.
> In this PR we will only implement the ability to tell control.sh how to
> connect to the cluster.
> connection parameters should be passed through globals with structure like
> that.
> {
> "use_ssl": True,
> "admin": {
> "credentials": ["username", "qwerty_123"],
> "ssl": {
> "key_store_jks":
> }
> }
> }
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14226) Ducktape test of rebalance
[ https://issues.apache.org/jira/browse/IGNITE-14226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitriy Sorokin updated IGNITE-14226: - Sprint: Ducktape Sprint 4 > Ducktape test of rebalance > -- > > Key: IGNITE-14226 > URL: https://issues.apache.org/jira/browse/IGNITE-14226 > Project: Ignite > Issue Type: Test >Reporter: Dmitriy Sorokin >Assignee: Dmitriy Sorokin >Priority: Major > > The test should check the rebalance on both in-memory caches and persistent > caches. > In case of persistent caches, the test also should check both modes of > rebalance: full and the historical (asserts is needed that the proper mode of > rebalance was worked). > Basic scenario: > Testing of rebalance triggered by two event types: node enter and node leave > (baseline change if persistent mode). > Extended scenario: > Node entering or leaving during rebalance process. > Test parameters: > # Initial node count; > # Cache count; > # Cache entry count; > # Cache entry size; > # Mode: in-memory or persistence; > # Rebalance trigger event: node enter or node leave. > Test result: time taken to rebalance process. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-14226) Ducktape test of rebalance
Dmitriy Sorokin created IGNITE-14226: Summary: Ducktape test of rebalance Key: IGNITE-14226 URL: https://issues.apache.org/jira/browse/IGNITE-14226 Project: Ignite Issue Type: Test Reporter: Dmitriy Sorokin Assignee: Dmitriy Sorokin The test should check the rebalance on both in-memory caches and persistent caches. In case of persistent caches, the test also should check both modes of rebalance: full and the historical (asserts is needed that the proper mode of rebalance was worked). Basic scenario: Testing of rebalance triggered by two event types: node enter and node leave (baseline change if persistent mode). Extended scenario: Node entering or leaving during rebalance process. Test parameters: # Initial node count; # Cache count; # Cache entry count; # Cache entry size; # Mode: in-memory or persistence; # Rebalance trigger event: node enter or node leave. Test result: time taken to rebalance process. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13430) Create minimal documentation for ducktape tests
[
https://issues.apache.org/jira/browse/IGNITE-13430?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-13430:
--
Priority: Blocker (was: Critical)
> Create minimal documentation for ducktape tests
> ---
>
> Key: IGNITE-13430
> URL: https://issues.apache.org/jira/browse/IGNITE-13430
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Ivan Daschinskiy
>Assignee: Sergei Ryzhov
>Priority: Blocker
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Create minimal quickstart documentation in {{README.md}}
> Documentation should contain following:
> # Requirements for development
> # Requirements for running tests locally
> # Exact algorithm how to run tests locally (full suite, particular suite,
> particular test)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13448) Ducktests selftest: time is synchronized on nodes
[ https://issues.apache.org/jira/browse/IGNITE-13448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-13448: -- Priority: Blocker (was: Critical) > Ducktests selftest: time is synchronized on nodes > - > > Key: IGNITE-13448 > URL: https://issues.apache.org/jira/browse/IGNITE-13448 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Oleg Ostanin >Priority: Blocker > Time Spent: 1h 50m > Remaining Estimate: 0h > > Selftests are tests that check ducktests environment is correct and test are > reliable, and we can rely on their timings and results. > It's required to add test that check that time on all nodes is synchronized > (the same). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14137) Detect and fix failures reasons (nightly runs fails)
[ https://issues.apache.org/jira/browse/IGNITE-14137?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-14137: -- Priority: Blocker (was: Critical) > Detect and fix failures reasons (nightly runs fails) > > > Key: IGNITE-14137 > URL: https://issues.apache.org/jira/browse/IGNITE-14137 > Project: Ignite > Issue Type: Bug >Reporter: Anton Vinogradov >Assignee: Mikhail Filatov >Priority: Blocker > > Jenkins runs fails, 1-4 ... 60 tests affected. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14207) Access to system views is not controlled by security processor
[
https://issues.apache.org/jira/browse/IGNITE-14207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Kuznetsov reassigned IGNITE-14207:
-
Assignee: Andrey Kuznetsov
> Access to system views is not controlled by security processor
> --
>
> Key: IGNITE-14207
> URL: https://issues.apache.org/jira/browse/IGNITE-14207
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9.1
>Reporter: Andrey Kuznetsov
>Assignee: Andrey Kuznetsov
>Priority: Major
>
> As of now, it is impossible to restrict access to system views (SYS scheme)
> with {{IgniteSecurityProcessor}}; this should be fixed.
> Suggestions:
> - add new {{SecurityPermission}};
> - authorize this permission before accessing any system view.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14223) Remove FilePageStoreFactory internal interface
[ https://issues.apache.org/jira/browse/IGNITE-14223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-14223: - Ignite Flags: (was: Docs Required,Release Notes Required) > Remove FilePageStoreFactory internal interface > -- > > Key: IGNITE-14223 > URL: https://issues.apache.org/jira/browse/IGNITE-14223 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.11 > > Time Spent: 10m > Remaining Estimate: 0h > > The FilePageStoreFactory can be simplified since this factory has a single > implementation that produces FilePageStore's. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14163) SQL. Calcite: Error: Failed to plan query. (state=50000,code=1)
[
https://issues.apache.org/jira/browse/IGNITE-14163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17289769#comment-17289769
]
Fedor Malchikov commented on IGNITE-14163:
---
{code:java}
4656/43059 SELECT t1_1.int_col1, t1_2.int_col1, t1_1.id FROM t1_1 LEFT JOIN
t1_2 ON t1_1.id=t1_2.id WHERE t1_1.int_col1 BETWEEN 0 AND 100 AND
t1_2.varchar_col1 IS NULL AND t1_2.int_col1 > 10 ORDER BY t1_1.id;Error: Failed
to plan query. (state=5,code=1)java.sql.SQLException: Failed to plan query.
at
org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:1009)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:234)
at
org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:560)
at sqlline.Commands.execute(Commands.java:823)at
sqlline.Commands.sql(Commands.java:733)at
sqlline.SqlLine.dispatch(SqlLine.java:795)at
sqlline.SqlLine.runCommands(SqlLine.java:1706)at
sqlline.Commands.run(Commands.java:1317)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
sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
at sqlline.SqlLine.dispatch(SqlLine.java:791)at
sqlline.SqlLine.initArgs(SqlLine.java:595)at
sqlline.SqlLine.begin(SqlLine.java:643)at
sqlline.SqlLine.start(SqlLine.java:373)at
sqlline.SqlLine.main(SqlLine.java:265)
{code}
> SQL. Calcite: Error: Failed to plan query. (state=5,code=1)
>
>
> Key: IGNITE-14163
> URL: https://issues.apache.org/jira/browse/IGNITE-14163
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Fedor Malchikov
>Assignee: Konstantin Orlov
>Priority: Blocker
> Attachments: caches.xml, create_env.txt, data-reg.xml, ignite.log,
> server.xml, sqlline.log
>
>
> Problem reproduced on inner , right, right outer joins and unions, but not
> affected left\ left outer joins.
> For test db creation please use create_env.txt.
> {code:SQL}
> SELECT t17_1.int_col1, t17_2.int_col1, t17_1.id FROM t17_1 INNER JOIN t17_2
> ON t17_1.id=t17_2.id WHERE t17_1.int_col2
> IN(0,1,-2,3,-5,7,-11,13,-17,19,-23,29,-31,37,-41,43,-47,53,-59,61,-67,71,-73,79,-83,89,-97)
> OR t17_1.int_col1 > 10 ORDER BY t17_1.id;
> {code}
> {code:java}
> Error: Failed to plan query. (state=5,code=1)
> java.sql.SQLException: Failed to plan query.
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:1009)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:234)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:560)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.runCommands(SqlLine.java:1706)
> at sqlline.Commands.run(Commands.java:1317)
> 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
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
> at sqlline.SqlLine.dispatch(SqlLine.java:791)
> at sqlline.SqlLine.initArgs(SqlLine.java:595)
> at sqlline.SqlLine.begin(SqlLine.java:643)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> {code}
> Ignite log:
> {code:java}
> [20:50:31,206][SEVERE][client-connector-#142][JdbcRequestHandler] Failed to
> execute SQL query [reqId=392, req=JdbcQueryExecuteRequest [schemaName=PUBLIC,
> pageSize=1024, maxRows=0, sqlQry=SELECT t17_1.int_col1, t17_2.int_col1,
> t17_1.id FROM t17_1 INNER JOIN t17_2 ON t17_1.id=t17_2.id WHERE
> t17_1.int_col1
> IN(0,1,-2,3,-5,7,-11,13,-17,19,-23,29,-31,37,-41,43,-47,53,-59,61,-67,71,-73,79,-83,89,-97)
> OR t17_1.int_col1 > 10 ORDER BY t17_1.id, args=Object[] [],
> stmtType=ANY_STATEMENT_TYPE, autoCommit=true, partResReq=false,
> explicitTimeout=false, super=JdbcRequest [type=2, reqId=392]]]
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed
> to plan query.
> at
>
[jira] [Commented] (IGNITE-14163) SQL. Calcite: Error: Failed to plan query. (state=50000,code=1)
[
https://issues.apache.org/jira/browse/IGNITE-14163?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17289768#comment-17289768
]
Fedor Malchikov commented on IGNITE-14163:
---
New tests shows that problem affects all join requests.
> SQL. Calcite: Error: Failed to plan query. (state=5,code=1)
>
>
> Key: IGNITE-14163
> URL: https://issues.apache.org/jira/browse/IGNITE-14163
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Fedor Malchikov
>Assignee: Konstantin Orlov
>Priority: Blocker
> Attachments: caches.xml, create_env.txt, data-reg.xml, ignite.log,
> server.xml, sqlline.log
>
>
> Problem reproduced on inner , right, right outer joins and unions, but not
> affected left\ left outer joins.
> For test db creation please use create_env.txt.
> {code:SQL}
> SELECT t17_1.int_col1, t17_2.int_col1, t17_1.id FROM t17_1 INNER JOIN t17_2
> ON t17_1.id=t17_2.id WHERE t17_1.int_col2
> IN(0,1,-2,3,-5,7,-11,13,-17,19,-23,29,-31,37,-41,43,-47,53,-59,61,-67,71,-73,79,-83,89,-97)
> OR t17_1.int_col1 > 10 ORDER BY t17_1.id;
> {code}
> {code:java}
> Error: Failed to plan query. (state=5,code=1)
> java.sql.SQLException: Failed to plan query.
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:1009)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:234)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:560)
> at sqlline.Commands.execute(Commands.java:823)
> at sqlline.Commands.sql(Commands.java:733)
> at sqlline.SqlLine.dispatch(SqlLine.java:795)
> at sqlline.SqlLine.runCommands(SqlLine.java:1706)
> at sqlline.Commands.run(Commands.java:1317)
> 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
> sqlline.ReflectiveCommandHandler.execute(ReflectiveCommandHandler.java:38)
> at sqlline.SqlLine.dispatch(SqlLine.java:791)
> at sqlline.SqlLine.initArgs(SqlLine.java:595)
> at sqlline.SqlLine.begin(SqlLine.java:643)
> at sqlline.SqlLine.start(SqlLine.java:373)
> at sqlline.SqlLine.main(SqlLine.java:265)
> {code}
> Ignite log:
> {code:java}
> [20:50:31,206][SEVERE][client-connector-#142][JdbcRequestHandler] Failed to
> execute SQL query [reqId=392, req=JdbcQueryExecuteRequest [schemaName=PUBLIC,
> pageSize=1024, maxRows=0, sqlQry=SELECT t17_1.int_col1, t17_2.int_col1,
> t17_1.id FROM t17_1 INNER JOIN t17_2 ON t17_1.id=t17_2.id WHERE
> t17_1.int_col1
> IN(0,1,-2,3,-5,7,-11,13,-17,19,-23,29,-31,37,-41,43,-47,53,-59,61,-67,71,-73,79,-83,89,-97)
> OR t17_1.int_col1 > 10 ORDER BY t17_1.id, args=Object[] [],
> stmtType=ANY_STATEMENT_TYPE, autoCommit=true, partResReq=false,
> explicitTimeout=false, super=JdbcRequest [type=2, reqId=392]]]
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Failed
> to plan query.
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareQuery(ExecutionServiceImpl.java:522)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.queryPlan(QueryPlanCacheImpl.java:84)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executeQuery(ExecutionServiceImpl.java:379)
> at
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:248)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.querySqlFields(JdbcRequestHandler.java:790)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.executeQuery(JdbcRequestHandler.java:673)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.doHandle(JdbcRequestHandler.java:341)
> at
> org.apache.ignite.internal.processors.odbc.jdbc.JdbcRequestHandler.handle(JdbcRequestHandler.java:278)
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:202)
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:56)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
> at
>
[jira] [Updated] (IGNITE-14219) stopAllGrids does not wait for IgniteProcessProxy stop.
[ https://issues.apache.org/jira/browse/IGNITE-14219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-14219: -- Fix Version/s: 2.11 > stopAllGrids does not wait for IgniteProcessProxy stop. > --- > > Key: IGNITE-14219 > URL: https://issues.apache.org/jira/browse/IGNITE-14219 > Project: Ignite > Issue Type: Bug >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Fix For: 2.11 > > Time Spent: 0.5h > Remaining Estimate: 0h > > stopAllGrids does not wait for subprocess stops. In case of running grids in > subprocess (IgniteProcessProxy). It just wait for "kill -9" command, but it's > performed async. So subprocess with grid may be running for more time and > interfere with other tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14219) stopAllGrids does not wait for IgniteProcessProxy stop.
[ https://issues.apache.org/jira/browse/IGNITE-14219?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17289764#comment-17289764 ] Anton Vinogradov commented on IGNITE-14219: --- Merged to master. Thanks for your contribution! > stopAllGrids does not wait for IgniteProcessProxy stop. > --- > > Key: IGNITE-14219 > URL: https://issues.apache.org/jira/browse/IGNITE-14219 > Project: Ignite > Issue Type: Bug >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > stopAllGrids does not wait for subprocess stops. In case of running grids in > subprocess (IgniteProcessProxy). It just wait for "kill -9" command, but it's > performed async. So subprocess with grid may be running for more time and > interfere with other tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13873) Milti-cell transaction changes may be not visible (during some time) after the Cellular switch
[ https://issues.apache.org/jira/browse/IGNITE-13873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17289141#comment-17289141 ] Anton Vinogradov edited comment on IGNITE-13873 at 2/24/21, 8:15 AM: - Fixed the issue, also simplified the Cellular switch code/logic. 1) Got rid of useless "remote counters update on rollback on tx recovery" (PartitionCountersNeighborcastRequest/Response/Future). Previously, each rollback (it's gaps) was propagated by these messages to other backups to solve counters de-sync issue happens because of partially prepared transactions. Partially prepare means some (not all) backups have them, so, when we taking these gaps into account as updates we must propagate them to other nodes to avoid counters de-sync. This approach may cause a lot of messages sending/handling :( This, actually, was a dirty hack to fit "new" counters. Just changed the strategy to ignore such updates (keep as gaps). So, now, partially prepared and failed on preparation (not prepared at all) transactions are handled in the same way. Gaps are closing on counters finalization on node left for partitions with failed primary. This way allows us to avoid the "gaps tail" we have before (when rolled back transactions with counters higher than committed transactions required counters (gaps tail) propagation to other nodes). 2) Simplified PME-Free switch code. Got rid of any latch-based synchronizations during the switch, which was used to ... fit dirty hack to ... fit dirty hack to ... new counters (to wait for all gaps tails are propagated). Currently, counters will be synchronized on the latest committed tx counters by design, no need for latches/sync. 3) Fixed Celular switch code for transactions that affect more than one cell (see issue description for details). Got rid of 'primaryNodes' computation. Now each node just waits for recovery of every tx having one of its primaries failed. Also, I've checked the speedup using [IEP-56 framework|https://cwiki.apache.org/confluence/display/IGNITE/IEP-56%3A+Distributed+environment+tests] on 48 real servers. On the slide, you may see the difference between the 2.9 and the PR. Numbers represent the worst (max) latency happen on node failure on broken/alive cell. !master (as 2.9) vs improved (as dev) .png|width=100%! [~alex_pl], [~ascherbakov], Could you please review the changes? was (Author: av): Fixed the issue, also simplified the Cellular switch code/logic. 1) Got rid of useless "remote counters update on rollback on tx recovery" (PartitionCountersNeighborcastRequest/Response/Future). Previously, each rollback (it's gaps) was propagated by these messages to other backups to solve counters de-sync issue happens because of partially prepared transactions. Partially prepare means some (not all) backups have them, so, when we taking these gaps into account as updates we must propagate them to other nodes to avoid counters de-sync. This approach may cause a lot of messages sending/handling :( This, actually, was a dirty hack to fit "new" counters. Just changed the strategy to ignore such updates (keep as gaps). So, now, partially prepared and failed on preparation (not prepared at all) transactions are handled in the same way. Gaps are closing on counters finalization on node left for partitions with failed primary. This way allows us to avoid the "gaps tail" we have before (when rolled back transactions with counters higher than committed transactions required counters (gaps tail) propagation to other nodes). 2) Simplified PME-Free switch code. Got rid of any latch-based synchronizations during the switch, which was used to ... fit dirty hack to ... fit new counters (to wait for all gaps tails are propagated). Currently, counters will be synchronized on the latest committed tx counters by design, no need for latches/sync. 3) Fixed Celular switch code for transactions that affect more than one cell (see issue description for details). Got rid of 'primaryNodes' computation. Now each node just waits for recovery of every tx having one of its primaries failed. Also, I've checked the speedup using [IEP-56 framework|https://cwiki.apache.org/confluence/display/IGNITE/IEP-56%3A+Distributed+environment+tests] on 48 real servers. On the slide, you may see the difference between the 2.9 and the PR. Numbers represent the worst (max) latency happen on node failure on broken/alive cell. !master (as 2.9) vs improved (as dev) .png|width=100%! [~alex_pl], [~ascherbakov], Could you please review the changes? > Milti-cell transaction changes may be not visible (during some time) after > the Cellular switch > -- > > Key: IGNITE-13873 > URL: https://issues.apache.org/jira/browse/IGNITE-13873 > Project: Ignite
