[jira] [Commented] (IGNITE-13289) PagesWriteThrottleSmokeTest.testThrottle start to fail on TC.
[
https://issues.apache.org/jira/browse/IGNITE-13289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17164162#comment-17164162
]
Ignite TC Bot commented on IGNITE-13289:
{panel:title=Branch: [pull/8072/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8072/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: Basic Tests*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5486743buildTypeId=IgniteTests24Java8_RunBasicTests]
> PagesWriteThrottleSmokeTest.testThrottle start to fail on TC.
> -
>
> Key: IGNITE-13289
> URL: https://issues.apache.org/jira/browse/IGNITE-13289
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.8.1
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> PagesWriteThrottleSmokeTest.testThrottle start to fail on master, possible
> after IGNITE-12802 was merged.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13289) PagesWriteThrottleSmokeTest.testThrottle start to fail on TC.
[ https://issues.apache.org/jira/browse/IGNITE-13289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17164161#comment-17164161 ] Stanilovsky Evgeny commented on IGNITE-13289: - [~alex_pl] thanks, i fix it. > PagesWriteThrottleSmokeTest.testThrottle start to fail on TC. > - > > Key: IGNITE-13289 > URL: https://issues.apache.org/jira/browse/IGNITE-13289 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.8.1 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Time Spent: 0.5h > Remaining Estimate: 0h > > PagesWriteThrottleSmokeTest.testThrottle start to fail on master, possible > after IGNITE-12802 was merged. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13289) PagesWriteThrottleSmokeTest.testThrottle start to fail on TC.
[
https://issues.apache.org/jira/browse/IGNITE-13289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17164160#comment-17164160
]
Ignite TC Bot commented on IGNITE-13289:
{panel:title=Branch: [pull/8072/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8072/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: Basic Tests*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5486743buildTypeId=IgniteTests24Java8_RunBasicTests]
> PagesWriteThrottleSmokeTest.testThrottle start to fail on TC.
> -
>
> Key: IGNITE-13289
> URL: https://issues.apache.org/jira/browse/IGNITE-13289
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.8.1
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> PagesWriteThrottleSmokeTest.testThrottle start to fail on master, possible
> after IGNITE-12802 was merged.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13295) Expiration of cache entries, which relate to a non-persistent data region in the persistent cluster, results in AssertionError
[
https://issues.apache.org/jira/browse/IGNITE-13295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-13295:
-
Description:
In the case of the cluster uses AI native persistent and, in the same time, it
has a non-persistent data region and cache related to that non-persistent
region with expiry policy specified, the following Exception is thrown:
{noformat}
java.lang.AssertionError
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:2678)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:619)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4411)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:4103)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onTtlExpired(GridCacheMapEntry.java:4028)
at
org.apache.ignite.internal.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:76)
at
org.apache.ignite.internal.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:67)
at
org.apache.ignite.internal.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.expireInternal(IgniteCacheOffheapManagerImpl.java:1422)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.expire(IgniteCacheOffheapManagerImpl.java:1367)
at
org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:243)
at
org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.lambda$body$0(GridCacheSharedTtlCleanupManager.java:179)
at
java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769)
at
org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.body(GridCacheSharedTtlCleanupManager.java:178)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748)
{noformat}
The root cause of the issue is the fact that
{{IgniteCacheOffheapManagerImpl#expireInternal}} does not try to acquire a
checkpoint read lock at all.
was:
In the case of the cluster uses AI native persistent and, in the same time, it
has a non-persistent data region and cache related to that non-persistent
region with expiry policy specified, the following Exception is thrown:
{noformat}
java.lang.AssertionErrorjava.lang.AssertionError at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:2678)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:619)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4411)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:4103)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onTtlExpired(GridCacheMapEntry.java:4028)
at
org.apache.ignite.internal.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:76)
at
org.apache.ignite.internal.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:67)
at
org.apache.ignite.internal.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.expireInternal(IgniteCacheOffheapManagerImpl.java:1422)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.expire(IgniteCacheOffheapManagerImpl.java:1367)
at
org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:243)
at
org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.lambda$body$0(GridCacheSharedTtlCleanupManager.java:179)
at
java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769)
at
org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.body(GridCacheSharedTtlCleanupManager.java:178)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748){noformat}
The root cause of the issue is the fact that
{{IgniteCacheOffheapManagerImpl#expireInternal}} does not try to acquire a
checkpoint read lock at all.
> Expiration of cache entries, which relate to a non-persistent data region in
> the persistent cluster, results in AssertionError
>
[jira] [Created] (IGNITE-13295) Expiration of cache entries, which relate to a non-persistent data region in the persistent cluster, results in AssertionError
Vyacheslav Koptilin created IGNITE-13295:
Summary: Expiration of cache entries, which relate to a
non-persistent data region in the persistent cluster, results in AssertionError
Key: IGNITE-13295
URL: https://issues.apache.org/jira/browse/IGNITE-13295
Project: Ignite
Issue Type: Bug
Affects Versions: 2.8.1
Reporter: Vyacheslav Koptilin
Assignee: Vyacheslav Koptilin
Fix For: 2.10
In the case of the cluster uses AI native persistent and, in the same time, it
has a non-persistent data region and cache related to that non-persistent
region with expiry policy specified, the following Exception is thrown:
{noformat}
java.lang.AssertionErrorjava.lang.AssertionError at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.remove(IgniteCacheOffheapManagerImpl.java:2678)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.remove(IgniteCacheOffheapManagerImpl.java:619)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.removeValue(GridCacheMapEntry.java:4411)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onExpired(GridCacheMapEntry.java:4103)
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.onTtlExpired(GridCacheMapEntry.java:4028)
at
org.apache.ignite.internal.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:76)
at
org.apache.ignite.internal.processors.cache.GridCacheTtlManager$1.applyx(GridCacheTtlManager.java:67)
at
org.apache.ignite.internal.util.lang.IgniteInClosure2X.apply(IgniteInClosure2X.java:38)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.expireInternal(IgniteCacheOffheapManagerImpl.java:1422)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.expire(IgniteCacheOffheapManagerImpl.java:1367)
at
org.apache.ignite.internal.processors.cache.GridCacheTtlManager.expire(GridCacheTtlManager.java:243)
at
org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.lambda$body$0(GridCacheSharedTtlCleanupManager.java:179)
at
java.util.concurrent.ConcurrentHashMap.computeIfPresent(ConcurrentHashMap.java:1769)
at
org.apache.ignite.internal.processors.cache.GridCacheSharedTtlCleanupManager$CleanupWorker.body(GridCacheSharedTtlCleanupManager.java:178)
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.lang.Thread.run(Thread.java:748){noformat}
The root cause of the issue is the fact that
{{IgniteCacheOffheapManagerImpl#expireInternal}} does not try to acquire a
checkpoint read lock at all.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13175) NPE due to race on cache stop and transaction commit.
[
https://issues.apache.org/jira/browse/IGNITE-13175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17164016#comment-17164016
]
Ignite TC Bot commented on IGNITE-13175:
{panel:title=Branch: [pull/8075/head] Base: [master] : Possible Blockers
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS 4{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5486909]]
{color:#d04437}Platform .NET (Long Running){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5486911]]
{panel}
{panel:title=Branch: [pull/8075/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=5485911buildTypeId=IgniteTests24Java8_RunAll]
> NPE due to race on cache stop and transaction commit.
> -
>
> Key: IGNITE-13175
> URL: https://issues.apache.org/jira/browse/IGNITE-13175
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Alexand Polyakov
>Assignee: Maria Makedonskaya
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If don't stop load and execute stop cache, sometimes throw
> NullPointerException and nodes failed
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.finishUnmarshal(BinaryObjectImpl.java:190)
> at
> org.apache.ignite.internal.processors.cache.transactions.TxEntryValueHolder.unmarshal(TxEntryValueHolder.java:154)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxEntry.unmarshal(IgniteTxEntry.java:971)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.unmarshal(IgniteTxHandler.java:354)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:403)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:386)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:188)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.lambda$null$0(IgniteTxHandler.java:644)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:559)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> transaction use cache context race with stopCache
> {code:java}
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.cleanup(GridCacheContext.java:2058)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.cleanup(GridCacheProcessor.java:467)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCache(GridCacheProcessor.java:1020)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2539)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2518)
> {code}
> there is a reproducer who adds CountDownLatch await to
> IgniteTxEntry#unmarshal which is countDown in GridCacheContext#cleanup
> https://github.com/gridgain/gridgain/tree/sdsb-11837
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12641) IgniteSequenceInternalCleanupTest flacky after IGNITE-12598
[ https://issues.apache.org/jira/browse/IGNITE-12641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163995#comment-17163995 ] Andrey N. Gura commented on IGNITE-12641: - [~nizhikov] Actually IGNITE-12598 is about metrics configuration not about metrics values. After deactivation metric registries should be removed and after activation - new metric registries should be created. So test is incorrect after this change. But ok, will be fixed under IGNITE-11927. > IgniteSequenceInternalCleanupTest flacky after IGNITE-12598 > --- > > Key: IGNITE-12641 > URL: https://issues.apache.org/jira/browse/IGNITE-12641 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Nikolay Izhikov >Priority: Major > Labels: IEP-35 > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > IgniteSequenceInternalCleanupTest#deactivate is flacky after IGNITE-12598 > The test expects that cache metrics will be reset after cluster deactivation > and subsequent cache stop. > But this was changed intentionally in IGNITE-12598. > Test not always fail because it asserts cluster metrics value which updated > concurrently with the test thread. > We should fix the assert. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12930) DistributedProcess fails node if unable to send single message to coordinator
[
https://issues.apache.org/jira/browse/IGNITE-12930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163767#comment-17163767
]
Maxim Muzafarov commented on IGNITE-12930:
--
[~alex_pl],
Can you please herry-pick changes to 2.9 branch?
> DistributedProcess fails node if unable to send single message to coordinator
> -
>
> Key: IGNITE-12930
> URL: https://issues.apache.org/jira/browse/IGNITE-12930
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: Amelchev Nikita
>Priority: Critical
> Fix For: 2.9
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> The
> [DistributedProcess|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/util/distributed/DistributedProcess.java]
> fails the local node ({{FailureHandler}} CRITICAL_ERROR thrown) if unable to
> send a message to the coordinator (e.g. the coordinator fails right before
> the single message is sent).
> {code:java}
> try {
> ctx.io().sendToGridTopic(p.crdId,
> GridTopic.TOPIC_DISTRIBUTED_PROCESS, singleMsg, SYSTEM_POOL);
> }
> catch (IgniteCheckedException e) {
> log.error("Unable to send message to coordinator.", e);
> ctx.failure().process(new FailureContext(CRITICAL_ERROR,
> new Exception("Unable to send message to coordinator.",
> e)));
> }
> {code}
> h4. Expected behaviour
> If the {{ClusterTopologyCheckedException}} occurs need to wait for the
> NODE_LEFT event of the coordinator node and re-init the distributed process
> future.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13282) Fix TcpDiscoveryCoordinatorFailureTest.testClusterFailedNewCoordinatorInitialized()
[
https://issues.apache.org/jira/browse/IGNITE-13282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163768#comment-17163768
]
Ignite TC Bot commented on IGNITE-13282:
{panel:title=Branch: [pull/8073/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8073/head] Base: [master] : New Tests
(8)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Service Grid (legacy mode){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5484938]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=8d2894d4-a884-4e9c-a150-2952ca7a35de, topVer=0,
msgTemplate=null, span=null, nodeId8=e4b89b10, msg=, type=NODE_JOINED,
tstamp=1595451927348], val2=AffinityTopologyVersion
[topVer=-5364889628245386958, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=8d2894d4-a884-4e9c-a150-2952ca7a35de, topVer=0,
msgTemplate=null, span=null, nodeId8=e4b89b10, msg=, type=NODE_JOINED,
tstamp=1595451927348], val2=AffinityTopologyVersion
[topVer=-5364889628245386958, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=83b68587371-b6474a1a-0d21-48d1-bee2-3e5fdf826695, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=db62c97b-dd8a-412f-8365-ac3478744177, topVer=0, msgTemplate=null,
span=null, nodeId8=db62c97b, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595451927348]], val2=AffinityTopologyVersion
[topVer=6450744355825789367, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=83b68587371-b6474a1a-0d21-48d1-bee2-3e5fdf826695, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=db62c97b-dd8a-412f-8365-ac3478744177, topVer=0, msgTemplate=null,
span=null, nodeId8=db62c97b, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595451927348]], val2=AffinityTopologyVersion
[topVer=6450744355825789367, minorTopVer=0]]] - PASSED{color}
{color:#8b}Service Grid{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5484937]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=c265f392-ba0e-4292-acf7-cc68459452bb, topVer=0,
msgTemplate=null, span=null, nodeId8=0a0f16b7, msg=, type=NODE_JOINED,
tstamp=1595451967944], val2=AffinityTopologyVersion
[topVer=2201327657831461553, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=c6763687371-a290390b-4ac7-473d-a55d-d56822fb1e7f, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=06ab6b23-c329-42ab-b1e0-068473d4573f, topVer=0, msgTemplate=null,
span=null, nodeId8=06ab6b23, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595451967944]], val2=AffinityTopologyVersion
[topVer=-6810063726558881715, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=c6763687371-a290390b-4ac7-473d-a55d-d56822fb1e7f, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=06ab6b23-c329-42ab-b1e0-068473d4573f, topVer=0, msgTemplate=null,
span=null, nodeId8=06ab6b23, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595451967944]], val2=AffinityTopologyVersion
[topVer=-6810063726558881715, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=c265f392-ba0e-4292-acf7-cc68459452bb, topVer=0,
msgTemplate=null, span=null, nodeId8=0a0f16b7, msg=, type=NODE_JOINED,
tstamp=1595451967944], val2=AffinityTopologyVersion
[topVer=2201327657831461553, minorTopVer=0]]] - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5484960buildTypeId=IgniteTests24Java8_RunAll]
> Fix
> TcpDiscoveryCoordinatorFailureTest.testClusterFailedNewCoordinatorInitialized()
> ---
>
> Key:
[jira] [Commented] (IGNITE-12930) DistributedProcess fails node if unable to send single message to coordinator
[
https://issues.apache.org/jira/browse/IGNITE-12930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163715#comment-17163715
]
Maxim Muzafarov commented on IGNITE-12930:
--
LGTM, merged to the master branch.
> DistributedProcess fails node if unable to send single message to coordinator
> -
>
> Key: IGNITE-12930
> URL: https://issues.apache.org/jira/browse/IGNITE-12930
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: Amelchev Nikita
>Priority: Critical
> Fix For: 2.9
>
> Time Spent: 1h 40m
> Remaining Estimate: 0h
>
> The
> [DistributedProcess|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/util/distributed/DistributedProcess.java]
> fails the local node ({{FailureHandler}} CRITICAL_ERROR thrown) if unable to
> send a message to the coordinator (e.g. the coordinator fails right before
> the single message is sent).
> {code:java}
> try {
> ctx.io().sendToGridTopic(p.crdId,
> GridTopic.TOPIC_DISTRIBUTED_PROCESS, singleMsg, SYSTEM_POOL);
> }
> catch (IgniteCheckedException e) {
> log.error("Unable to send message to coordinator.", e);
> ctx.failure().process(new FailureContext(CRITICAL_ERROR,
> new Exception("Unable to send message to coordinator.",
> e)));
> }
> {code}
> h4. Expected behaviour
> If the {{ClusterTopologyCheckedException}} occurs need to wait for the
> NODE_LEFT event of the coordinator node and re-init the distributed process
> future.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13250) Use descriptive thread names for async file channels
[
https://issues.apache.org/jira/browse/IGNITE-13250?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163702#comment-17163702
]
Ignite TC Bot commented on IGNITE-13250:
{panel:title=Branch: [pull/8032/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8032/head] Base: [master] : New Tests
(9)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Basic 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5467206]]
* {color:#013220}IgniteBasicTestSuite:
ThreadNameValidationTest.testThreadsWithDefaultNames - PASSED{color}
{color:#8b}Service Grid (legacy mode){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5467260]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=2caccef1-197d-4075-ac84-1e083f0a8ba7, topVer=0,
msgTemplate=null, span=null, nodeId8=ff8b24c6, msg=, type=NODE_JOINED,
tstamp=1594898562538], val2=AffinityTopologyVersion
[topVer=7945989168746811718, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=2caccef1-197d-4075-ac84-1e083f0a8ba7, topVer=0,
msgTemplate=null, span=null, nodeId8=ff8b24c6, msg=, type=NODE_JOINED,
tstamp=1594898562538], val2=AffinityTopologyVersion
[topVer=7945989168746811718, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=eedbc575371-353e8c05-0832-465e-b8d2-903611006220, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=cb8bde87-f161-4d5d-bd25-5e5824f78343, topVer=0, msgTemplate=null,
span=null, nodeId8=cb8bde87, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1594898562538]], val2=AffinityTopologyVersion
[topVer=2993210309250189496, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=eedbc575371-353e8c05-0832-465e-b8d2-903611006220, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=cb8bde87-f161-4d5d-bd25-5e5824f78343, topVer=0, msgTemplate=null,
span=null, nodeId8=cb8bde87, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1594898562538]], val2=AffinityTopologyVersion
[topVer=2993210309250189496, minorTopVer=0]]] - PASSED{color}
{color:#8b}Service Grid{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5467259]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=68a16330-1eb4-4d80-942f-0006aead4666, topVer=0,
msgTemplate=null, span=null, nodeId8=2817badb, msg=, type=NODE_JOINED,
tstamp=1594898400673], val2=AffinityTopologyVersion
[topVer=-339133936513009841, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=68a16330-1eb4-4d80-942f-0006aead4666, topVer=0,
msgTemplate=null, span=null, nodeId8=2817badb, msg=, type=NODE_JOINED,
tstamp=1594898400673], val2=AffinityTopologyVersion
[topVer=-339133936513009841, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=e0b74675371-bed380a3-9701-46e9-ad65-77307987a7d0, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=db81dda8-f98f-45a6-b819-dd208ee24f4b, topVer=0, msgTemplate=null,
span=null, nodeId8=db81dda8, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1594898400673]], val2=AffinityTopologyVersion
[topVer=3581509374157688215, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=e0b74675371-bed380a3-9701-46e9-ad65-77307987a7d0, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=db81dda8-f98f-45a6-b819-dd208ee24f4b, topVer=0, msgTemplate=null,
span=null, nodeId8=db81dda8, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1594898400673]], val2=AffinityTopologyVersion
[topVer=3581509374157688215, minorTopVer=0]]] - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5467280buildTypeId=IgniteTests24Java8_RunAll]
>
[jira] [Updated] (IGNITE-13263) PDS 4 suite timeout and stabilization
[ https://issues.apache.org/jira/browse/IGNITE-13263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Tolstunov updated IGNITE-13263: -- Description: Build fails sometimes with timeout or 137 codes https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Pds4?branch==overview=builds log in attach Detailed issues: # possible OOM when DataRegionConfiguration isn't set in test(by default 20%, which may be calculated incorrectly in docker containers) # some tests doesn't use base test and doesn't have any timeout # 137 code may be caused by the same reason, as in IGNITE-13266 was: Build fails sometimes with timeout or 137 codes https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Pds4?branch==overview=builds log in attach Detailed issues: # possible OOM when DataRegionConfiguration isn't set in test(by default 20%, which may be calculated incorrectly in docker containers) # some tests doesn't use base test and doesn't have any timeout # 137 code may be caused by the same reason, as in > PDS 4 suite timeout and stabilization > - > > Key: IGNITE-13263 > URL: https://issues.apache.org/jira/browse/IGNITE-13263 > Project: Ignite > Issue Type: Bug >Reporter: Nikita Tolstunov >Assignee: Nikita Tolstunov >Priority: Major > Attachments: Ignite_Tests_2.4_Java_8_9_10_11_PDS_4_18257.log.zip > > Time Spent: 10m > Remaining Estimate: 0h > > Build fails sometimes with timeout or 137 codes > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Pds4?branch==overview=builds > log in attach > Detailed issues: > # possible OOM when DataRegionConfiguration isn't set in test(by default 20%, > which may be calculated incorrectly in docker containers) > # some tests doesn't use base test and doesn't have any timeout > # 137 code may be caused by the same reason, as in IGNITE-13266 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13263) PDS 4 suite timeout and stabilization
[ https://issues.apache.org/jira/browse/IGNITE-13263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Tolstunov updated IGNITE-13263: -- Description: Build fails sometimes with timeout or 137 codes https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Pds4?branch==overview=builds log in attach Detailed issues: # possible OOM when DataRegionConfiguration isn't set in test(by default 20%, which may be calculated incorrectly in docker containers) # some tests doesn't use base test and doesn't have any timeout # 137 code may be caused by the same reason, as in was: Build fails sometimes with timeout or 137 codes https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Pds4?branch==overview=builds log in attach Detailed issues: # possible OOM when DataRegionConfiguration isn't set in test(by default 20%, which may be calculated incorrectly in docker containers) # some tests doesn't use base test and doesn't have any timeout # > PDS 4 suite timeout and stabilization > - > > Key: IGNITE-13263 > URL: https://issues.apache.org/jira/browse/IGNITE-13263 > Project: Ignite > Issue Type: Bug >Reporter: Nikita Tolstunov >Assignee: Nikita Tolstunov >Priority: Major > Attachments: Ignite_Tests_2.4_Java_8_9_10_11_PDS_4_18257.log.zip > > Time Spent: 10m > Remaining Estimate: 0h > > Build fails sometimes with timeout or 137 codes > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Pds4?branch==overview=builds > log in attach > Detailed issues: > # possible OOM when DataRegionConfiguration isn't set in test(by default 20%, > which may be calculated incorrectly in docker containers) > # some tests doesn't use base test and doesn't have any timeout > # 137 code may be caused by the same reason, as in -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13263) PDS 4 suite timeout and stabilization
[ https://issues.apache.org/jira/browse/IGNITE-13263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Tolstunov updated IGNITE-13263: -- Description: Build fails sometimes with timeout or 137 codes https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Pds4?branch==overview=builds log in attach Detailed issues: # possible OOM when DataRegionConfiguration isn't set in test(by default 20%, which may be calculated incorrectly in docker containers) # some tests doesn't use base test and doesn't have any timeout # was: Build fails sometimes with timeout or 137 codes https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Pds4?branch==overview=builds log in attach > PDS 4 suite timeout and stabilization > - > > Key: IGNITE-13263 > URL: https://issues.apache.org/jira/browse/IGNITE-13263 > Project: Ignite > Issue Type: Bug >Reporter: Nikita Tolstunov >Assignee: Nikita Tolstunov >Priority: Major > Attachments: Ignite_Tests_2.4_Java_8_9_10_11_PDS_4_18257.log.zip > > Time Spent: 10m > Remaining Estimate: 0h > > Build fails sometimes with timeout or 137 codes > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Pds4?branch==overview=builds > log in attach > Detailed issues: > # possible OOM when DataRegionConfiguration isn't set in test(by default 20%, > which may be calculated incorrectly in docker containers) > # some tests doesn't use base test and doesn't have any timeout > # -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13263) PDS 4 suite timeout and stabilization
[
https://issues.apache.org/jira/browse/IGNITE-13263?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163607#comment-17163607
]
Ignite TC Bot commented on IGNITE-13263:
{panel:title=Branch: [pull/8045/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8045/head] Base: [master] : New Tests
(24)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS 4{color} [[tests
16|https://ci.ignite.apache.org/viewLog.html?buildId=5485921]]
* {color:#013220}IgnitePdsTestSuite4:
SharedPageLockTrackerTest.testAutoDetectHangThreads[trackerType=2] -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
SharedPageLockTrackerTest.testTakeDumpByTime[trackerType=2] - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
SharedPageLockTrackerTest.testMemoryLeakOnThreadTerminates[trackerType=2] -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
SharedPageLockTrackerTest.testTakeDumpByCount[trackerType=1] - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
SharedPageLockTrackerTest.testAutoDetectHangThreads[trackerType=1] -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
SharedPageLockTrackerTest.testTakeDumpByTime[trackerType=1] - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
SharedPageLockTrackerTest.testMemoryLeakOnThreadTerminates[trackerType=1] -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
SharedPageLockTrackerTest.testAutoDetectHangThreads[trackerType=4] -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
SharedPageLockTrackerTest.testTakeDumpByTime[trackerType=4] - PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
SharedPageLockTrackerTest.testMemoryLeakOnThreadTerminates[trackerType=4] -
PASSED{color}
* {color:#013220}IgnitePdsTestSuite4:
SharedPageLockTrackerTest.testTakeDumpByCount[trackerType=3] - PASSED{color}
... and 5 new tests
{color:#8b}Service Grid (legacy mode){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5481949]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=03a87283-9340-4ede-ac24-c4119547ed59, topVer=0,
msgTemplate=null, span=null, nodeId8=122356c9, msg=, type=NODE_JOINED,
tstamp=1595340535417], val2=AffinityTopologyVersion
[topVer=5432732675578875911, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=03a87283-9340-4ede-ac24-c4119547ed59, topVer=0,
msgTemplate=null, span=null, nodeId8=122356c9, msg=, type=NODE_JOINED,
tstamp=1595340535417], val2=AffinityTopologyVersion
[topVer=5432732675578875911, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=0510fb17371-004a9a84-64d9-4c13-b0ad-9a54bccaeb0b, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=2d6ffe0d-e03e-49fa-8299-be400dd317cd, topVer=0, msgTemplate=null,
span=null, nodeId8=2d6ffe0d, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595340535417]], val2=AffinityTopologyVersion
[topVer=5710396860696734898, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=0510fb17371-004a9a84-64d9-4c13-b0ad-9a54bccaeb0b, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=2d6ffe0d-e03e-49fa-8299-be400dd317cd, topVer=0, msgTemplate=null,
span=null, nodeId8=2d6ffe0d, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595340535417]], val2=AffinityTopologyVersion
[topVer=5710396860696734898, minorTopVer=0]]] - PASSED{color}
{color:#8b}Service Grid{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5481948]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=53f2b204-8917-4708-946a-4d472d311f9b, topVer=0,
msgTemplate=null, span=null, nodeId8=521d174f, msg=, type=NODE_JOINED,
tstamp=1595340571155], val2=AffinityTopologyVersion
[topVer=-5891702242013147805, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=3a82fb17371-2672fb3e-bb1e-4ad9-9225-b4317b4a6b45, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=c998d94f-f7bd-43f8-91a5-dcf4dba5d4e6, topVer=0, msgTemplate=null,
span=null, nodeId8=c998d94f, msg=null,
[jira] [Commented] (IGNITE-13269) Waiting for completion of operations on indexes before cache stop
[
https://issues.apache.org/jira/browse/IGNITE-13269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163605#comment-17163605
]
Kirill Tkalenko commented on IGNITE-13269:
--
[~sergey-chugunov] Please make review after minor changes.
https://ci.ignite.apache.org/viewLog.html?buildId=5486178=IgniteTests24Java8_BuildApacheIgnite=buildResultsDiv_IgniteTests24Java8=pull%2F8056%2Fhead
> Waiting for completion of operations on indexes before cache stop
> -
>
> Key: IGNITE-13269
> URL: https://issues.apache.org/jira/browse/IGNITE-13269
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently, there is no waiting for completion of operation on indexes when
> cache is stopped. Because of this, there may be errors, for example, when
> restarting the node:
> {code:java}
> Suppressed: java.lang.AssertionError: Release pinned page: FullPageId
> [pageId=000206bfc352, effectivePageId=06bfc352, grpId=-782612924]
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.releaseFreePage(PageMemoryImpl.java:1902)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$PagePool.access$2100(PageMemoryImpl.java:1773)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl$ClearSegmentRunnable.run(PageMemoryImpl.java:2878)
> ... 3 common frames omitted
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-6893) Java Deadlocks monitoring
[
https://issues.apache.org/jira/browse/IGNITE-6893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163574#comment-17163574
]
Anton Vinogradov commented on IGNITE-6893:
--
[~slukyanov], Java deadlock may happen because of the huge list of problems.
Checking only pool starvation we'll skip this important guarantee level.
> Java Deadlocks monitoring
> -
>
> Key: IGNITE-6893
> URL: https://issues.apache.org/jira/browse/IGNITE-6893
> Project: Ignite
> Issue Type: Improvement
>Reporter: Anton Vinogradov
>Priority: Major
> Labels: iep-7
>
> Java Level Deadlocks
> Description
> This situation occurs if user or Ignite comes to a Java-level deadlock due to
> a bug in code - reverse order synchronized(mux1) {synchronized (mux2) {}}
> sections, reverse order reentrant locks, etc.
> Detection and Solution
> This most likely cannot be resolved automatically and will require JVM
> restart.
> We can implement periodical threaddumps analysis and detect the deadlock.
> Report
> Deadlock should be reported to the logs.
> Web Console should fire an alert on java deadlock detection and display a
> warning on UI.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-6894) Hanged Tx monitoring
[ https://issues.apache.org/jira/browse/IGNITE-6894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163575#comment-17163575 ] Anton Vinogradov commented on IGNITE-6894: -- [~slukyanov] what is `dumpLongRunningOperations`, could you provide detailed info on what was fixed and how this solves the current issue? > Hanged Tx monitoring > > > Key: IGNITE-6894 > URL: https://issues.apache.org/jira/browse/IGNITE-6894 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov >Assignee: Dmitriy Sorokin >Priority: Major > Labels: iep-7 > > Hanging Transactions not Related to Deadlock > Description > This situation can occur if user explicitly markups the transaction (esp > Pessimistic Repeatable Read) and, for example, calls remote service (which > may be unresponsive) after acquiring some locks. All other transactions > depending on the same keys will hang. > Detection and Solution > This most likely cannot be resolved automatically other than rollback TX by > timeout and release all the locks acquired so far. Also such TXs can be > rolled back from Web Console as described above. > If transaction has been rolled back on timeout or via UI then any further > action in the transaction, e.g. lock acquisition or commit attempt should > throw exception. > Report > Management tools (eg. Web Console) should provide ability to rollback any > transaction via UI. > Long running transaction should be reported to logs. Log record should > contain: near nodes, transaction IDs, cache names, keys (limited to several > tens of), etc ( ?). > Also there should be a screen in Web Console that will list all ongoing > transactions in the cluster including the info as above. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-6895) TX deadlock monitoring
[ https://issues.apache.org/jira/browse/IGNITE-6895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163571#comment-17163571 ] Anton Vinogradov commented on IGNITE-6895: -- [~slukyanov] what is `dumpLongRunningOperations`, could you provide detailed info what was fixes and how this solves current issue? > TX deadlock monitoring > -- > > Key: IGNITE-6895 > URL: https://issues.apache.org/jira/browse/IGNITE-6895 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov >Assignee: Dmitriy Sorokin >Priority: Major > Labels: iep-7 > > Deadlocks with Cache Transactions > Description > Deadlocks of this type are possible if user locks 2 or more keys within 2 or > more transactions in different orders (this does not apply to OPTIMISTIC > SERIALIZABLE transactions as they are capable to detect deadlock and choose > winning tx). Currently, Ignite can detect deadlocked transactions but this > procedure is started only for transactions that have timeout set explicitly > or default timeout in configuration set to value greater than 0. > Detection and Solution > Each NEAR node should periodically (need new config property?) scan the list > of local transactions and initiate the same procedure as we have now for > timed out transactions. If deadlock found it should be reported to logs. Log > record should contain: near nodes, transaction IDs, cache names, keys > (limited to several tens of) involved in deadlock. User should have ability > to configure default behavior - REPORT_ONLY, ROLLBACK (any more?) or manually > rollback selected transaction through web console or Visor. > Report > If deadlock found it should be reported to logs. Log record should contain: > near nodes, transaction IDs, cache names, keys (limited to several tens of) > involved in deadlock. > Also there should be a screen in Web Console that will list all ongoing > transactions in the cluster including the following info: > - Near node > - Start time > - DHT nodes > - Pending Locks (by request) > Web Console should provide ability to rollback any transaction via UI. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-6895) TX deadlock monitoring
[ https://issues.apache.org/jira/browse/IGNITE-6895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163571#comment-17163571 ] Anton Vinogradov edited comment on IGNITE-6895 at 7/23/20, 1:26 PM: [~slukyanov] what is `dumpLongRunningOperations`, could you provide detailed info on what was fixed and how this solves the current issue? was (Author: avinogradov): [~slukyanov] what is `dumpLongRunningOperations`, could you provide detailed info what was fixes and how this solves current issue? > TX deadlock monitoring > -- > > Key: IGNITE-6895 > URL: https://issues.apache.org/jira/browse/IGNITE-6895 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Vinogradov >Assignee: Dmitriy Sorokin >Priority: Major > Labels: iep-7 > > Deadlocks with Cache Transactions > Description > Deadlocks of this type are possible if user locks 2 or more keys within 2 or > more transactions in different orders (this does not apply to OPTIMISTIC > SERIALIZABLE transactions as they are capable to detect deadlock and choose > winning tx). Currently, Ignite can detect deadlocked transactions but this > procedure is started only for transactions that have timeout set explicitly > or default timeout in configuration set to value greater than 0. > Detection and Solution > Each NEAR node should periodically (need new config property?) scan the list > of local transactions and initiate the same procedure as we have now for > timed out transactions. If deadlock found it should be reported to logs. Log > record should contain: near nodes, transaction IDs, cache names, keys > (limited to several tens of) involved in deadlock. User should have ability > to configure default behavior - REPORT_ONLY, ROLLBACK (any more?) or manually > rollback selected transaction through web console or Visor. > Report > If deadlock found it should be reported to logs. Log record should contain: > near nodes, transaction IDs, cache names, keys (limited to several tens of) > involved in deadlock. > Also there should be a screen in Web Console that will list all ongoing > transactions in the cluster including the following info: > - Near node > - Start time > - DHT nodes > - Pending Locks (by request) > Web Console should provide ability to rollback any transaction via UI. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-13294) Page write throttling can park threads for too long
[
https://issues.apache.org/jira/browse/IGNITE-13294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov resolved IGNITE-13294.
Resolution: Duplicate
> Page write throttling can park threads for too long
> ---
>
> Key: IGNITE-13294
> URL: https://issues.apache.org/jira/browse/IGNITE-13294
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Page write throttling incorrectly calculate average checkpoint write speed in
> some circumstances (gets wrong interval for calculation), this leads to
> parking threads for too long.
> Root cause: {{PagesWriteSpeedBasedThrottle.onMarkDirty()}} should not open
> new interval for {{speedCpWrite}} after
> {{PagesWriteSpeedBasedThrottle.onFinishCheckpoint()}} until new checkpoint
> begin.
> Reproducer: {{PagesWriteThrottleSmokeTest.testThrottle()}}, currently always
> failed in master
> (https://ci.ignite.apache.org/project.html?tab=testDetails=IgniteTests24Java8=2808794487465215609=1_IgniteTests24Java8=%3Cdefault%3E)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13263) PDS 4 suite timeout and stabilization
[ https://issues.apache.org/jira/browse/IGNITE-13263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Tolstunov updated IGNITE-13263: -- Description: Build fails sometimes with timeout or 137 codes https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Pds4?branch==overview=builds log in attach was: Build fails sometimes with timeout https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Pds4?branch==overview=builds log in attach > PDS 4 suite timeout and stabilization > - > > Key: IGNITE-13263 > URL: https://issues.apache.org/jira/browse/IGNITE-13263 > Project: Ignite > Issue Type: Bug >Reporter: Nikita Tolstunov >Assignee: Nikita Tolstunov >Priority: Major > Attachments: Ignite_Tests_2.4_Java_8_9_10_11_PDS_4_18257.log.zip > > Time Spent: 10m > Remaining Estimate: 0h > > Build fails sometimes with timeout or 137 codes > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Pds4?branch==overview=builds > log in attach -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13263) PDS 4 suite timeout and stabilization
[ https://issues.apache.org/jira/browse/IGNITE-13263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Tolstunov updated IGNITE-13263: -- Summary: PDS 4 suite timeout and stabilization (was: PDS 4 suite timeout) > PDS 4 suite timeout and stabilization > - > > Key: IGNITE-13263 > URL: https://issues.apache.org/jira/browse/IGNITE-13263 > Project: Ignite > Issue Type: Bug >Reporter: Nikita Tolstunov >Assignee: Nikita Tolstunov >Priority: Major > Attachments: Ignite_Tests_2.4_Java_8_9_10_11_PDS_4_18257.log.zip > > Time Spent: 10m > Remaining Estimate: 0h > > Build fails sometimes with timeout > https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Pds4?branch==overview=builds > log in attach -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13294) Page write throttling can park threads for too long
[
https://issues.apache.org/jira/browse/IGNITE-13294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163507#comment-17163507
]
Stanilovsky Evgeny commented on IGNITE-13294:
-
already fixed in https://issues.apache.org/jira/browse/IGNITE-13289
> Page write throttling can park threads for too long
> ---
>
> Key: IGNITE-13294
> URL: https://issues.apache.org/jira/browse/IGNITE-13294
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>
> Page write throttling incorrectly calculate average checkpoint write speed in
> some circumstances (gets wrong interval for calculation), this leads to
> parking threads for too long.
> Root cause: {{PagesWriteSpeedBasedThrottle.onMarkDirty()}} should not open
> new interval for {{speedCpWrite}} after
> {{PagesWriteSpeedBasedThrottle.onFinishCheckpoint()}} until new checkpoint
> begin.
> Reproducer: {{PagesWriteThrottleSmokeTest.testThrottle()}}, currently always
> failed in master
> (https://ci.ignite.apache.org/project.html?tab=testDetails=IgniteTests24Java8=2808794487465215609=1_IgniteTests24Java8=%3Cdefault%3E)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13294) Page write throttling can park threads for too long
[
https://issues.apache.org/jira/browse/IGNITE-13294?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-13294:
---
Description:
Page write throttling incorrectly calculate average checkpoint write speed in
some circumstances (gets wrong interval for calculation), this leads to parking
threads for too long.
Root cause: {{PagesWriteSpeedBasedThrottle.onMarkDirty()}} should not open new
interval for {{speedCpWrite}} after
{{PagesWriteSpeedBasedThrottle.onFinishCheckpoint()}} until new checkpoint
begin.
Reproducer: {{PagesWriteThrottleSmokeTest.testThrottle()}}, currently always
failed in master
(https://ci.ignite.apache.org/project.html?tab=testDetails=IgniteTests24Java8=2808794487465215609=1_IgniteTests24Java8=%3Cdefault%3E)
was:
Page write throttling incorrectly calculate average checkpoint write speed in
some circumstances (gets wrong interval for calculation), this leads to parking
threads for too long.
Root cause: {{PagesWriteSpeedBasedThrottle.onMarkDirty()}} should not open new
interval for {{speedCpWrite}} after
{{PagesWriteSpeedBasedThrottle.onFinishCheckpoint()}} until new checkpoint
begin.
Reproducer: {{PagesWriteThrottleSmokeTest#testThrottle}}, currently always
failed in master
(https://ci.ignite.apache.org/project.html?tab=testDetails=IgniteTests24Java8=2808794487465215609=1_IgniteTests24Java8=%3Cdefault%3E)
> Page write throttling can park threads for too long
> ---
>
> Key: IGNITE-13294
> URL: https://issues.apache.org/jira/browse/IGNITE-13294
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>
> Page write throttling incorrectly calculate average checkpoint write speed in
> some circumstances (gets wrong interval for calculation), this leads to
> parking threads for too long.
> Root cause: {{PagesWriteSpeedBasedThrottle.onMarkDirty()}} should not open
> new interval for {{speedCpWrite}} after
> {{PagesWriteSpeedBasedThrottle.onFinishCheckpoint()}} until new checkpoint
> begin.
> Reproducer: {{PagesWriteThrottleSmokeTest.testThrottle()}}, currently always
> failed in master
> (https://ci.ignite.apache.org/project.html?tab=testDetails=IgniteTests24Java8=2808794487465215609=1_IgniteTests24Java8=%3Cdefault%3E)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13294) Page write throttling can park threads for too long
Aleksey Plekhanov created IGNITE-13294:
--
Summary: Page write throttling can park threads for too long
Key: IGNITE-13294
URL: https://issues.apache.org/jira/browse/IGNITE-13294
Project: Ignite
Issue Type: Bug
Affects Versions: 2.9
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Page write throttling incorrectly calculate average checkpoint write speed in
some circumstances (gets wrong interval for calculation), this leads to parking
threads for too long.
Root cause: {{PagesWriteSpeedBasedThrottle.onMarkDirty()}} should not open new
interval for {{speedCpWrite}} after
{{PagesWriteSpeedBasedThrottle.onFinishCheckpoint()}} until new checkpoint
begin.
Reproducer: {{PagesWriteThrottleSmokeTest#testThrottle}}, currently always
failed in master
(https://ci.ignite.apache.org/project.html?tab=testDetails=IgniteTests24Java8=2808794487465215609=1_IgniteTests24Java8=%3Cdefault%3E)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13289) PagesWriteThrottleSmokeTest.testThrottle start to fail on TC.
[ https://issues.apache.org/jira/browse/IGNITE-13289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163495#comment-17163495 ] Stanilovsky Evgeny commented on IGNITE-13289: - [~alex_pl] can you check it plz ? > PagesWriteThrottleSmokeTest.testThrottle start to fail on TC. > - > > Key: IGNITE-13289 > URL: https://issues.apache.org/jira/browse/IGNITE-13289 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 2.8.1 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > PagesWriteThrottleSmokeTest.testThrottle start to fail on master, possible > after IGNITE-12802 was merged. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13289) PagesWriteThrottleSmokeTest.testThrottle start to fail on TC.
[
https://issues.apache.org/jira/browse/IGNITE-13289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163494#comment-17163494
]
Ignite TC Bot commented on IGNITE-13289:
{panel:title=Branch: [pull/8072/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5484349]]
{panel}
{panel:title=Branch: [pull/8072/head] Base: [master] : New Tests
(8)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Service Grid (legacy mode){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5484368]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=7a618988-0cbf-4282-b4c8-617a12774a32, topVer=0,
msgTemplate=null, span=null, nodeId8=740d4544, msg=, type=NODE_JOINED,
tstamp=1595438730069], val2=AffinityTopologyVersion
[topVer=1748702708827954037, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=7a618988-0cbf-4282-b4c8-617a12774a32, topVer=0,
msgTemplate=null, span=null, nodeId8=740d4544, msg=, type=NODE_JOINED,
tstamp=1595438730069], val2=AffinityTopologyVersion
[topVer=1748702708827954037, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=95b0f877371-585ad1c6-ce82-4d7e-9915-926ff1146f09, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=e04e5110-4754-4a15-ba62-81590f5cabb1, topVer=0, msgTemplate=null,
span=null, nodeId8=e04e5110, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595438730069]], val2=AffinityTopologyVersion
[topVer=7557505249121493695, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=95b0f877371-585ad1c6-ce82-4d7e-9915-926ff1146f09, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=e04e5110-4754-4a15-ba62-81590f5cabb1, topVer=0, msgTemplate=null,
span=null, nodeId8=e04e5110, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595438730069]], val2=AffinityTopologyVersion
[topVer=7557505249121493695, minorTopVer=0]]] - PASSED{color}
{color:#8b}Service Grid{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5484367]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=ea9ceff7-7cb3-4ec2-8e68-dbb75bd6dc01, topVer=0,
msgTemplate=null, span=null, nodeId8=d5159299, msg=, type=NODE_JOINED,
tstamp=1595438838744], val2=AffinityTopologyVersion
[topVer=5967446117423387856, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=ea9ceff7-7cb3-4ec2-8e68-dbb75bd6dc01, topVer=0,
msgTemplate=null, span=null, nodeId8=d5159299, msg=, type=NODE_JOINED,
tstamp=1595438838744], val2=AffinityTopologyVersion
[topVer=5967446117423387856, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=3d9ca977371-1c3ba0ab-8fd3-44a1-aba4-791d68e70a7f, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=95dbda34-73ea-43b0-8b8e-048083a02e2a, topVer=0, msgTemplate=null,
span=null, nodeId8=95dbda34, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595438838744]], val2=AffinityTopologyVersion
[topVer=-878178698243749971, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=3d9ca977371-1c3ba0ab-8fd3-44a1-aba4-791d68e70a7f, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=95dbda34-73ea-43b0-8b8e-048083a02e2a, topVer=0, msgTemplate=null,
span=null, nodeId8=95dbda34, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595438838744]], val2=AffinityTopologyVersion
[topVer=-878178698243749971, minorTopVer=0]]] - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5484390buildTypeId=IgniteTests24Java8_RunAll]
> PagesWriteThrottleSmokeTest.testThrottle start to fail on TC.
>
[jira] [Commented] (IGNITE-13270) Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5
[ https://issues.apache.org/jira/browse/IGNITE-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163442#comment-17163442 ] Stanilovsky Evgeny commented on IGNITE-13270: - [~tambre] check for attached reproducer plz, i found that ignite 2.7.5 has bugs, thus you can obtain incorrect resultset here (attached test prove it) . If you want to repeat my experiments just download appropriate sources and put this class in neighbor of BasicIndexTest.java for example. So my conclusion - your cpu burn is due to increasing result sets and further processing > Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5 > -- > > Key: IGNITE-13270 > URL: https://issues.apache.org/jira/browse/IGNITE-13270 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8, 2.8.1 >Reporter: Tanmay Ambre >Assignee: Stanilovsky Evgeny >Priority: Major > Attachments: IDX13270.java > > > After upgrading to ignite 2.8.0 from 2.7.5 the following query is causing > massive CPU burn. We have a 8 node server cluster for Ignite (with 32 CPUs on > each node). with 2.8.0, 2 nodes are maxed out on CPU. with 2.8.1 all nodes > are above 80%. On 2.7.5 the same query was performing very nicely. > The query is a join with 3 tables having same affinity key. however, we dont > know the affinity key when we are querying and there this results in a merge > scan. > Query: > select A.A_ID, A.AFFINITYKEY, B.B_ID from A, B, C > where > A.A_ID = B.A_ID AND > B.B_ID = C.B_ID AND > A.AFFINITYKEY = B.AFFINITYKEY AND > B.AFFINITYKEY = C.AFFINITYKEY AND > B.B_ID = ? AND > C.C_ID = ? > > Performance: > 2.7.5 ~ 2 to 5 ms > 2.8.0 ~ 6 to 12 seconds > 2.8.1 ~ within 3 seconds > > Volume (we have a EDA based system where messages come in burst. One burst > has approx. 150K events - each event correspond to one query). > > throughput of our java based processor (that fires this query): > 2.7.5 ~ 750 transactions per second > 2.8.0 ~ 3 transactions per second > 2.8.1 ~ 6 transactions per second > > CPU burn > 2.7.5 ~ 10 to 15% on each node > 2.8.0 ~ 100% on 2 nodes other nodes are idling > 2.8.1 ~ 80 to 90% on each node > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13270) Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5
[ https://issues.apache.org/jira/browse/IGNITE-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanilovsky Evgeny reassigned IGNITE-13270: --- Assignee: Stanilovsky Evgeny > Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5 > -- > > Key: IGNITE-13270 > URL: https://issues.apache.org/jira/browse/IGNITE-13270 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8, 2.8.1 >Reporter: Tanmay Ambre >Assignee: Stanilovsky Evgeny >Priority: Major > Attachments: IDX13270.java > > > After upgrading to ignite 2.8.0 from 2.7.5 the following query is causing > massive CPU burn. We have a 8 node server cluster for Ignite (with 32 CPUs on > each node). with 2.8.0, 2 nodes are maxed out on CPU. with 2.8.1 all nodes > are above 80%. On 2.7.5 the same query was performing very nicely. > The query is a join with 3 tables having same affinity key. however, we dont > know the affinity key when we are querying and there this results in a merge > scan. > Query: > select A.A_ID, A.AFFINITYKEY, B.B_ID from A, B, C > where > A.A_ID = B.A_ID AND > B.B_ID = C.B_ID AND > A.AFFINITYKEY = B.AFFINITYKEY AND > B.AFFINITYKEY = C.AFFINITYKEY AND > B.B_ID = ? AND > C.C_ID = ? > > Performance: > 2.7.5 ~ 2 to 5 ms > 2.8.0 ~ 6 to 12 seconds > 2.8.1 ~ within 3 seconds > > Volume (we have a EDA based system where messages come in burst. One burst > has approx. 150K events - each event correspond to one query). > > throughput of our java based processor (that fires this query): > 2.7.5 ~ 750 transactions per second > 2.8.0 ~ 3 transactions per second > 2.8.1 ~ 6 transactions per second > > CPU burn > 2.7.5 ~ 10 to 15% on each node > 2.8.0 ~ 100% on 2 nodes other nodes are idling > 2.8.1 ~ 80 to 90% on each node > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13293) .NET: Enum serialization is slow
Pavel Tupitsyn created IGNITE-13293: --- Summary: .NET: Enum serialization is slow Key: IGNITE-13293 URL: https://issues.apache.org/jira/browse/IGNITE-13293 Project: Ignite Issue Type: Bug Components: platforms Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 2.10 BinaryWriter.SaveMetadata has performance issues when enums are present: every enum write causes GetEnumValues call in BinaryType, which uses reflection. We should cache enum values per type. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13270) Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5
[ https://issues.apache.org/jira/browse/IGNITE-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanilovsky Evgeny updated IGNITE-13270: Attachment: IDX13270.java > Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5 > -- > > Key: IGNITE-13270 > URL: https://issues.apache.org/jira/browse/IGNITE-13270 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8, 2.8.1 >Reporter: Tanmay Ambre >Priority: Major > Attachments: IDX13270.java > > > After upgrading to ignite 2.8.0 from 2.7.5 the following query is causing > massive CPU burn. We have a 8 node server cluster for Ignite (with 32 CPUs on > each node). with 2.8.0, 2 nodes are maxed out on CPU. with 2.8.1 all nodes > are above 80%. On 2.7.5 the same query was performing very nicely. > The query is a join with 3 tables having same affinity key. however, we dont > know the affinity key when we are querying and there this results in a merge > scan. > Query: > select A.A_ID, A.AFFINITYKEY, B.B_ID from A, B, C > where > A.A_ID = B.A_ID AND > B.B_ID = C.B_ID AND > A.AFFINITYKEY = B.AFFINITYKEY AND > B.AFFINITYKEY = C.AFFINITYKEY AND > B.B_ID = ? AND > C.C_ID = ? > > Performance: > 2.7.5 ~ 2 to 5 ms > 2.8.0 ~ 6 to 12 seconds > 2.8.1 ~ within 3 seconds > > Volume (we have a EDA based system where messages come in burst. One burst > has approx. 150K events - each event correspond to one query). > > throughput of our java based processor (that fires this query): > 2.7.5 ~ 750 transactions per second > 2.8.0 ~ 3 transactions per second > 2.8.1 ~ 6 transactions per second > > CPU burn > 2.7.5 ~ 10 to 15% on each node > 2.8.0 ~ 100% on 2 nodes other nodes are idling > 2.8.1 ~ 80 to 90% on each node > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13270) Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5
[ https://issues.apache.org/jira/browse/IGNITE-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanilovsky Evgeny updated IGNITE-13270: Attachment: (was: IDX13270.java) > Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5 > -- > > Key: IGNITE-13270 > URL: https://issues.apache.org/jira/browse/IGNITE-13270 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8, 2.8.1 >Reporter: Tanmay Ambre >Priority: Major > Attachments: IDX13270.java > > > After upgrading to ignite 2.8.0 from 2.7.5 the following query is causing > massive CPU burn. We have a 8 node server cluster for Ignite (with 32 CPUs on > each node). with 2.8.0, 2 nodes are maxed out on CPU. with 2.8.1 all nodes > are above 80%. On 2.7.5 the same query was performing very nicely. > The query is a join with 3 tables having same affinity key. however, we dont > know the affinity key when we are querying and there this results in a merge > scan. > Query: > select A.A_ID, A.AFFINITYKEY, B.B_ID from A, B, C > where > A.A_ID = B.A_ID AND > B.B_ID = C.B_ID AND > A.AFFINITYKEY = B.AFFINITYKEY AND > B.AFFINITYKEY = C.AFFINITYKEY AND > B.B_ID = ? AND > C.C_ID = ? > > Performance: > 2.7.5 ~ 2 to 5 ms > 2.8.0 ~ 6 to 12 seconds > 2.8.1 ~ within 3 seconds > > Volume (we have a EDA based system where messages come in burst. One burst > has approx. 150K events - each event correspond to one query). > > throughput of our java based processor (that fires this query): > 2.7.5 ~ 750 transactions per second > 2.8.0 ~ 3 transactions per second > 2.8.1 ~ 6 transactions per second > > CPU burn > 2.7.5 ~ 10 to 15% on each node > 2.8.0 ~ 100% on 2 nodes other nodes are idling > 2.8.1 ~ 80 to 90% on each node > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13292) Remove unneeded ZkPinger from ZookeeperDiscovery
[
https://issues.apache.org/jira/browse/IGNITE-13292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-13292:
--
Description:
We need remove uneeded {{ZkPinger}} from our codebase, introduced in
[IGNITE-9683|https://issues.apache.org/jira/browse/IGNITE-9683].
This pinger was introduced to solve issues with server nodes segmentation when
cluster is deactivated. The main reason of that is the strange all thread
freeze when huge amount of memory is deallocated with {{Unsafe.freeMemory}},
such freeze can last for a minute and more. So this pinger doesn't solve
problem at all and this is proved. The working solution to this problem is
introduced in [IGNITE-9658|https://issues.apache.org/jira/browse/IGNITE-9658]
So we should remove this code from our codebase.
was:
We need remove unneede {{ZkPinger}} from our codebase, introduced in
[IGNITE-9683|https://issues.apache.org/jira/browse/IGNITE-9683]. This pinger
was introduced to solve issues with server nodes segmentation when cluster is
deactivated. The main reason of that is the strange all thread freeze when huge
amount of memory is deallocated with {{Unsafe.freeMemory}}, such freeze can
last for a minute and more. So this pinger doesn't solve problem at all and
this is proved. The working solution to this problem is introduced in
[IGNITE-9658|https://issues.apache.org/jira/browse/IGNITE-9658]
So we should remove this code from our codebase.
> Remove unneeded ZkPinger from ZookeeperDiscovery
>
>
> Key: IGNITE-13292
> URL: https://issues.apache.org/jira/browse/IGNITE-13292
> Project: Ignite
> Issue Type: Improvement
> Components: zookeeper
>Affects Versions: 2.9
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Trivial
> Fix For: 2.10
>
>
> We need remove uneeded {{ZkPinger}} from our codebase, introduced in
> [IGNITE-9683|https://issues.apache.org/jira/browse/IGNITE-9683].
> This pinger was introduced to solve issues with server nodes segmentation
> when cluster is deactivated. The main reason of that is the strange all
> thread freeze when huge amount of memory is deallocated with
> {{Unsafe.freeMemory}}, such freeze can last for a minute and more. So this
> pinger doesn't solve problem at all and this is proved. The working solution
> to this problem is introduced in
> [IGNITE-9658|https://issues.apache.org/jira/browse/IGNITE-9658]
> So we should remove this code from our codebase.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13292) Remove unneeded ZkPinger from ZookeeperDiscovery
Ivan Daschinskiy created IGNITE-13292:
-
Summary: Remove unneeded ZkPinger from ZookeeperDiscovery
Key: IGNITE-13292
URL: https://issues.apache.org/jira/browse/IGNITE-13292
Project: Ignite
Issue Type: Improvement
Components: zookeeper
Affects Versions: 2.9
Reporter: Ivan Daschinskiy
Assignee: Ivan Daschinskiy
Fix For: 2.10
We need remove unneede {{ZkPinger}} from our codebase, introduced in
[IGNITE-9683|https://issues.apache.org/jira/browse/IGNITE-9683]. This pinger
was introduced to solve issues with server nodes segmentation when cluster is
deactivated. The main reason of that is the strange all thread freeze when huge
amount of memory is deallocated with {{Unsafe.freeMemory}}, such freeze can
last for a minute and more. So this pinger doesn't solve problem at all and
this is proved. The working solution to this problem is introduced in
[IGNITE-9658|https://issues.apache.org/jira/browse/IGNITE-9658]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13292) Remove unneeded ZkPinger from ZookeeperDiscovery
[
https://issues.apache.org/jira/browse/IGNITE-13292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-13292:
--
Description:
We need remove unneede {{ZkPinger}} from our codebase, introduced in
[IGNITE-9683|https://issues.apache.org/jira/browse/IGNITE-9683]. This pinger
was introduced to solve issues with server nodes segmentation when cluster is
deactivated. The main reason of that is the strange all thread freeze when huge
amount of memory is deallocated with {{Unsafe.freeMemory}}, such freeze can
last for a minute and more. So this pinger doesn't solve problem at all and
this is proved. The working solution to this problem is introduced in
[IGNITE-9658|https://issues.apache.org/jira/browse/IGNITE-9658]
So we should remove this code from our codebase.
was:
We need remove unneede {{ZkPinger}} from our codebase, introduced in
[IGNITE-9683|https://issues.apache.org/jira/browse/IGNITE-9683]. This pinger
was introduced to solve issues with server nodes segmentation when cluster is
deactivated. The main reason of that is the strange all thread freeze when huge
amount of memory is deallocated with {{Unsafe.freeMemory}}, such freeze can
last for a minute and more. So this pinger doesn't solve problem at all and
this is proved. The working solution to this problem is introduced in
[IGNITE-9658|https://issues.apache.org/jira/browse/IGNITE-9658]
> Remove unneeded ZkPinger from ZookeeperDiscovery
>
>
> Key: IGNITE-13292
> URL: https://issues.apache.org/jira/browse/IGNITE-13292
> Project: Ignite
> Issue Type: Improvement
> Components: zookeeper
>Affects Versions: 2.9
>Reporter: Ivan Daschinskiy
>Assignee: Ivan Daschinskiy
>Priority: Trivial
> Fix For: 2.10
>
>
> We need remove unneede {{ZkPinger}} from our codebase, introduced in
> [IGNITE-9683|https://issues.apache.org/jira/browse/IGNITE-9683]. This pinger
> was introduced to solve issues with server nodes segmentation when cluster is
> deactivated. The main reason of that is the strange all thread freeze when
> huge amount of memory is deallocated with {{Unsafe.freeMemory}}, such freeze
> can last for a minute and more. So this pinger doesn't solve problem at all
> and this is proved. The working solution to this problem is introduced in
> [IGNITE-9658|https://issues.apache.org/jira/browse/IGNITE-9658]
> So we should remove this code from our codebase.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13270) Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5
[ https://issues.apache.org/jira/browse/IGNITE-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanilovsky Evgeny updated IGNITE-13270: Attachment: (was: IDX13270.java) > Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5 > -- > > Key: IGNITE-13270 > URL: https://issues.apache.org/jira/browse/IGNITE-13270 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8, 2.8.1 >Reporter: Tanmay Ambre >Priority: Major > Attachments: IDX13270.java > > > After upgrading to ignite 2.8.0 from 2.7.5 the following query is causing > massive CPU burn. We have a 8 node server cluster for Ignite (with 32 CPUs on > each node). with 2.8.0, 2 nodes are maxed out on CPU. with 2.8.1 all nodes > are above 80%. On 2.7.5 the same query was performing very nicely. > The query is a join with 3 tables having same affinity key. however, we dont > know the affinity key when we are querying and there this results in a merge > scan. > Query: > select A.A_ID, A.AFFINITYKEY, B.B_ID from A, B, C > where > A.A_ID = B.A_ID AND > B.B_ID = C.B_ID AND > A.AFFINITYKEY = B.AFFINITYKEY AND > B.AFFINITYKEY = C.AFFINITYKEY AND > B.B_ID = ? AND > C.C_ID = ? > > Performance: > 2.7.5 ~ 2 to 5 ms > 2.8.0 ~ 6 to 12 seconds > 2.8.1 ~ within 3 seconds > > Volume (we have a EDA based system where messages come in burst. One burst > has approx. 150K events - each event correspond to one query). > > throughput of our java based processor (that fires this query): > 2.7.5 ~ 750 transactions per second > 2.8.0 ~ 3 transactions per second > 2.8.1 ~ 6 transactions per second > > CPU burn > 2.7.5 ~ 10 to 15% on each node > 2.8.0 ~ 100% on 2 nodes other nodes are idling > 2.8.1 ~ 80 to 90% on each node > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13270) Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5
[ https://issues.apache.org/jira/browse/IGNITE-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanilovsky Evgeny updated IGNITE-13270: Attachment: IDX13270.java > Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5 > -- > > Key: IGNITE-13270 > URL: https://issues.apache.org/jira/browse/IGNITE-13270 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8, 2.8.1 >Reporter: Tanmay Ambre >Priority: Major > Attachments: IDX13270.java > > > After upgrading to ignite 2.8.0 from 2.7.5 the following query is causing > massive CPU burn. We have a 8 node server cluster for Ignite (with 32 CPUs on > each node). with 2.8.0, 2 nodes are maxed out on CPU. with 2.8.1 all nodes > are above 80%. On 2.7.5 the same query was performing very nicely. > The query is a join with 3 tables having same affinity key. however, we dont > know the affinity key when we are querying and there this results in a merge > scan. > Query: > select A.A_ID, A.AFFINITYKEY, B.B_ID from A, B, C > where > A.A_ID = B.A_ID AND > B.B_ID = C.B_ID AND > A.AFFINITYKEY = B.AFFINITYKEY AND > B.AFFINITYKEY = C.AFFINITYKEY AND > B.B_ID = ? AND > C.C_ID = ? > > Performance: > 2.7.5 ~ 2 to 5 ms > 2.8.0 ~ 6 to 12 seconds > 2.8.1 ~ within 3 seconds > > Volume (we have a EDA based system where messages come in burst. One burst > has approx. 150K events - each event correspond to one query). > > throughput of our java based processor (that fires this query): > 2.7.5 ~ 750 transactions per second > 2.8.0 ~ 3 transactions per second > 2.8.1 ~ 6 transactions per second > > CPU burn > 2.7.5 ~ 10 to 15% on each node > 2.8.0 ~ 100% on 2 nodes other nodes are idling > 2.8.1 ~ 80 to 90% on each node > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13270) Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5
[ https://issues.apache.org/jira/browse/IGNITE-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanilovsky Evgeny updated IGNITE-13270: Attachment: (was: IDX13270.java) > Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5 > -- > > Key: IGNITE-13270 > URL: https://issues.apache.org/jira/browse/IGNITE-13270 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8, 2.8.1 >Reporter: Tanmay Ambre >Priority: Major > Attachments: IDX13270.java > > > After upgrading to ignite 2.8.0 from 2.7.5 the following query is causing > massive CPU burn. We have a 8 node server cluster for Ignite (with 32 CPUs on > each node). with 2.8.0, 2 nodes are maxed out on CPU. with 2.8.1 all nodes > are above 80%. On 2.7.5 the same query was performing very nicely. > The query is a join with 3 tables having same affinity key. however, we dont > know the affinity key when we are querying and there this results in a merge > scan. > Query: > select A.A_ID, A.AFFINITYKEY, B.B_ID from A, B, C > where > A.A_ID = B.A_ID AND > B.B_ID = C.B_ID AND > A.AFFINITYKEY = B.AFFINITYKEY AND > B.AFFINITYKEY = C.AFFINITYKEY AND > B.B_ID = ? AND > C.C_ID = ? > > Performance: > 2.7.5 ~ 2 to 5 ms > 2.8.0 ~ 6 to 12 seconds > 2.8.1 ~ within 3 seconds > > Volume (we have a EDA based system where messages come in burst. One burst > has approx. 150K events - each event correspond to one query). > > throughput of our java based processor (that fires this query): > 2.7.5 ~ 750 transactions per second > 2.8.0 ~ 3 transactions per second > 2.8.1 ~ 6 transactions per second > > CPU burn > 2.7.5 ~ 10 to 15% on each node > 2.8.0 ~ 100% on 2 nodes other nodes are idling > 2.8.1 ~ 80 to 90% on each node > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13270) Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5
[ https://issues.apache.org/jira/browse/IGNITE-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanilovsky Evgeny updated IGNITE-13270: Attachment: IDX13270.java > Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5 > -- > > Key: IGNITE-13270 > URL: https://issues.apache.org/jira/browse/IGNITE-13270 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8, 2.8.1 >Reporter: Tanmay Ambre >Priority: Major > Attachments: IDX13270.java > > > After upgrading to ignite 2.8.0 from 2.7.5 the following query is causing > massive CPU burn. We have a 8 node server cluster for Ignite (with 32 CPUs on > each node). with 2.8.0, 2 nodes are maxed out on CPU. with 2.8.1 all nodes > are above 80%. On 2.7.5 the same query was performing very nicely. > The query is a join with 3 tables having same affinity key. however, we dont > know the affinity key when we are querying and there this results in a merge > scan. > Query: > select A.A_ID, A.AFFINITYKEY, B.B_ID from A, B, C > where > A.A_ID = B.A_ID AND > B.B_ID = C.B_ID AND > A.AFFINITYKEY = B.AFFINITYKEY AND > B.AFFINITYKEY = C.AFFINITYKEY AND > B.B_ID = ? AND > C.C_ID = ? > > Performance: > 2.7.5 ~ 2 to 5 ms > 2.8.0 ~ 6 to 12 seconds > 2.8.1 ~ within 3 seconds > > Volume (we have a EDA based system where messages come in burst. One burst > has approx. 150K events - each event correspond to one query). > > throughput of our java based processor (that fires this query): > 2.7.5 ~ 750 transactions per second > 2.8.0 ~ 3 transactions per second > 2.8.1 ~ 6 transactions per second > > CPU burn > 2.7.5 ~ 10 to 15% on each node > 2.8.0 ~ 100% on 2 nodes other nodes are idling > 2.8.1 ~ 80 to 90% on each node > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13270) Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5
[ https://issues.apache.org/jira/browse/IGNITE-13270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanilovsky Evgeny updated IGNITE-13270: Attachment: IDX13270.java > Massive CPU burn in 2.8.0 and 2.8.1 after upgrading from 2.7.5 > -- > > Key: IGNITE-13270 > URL: https://issues.apache.org/jira/browse/IGNITE-13270 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8, 2.8.1 >Reporter: Tanmay Ambre >Priority: Major > Attachments: IDX13270.java > > > After upgrading to ignite 2.8.0 from 2.7.5 the following query is causing > massive CPU burn. We have a 8 node server cluster for Ignite (with 32 CPUs on > each node). with 2.8.0, 2 nodes are maxed out on CPU. with 2.8.1 all nodes > are above 80%. On 2.7.5 the same query was performing very nicely. > The query is a join with 3 tables having same affinity key. however, we dont > know the affinity key when we are querying and there this results in a merge > scan. > Query: > select A.A_ID, A.AFFINITYKEY, B.B_ID from A, B, C > where > A.A_ID = B.A_ID AND > B.B_ID = C.B_ID AND > A.AFFINITYKEY = B.AFFINITYKEY AND > B.AFFINITYKEY = C.AFFINITYKEY AND > B.B_ID = ? AND > C.C_ID = ? > > Performance: > 2.7.5 ~ 2 to 5 ms > 2.8.0 ~ 6 to 12 seconds > 2.8.1 ~ within 3 seconds > > Volume (we have a EDA based system where messages come in burst. One burst > has approx. 150K events - each event correspond to one query). > > throughput of our java based processor (that fires this query): > 2.7.5 ~ 750 transactions per second > 2.8.0 ~ 3 transactions per second > 2.8.1 ~ 6 transactions per second > > CPU burn > 2.7.5 ~ 10 to 15% on each node > 2.8.0 ~ 100% on 2 nodes other nodes are idling > 2.8.1 ~ 80 to 90% on each node > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13290) SpringTransactionManager adds support for nested transactions
[ https://issues.apache.org/jira/browse/IGNITE-13290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163374#comment-17163374 ] YuJue Li commented on IGNITE-13290: --- OK > SpringTransactionManager adds support for nested transactions > - > > Key: IGNITE-13290 > URL: https://issues.apache.org/jira/browse/IGNITE-13290 > Project: Ignite > Issue Type: Bug > Components: spring >Affects Versions: 2.8.1 >Reporter: YuJue Li >Priority: Minor > Fix For: 2.10 > > > If the transaction propagation of the outer method is REQUIRED, the > transaction propagation of the inner method is REQUIRES_NEW, the following > error will be prompted: > org.springframework.transaction.TransactionSuspensionNotSupportedException: > Transaction manager > [org.apache.ignite.transactions.spring.SpringTransactionManager] does not > support transaction suspension > But we see, Ignite's org.apache.ignite.transactions.Transaction, there are > suspend() and resume() methods, and the function is normal, so > SpringTransactionManager should support similar functions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13291) Remove unnecessary dependency to curator-client from ZookeeperDiscoverySpi
Ivan Daschinskiy created IGNITE-13291:
-
Summary: Remove unnecessary dependency to curator-client from
ZookeeperDiscoverySpi
Key: IGNITE-13291
URL: https://issues.apache.org/jira/browse/IGNITE-13291
Project: Ignite
Issue Type: Improvement
Components: zookeeper
Affects Versions: 2.9
Reporter: Ivan Daschinskiy
Assignee: Ivan Daschinskiy
Fix For: 2.10
Currently, I suppose by mistake, we use
{{org.apache.curator.utils.PathUtils#validatePath(java.lang.String)}} from
{{curator-client}}
in {{ZookeeperDiscoverySpi}}. Generally, this discovery implementation doesn't
depend on curator framework at all, except some test code. We should remove
this dependency and add this utility method to our codebase.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13259) "default" cache usage should be removed from REST API
[ https://issues.apache.org/jira/browse/IGNITE-13259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeniy Rudenko updated IGNITE-13259: - Release Note: Removed "default" cache from Cache and Query REST APIs. User will receive "Failed to find mandatory parameter in request: cacheName" if cache name is not provided. > "default" cache usage should be removed from REST API > - > > Key: IGNITE-13259 > URL: https://issues.apache.org/jira/browse/IGNITE-13259 > Project: Ignite > Issue Type: Improvement >Reporter: Evgeniy Rudenko >Assignee: Evgeniy Rudenko >Priority: Major > Time Spent: 50m > Remaining Estimate: 0h > > Right now lots of REST APIs will try to use "default" cache if cacheName is > not provided. This is pointless because such cache doesn't exist by default. > It will be better to change current behavior and return correct error instead > of "Failed to find cache for given cache name: default". -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13262) Remove GridClientUtils#shutdownNow() as full duplicate of U#shutdownNow
[ https://issues.apache.org/jira/browse/IGNITE-13262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov updated IGNITE-13262: -- Fix Version/s: 2.10 > Remove GridClientUtils#shutdownNow() as full duplicate of U#shutdownNow > --- > > Key: IGNITE-13262 > URL: https://issues.apache.org/jira/browse/IGNITE-13262 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: 2.8.1 >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Minor > Fix For: 2.10 > > Original Estimate: 4h > Time Spent: 10m > Remaining Estimate: 3h 50m > > Method o.a.i.internal.client.util.GridClientUtils#shutdownNow is a full > duplicate of U#shutdownNow. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13038) Phase out Ignite Web Console
[
https://issues.apache.org/jira/browse/IGNITE-13038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163243#comment-17163243
]
Alexey Kuznetsov edited comment on IGNITE-13038 at 7/23/20, 7:02 AM:
-
{panel:title=Branch: [pull/8065/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#cc|titleBGColor=#f7d6c1}
{color:#d04437}PDS (Indexing){color} [[tests 0 Exit
Code|https://ci.ignite.apache.org/viewLog.html?buildId=5484140]]
{panel}
was (Author: ignitetcbot):
{panel:title=Branch: [pull/8065/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5484140]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5480154buildTypeId=IgniteTests24Java8_RunAll]
> Phase out Ignite Web Console
>
>
> Key: IGNITE-13038
> URL: https://issues.apache.org/jira/browse/IGNITE-13038
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis A. Magda
>Assignee: Alexey Kuznetsov
>Priority: Critical
> Fix For: 2.10
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> The community voted to stop the development and maintenance of Ignite Web
> Console:
> http://apache-ignite-developers.2346864.n4.nabble.com/RESULT-VOTE-Stop-Maintenance-of-Ignite-Web-Console-td47548.html
> The following needs to be done:
> * Move the tool's source code from the Ignite core to its own repository
> (https://github.com/apache/ignite-web-console)
> * Update the repository description highlighting that the tool is no longer
> supported by the community.
> * Unlist Web Console documentation from the navigation and main menus. Do NOT
> remove as long as there are many pages referring to the docs. Just hide.
> * Put a callout on all the hidden documentation pages saying that the tool's
> source code is archived (provide a reference to the repo).
> * Close all the JIRA tickets created for Web Console with the notice that the
> tool is discontinued and no longer supported.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13038) Phase out Ignite Web Console
[
https://issues.apache.org/jira/browse/IGNITE-13038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163243#comment-17163243
]
Alexey Kuznetsov edited comment on IGNITE-13038 at 7/23/20, 7:02 AM:
-
{panel:title=Branch: [pull/8065/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5484140]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5480154buildTypeId=IgniteTests24Java8_RunAll]
was (Author: ignitetcbot):
{panel:title=Branch: [pull/8065/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5484140]]
{panel}
{panel:title=Branch: [pull/8065/head] Base: [master] : New Tests
(8)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Service Grid (legacy mode){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5480132]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=8a3b11fe-afad-4542-aafd-b85539350602, topVer=0,
msgTemplate=null, span=null, nodeId8=dccc70c0, msg=, type=NODE_JOINED,
tstamp=1595311810821], val2=AffinityTopologyVersion
[topVer=1521064462771258804, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=8a3b11fe-afad-4542-aafd-b85539350602, topVer=0,
msgTemplate=null, span=null, nodeId8=dccc70c0, msg=, type=NODE_JOINED,
tstamp=1595311810821], val2=AffinityTopologyVersion
[topVer=1521064462771258804, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=9096eff6371-4217c0ad-0a0e-40c0-9f6b-ed800ad90593, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=e8a9d277-d6f2-4fbb-953a-f1b04bde86e4, topVer=0, msgTemplate=null,
span=null, nodeId8=e8a9d277, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595311810821]], val2=AffinityTopologyVersion
[topVer=-5543092273419277411, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=9096eff6371-4217c0ad-0a0e-40c0-9f6b-ed800ad90593, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=e8a9d277-d6f2-4fbb-953a-f1b04bde86e4, topVer=0, msgTemplate=null,
span=null, nodeId8=e8a9d277, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595311810821]], val2=AffinityTopologyVersion
[topVer=-5543092273419277411, minorTopVer=0]]] - PASSED{color}
{color:#8b}Service Grid{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5480131]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=47c18007371-e3d2ef27-d673-4761-a871-b506cdfba8f4, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=a902d926-053c-47f2-9975-2bd374667c62, topVer=0, msgTemplate=null,
span=null, nodeId8=a902d926, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595311781229]], val2=AffinityTopologyVersion
[topVer=8312076667784893398, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=287a82da-8ffc-4f1e-a56f-172c71c19557, topVer=0,
msgTemplate=null, span=null, nodeId8=b0714866, msg=, type=NODE_JOINED,
tstamp=1595311781229], val2=AffinityTopologyVersion
[topVer=-6264468474552593226, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=287a82da-8ffc-4f1e-a56f-172c71c19557, topVer=0,
msgTemplate=null, span=null, nodeId8=b0714866, msg=, type=NODE_JOINED,
tstamp=1595311781229], val2=AffinityTopologyVersion
[topVer=-6264468474552593226, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=47c18007371-e3d2ef27-d673-4761-a871-b506cdfba8f4, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[jira] [Commented] (IGNITE-13038) Phase out Ignite Web Console
[ https://issues.apache.org/jira/browse/IGNITE-13038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163269#comment-17163269 ] Alexey Kuznetsov commented on IGNITE-13038: --- PDS (indexing) also failed in master. > Phase out Ignite Web Console > > > Key: IGNITE-13038 > URL: https://issues.apache.org/jira/browse/IGNITE-13038 > Project: Ignite > Issue Type: Improvement >Reporter: Denis A. Magda >Assignee: Alexey Kuznetsov >Priority: Critical > Fix For: 2.10 > > Time Spent: 0.5h > Remaining Estimate: 0h > > The community voted to stop the development and maintenance of Ignite Web > Console: > http://apache-ignite-developers.2346864.n4.nabble.com/RESULT-VOTE-Stop-Maintenance-of-Ignite-Web-Console-td47548.html > The following needs to be done: > * Move the tool's source code from the Ignite core to its own repository > (https://github.com/apache/ignite-web-console) > * Update the repository description highlighting that the tool is no longer > supported by the community. > * Unlist Web Console documentation from the navigation and main menus. Do NOT > remove as long as there are many pages referring to the docs. Just hide. > * Put a callout on all the hidden documentation pages saying that the tool's > source code is archived (provide a reference to the repo). > * Close all the JIRA tickets created for Web Console with the notice that the > tool is discontinued and no longer supported. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13266) PDS (Indexing) fails with 'Exit code 137"
[
https://issues.apache.org/jira/browse/IGNITE-13266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163263#comment-17163263
]
Ivan Bessonov commented on IGNITE-13266:
So there are two main problems with the suite.
Exit with error code 130 - caused by {{StopNodeOrHaltFailureHandler}} in
{{WalRolloverRecordLoggingTest}}.
Exit with error code 137 - JVM's excessive memory consumption, caused by
rapidly started and stopped threads that allocate a lot of memory in parallel.
This causes "malloc" to behave really weird, it wasn't meant to be used this
way.
Popular fix found on the internet is to set MALLOC_ARENA_MAX environment
variable to some low value like 1, 2 or 4. Tested it with 4 both locally and on
TC, looks good. We should consider propagating this setting on all suites, I've
seen that at least PDS 4 suffers from the same problem.
In general - the longer the suite, the more chances it has to fail with the
same error, purely because of threads count and constant memory allocation.
[https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PdsIndexing=buildTypeStatusDiv_IgniteTests24Java8=pull%2F8051%2Fhead]
> PDS (Indexing) fails with 'Exit code 137"
> -
>
> Key: IGNITE-13266
> URL: https://issues.apache.org/jira/browse/IGNITE-13266
> Project: Ignite
> Issue Type: Test
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> [https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_PdsIndexing_IgniteTests24Java8=%3Cdefault%3E=buildTypeHistoryList]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13290) SpringTransactionManager adds support for nested transactions
[ https://issues.apache.org/jira/browse/IGNITE-13290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163251#comment-17163251 ] Ivan Pavlukhin commented on IGNITE-13290: - Hi [~liyuj], issue summary confuses with [NESTED|https://docs.spring.io/spring-framework/docs/current/javadoc-api/org/springframework/transaction/annotation/Propagation.html#NESTED] transaction propagation. But as I see from description the issue is mostly about REQUIRES_NEW support. I suggest to rename it to "SpringTransactionManager adds support for REQUIRES_NEW transaction propagation". What do you think? > SpringTransactionManager adds support for nested transactions > - > > Key: IGNITE-13290 > URL: https://issues.apache.org/jira/browse/IGNITE-13290 > Project: Ignite > Issue Type: Bug > Components: spring >Affects Versions: 2.8.1 >Reporter: YuJue Li >Priority: Minor > Fix For: 2.10 > > > If the transaction propagation of the outer method is REQUIRED, the > transaction propagation of the inner method is REQUIRES_NEW, the following > error will be prompted: > org.springframework.transaction.TransactionSuspensionNotSupportedException: > Transaction manager > [org.apache.ignite.transactions.spring.SpringTransactionManager] does not > support transaction suspension > But we see, Ignite's org.apache.ignite.transactions.Transaction, there are > suspend() and resume() methods, and the function is normal, so > SpringTransactionManager should support similar functions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13038) Phase out Ignite Web Console
[
https://issues.apache.org/jira/browse/IGNITE-13038?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17163243#comment-17163243
]
Ignite TC Bot commented on IGNITE-13038:
{panel:title=Branch: [pull/8065/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5484140]]
{panel}
{panel:title=Branch: [pull/8065/head] Base: [master] : New Tests
(8)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Service Grid (legacy mode){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5480132]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=8a3b11fe-afad-4542-aafd-b85539350602, topVer=0,
msgTemplate=null, span=null, nodeId8=dccc70c0, msg=, type=NODE_JOINED,
tstamp=1595311810821], val2=AffinityTopologyVersion
[topVer=1521064462771258804, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=8a3b11fe-afad-4542-aafd-b85539350602, topVer=0,
msgTemplate=null, span=null, nodeId8=dccc70c0, msg=, type=NODE_JOINED,
tstamp=1595311810821], val2=AffinityTopologyVersion
[topVer=1521064462771258804, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=9096eff6371-4217c0ad-0a0e-40c0-9f6b-ed800ad90593, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=e8a9d277-d6f2-4fbb-953a-f1b04bde86e4, topVer=0, msgTemplate=null,
span=null, nodeId8=e8a9d277, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595311810821]], val2=AffinityTopologyVersion
[topVer=-5543092273419277411, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=9096eff6371-4217c0ad-0a0e-40c0-9f6b-ed800ad90593, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=e8a9d277-d6f2-4fbb-953a-f1b04bde86e4, topVer=0, msgTemplate=null,
span=null, nodeId8=e8a9d277, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595311810821]], val2=AffinityTopologyVersion
[topVer=-5543092273419277411, minorTopVer=0]]] - PASSED{color}
{color:#8b}Service Grid{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5480131]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=47c18007371-e3d2ef27-d673-4761-a871-b506cdfba8f4, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=a902d926-053c-47f2-9975-2bd374667c62, topVer=0, msgTemplate=null,
span=null, nodeId8=a902d926, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595311781229]], val2=AffinityTopologyVersion
[topVer=8312076667784893398, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=287a82da-8ffc-4f1e-a56f-172c71c19557, topVer=0,
msgTemplate=null, span=null, nodeId8=b0714866, msg=, type=NODE_JOINED,
tstamp=1595311781229], val2=AffinityTopologyVersion
[topVer=-6264468474552593226, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=287a82da-8ffc-4f1e-a56f-172c71c19557, topVer=0,
msgTemplate=null, span=null, nodeId8=b0714866, msg=, type=NODE_JOINED,
tstamp=1595311781229], val2=AffinityTopologyVersion
[topVer=-6264468474552593226, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=47c18007371-e3d2ef27-d673-4761-a871-b506cdfba8f4, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=a902d926-053c-47f2-9975-2bd374667c62, topVer=0, msgTemplate=null,
span=null, nodeId8=a902d926, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595311781229]], val2=AffinityTopologyVersion
[topVer=8312076667784893398, minorTopVer=0]]] - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5480154buildTypeId=IgniteTests24Java8_RunAll]
> Phase out Ignite Web Console
>
>
> Key:
