[jira] [Updated] (IGNITE-17524) Shutdown of large numbers of servers slowed by linear lookup in IgniteServiceProcessor
[ https://issues.apache.org/jira/browse/IGNITE-17524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-17524: Fix Version/s: 2.14 > Shutdown of large numbers of servers slowed by linear lookup in > IgniteServiceProcessor > -- > > Key: IGNITE-17524 > URL: https://issues.apache.org/jira/browse/IGNITE-17524 > Project: Ignite > Issue Type: Improvement > Components: managed services >Affects Versions: 2.13 >Reporter: Arthur Naseef >Assignee: Arthur Naseef >Priority: Major > Fix For: 2.14 > > Time Spent: 40m > Remaining Estimate: 0h > > Cloned from IGNITE-17274. That ticket addresses startup timing, and this one > addresses shutdown timing. > Shutting down large numbers of services is slowed down by a linear lookup > that can be addressed by adding a map to perform the lookups. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17524) Shutdown of large numbers of servers slowed by linear lookup in IgniteServiceProcessor
[ https://issues.apache.org/jira/browse/IGNITE-17524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580043#comment-17580043 ] Pavel Tupitsyn commented on IGNITE-17524: - Merged to master: 777db6e24e893d420e909ea584b2b2db28b27eaa [~artnaseef] thanks for the contribution. > Shutdown of large numbers of servers slowed by linear lookup in > IgniteServiceProcessor > -- > > Key: IGNITE-17524 > URL: https://issues.apache.org/jira/browse/IGNITE-17524 > Project: Ignite > Issue Type: Improvement > Components: managed services >Affects Versions: 2.13 >Reporter: Arthur Naseef >Assignee: Arthur Naseef >Priority: Major > Time Spent: 40m > Remaining Estimate: 0h > > Cloned from IGNITE-17274. That ticket addresses startup timing, and this one > addresses shutdown timing. > Shutting down large numbers of services is slowed down by a linear lookup > that can be addressed by adding a map to perform the lookups. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (IGNITE-17524) Shutdown of large numbers of servers slowed by linear lookup in IgniteServiceProcessor
[ https://issues.apache.org/jira/browse/IGNITE-17524 ]
Pavel Tupitsyn deleted comment on IGNITE-17524:
-
was (Author: ignitetcbot):
{panel:title=Branch: [pull/10196/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 6{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6732372]]
* IgniteCacheTestSuite6: CacheExchangeMergeTest.testMergeServersFail1_6 - Test
has low fail rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/10196/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=6731700buildTypeId=IgniteTests24Java8_RunAll]
> Shutdown of large numbers of servers slowed by linear lookup in
> IgniteServiceProcessor
> --
>
> Key: IGNITE-17524
> URL: https://issues.apache.org/jira/browse/IGNITE-17524
> Project: Ignite
> Issue Type: Improvement
> Components: managed services
>Affects Versions: 2.13
>Reporter: Arthur Naseef
>Assignee: Arthur Naseef
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Cloned from IGNITE-17274. That ticket addresses startup timing, and this one
> addresses shutdown timing.
> Shutting down large numbers of services is slowed down by a linear lookup
> that can be addressed by adding a map to perform the lookups.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17524) Shutdown of large numbers of servers slowed by linear lookup in IgniteServiceProcessor
[
https://issues.apache.org/jira/browse/IGNITE-17524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17580038#comment-17580038
]
Ignite TC Bot commented on IGNITE-17524:
{panel:title=Branch: [pull/10196/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10196/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=6731700buildTypeId=IgniteTests24Java8_RunAll]
> Shutdown of large numbers of servers slowed by linear lookup in
> IgniteServiceProcessor
> --
>
> Key: IGNITE-17524
> URL: https://issues.apache.org/jira/browse/IGNITE-17524
> Project: Ignite
> Issue Type: Improvement
> Components: managed services
>Affects Versions: 2.13
>Reporter: Arthur Naseef
>Assignee: Arthur Naseef
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Cloned from IGNITE-17274. That ticket addresses startup timing, and this one
> addresses shutdown timing.
> Shutting down large numbers of services is slowed down by a linear lookup
> that can be addressed by adding a map to perform the lookups.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17496) LWM may be after HWM (reserved) on primary after the node restart
[
https://issues.apache.org/jira/browse/IGNITE-17496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17579877#comment-17579877
]
Ignite TC Bot commented on IGNITE-17496:
{panel:title=Branch: [pull/10185/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10185/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6560712buildTypeId=IgniteTests24Java8_RunAll]
> LWM may be after HWM (reserved) on primary after the node restart
> -
>
> Key: IGNITE-17496
> URL: https://issues.apache.org/jira/browse/IGNITE-17496
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> java.lang.AssertionError: LWM after HWM: lwm=10010, hwm=10003, cntr=Counter
> [lwm=10010, missed=[10011 - 10012, 10021, 10031 - 10032, 10043 - 10044],
> maxApplied=10047, hwm=10004]
> at
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl.reserve(PartitionUpdateCounterTrackingImpl.java:265)
> at
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterErrorWrapper.reserve(PartitionUpdateCounterErrorWrapper.java:58)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.getAndIncrementUpdateCounter(IgniteCacheOffheapManagerImpl.java:1620)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.getAndIncrementUpdateCounter(GridCacheOffheapManager.java:2538)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition.getAndIncrementUpdateCounter(GridDhtLocalPartition.java:942)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.calculatePartitionUpdateCounters(IgniteTxLocalAdapter.java:510)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1360)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:730)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare(GridDhtTxPrepareFuture.java:1136)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocal.prepareAsync(GridDhtTxLocal.java:400)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:581)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:378)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:201)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest(IgniteTxHandler.java:175)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$000(IgniteTxHandler.java:135)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:223)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$1.apply(IgniteTxHandler.java:221)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1151)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:592)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:393)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:110)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:309)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1907)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:243)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
> at
>
[jira] (IGNITE-17524) Shutdown of large numbers of servers slowed by linear lookup in IgniteServiceProcessor
[ https://issues.apache.org/jira/browse/IGNITE-17524 ]
Pavel Tupitsyn deleted comment on IGNITE-17524:
-
was (Author: ignitetcbot):
{panel:title=Branch: [pull/10196/head] Base: [master] : Possible Blockers
(11)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 5{color} [[tests 2 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6731604]]
* IgniteCacheTestSuite5:
GridExchangeFreeCellularSwitchComplexOperationsTest.testComplexOperationsRecoveryOnCellularSwitch[Isolation
= OPTIMISTIC, Concurrency = SERIALIZABLE, Started from = CLIENT] - Test has
low fail rate in base branch 0,0% and is not flaky
* IgniteCacheTestSuite5:
GridExchangeFreeCellularSwitchComplexOperationsTest.testComplexOperationsRecoveryOnCellularSwitch[Isolation
= PESSIMISTIC, Concurrency = READ_COMMITTED, Started from = FAILED] - Test has
low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache 6{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6731605]]
{color:#d04437}Platform .NET (Windows){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=6731669]]
* exe: CancellationTest.TestTask - Test has low fail rate in base branch 0,0%
and is not flaky
* exe: IgniteLockTests.TestFairLockGuaranteesOrder - Test has low fail rate in
base branch 0,0% and is not flaky
{color:#d04437}Cache 9{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6731608]]
{color:#d04437}Cache 8{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=6731607]]
* IgniteCacheTestSuite8:
GridCacheConcurrentEvictionConsistencySelfTest.testPolicyConsistencySorted -
Test has low fail rate in base branch 0,0% and is not flaky
* IgniteCacheTestSuite8: PageEvictionDataStreamerTest.testPageEviction - Test
has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}PDS 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6731654]]
* IgnitePdsTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateDuringEvictionAndRebalance
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Queries 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6731672]]
* IgniteBinaryCacheQueryTestSuite2:
IgniteCacheQueryNodeRestartDistributedJoinSelfTest.testRestartsBroadcast - Test
has low fail rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/10196/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=6731700buildTypeId=IgniteTests24Java8_RunAll]
> Shutdown of large numbers of servers slowed by linear lookup in
> IgniteServiceProcessor
> --
>
> Key: IGNITE-17524
> URL: https://issues.apache.org/jira/browse/IGNITE-17524
> Project: Ignite
> Issue Type: Improvement
> Components: managed services
>Affects Versions: 2.13
>Reporter: Arthur Naseef
>Assignee: Arthur Naseef
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Cloned from IGNITE-17274. That ticket addresses startup timing, and this one
> addresses shutdown timing.
> Shutting down large numbers of services is slowed down by a linear lookup
> that can be addressed by adding a map to perform the lookups.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17524) Shutdown of large numbers of servers slowed by linear lookup in IgniteServiceProcessor
[
https://issues.apache.org/jira/browse/IGNITE-17524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17579869#comment-17579869
]
Ignite TC Bot commented on IGNITE-17524:
{panel:title=Branch: [pull/10196/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 6{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6732372]]
* IgniteCacheTestSuite6: CacheExchangeMergeTest.testMergeServersFail1_6 - Test
has low fail rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/10196/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=6731700buildTypeId=IgniteTests24Java8_RunAll]
> Shutdown of large numbers of servers slowed by linear lookup in
> IgniteServiceProcessor
> --
>
> Key: IGNITE-17524
> URL: https://issues.apache.org/jira/browse/IGNITE-17524
> Project: Ignite
> Issue Type: Improvement
> Components: managed services
>Affects Versions: 2.13
>Reporter: Arthur Naseef
>Assignee: Arthur Naseef
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Cloned from IGNITE-17274. That ticket addresses startup timing, and this one
> addresses shutdown timing.
> Shutting down large numbers of services is slowed down by a linear lookup
> that can be addressed by adding a map to perform the lookups.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17051) Incorrect parsing of 'IN' clause in IgniteQueryGenerator
[
https://issues.apache.org/jira/browse/IGNITE-17051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17579861#comment-17579861
]
Mikhail Petrov commented on IGNITE-17051:
-
[~xtern] Thanks a lot for the review.
> Incorrect parsing of 'IN' clause in IgniteQueryGenerator
>
>
> Key: IGNITE-17051
> URL: https://issues.apache.org/jira/browse/IGNITE-17051
> Project: Ignite
> Issue Type: Bug
> Components: springdata
>Reporter: Ilya Shishkov
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: ise
> Attachments: IncorrectInOperator.patch
>
>
> If you create JPA-repository method with with 'IN' operator (eg.
> findBySecondName{*}In{*}), it should be parsed in correct SQL form, but when
> such repository method is called, below error occurs:
> {code:java}
> Syntax error in SQL statement "SELECT ""PersonCache"".""PERSON""._KEY,
> ""PersonCache"".""PERSON""._VAL FROM PERSON WHERE ((PERSON.SECONDNAME IN
> ?[*])) "; expected "("; SQL statement:
> SELECT "PersonCache"."PERSON"._KEY, "PersonCache"."PERSON"._VAL FROM Person
> WHERE ((Person.secondName IN ?)) [42001-197]
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:861)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:420)
> at
> org.apache.ignite.springdata.proxy.IgniteNodeCacheProxy.query(IgniteNodeCacheProxy.java:90)
> at
> org.apache.ignite.springdata.repository.query.IgniteRepositoryQuery.execute(IgniteRepositoryQuery.java:348)
> at
> org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.doInvoke(RepositoryFactorySupport.java:619)
> at
> org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.invoke(RepositoryFactorySupport.java:606)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
> at
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:95)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:212)
> at com.sun.proxy.$Proxy51.findBySecondNameIn(Unknown Source)
> at
> org.apache.ignite.springdata.IgniteSpringDataCrudSelfTest.testGetPersonsBySecondNameInList(IgniteSpringDataCrudSelfTest.java:453)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2434)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Here is a reproducer patch (apply to master of ignite-extensions):
> [^IncorrectInOperator.patch]. It contains two tests for single argument and
> for list of arguments.
> It seems, that {{IgniteQueryGenerator}} incorrectly handles {{IN}} (and
> {{{}NOT IN{}}}) operator [1], because if you place '?' between parenthesis,
> error will disappear for single argument.
> But there is another problem after addition of parenthesis: if Collection is
> passed as argument below error will occur:
> {code:java}
> General error: "class org.apache.ignite.IgniteCheckedException: Runtime
> failure on bounds: [lower=IndexSearchRowImpl
> [rowHnd=org.apache.ignite.internal.processors.query.h2.index.QueryIndexRowHandler@6183d0d9],
> upper=IndexSearchRowImpl
> [rowHnd=org.apache.ignite.internal.processors.query.h2.index.QueryIndexRowHandler@6183d0d9]]";
> SQL statement:
> SELECT
> "PersonCache".__Z0._KEY __C0_0,
> "PersonCache".__Z0._VAL __C0_1
> FROM "PersonCache".PERSON __Z0
> WHERE __Z0.SECONDNAME = ?1 [5-197]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:900)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:987)
> at
>
[jira] [Comment Edited] (IGNITE-16136) System Thread pool starvation and out of memory
[
https://issues.apache.org/jira/browse/IGNITE-16136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17579835#comment-17579835
]
Maxim Muzafarov edited comment on IGNITE-16136 at 8/15/22 6:06 PM:
---
Please, provide the additional information about the number of registered
binary metadata types on server nodes.
{code:java}
ls -la /ingite/work/db/marshaller/ | wc -l
{code}
or since 2.10
{code:java}
select count(*) from SYS.BINARY_METADATA
{code}
[BINARY_METADATA|https://ignite.apache.org/docs/latest/monitoring-metrics/system-views#binary_metadata]
was (Author: mmuzaf):
Please, provide the additional information about the number of registered
binary metadata types on server nodes.
{code:java}
ls -la /ingite/work/db/marshaller/ | wc -l
{code}
or since 2.12
{code:java}
select count(*) from SYS.BINARY_METADATA
{code}
[BINARY_METADATA|https://ignite.apache.org/docs/latest/monitoring-metrics/system-views#binary_metadata]
> System Thread pool starvation and out of memory
> ---
>
> Key: IGNITE-16136
> URL: https://issues.apache.org/jira/browse/IGNITE-16136
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7.6
>Reporter: David Albrecht
>Priority: Critical
> Labels: ise
> Fix For: 2.14
>
> Attachments: image-2021-12-15-21-13-43-775.png,
> image-2021-12-15-21-17-47-652.png
>
>
> We are experiencing thread pool starvations and after some time out of memory
> exceptions in some of our ignite client nodes while the server node seems to
> be running without any problems. It seems like all sys threads are stuck when
> calling MarshallerContextImpl.getClassName. Which in turn leads to a growing
> worker queue.
>
> First warnings regarding the thread pool starvation:
> {code:java}
> 10.12.21 11:22:34.603 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:27:34.654 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:32:34.713 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:37:34.764 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:42:34.796 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:47:34.839 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> {code}
> Out of memory error leading to a crash of the application:
> {code}
> Exception: java.lang.OutOfMemoryError thrown from the
> UncaughtExceptionHandler in thread "https-openssl-nio-16443-ClientPoller"
> Exception: java.lang.OutOfMemoryError thrown from the
> UncaughtExceptionHandler in thread "ajp-nio-16009-ClientPoller"
> 11-Dec-2021 03:07:24.446 SEVERE [Catalina-utility-1]
> org.apache.coyote.AbstractProtocol.startAsyncTimeout Error processing async
> timeouts
> java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError:
> Java heap space
> {code}
> The queue full of messages:
> !image-2021-12-15-21-17-47-652.png!
> It seems like all sys threads are stuck while waiting at:
> {code}
> sys-#170
> at jdk.internal.misc.Unsafe.park(ZJ)V (Native Method)
> at java.util.concurrent.locks.LockSupport.park()V (LockSupport.java:323)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(Z)Ljava/lang/Object;
> (GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get()Ljava/lang/Object;
> (GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClassName(BI)Ljava/lang/String;
> (MarshallerContextImpl.java:379)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClass(ILjava/lang/ClassLoader;)Ljava/lang/Class;
> (MarshallerContextImpl.java:344)
> at
>
[jira] [Commented] (IGNITE-16136) System Thread pool starvation and out of memory
[
https://issues.apache.org/jira/browse/IGNITE-16136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17579835#comment-17579835
]
Maxim Muzafarov commented on IGNITE-16136:
--
Please, provide the additional information about the number of registered
binary metadata types on server nodes.
{code:java}
ls -la /ingite/work/db/marshaller/ | wc -l
{code}
or since 2.12
{code:java}
select count(*) from SYS.BINARY_METADATA
{code}
[BINARY_METADATA|https://ignite.apache.org/docs/latest/monitoring-metrics/system-views#binary_metadata]
> System Thread pool starvation and out of memory
> ---
>
> Key: IGNITE-16136
> URL: https://issues.apache.org/jira/browse/IGNITE-16136
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7.6
>Reporter: David Albrecht
>Priority: Critical
> Labels: ise
> Fix For: 2.14
>
> Attachments: image-2021-12-15-21-13-43-775.png,
> image-2021-12-15-21-17-47-652.png
>
>
> We are experiencing thread pool starvations and after some time out of memory
> exceptions in some of our ignite client nodes while the server node seems to
> be running without any problems. It seems like all sys threads are stuck when
> calling MarshallerContextImpl.getClassName. Which in turn leads to a growing
> worker queue.
>
> First warnings regarding the thread pool starvation:
> {code:java}
> 10.12.21 11:22:34.603 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:27:34.654 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:32:34.713 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:37:34.764 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:42:34.796 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:47:34.839 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> {code}
> Out of memory error leading to a crash of the application:
> {code}
> Exception: java.lang.OutOfMemoryError thrown from the
> UncaughtExceptionHandler in thread "https-openssl-nio-16443-ClientPoller"
> Exception: java.lang.OutOfMemoryError thrown from the
> UncaughtExceptionHandler in thread "ajp-nio-16009-ClientPoller"
> 11-Dec-2021 03:07:24.446 SEVERE [Catalina-utility-1]
> org.apache.coyote.AbstractProtocol.startAsyncTimeout Error processing async
> timeouts
> java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError:
> Java heap space
> {code}
> The queue full of messages:
> !image-2021-12-15-21-17-47-652.png!
> It seems like all sys threads are stuck while waiting at:
> {code}
> sys-#170
> at jdk.internal.misc.Unsafe.park(ZJ)V (Native Method)
> at java.util.concurrent.locks.LockSupport.park()V (LockSupport.java:323)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(Z)Ljava/lang/Object;
> (GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get()Ljava/lang/Object;
> (GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClassName(BI)Ljava/lang/String;
> (MarshallerContextImpl.java:379)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClass(ILjava/lang/ClassLoader;)Ljava/lang/Class;
> (MarshallerContextImpl.java:344)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(Ljava/util/concurrent/ConcurrentMap;ILjava/lang/ClassLoader;Lorg/apache/ignite/marshaller/MarshallerContext;Lorg/apache/ignite/internal/marshaller/optimized/OptimizedMarshallerIdMapper;)Lorg/apache/ignite/internal/marshaller/optimized/OptimizedClassDescriptor;
> (OptimizedMarshallerUtils.java:264)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0()Ljava/lang/Object;
> (OptimizedObjectInputStream.java:341)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride()Ljava/lang/Object;
>
[jira] [Commented] (IGNITE-17051) Incorrect parsing of 'IN' clause in IgniteQueryGenerator
[
https://issues.apache.org/jira/browse/IGNITE-17051?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17579833#comment-17579833
]
Pavel Pereslegin commented on IGNITE-17051:
---
[~PetrovMikhail],
merged to the master branch,
thanks for the contribution!
> Incorrect parsing of 'IN' clause in IgniteQueryGenerator
>
>
> Key: IGNITE-17051
> URL: https://issues.apache.org/jira/browse/IGNITE-17051
> Project: Ignite
> Issue Type: Bug
> Components: springdata
>Reporter: Ilya Shishkov
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: ise
> Attachments: IncorrectInOperator.patch
>
>
> If you create JPA-repository method with with 'IN' operator (eg.
> findBySecondName{*}In{*}), it should be parsed in correct SQL form, but when
> such repository method is called, below error occurs:
> {code:java}
> Syntax error in SQL statement "SELECT ""PersonCache"".""PERSON""._KEY,
> ""PersonCache"".""PERSON""._VAL FROM PERSON WHERE ((PERSON.SECONDNAME IN
> ?[*])) "; expected "("; SQL statement:
> SELECT "PersonCache"."PERSON"._KEY, "PersonCache"."PERSON"._VAL FROM Person
> WHERE ((Person.secondName IN ?)) [42001-197]
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:861)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:420)
> at
> org.apache.ignite.springdata.proxy.IgniteNodeCacheProxy.query(IgniteNodeCacheProxy.java:90)
> at
> org.apache.ignite.springdata.repository.query.IgniteRepositoryQuery.execute(IgniteRepositoryQuery.java:348)
> at
> org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.doInvoke(RepositoryFactorySupport.java:619)
> at
> org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.invoke(RepositoryFactorySupport.java:606)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
> at
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:95)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:212)
> at com.sun.proxy.$Proxy51.findBySecondNameIn(Unknown Source)
> at
> org.apache.ignite.springdata.IgniteSpringDataCrudSelfTest.testGetPersonsBySecondNameInList(IgniteSpringDataCrudSelfTest.java:453)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2434)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Here is a reproducer patch (apply to master of ignite-extensions):
> [^IncorrectInOperator.patch]. It contains two tests for single argument and
> for list of arguments.
> It seems, that {{IgniteQueryGenerator}} incorrectly handles {{IN}} (and
> {{{}NOT IN{}}}) operator [1], because if you place '?' between parenthesis,
> error will disappear for single argument.
> But there is another problem after addition of parenthesis: if Collection is
> passed as argument below error will occur:
> {code:java}
> General error: "class org.apache.ignite.IgniteCheckedException: Runtime
> failure on bounds: [lower=IndexSearchRowImpl
> [rowHnd=org.apache.ignite.internal.processors.query.h2.index.QueryIndexRowHandler@6183d0d9],
> upper=IndexSearchRowImpl
> [rowHnd=org.apache.ignite.internal.processors.query.h2.index.QueryIndexRowHandler@6183d0d9]]";
> SQL statement:
> SELECT
> "PersonCache".__Z0._KEY __C0_0,
> "PersonCache".__Z0._VAL __C0_1
> FROM "PersonCache".PERSON __Z0
> WHERE __Z0.SECONDNAME = ?1 [5-197]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:900)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:987)
>
[jira] [Updated] (IGNITE-17051) Incorrect parsing of 'IN' clause in IgniteQueryGenerator
[
https://issues.apache.org/jira/browse/IGNITE-17051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-17051:
--
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Incorrect parsing of 'IN' clause in IgniteQueryGenerator
>
>
> Key: IGNITE-17051
> URL: https://issues.apache.org/jira/browse/IGNITE-17051
> Project: Ignite
> Issue Type: Bug
> Components: springdata
>Reporter: Ilya Shishkov
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: ise
> Attachments: IncorrectInOperator.patch
>
>
> If you create JPA-repository method with with 'IN' operator (eg.
> findBySecondName{*}In{*}), it should be parsed in correct SQL form, but when
> such repository method is called, below error occurs:
> {code:java}
> Syntax error in SQL statement "SELECT ""PersonCache"".""PERSON""._KEY,
> ""PersonCache"".""PERSON""._VAL FROM PERSON WHERE ((PERSON.SECONDNAME IN
> ?[*])) "; expected "("; SQL statement:
> SELECT "PersonCache"."PERSON"._KEY, "PersonCache"."PERSON"._VAL FROM Person
> WHERE ((Person.secondName IN ?)) [42001-197]
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.query(IgniteCacheProxyImpl.java:861)
> at
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.query(GatewayProtectedCacheProxy.java:420)
> at
> org.apache.ignite.springdata.proxy.IgniteNodeCacheProxy.query(IgniteNodeCacheProxy.java:90)
> at
> org.apache.ignite.springdata.repository.query.IgniteRepositoryQuery.execute(IgniteRepositoryQuery.java:348)
> at
> org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.doInvoke(RepositoryFactorySupport.java:619)
> at
> org.springframework.data.repository.core.support.RepositoryFactorySupport$QueryExecutorMethodInterceptor.invoke(RepositoryFactorySupport.java:606)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
> at
> org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:95)
> at
> org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
> at
> org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:212)
> at com.sun.proxy.$Proxy51.findBySecondNameIn(Unknown Source)
> at
> org.apache.ignite.springdata.IgniteSpringDataCrudSelfTest.testGetPersonsBySecondNameInList(IgniteSpringDataCrudSelfTest.java:453)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2434)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> Here is a reproducer patch (apply to master of ignite-extensions):
> [^IncorrectInOperator.patch]. It contains two tests for single argument and
> for list of arguments.
> It seems, that {{IgniteQueryGenerator}} incorrectly handles {{IN}} (and
> {{{}NOT IN{}}}) operator [1], because if you place '?' between parenthesis,
> error will disappear for single argument.
> But there is another problem after addition of parenthesis: if Collection is
> passed as argument below error will occur:
> {code:java}
> General error: "class org.apache.ignite.IgniteCheckedException: Runtime
> failure on bounds: [lower=IndexSearchRowImpl
> [rowHnd=org.apache.ignite.internal.processors.query.h2.index.QueryIndexRowHandler@6183d0d9],
> upper=IndexSearchRowImpl
> [rowHnd=org.apache.ignite.internal.processors.query.h2.index.QueryIndexRowHandler@6183d0d9]]";
> SQL statement:
> SELECT
> "PersonCache".__Z0._KEY __C0_0,
> "PersonCache".__Z0._VAL __C0_1
> FROM "PersonCache".PERSON __Z0
> WHERE __Z0.SECONDNAME = ?1 [5-197]
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQuery(IgniteH2Indexing.java:900)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeSqlQueryWithTimer(IgniteH2Indexing.java:987)
> at
>
[jira] [Commented] (IGNITE-16136) System Thread pool starvation and out of memory
[
https://issues.apache.org/jira/browse/IGNITE-16136?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17579823#comment-17579823
]
Maxim Muzafarov commented on IGNITE-16136:
--
[~Norbert Löffler] donations to the open-source are always a good thing, but I
doubt it will speedup any particular issue for investigation :-)
[~Norbert Löffler]
[~Sawfish]
Can you help with the issue investigation and describe the steps to reproduce
the issue? Can you attach configuration?
As I can see the Continuous Query and thick clients are used here.
> System Thread pool starvation and out of memory
> ---
>
> Key: IGNITE-16136
> URL: https://issues.apache.org/jira/browse/IGNITE-16136
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7.6
>Reporter: David Albrecht
>Priority: Critical
> Labels: ise
> Fix For: 2.14
>
> Attachments: image-2021-12-15-21-13-43-775.png,
> image-2021-12-15-21-17-47-652.png
>
>
> We are experiencing thread pool starvations and after some time out of memory
> exceptions in some of our ignite client nodes while the server node seems to
> be running without any problems. It seems like all sys threads are stuck when
> calling MarshallerContextImpl.getClassName. Which in turn leads to a growing
> worker queue.
>
> First warnings regarding the thread pool starvation:
> {code:java}
> 10.12.21 11:22:34.603 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:27:34.654 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:32:34.713 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:37:34.764 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:42:34.796 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:47:34.839 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> {code}
> Out of memory error leading to a crash of the application:
> {code}
> Exception: java.lang.OutOfMemoryError thrown from the
> UncaughtExceptionHandler in thread "https-openssl-nio-16443-ClientPoller"
> Exception: java.lang.OutOfMemoryError thrown from the
> UncaughtExceptionHandler in thread "ajp-nio-16009-ClientPoller"
> 11-Dec-2021 03:07:24.446 SEVERE [Catalina-utility-1]
> org.apache.coyote.AbstractProtocol.startAsyncTimeout Error processing async
> timeouts
> java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError:
> Java heap space
> {code}
> The queue full of messages:
> !image-2021-12-15-21-17-47-652.png!
> It seems like all sys threads are stuck while waiting at:
> {code}
> sys-#170
> at jdk.internal.misc.Unsafe.park(ZJ)V (Native Method)
> at java.util.concurrent.locks.LockSupport.park()V (LockSupport.java:323)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(Z)Ljava/lang/Object;
> (GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get()Ljava/lang/Object;
> (GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClassName(BI)Ljava/lang/String;
> (MarshallerContextImpl.java:379)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClass(ILjava/lang/ClassLoader;)Ljava/lang/Class;
> (MarshallerContextImpl.java:344)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(Ljava/util/concurrent/ConcurrentMap;ILjava/lang/ClassLoader;Lorg/apache/ignite/marshaller/MarshallerContext;Lorg/apache/ignite/internal/marshaller/optimized/OptimizedMarshallerIdMapper;)Lorg/apache/ignite/internal/marshaller/optimized/OptimizedClassDescriptor;
> (OptimizedMarshallerUtils.java:264)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0()Ljava/lang/Object;
> (OptimizedObjectInputStream.java:341)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride()Ljava/lang/Object;
>
[jira] [Commented] (IGNITE-17524) Shutdown of large numbers of servers slowed by linear lookup in IgniteServiceProcessor
[
https://issues.apache.org/jira/browse/IGNITE-17524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17579784#comment-17579784
]
Ignite TC Bot commented on IGNITE-17524:
{panel:title=Branch: [pull/10196/head] Base: [master] : Possible Blockers
(11)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 5{color} [[tests 2 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6731604]]
* IgniteCacheTestSuite5:
GridExchangeFreeCellularSwitchComplexOperationsTest.testComplexOperationsRecoveryOnCellularSwitch[Isolation
= OPTIMISTIC, Concurrency = SERIALIZABLE, Started from = CLIENT] - Test has
low fail rate in base branch 0,0% and is not flaky
* IgniteCacheTestSuite5:
GridExchangeFreeCellularSwitchComplexOperationsTest.testComplexOperationsRecoveryOnCellularSwitch[Isolation
= PESSIMISTIC, Concurrency = READ_COMMITTED, Started from = FAILED] - Test has
low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache 6{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6731605]]
{color:#d04437}Platform .NET (Windows){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=6731669]]
* exe: CancellationTest.TestTask - Test has low fail rate in base branch 0,0%
and is not flaky
* exe: IgniteLockTests.TestFairLockGuaranteesOrder - Test has low fail rate in
base branch 0,0% and is not flaky
{color:#d04437}Cache 9{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6731608]]
{color:#d04437}Cache 8{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=6731607]]
* IgniteCacheTestSuite8:
GridCacheConcurrentEvictionConsistencySelfTest.testPolicyConsistencySorted -
Test has low fail rate in base branch 0,0% and is not flaky
* IgniteCacheTestSuite8: PageEvictionDataStreamerTest.testPageEviction - Test
has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}PDS 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6731654]]
* IgnitePdsTestSuite:
IgniteClusterActivateDeactivateTestWithPersistence.testDeactivateDuringEvictionAndRebalance
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Queries 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6731672]]
* IgniteBinaryCacheQueryTestSuite2:
IgniteCacheQueryNodeRestartDistributedJoinSelfTest.testRestartsBroadcast - Test
has low fail rate in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/10196/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=6731700buildTypeId=IgniteTests24Java8_RunAll]
> Shutdown of large numbers of servers slowed by linear lookup in
> IgniteServiceProcessor
> --
>
> Key: IGNITE-17524
> URL: https://issues.apache.org/jira/browse/IGNITE-17524
> Project: Ignite
> Issue Type: Improvement
> Components: managed services
>Affects Versions: 2.13
>Reporter: Arthur Naseef
>Assignee: Arthur Naseef
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Cloned from IGNITE-17274. That ticket addresses startup timing, and this one
> addresses shutdown timing.
> Shutting down large numbers of services is slowed down by a linear lookup
> that can be addressed by adding a map to perform the lookups.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (IGNITE-17496) LWM may be after HWM (reserved) on primary after the node restart
[ https://issues.apache.org/jira/browse/IGNITE-17496 ]
Anton Vinogradov deleted comment on IGNITE-17496:
---
was (Author: ignitetcbot):
{panel:title=Branch: [pull/10185/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10185/head] Base: [master] : New Tests
(40)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Control Utility{color} [[tests
40|https://ci2.ignite.apache.org/viewLog.html?buildId=6556545]]
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyCountersTest.testCountersOnCrachRecovery[strategy=LWW,
reuse=false, historical=false, atomicity=ATOMIC] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyCountersTest.testCountersOnCrachRecovery[strategy=LWW,
reuse=true, historical=false, atomicity=ATOMIC] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyCountersTest.testCountersOnCrachRecovery[strategy=LWW,
reuse=false, historical=true, atomicity=TRANSACTIONAL] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyCountersTest.testCountersOnCrachRecovery[strategy=LWW,
reuse=false, historical=true, atomicity=ATOMIC] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyCountersTest.testCountersOnCrachRecovery[strategy=LWW,
reuse=false, historical=false, atomicity=TRANSACTIONAL] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyCountersTest.testCountersOnCrachRecovery[strategy=PRIMARY,
reuse=false, historical=false, atomicity=ATOMIC] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyCountersTest.testCountersOnCrachRecovery[strategy=LWW,
reuse=true, historical=true, atomicity=TRANSACTIONAL] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyCountersTest.testCountersOnCrachRecovery[strategy=LWW,
reuse=true, historical=true, atomicity=ATOMIC] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyCountersTest.testCountersOnCrachRecovery[strategy=LWW,
reuse=true, historical=false, atomicity=TRANSACTIONAL] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyCountersTest.testCountersOnCrachRecovery[strategy=PRIMARY,
reuse=true, historical=false, atomicity=ATOMIC] - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerConsistencyCountersTest.testCountersOnCrachRecovery[strategy=PRIMARY,
reuse=false, historical=true, atomicity=TRANSACTIONAL] - PASSED{color}
... and 29 new tests
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6556537buildTypeId=IgniteTests24Java8_RunAll]
> LWM may be after HWM (reserved) on primary after the node restart
> -
>
> Key: IGNITE-17496
> URL: https://issues.apache.org/jira/browse/IGNITE-17496
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {code:java}
> java.lang.AssertionError: LWM after HWM: lwm=10010, hwm=10003, cntr=Counter
> [lwm=10010, missed=[10011 - 10012, 10021, 10031 - 10032, 10043 - 10044],
> maxApplied=10047, hwm=10004]
> at
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl.reserve(PartitionUpdateCounterTrackingImpl.java:265)
> at
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterErrorWrapper.reserve(PartitionUpdateCounterErrorWrapper.java:58)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.getAndIncrementUpdateCounter(IgniteCacheOffheapManagerImpl.java:1620)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.getAndIncrementUpdateCounter(GridCacheOffheapManager.java:2538)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition.getAndIncrementUpdateCounter(GridDhtLocalPartition.java:942)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxLocalAdapter.calculatePartitionUpdateCounters(IgniteTxLocalAdapter.java:510)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.prepare0(GridDhtTxPrepareFuture.java:1360)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxPrepareFuture.mapIfLocked(GridDhtTxPrepareFuture.java:730)
> at
>
[jira] [Updated] (IGNITE-17528) Use parameter instead of option in config show commands
[
https://issues.apache.org/jira/browse/IGNITE-17528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vadim Pakhnushev updated IGNITE-17528:
--
Summary: Use parameter instead of option in config show commands (was: Use
paramer instead of option in config show commands)
> Use parameter instead of option in config show commands
> ---
>
> Key: IGNITE-17528
> URL: https://issues.apache.org/jira/browse/IGNITE-17528
> Project: Ignite
> Issue Type: Task
> Components: cli
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
>
> Currently {{node config show}} command use {{--selector}} option to pass the
> config path.
> Change it to the parameter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17531) Tests covers consistency repair at inconsistent cluster with nonfinalized counters
Anton Vinogradov created IGNITE-17531: - Summary: Tests covers consistency repair at inconsistent cluster with nonfinalized counters Key: IGNITE-17531 URL: https://issues.apache.org/jira/browse/IGNITE-17531 Project: Ignite Issue Type: Sub-task Reporter: Anton Vinogradov Assignee: Anton Vinogradov Test must 1) Generate data with missed unordered update counter (gaps) 2) Perform restart with rebalance (full or historiical) 3) Check consistency on restart using idle_verify 4) Fix inconsistency using consistency_repair 5) Check result using idle_verify The main goal is to check recovery at production (where cluster may fail under the load) tools and approaches. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17257) Implement Replica server-side logic
[ https://issues.apache.org/jira/browse/IGNITE-17257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17579712#comment-17579712 ] Alexander Lapin commented on IGNITE-17257: -- [~Sergey Uttsel] LGTM to feature branch. > Implement Replica server-side logic > --- > > Key: IGNITE-17257 > URL: https://issues.apache.org/jira/browse/IGNITE-17257 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3, transaction3_rw > > For general context please check IGNITE-17252. In addition to client > [ReplicaService|https://issues.apache.org/jira/browse/IGNITE-17257] it's > required to implement server side logic that will handle actionRequests. > Generally speaking all business related logic will be specified in > ReplicaListener, Replica or replica server itself should only handle > replication-outer action requests and propagate them to ReplicaListener, so > that it might be considered as > org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcServer / > org.apache.ignite.raft.jraft.rpc.impl.ActionRequestProcessor counterpart that > handles all business related replication-external requests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17257) Implement Replica server-side logic
[ https://issues.apache.org/jira/browse/IGNITE-17257?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-17257: - Reviewer: Alexander Lapin > Implement Replica server-side logic > --- > > Key: IGNITE-17257 > URL: https://issues.apache.org/jira/browse/IGNITE-17257 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3, transaction3_rw > > For general context please check IGNITE-17252. In addition to client > [ReplicaService|https://issues.apache.org/jira/browse/IGNITE-17257] it's > required to implement server side logic that will handle actionRequests. > Generally speaking all business related logic will be specified in > ReplicaListener, Replica or replica server itself should only handle > replication-outer action requests and propagate them to ReplicaListener, so > that it might be considered as > org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcServer / > org.apache.ignite.raft.jraft.rpc.impl.ActionRequestProcessor counterpart that > handles all business related replication-external requests. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17470) Add initial support of Spark 3.2
[ https://issues.apache.org/jira/browse/IGNITE-17470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Gagarkin updated IGNITE-17470: --- Reviewer: (was: Nikolay Izhikov) > Add initial support of Spark 3.2 > > > Key: IGNITE-17470 > URL: https://issues.apache.org/jira/browse/IGNITE-17470 > Project: Ignite > Issue Type: Task > Components: spark >Affects Versions: 2.14 >Reporter: Ivan Gagarkin >Assignee: Ivan Gagarkin >Priority: Major > Fix For: 2.14 > > Time Spent: 40m > Remaining Estimate: 0h > > Update ignite-spark module to spark-3.2 and scala 12 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (IGNITE-17470) Add initial support of Spark 3.2
[ https://issues.apache.org/jira/browse/IGNITE-17470 ] Ivan Gagarkin deleted comment on IGNITE-17470: was (Author: JIRAUSER293370): [~NIzhikov] Could you take a look at the PR, please? > Add initial support of Spark 3.2 > > > Key: IGNITE-17470 > URL: https://issues.apache.org/jira/browse/IGNITE-17470 > Project: Ignite > Issue Type: Task > Components: spark >Affects Versions: 2.14 >Reporter: Ivan Gagarkin >Assignee: Ivan Gagarkin >Priority: Major > Fix For: 2.14 > > Time Spent: 40m > Remaining Estimate: 0h > > Update ignite-spark module to spark-3.2 and scala 12 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17530) Can't start node with custom config file
Vadim Pakhnushev created IGNITE-17530:
-
Summary: Can't start node with custom config file
Key: IGNITE-17530
URL: https://issues.apache.org/jira/browse/IGNITE-17530
Project: Ignite
Issue Type: Bug
Components: cli
Reporter: Vadim Pakhnushev
Assignee: Vadim Pakhnushev
Running {{ignite node start --config examples/config/ignite-config.conf node4}}
produces following error in the node4.log file:
{{Unknown options: '--config-path', 'node4'}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17338) Implement RocksDB based hash index storage
[
https://issues.apache.org/jira/browse/IGNITE-17338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev reassigned IGNITE-17338:
Assignee: Aleksandr Polovtcev
> Implement RocksDB based hash index storage
> --
>
> Key: IGNITE-17338
> URL: https://issues.apache.org/jira/browse/IGNITE-17338
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> Please see IGNITE-17318 for partial description of what needs to be achieved.
> I expect that hash index records will have the following structure:
> {code:java}
> [ indexId | partitionId | hash | tuple | rowId ] -> []{code}
> Fixed-length prefix should cover indexId, partitionId and hash value.
> Searching rows effectively becomes a scan, but this is fine.
> Hashing must be performed internally, hash function already presents
> somewhere in the code.
> Is far as I understand, PK is going to be implemented as a secondary hash
> index.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17524) Shutdown of large numbers of servers slowed by linear lookup in IgniteServiceProcessor
[ https://issues.apache.org/jira/browse/IGNITE-17524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17579674#comment-17579674 ] Pavel Tupitsyn commented on IGNITE-17524: - The PR looks good to me. Waiting for the TC build: https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_RunAll/6731700? > Shutdown of large numbers of servers slowed by linear lookup in > IgniteServiceProcessor > -- > > Key: IGNITE-17524 > URL: https://issues.apache.org/jira/browse/IGNITE-17524 > Project: Ignite > Issue Type: Improvement > Components: managed services >Affects Versions: 2.13 >Reporter: Arthur Naseef >Assignee: Arthur Naseef >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > Cloned from IGNITE-17274. That ticket addresses startup timing, and this one > addresses shutdown timing. > Shutting down large numbers of services is slowed down by a linear lookup > that can be addressed by adding a map to perform the lookups. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17529) Allow changing CLI config file path via environment variable
Vadim Pakhnushev created IGNITE-17529:
-
Summary: Allow changing CLI config file path via environment
variable
Key: IGNITE-17529
URL: https://issues.apache.org/jira/browse/IGNITE-17529
Project: Ignite
Issue Type: Task
Components: cli
Reporter: Vadim Pakhnushev
Assignee: Vadim Pakhnushev
Use {{IGNITE_CLI_CONFIG_FILE}} to define path to the CLI config file which is
currently defined as {{XDG_CONFIG_HOME/ignitecli/defaults}} where
{{XDG_CONFIG_HOME}} defaults to {{~/.config}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17528) Use paramer instead of option in config show commands
Vadim Pakhnushev created IGNITE-17528:
-
Summary: Use paramer instead of option in config show commands
Key: IGNITE-17528
URL: https://issues.apache.org/jira/browse/IGNITE-17528
Project: Ignite
Issue Type: Task
Components: cli
Reporter: Vadim Pakhnushev
Assignee: Vadim Pakhnushev
Currently {{node config show}} command use {{--selector}} option to pass the
config path.
Change it to the parameter.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17527) Add short aliases for options
Vadim Pakhnushev created IGNITE-17527:
-
Summary: Add short aliases for options
Key: IGNITE-17527
URL: https://issues.apache.org/jira/browse/IGNITE-17527
Project: Ignite
Issue Type: Task
Components: cli
Reporter: Vadim Pakhnushev
Assignee: Vadim Pakhnushev
According to
[IEP|https://cwiki.apache.org/confluence/display/IGNITE/IEP-88%3A+CLI+Tool],
every CLI command option should have both long and short versions.
Add short version {{-u}} to URL options.
Use {{-c -p -r -j}} for {{-config --port --rest-port --join}} in {{{}node
start{}}}, respectively.
Use {{-m -c -n}} for {{-meta-storage-node --cmg-node --cluster-name}} in
{{cluster init}}, respectively.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17526) NPE in GridCacheDistributedQueryFuture for node failure
[
https://issues.apache.org/jira/browse/IGNITE-17526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17579648#comment-17579648
]
Ignite TC Bot commented on IGNITE-17526:
{panel:title=Branch: [pull/10197/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10197/head] Base: [master] : New Tests
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Queries 2 (lazy=true){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6731417]]
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite2:
IgniteCacheQueryNodeFailTest.testNonQueryClientNodeFailed - PASSED{color}
{color:#8b}Queries 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6731118]]
* {color:#013220}IgniteBinaryCacheQueryTestSuite2:
IgniteCacheQueryNodeFailTest.testNonQueryClientNodeFailed - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6731146buildTypeId=IgniteTests24Java8_RunAll]
> NPE in GridCacheDistributedQueryFuture for node failure
> ---
>
> Key: IGNITE-17526
> URL: https://issues.apache.org/jira/browse/IGNITE-17526
> Project: Ignite
> Issue Type: Bug
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> NPE in #onNodeLeft as it doesn't check whether node is in the `#streams` or
> not.
>
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryFuture.onNodeLeft(GridCacheDistributedQueryFuture.java:144)
> ~[ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$3.onEvent(GridCacheDistributedQueryManager.java:118)
> ~[ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT]
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager$LocalListenerWrapper.onEvent(GridEventStorageManager.java:1408)
> ~[ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT]
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:903)
> [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT]
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:888)
> [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT]
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record0(GridEventStorageManager.java:359)
> [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT]
> at
> org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record(GridEventStorageManager.java:322)
> [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT]
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.recordEvent(GridDiscoveryManager.java:3056)
> [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT]
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body0(GridDiscoveryManager.java:3273)
> [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT]
> at
> org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body(GridDiscoveryManager.java:3076)
> [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT]
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT]
> at java.lang.Thread.run(Thread.java:748) [?:1.8.0_291]
>
> [https://ci2.ignite.apache.org/test/-8353273041775919887?currentProjectId=IgniteTests24Java8=%3Cdefault%3E=true]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-12662) Get rid of CacheConfiguration#getRebalanceDelay and related functionality.
[ https://issues.apache.org/jira/browse/IGNITE-12662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov reassigned IGNITE-12662: Assignee: Maxim Muzafarov > Get rid of CacheConfiguration#getRebalanceDelay and related functionality. > -- > > Key: IGNITE-12662 > URL: https://issues.apache.org/jira/browse/IGNITE-12662 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Scherbakov >Assignee: Maxim Muzafarov >Priority: Major > Labels: IEP-80 > Fix For: 2.14 > > > We have for a long time this property to mitigate a case with premature > rebalancing on node restart. > Currently this is handled by baseline topology. > I suggest to deprecate and remove related functionality in next releases. > For example org.apache.ignite.IgniteCache#rebalance is no longer needed as > well. > [Dev list > discussion|http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Deprecation-of-obsolete-rebalancing-functionality-td45824.html] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17526) NPE in GridCacheDistributedQueryFuture for node failure
[ https://issues.apache.org/jira/browse/IGNITE-17526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-17526: Description: NPE in #onNodeLeft as it doesn't check whether node is in the `#streams` or not. java.lang.NullPointerException: null at org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryFuture.onNodeLeft(GridCacheDistributedQueryFuture.java:144) ~[ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] at org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$3.onEvent(GridCacheDistributedQueryManager.java:118) ~[ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] at org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager$LocalListenerWrapper.onEvent(GridEventStorageManager.java:1408) ~[ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] at org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:903) [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] at org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:888) [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] at org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record0(GridEventStorageManager.java:359) [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] at org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record(GridEventStorageManager.java:322) [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] at org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.recordEvent(GridDiscoveryManager.java:3056) [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] at org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body0(GridDiscoveryManager.java:3273) [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] at org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body(GridDiscoveryManager.java:3076) [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125) [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] at java.lang.Thread.run(Thread.java:748) [?:1.8.0_291] [https://ci2.ignite.apache.org/test/-8353273041775919887?currentProjectId=IgniteTests24Java8=%3Cdefault%3E=true] was: NPE in #onNodeLeft as it doesn't check whether node is in the `#streams` or not. https://ci2.ignite.apache.org/test/-8353273041775919887?currentProjectId=IgniteTests24Java8=%3Cdefault%3E=true > NPE in GridCacheDistributedQueryFuture for node failure > --- > > Key: IGNITE-17526 > URL: https://issues.apache.org/jira/browse/IGNITE-17526 > Project: Ignite > Issue Type: Bug >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > NPE in #onNodeLeft as it doesn't check whether node is in the `#streams` or > not. > > java.lang.NullPointerException: null > at > org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryFuture.onNodeLeft(GridCacheDistributedQueryFuture.java:144) > ~[ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.processors.cache.query.GridCacheDistributedQueryManager$3.onEvent(GridCacheDistributedQueryManager.java:118) > ~[ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager$LocalListenerWrapper.onEvent(GridEventStorageManager.java:1408) > ~[ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:903) > [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.notifyListeners(GridEventStorageManager.java:888) > [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record0(GridEventStorageManager.java:359) > [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.eventstorage.GridEventStorageManager.record(GridEventStorageManager.java:322) > [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.recordEvent(GridDiscoveryManager.java:3056) > [ignite-core-2.14.0-SNAPSHOT.jar:2.14.0-SNAPSHOT] > at > org.apache.ignite.internal.managers.discovery.GridDiscoveryManager$DiscoveryWorker.body0(GridDiscoveryManager.java:3273) >
[jira] [Assigned] (IGNITE-17378) Check the replica is a primary before processing request at Replica
[ https://issues.apache.org/jira/browse/IGNITE-17378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel reassigned IGNITE-17378: -- Assignee: Sergey Uttsel > Check the replica is a primary before processing request at Replica > --- > > Key: IGNITE-17378 > URL: https://issues.apache.org/jira/browse/IGNITE-17378 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3, transaction3_rw > > Need to check that a current leader and a leader from request are equals on > Replica#processRequest. For this purpose we need to use > RaftGroupService#refreshAndGetLeaderWithTerm in InternalTableImpl#enlist, > send Leader and Term with request and compare it in Replica#processRequest. > If they not equals then need to throw PrimaryReplicaMissException. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17286) Race between completing table creation and stopping TableManager
[
https://issues.apache.org/jira/browse/IGNITE-17286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17579590#comment-17579590
]
Vladislav Pyatkov commented on IGNITE-17286:
Reverted the patch due to a new issue discovered in TC
6380367c8aecec8e3294b3801241f71d47effaf1
> Race between completing table creation and stopping TableManager
>
>
> Key: IGNITE-17286
> URL: https://issues.apache.org/jira/browse/IGNITE-17286
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> As IGNITE-17048 demonstrates, our tests sometimes fail with message like the
> following:
> java.lang.AssertionError: Raft groups are still running
> The leftover Raft groups always relate to table partitions (and NOT
> metastorage/cmg).
> It looks like this can happen due to TableManager.stop() being called before
> some table creation is completed (on some Ignite node). As a result,
> TableManager.stop() does not see this table, so the table does not get
> stopped, and its Raft groups are left forever.
> Adding a delay to table creation completion
> public void onSqlSchemaReady(long causalityToken) {
> if (Math.random() < 0.33) {
> try
> { Thread.sleep(1000); }
> catch (InterruptedException e)
> { // ignore }
> }
> LOG.info("SCHEMA READY FOR " + causalityToken);
> tablesByIdVv.complete(causalityToken);
> }
> makes the failure manifest itself easily.
> The reproducer is in
> [https://github.com/gridgain/apache-ignite-3/tree/ignite-17286-repr]
> To run the reproducer, just run
> ItComputeTest.executesColocatedByClassNameWithTupleKey()
> It usually takes less than 10 iterations to bump into the assertion.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17485) Gradle build support
[ https://issues.apache.org/jira/browse/IGNITE-17485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin reassigned IGNITE-17485: -- Assignee: Mikhail Pochatkin > Gradle build support > - > > Key: IGNITE-17485 > URL: https://issues.apache.org/jira/browse/IGNITE-17485 > Project: Ignite > Issue Type: New Feature > Components: build >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > > Move Apache Ignite to Gradle as second build system. > *IMPORTANT: Maven build should NOT remove in context of this ticket and > should stay as default build system.* > # Create gradle modules with similar structure as Maven and write build > scripts. > # All target artifacts should be same as maven. > (check-rules/maven-check-scripts content should be also applied, but better > to use plugins instead of binary scripts). > # All style checks and code quality checks should be not changed in gradle > build. > # Target Gradle version 7. > # Build process should be unified for Linux and Windows OS. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17526) NPE in GridCacheDistributedQueryFuture for node failure
[ https://issues.apache.org/jira/browse/IGNITE-17526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-17526: Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > NPE in GridCacheDistributedQueryFuture for node failure > --- > > Key: IGNITE-17526 > URL: https://issues.apache.org/jira/browse/IGNITE-17526 > Project: Ignite > Issue Type: Bug >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > NPE in #onNodeLeft as it doesn't check whether node is in the `#streams` or > not. > > https://ci2.ignite.apache.org/test/-8353273041775919887?currentProjectId=IgniteTests24Java8=%3Cdefault%3E=true -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17526) NPE in GridCacheDistributedQueryFuture for node failure
[ https://issues.apache.org/jira/browse/IGNITE-17526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-17526: Fix Version/s: 2.14 > NPE in GridCacheDistributedQueryFuture for node failure > --- > > Key: IGNITE-17526 > URL: https://issues.apache.org/jira/browse/IGNITE-17526 > Project: Ignite > Issue Type: Bug >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > NPE in #onNodeLeft as it doesn't check whether node is in the `#streams` or > not. > > https://ci2.ignite.apache.org/test/-8353273041775919887?currentProjectId=IgniteTests24Java8=%3Cdefault%3E=true -- This message was sent by Atlassian Jira (v8.20.10#820010)
