[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&focusedCommentId=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&tab=buildTypeStatusDiv&branch_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&branch_IgniteTests24Java8=%3Cdefault%3E&tab=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&focusedCommentId=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&focusedCommentId=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=5480154&buildTypeId=IgniteTests24Java8_RunAll]
> Phase out Ignite Web Console
>
>
>
[jira] [Created] (IGNITE-13290) SpringTransactionManager adds support for nested transactions
YuJue Li created IGNITE-13290: - Summary: 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 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-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&focusedCommentId=17163027#comment-17163027
]
Ignite TC Bot commented on IGNITE-12930:
{panel:title=Branch: [pull/7714/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=5483734]]
{panel}
{panel:title=Branch: [pull/7714/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=5476398]]
* {color:#013220}IgniteBasicTestSuite:
DistributedProcessCoordinatorLeftTest.testCoordinatorFailed - PASSED{color}
{color:#8b}Service Grid (legacy mode){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5477629]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=d39c1354-630f-4473-baf5-a1a7f6d98db1, topVer=0,
msgTemplate=null, span=null, nodeId8=834e6b1d, msg=, type=NODE_JOINED,
tstamp=1595272932280], val2=AffinityTopologyVersion
[topVer=2506475986375759344, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=d39c1354-630f-4473-baf5-a1a7f6d98db1, topVer=0,
msgTemplate=null, span=null, nodeId8=834e6b1d, msg=, type=NODE_JOINED,
tstamp=1595272932280], val2=AffinityTopologyVersion
[topVer=2506475986375759344, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=81787bd6371-eb1f7fb7-6b13-4baa-8289-717b85e530b2, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=abf8efb3-8dee-41e0-a013-6a0b2749be78, topVer=0, msgTemplate=null,
span=null, nodeId8=abf8efb3, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595272932280]], val2=AffinityTopologyVersion
[topVer=-331686843132431608, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=81787bd6371-eb1f7fb7-6b13-4baa-8289-717b85e530b2, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=abf8efb3-8dee-41e0-a013-6a0b2749be78, topVer=0, msgTemplate=null,
span=null, nodeId8=abf8efb3, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595272932280]], val2=AffinityTopologyVersion
[topVer=-331686843132431608, minorTopVer=0]]] - PASSED{color}
{color:#8b}Service Grid{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5476451]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=2dd53edc-dc06-462b-bf30-e545e6c14dfe, topVer=0,
msgTemplate=null, span=null, nodeId8=aafd3c7e, msg=, type=NODE_JOINED,
tstamp=1595260520048], val2=AffinityTopologyVersion
[topVer=-4844912795698995190, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=2dd53edc-dc06-462b-bf30-e545e6c14dfe, topVer=0,
msgTemplate=null, span=null, nodeId8=aafd3c7e, msg=, type=NODE_JOINED,
tstamp=1595260520048], val2=AffinityTopologyVersion
[topVer=-4844912795698995190, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=162a9fc6371-764d10c4-ba93-4e98-9c23-7213e8c6d27f, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=76541175-c259-4c83-a5c0-97e6eaf3eec5, topVer=0, msgTemplate=null,
span=null, nodeId8=76541175, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595260520048]], val2=AffinityTopologyVersion
[topVer=4650137978769321553, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=162a9fc6371-764d10c4-ba93-4e98-9c23-7213e8c6d27f, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=76541175-c259-4c83-a5c0-97e6eaf3eec5, topVer=0, msgTemplate=null,
span=null, nodeId8=76541175, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595260520048]], val2=AffinityTopologyVersion
[topVer=4650137978769321553, minorTopVer=0]]] - PASSED{co
[jira] [Commented] (IGNITE-13222) .NET: Consolidate tests - get rid of Tests.DotNetCore folder
[ https://issues.apache.org/jira/browse/IGNITE-13222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17163008#comment-17163008 ] Pavel Tupitsyn commented on IGNITE-13222: - Merged to master: 77202bc1c6467ed6b9b929c136961ed661c968ec > .NET: Consolidate tests - get rid of Tests.DotNetCore folder > > > Key: IGNITE-13222 > URL: https://issues.apache.org/jira/browse/IGNITE-13222 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Minor > Labels: .NET > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > Right now we have a separate directory for .NET Core tests, and most test > files are shared across Apache.Ignite.Core.Tests and > Apache.Ignite.Core.Tests.DotNetCore projects. > Move Apache.Ignite.Core.Tests.DotNetCore.csproj to Apache.Ignite.Core.Tests > directory, so that all tests are included into DotNetCore project by default. > Incompatible tests should be excluded specifically from the project, or using > compiler directives (#if !NETCOREAPP). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13222) .NET: Consolidate tests - get rid of Tests.DotNetCore folder
[ https://issues.apache.org/jira/browse/IGNITE-13222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17163007#comment-17163007 ] Igor Sapego commented on IGNITE-13222: -- [~ptupitsyn] looks good to me. > .NET: Consolidate tests - get rid of Tests.DotNetCore folder > > > Key: IGNITE-13222 > URL: https://issues.apache.org/jira/browse/IGNITE-13222 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Minor > Labels: .NET > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > Right now we have a separate directory for .NET Core tests, and most test > files are shared across Apache.Ignite.Core.Tests and > Apache.Ignite.Core.Tests.DotNetCore projects. > Move Apache.Ignite.Core.Tests.DotNetCore.csproj to Apache.Ignite.Core.Tests > directory, so that all tests are included into DotNetCore project by default. > Incompatible tests should be excluded specifically from the project, or using > compiler directives (#if !NETCOREAPP). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13287) Minor optimizations forgotten from ignite-13086.
[ https://issues.apache.org/jira/browse/IGNITE-13287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162981#comment-17162981 ] Stanilovsky Evgeny commented on IGNITE-13287: - [~alex_pl] can you check it plz ? > Minor optimizations forgotten from ignite-13086. > > > Key: IGNITE-13287 > URL: https://issues.apache.org/jira/browse/IGNITE-13287 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Some minor code improvements (pr #7864) have been forgotten after > IGNITE-13086 merging. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13287) Minor optimizations forgotten from ignite-13086.
[
https://issues.apache.org/jira/browse/IGNITE-13287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162980#comment-17162980
]
Ignite TC Bot commented on IGNITE-13287:
{panel:title=Branch: [pull/8068/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=5484063]]
{panel}
{panel:title=Branch: [pull/8068/head] Base: [master] : New Tests
(30)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Control Utility{color} [[tests
22|https://ci.ignite.apache.org/viewLog.html?buildId=5484102]]
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerIndexForceRebuildTest.testIndexRebuildUnderLoad -
PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerIndexForceRebuildTest.testEmptyResult - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerIndexForceRebuildTest.testComplexIndexRebuild - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerIndexForceRebuildTest.testAsyncIndexesRebuild - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
CommandHandlerParsingTest.testIndexRebuildStatusWrongArgs - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
CommandHandlerParsingTest.testIndexListWrongArgs - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
CommandHandlerParsingTest.testIndexForceRebuildWrongArgs - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerIndexListTest.testListCacheWithoutIndexes - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerIndexListTest.testCacheIndexList - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerIndexListTest.testCacheNameFilter2 - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerIndexListTest.testCacheNameFilter1 - PASSED{color}
... and 11 new tests
{color:#8b}Service Grid (legacy mode){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5484082]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=510bf2dc-b037-4d46-8669-b0c1d6146922, topVer=0,
msgTemplate=null, span=null, nodeId8=8bc73b13, msg=, type=NODE_JOINED,
tstamp=1595424445314], val2=AffinityTopologyVersion
[topVer=8765631649506742195, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=510bf2dc-b037-4d46-8669-b0c1d6146922, topVer=0,
msgTemplate=null, span=null, nodeId8=8bc73b13, msg=, type=NODE_JOINED,
tstamp=1595424445314], val2=AffinityTopologyVersion
[topVer=8765631649506742195, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=68315b67371-1e0de5e8-526b-4ca5-90be-2d925deab533, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=24ef8224-d480-453b-a078-d7e7221988f3, topVer=0, msgTemplate=null,
span=null, nodeId8=24ef8224, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595424445314]], val2=AffinityTopologyVersion
[topVer=6780593295121698486, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=68315b67371-1e0de5e8-526b-4ca5-90be-2d925deab533, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=24ef8224-d480-453b-a078-d7e7221988f3, topVer=0, msgTemplate=null,
span=null, nodeId8=24ef8224, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595424445314]], val2=AffinityTopologyVersion
[topVer=6780593295121698486, minorTopVer=0]]] - PASSED{color}
{color:#8b}Service Grid{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5484081]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=bd4f3e52-1b27-43a8-a78f-562f1d56f986, topVer=0,
msgTemplate=null, span=null, nodeId8=0c116a0c, msg=, type=NODE_JOINED,
tstamp=1595424591149], val2=AffinityTopologyVersion [topVer=218541342267633990,
minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=bd4f3e52-1b27-43a8-a78f-562f1d56f986, topVer=0,
msgTemplate=null, span=null, nodeId8=0c116a0c, msg=, type=NODE_JOINED,
tstamp=1595424591149], val2=Aff
[jira] [Updated] (IGNITE-13069) Rewrite creation of IgniteInClosure and IgniteOutClosure as lambda expression
[
https://issues.apache.org/jira/browse/IGNITE-13069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Sirotkin updated IGNITE-13069:
-
Issue Type: Improvement (was: New Feature)
> Rewrite creation of IgniteInClosure and IgniteOutClosure as lambda expression
> -
>
> Key: IGNITE-13069
> URL: https://issues.apache.org/jira/browse/IGNITE-13069
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.8.1
>Reporter: Nikolay Izhikov
>Assignee: Konstantin Sirotkin
>Priority: Trivial
> Labels: newbie
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> We can use lambda expression instead of direct instantiation of
> IgniteInClosure, IgniteOutClosure.
> This:
> {code:java}
> state = new DirectMessageState<>(StateItem.class, new
> IgniteOutClosure() {
> @Override public StateItem apply() {
> return new StateItem(msgFactory, protoVer);
> }
> });
> {code}
> Can be replaced with:
> {code:java}
> state = new DirectMessageState<>(StateItem.class, () -> new
> StateItem(msgFactory, protoVer));
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13069) Rewrite creation of IgniteInClosure and IgniteOutClosure as lambda expression
[
https://issues.apache.org/jira/browse/IGNITE-13069?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Sirotkin updated IGNITE-13069:
-
Component/s: general
> Rewrite creation of IgniteInClosure and IgniteOutClosure as lambda expression
> -
>
> Key: IGNITE-13069
> URL: https://issues.apache.org/jira/browse/IGNITE-13069
> Project: Ignite
> Issue Type: New Feature
> Components: general
>Affects Versions: 2.8.1
>Reporter: Nikolay Izhikov
>Assignee: Konstantin Sirotkin
>Priority: Trivial
> Labels: newbie
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> We can use lambda expression instead of direct instantiation of
> IgniteInClosure, IgniteOutClosure.
> This:
> {code:java}
> state = new DirectMessageState<>(StateItem.class, new
> IgniteOutClosure() {
> @Override public StateItem apply() {
> return new StateItem(msgFactory, protoVer);
> }
> });
> {code}
> Can be replaced with:
> {code:java}
> state = new DirectMessageState<>(StateItem.class, () -> new
> StateItem(msgFactory, protoVer));
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13069) Rewrite creation of IgniteInClosure and IgniteOutClosure as lambda expression
[
https://issues.apache.org/jira/browse/IGNITE-13069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162875#comment-17162875
]
Konstantin Sirotkin commented on IGNITE-13069:
--
[~nizhikov], can you review?
> Rewrite creation of IgniteInClosure and IgniteOutClosure as lambda expression
> -
>
> Key: IGNITE-13069
> URL: https://issues.apache.org/jira/browse/IGNITE-13069
> Project: Ignite
> Issue Type: New Feature
>Affects Versions: 2.8.1
>Reporter: Nikolay Izhikov
>Assignee: Konstantin Sirotkin
>Priority: Trivial
> Labels: newbie
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> We can use lambda expression instead of direct instantiation of
> IgniteInClosure, IgniteOutClosure.
> This:
> {code:java}
> state = new DirectMessageState<>(StateItem.class, new
> IgniteOutClosure() {
> @Override public StateItem apply() {
> return new StateItem(msgFactory, protoVer);
> }
> });
> {code}
> Can be replaced with:
> {code:java}
> state = new DirectMessageState<>(StateItem.class, () -> new
> StateItem(msgFactory, protoVer));
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13069) Rewrite creation of IgniteInClosure and IgniteOutClosure as lambda expression
[
https://issues.apache.org/jira/browse/IGNITE-13069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162867#comment-17162867
]
Ignite TC Bot commented on IGNITE-13069:
{panel:title=Branch: [pull/8063/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=5483921]]
{panel}
{panel:title=Branch: [pull/8063/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=5483656]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=dbc39357371-5fb14b1c-4587-4de2-bde2-958458002270, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=d8c39c10-ecce-4864-8b54-cf82efbe340a, topVer=0, msgTemplate=null,
span=null, nodeId8=d8c39c10, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595398930459]], val2=AffinityTopologyVersion
[topVer=-4793974714034106805, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=57bd2f73-7b19-446a-be72-e292783cbe97, topVer=0,
msgTemplate=null, span=null, nodeId8=60368ced, msg=, type=NODE_JOINED,
tstamp=1595398930459], val2=AffinityTopologyVersion
[topVer=-5692470451462576198, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=57bd2f73-7b19-446a-be72-e292783cbe97, topVer=0,
msgTemplate=null, span=null, nodeId8=60368ced, msg=, type=NODE_JOINED,
tstamp=1595398930459], val2=AffinityTopologyVersion
[topVer=-5692470451462576198, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=dbc39357371-5fb14b1c-4587-4de2-bde2-958458002270, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=d8c39c10-ecce-4864-8b54-cf82efbe340a, topVer=0, msgTemplate=null,
span=null, nodeId8=d8c39c10, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595398930459]], val2=AffinityTopologyVersion
[topVer=-4793974714034106805, minorTopVer=0]]] - PASSED{color}
{color:#8b}Service Grid{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5483091]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=242aa68c-75c7-49ae-b957-6b66fd6c0aa9, topVer=0,
msgTemplate=null, span=null, nodeId8=9cc61bb4, msg=, type=NODE_JOINED,
tstamp=1595363044421], val2=AffinityTopologyVersion
[topVer=7965957820425671152, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=94c2c037371-b3afda69-2613-444d-a7ab-7cc8d776fd4f, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=0157bf71-68f0-4d79-bd6f-d340a0845521, topVer=0, msgTemplate=null,
span=null, nodeId8=0157bf71, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595363044421]], val2=AffinityTopologyVersion
[topVer=2021454334948706136, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=94c2c037371-b3afda69-2613-444d-a7ab-7cc8d776fd4f, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=0157bf71-68f0-4d79-bd6f-d340a0845521, topVer=0, msgTemplate=null,
span=null, nodeId8=0157bf71, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595363044421]], val2=AffinityTopologyVersion
[topVer=2021454334948706136, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=242aa68c-75c7-49ae-b957-6b66fd6c0aa9, topVer=0,
msgTemplate=null, span=null, nodeId8=9cc61bb4, msg=, type=NODE_JOINED,
tstamp=1595363044421], val2=AffinityTopologyVersion
[topVer=7965957820425671152, minorTopVer=0]]] - PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5483919&buildTypeId=IgniteTests24Java8_RunAll]
> Rewrite creation of IgniteInClosure and IgniteOutClosure as lambda
[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&focusedCommentId=17162861#comment-17162861 ] Denis A. Magda commented on IGNITE-13038: - [~kuaw26], please go ahead and merge the changes if Andrey Novikov doesn't see any issues. I also wonder if we can get this done in 2.9? Please join this thread, the code freeze is coming, let's try to merge the change: http://apache-ignite-developers.2346864.n4.nabble.com/Apache-Ignite-2-9-0-RELEASE-Time-Scope-Manager-td47828.html > 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-8409) Ignite gets stuck on IgniteDataStreamer.addData when using Object with AffinityKeyMapped
[ https://issues.apache.org/jira/browse/IGNITE-8409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162858#comment-17162858 ] Stanislav Lukyanov commented on IGNITE-8409: Looks like this is no longer reproducible. Closing. > Ignite gets stuck on IgniteDataStreamer.addData when using Object with > AffinityKeyMapped > > > Key: IGNITE-8409 > URL: https://issues.apache.org/jira/browse/IGNITE-8409 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Andrey Aleksandrov >Priority: Critical > Fix For: 2.10 > > Attachments: ContextCpty.java, TradeKey.java, TradeKeyNew.java > > > This problem reproduces from time to time when we are streaming the data > (TradeKey.java) to Ignite sql cache. As AffinityKeyMapped we used the object > type (ContextCpty.java) > When we change AffinityKeyMapped type from object to long type > (TradeKeyNew.java) then problem disappears. > Investigation help to understand that we hang in BPlusTree.java class in next > method: > private Result putDown(final Put p, final long pageId, final long fwdId, > final int lvl) > In this method: > res = p.tryReplaceInner(pageId, page, fwdId, lvl); > if (res != RETRY) // Go down recursively. > res = putDown(p, p.pageId, p.fwdId, lvl - 1); > if (res == RETRY_ROOT || p.isFinished()) > return res; > if (res == RETRY) > checkInterrupted(); //WE ALWAYS GO TO THIS PLACE -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-8409) Ignite gets stuck on IgniteDataStreamer.addData when using Object with AffinityKeyMapped
[ https://issues.apache.org/jira/browse/IGNITE-8409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov resolved IGNITE-8409. Fix Version/s: (was: 2.10) Resolution: Cannot Reproduce > Ignite gets stuck on IgniteDataStreamer.addData when using Object with > AffinityKeyMapped > > > Key: IGNITE-8409 > URL: https://issues.apache.org/jira/browse/IGNITE-8409 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.3 >Reporter: Andrey Aleksandrov >Priority: Critical > Attachments: ContextCpty.java, TradeKey.java, TradeKeyNew.java > > > This problem reproduces from time to time when we are streaming the data > (TradeKey.java) to Ignite sql cache. As AffinityKeyMapped we used the object > type (ContextCpty.java) > When we change AffinityKeyMapped type from object to long type > (TradeKeyNew.java) then problem disappears. > Investigation help to understand that we hang in BPlusTree.java class in next > method: > private Result putDown(final Put p, final long pageId, final long fwdId, > final int lvl) > In this method: > res = p.tryReplaceInner(pageId, page, fwdId, lvl); > if (res != RETRY) // Go down recursively. > res = putDown(p, p.pageId, p.fwdId, lvl - 1); > if (res == RETRY_ROOT || p.isFinished()) > return res; > if (res == RETRY) > checkInterrupted(); //WE ALWAYS GO TO THIS PLACE -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-2311) Need to add an option to store cache objects only in deserialized form
[ https://issues.apache.org/jira/browse/IGNITE-2311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov resolved IGNITE-2311. Resolution: Invalid Closing as this is not applicable for 2.x. > Need to add an option to store cache objects only in deserialized form > -- > > Key: IGNITE-2311 > URL: https://issues.apache.org/jira/browse/IGNITE-2311 > Project: Ignite > Issue Type: New Feature > Components: cache >Reporter: Valentin Kulichenko >Priority: Minor > > In this new mode objects should be always deserialized when saved in cache > and serialized form should be discarded. Serialization should happen only on > demand (e.g., for get() or rebalancing). -- 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&focusedCommentId=17162844#comment-17162844 ] Stanislav Lukyanov commented on IGNITE-6894: This is already implemented today in the form of `dumpLongRunningOperations` as well as Failure Handlers. I think this needs to be closed. [~cyberdemon] [~avinogradov] WDYT? > 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-6893) Java Deadlocks monitoring
[
https://issues.apache.org/jira/browse/IGNITE-6893?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162843#comment-17162843
]
Stanislav Lukyanov commented on IGNITE-6893:
I believe we don't need this feature in particular now that we have Failure
Handlers. If there is a Java deadlock it is almost a guarantee that it will
lead to a blocked system thread, which will trigger FH. How about we close this
[~avinogradov] [~andrey-kuznetsov]?
> 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-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&focusedCommentId=17162841#comment-17162841
]
Anton Kalashnikov commented on IGNITE-13269:
[~ktkale...@gridgain.com] LGTM. [~sergey-chugunov] Can you help with merge,
please?
> 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-6895) TX deadlock monitoring
[ https://issues.apache.org/jira/browse/IGNITE-6895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162842#comment-17162842 ] Stanislav Lukyanov commented on IGNITE-6895: This is already implemented today in the form of `dumpLongRunningOperations` as well as Failure Handlers. I think this needs to be closed. [~cyberdemon] [~avinogradov] WDYT? > 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] [Created] (IGNITE-13289) PagesWriteThrottleSmokeTest.testThrottle start to fail on TC.
Stanilovsky Evgeny created IGNITE-13289: --- Summary: 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 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] [Created] (IGNITE-13287) Minor optimizations forgotten from ignite-13086.
Stanilovsky Evgeny created IGNITE-13287: --- Summary: Minor optimizations forgotten from ignite-13086. Key: IGNITE-13287 URL: https://issues.apache.org/jira/browse/IGNITE-13287 Project: Ignite Issue Type: Improvement Components: general Reporter: Stanilovsky Evgeny Assignee: Stanilovsky Evgeny Some minor code improvements (pr #7864) have been forgotten after IGNITE-13086 merging. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13288) Include few system events by default
Aleksandr Kozhenkov created IGNITE-13288: Summary: Include few system events by default Key: IGNITE-13288 URL: https://issues.apache.org/jira/browse/IGNITE-13288 Project: Ignite Issue Type: Wish Reporter: Aleksandr Kozhenkov Assignee: Aleksandr Kozhenkov There are discovery events that are listened to by all nodes. It will be useful to include these events to listen on all nodes by default too: - EVT_CLUSTER_ACTIVATED - EVT_CLUSTER_DEACTIVATED - EVT_BASELINE_CHANGED - EVT_CLUSTER_STATE_CHANGED They all are rare, system and cluster-wide. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13286) .NET: Add true NuGet multi-targeting
[ https://issues.apache.org/jira/browse/IGNITE-13286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-13286: Ignite Flags: (was: Docs Required,Release Notes Required) > .NET: Add true NuGet multi-targeting > > > Key: IGNITE-13286 > URL: https://issues.apache.org/jira/browse/IGNITE-13286 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.10 > > > Right now we pack the same .NET 4.0 dll as `net40` and `netstandard2.0` (see > nuspec file). While this works well, we can't truly use conditional > compilation to leverage modern .NET features (e.g. async transaction flow). > * Fix the build procedure to include true .NET Core assembly into the NuGet > package > * Make sure .NET Core tests run on Windows as well as on Linux (update > TeamCity projects) > * Fix JVM dll detection (right now Windows Registry is excluded on .NET Core > - bug) > * Review all `#if` conditions to make sure we deliver proper code on all > platforms -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13286) .NET: Add true NuGet multi-targeting
[ https://issues.apache.org/jira/browse/IGNITE-13286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-13286: Description: Right now we pack the same .NET 4.0 dll as `net40` and `netstandard2.0` (see nuspec file). While this works well, we can't truly use conditional compilation to leverage modern .NET features (e.g. async transaction flow). * Fix the build procedure to include true .NET Core assembly into the NuGet package * Make sure .NET Core tests run on Windows as well as on Linux (update TeamCity projects) * Fix JVM dll detection (right now Windows Registry is excluded on .NET Core - bug) * Review all `#if` conditions to make sure we deliver proper code on all platforms was: Right now we pack the same .NET 4.0 dll as `net40` and `netstandard2.0` (see nuspec file). While this works well, we can't truly use conditional compilation to leverage modern .NET features (e.g. async transaction flow). * Fix the build procedure to include true .NET Core assembly into NuGet package * Make sure .NET Core tests run on Windows as well as on Linux (update TeamCity projects) * Fix JVM dll detection (right now Windows Registry is excluded on .NET Core - bug) * Review all `#if` conditions to make sure we deliver proper code on all platforms > .NET: Add true NuGet multi-targeting > > > Key: IGNITE-13286 > URL: https://issues.apache.org/jira/browse/IGNITE-13286 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.10 > > > Right now we pack the same .NET 4.0 dll as `net40` and `netstandard2.0` (see > nuspec file). While this works well, we can't truly use conditional > compilation to leverage modern .NET features (e.g. async transaction flow). > * Fix the build procedure to include true .NET Core assembly into the NuGet > package > * Make sure .NET Core tests run on Windows as well as on Linux (update > TeamCity projects) > * Fix JVM dll detection (right now Windows Registry is excluded on .NET Core > - bug) > * Review all `#if` conditions to make sure we deliver proper code on all > platforms -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13286) .NET: Add true NuGet multi-targeting
[ https://issues.apache.org/jira/browse/IGNITE-13286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-13286: Description: Right now we pack the same .NET 4.0 dll as `net40` and `netstandard2.0` (see nuspec file). While this works well, we can't truly use conditional compilation to leverage modern .NET features (e.g. async transaction flow). * Fix the build procedure to include true .NET Core assembly into NuGet package * Make sure .NET Core tests run on Windows as well as on Linux (update TeamCity projects) * Fix JVM dll detection (right now Windows Registry is excluded on .NET Core - bug) * Review all `#if` conditions to make sure we deliver proper code on all platforms was: Right now we pack the same .NET 4.0 dll as `net40` and `netstandard2.0` (see nuspec file). While this works well, we can't truly use conditional compilation to leverage modern .NET features (e.g. async transaction flow). * Fix the build procedure to include true .NET Core assembly into NuGet package * Make sure .NET Core tests run on Windows as well as on Linux * Fix JVM dll detection (right now Windows Registry is excluded on .NET Core - bug) * Review all `#if` conditions to make sure we deliver proper code on all platforms > .NET: Add true NuGet multi-targeting > > > Key: IGNITE-13286 > URL: https://issues.apache.org/jira/browse/IGNITE-13286 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.10 > > > Right now we pack the same .NET 4.0 dll as `net40` and `netstandard2.0` (see > nuspec file). While this works well, we can't truly use conditional > compilation to leverage modern .NET features (e.g. async transaction flow). > * Fix the build procedure to include true .NET Core assembly into NuGet > package > * Make sure .NET Core tests run on Windows as well as on Linux (update > TeamCity projects) > * Fix JVM dll detection (right now Windows Registry is excluded on .NET Core > - bug) > * Review all `#if` conditions to make sure we deliver proper code on all > platforms -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13286) .NET: Add true NuGet multi-targeting
Pavel Tupitsyn created IGNITE-13286: --- Summary: .NET: Add true NuGet multi-targeting Key: IGNITE-13286 URL: https://issues.apache.org/jira/browse/IGNITE-13286 Project: Ignite Issue Type: Improvement Components: platforms Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 2.10 Right now we pack the same .NET 4.0 dll as `net40` and `netstandard2.0` (see nuspec file). While this works well, we can't truly use conditional compilation to leverage modern .NET features (e.g. async transaction flow). * Fix the build procedure to include true .NET Core assembly into NuGet package * Make sure .NET Core tests run on Windows as well as on Linux * Fix JVM dll detection (right now Windows Registry is excluded on .NET Core - bug) * Review all `#if` conditions to make sure we deliver proper code on all platforms -- This message was sent by Atlassian Jira (v8.3.4#803005)
[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&focusedCommentId=17162725#comment-17162725 ] Tanmay Ambre commented on IGNITE-13270: --- query that we fire is: 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.COL2 = ? AND C.COL6 = ? > 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 > > 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-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&focusedCommentId=17162724#comment-17162724 ] Tanmay Ambre commented on IGNITE-13270: --- CREATE TABLE IF NOT EXISTS A ( A_ID bigint, affinityKey varchar(100), COL1 varchar(30), COL2 bigint, COL3 varchar(40), COL4 varchar(40), COL5 varchar (100), COL6 varchar (100), COL7 int, COL8 int COL9 timestamp, COl10 varchar(30), COL11 bigint, COL12 varchar(50), COL13 timestamp, primary key(A_ID, affinityKey) ) WITH "template=inputCacheTemplate, CACHE_NAME=ACache, AFFINITY_KEY=affinityKey, CACHE_GROUP=INPUT_GROUP KEY_TYPE=com.foo.AKey, VALUE_TYPE=com.foo.A"; CREATE TABLE IF NOT EXISTS B ( B_ID bigint, affinityKey varchar(100), A_ID bigint, COL1 varchar(30), COL2 varchar(100), COL3 bigint, COL4 varchar(50), COL5 varchar(30), COL6 varchar(20), COL7 timestamp, COL8 timestamp, COL9 timestamp, COL10 timestamp, primary key(B_ID, affinityKey) ) WITH "template=inputCacheTemplate, CACHE_NAME=BCache, AFFINITY_KEY=affinityKey, CACHE_GROUP=INPUT_GROUP KEY_TYPE=com.foo.BKey, VALUE_TYPE=com.foo.B"; CREATE TABLE IF NOT EXISTS C( C_ID bigint, B_ID bigint, affinityKey varchar(100), COL1 varchar(20), COL2 bigint, COL3 varchar(50), COL4 varchar(20), COL5 varchar(20), COL6 int, COL7 timestamp, primary key(C_ID, affinityKey) ) WITH "template=inputCacheTemplate, CACHE_NAME=CCache, AFFINITY_KEY=affinityKey, CACHE_GROUP=INPUT_GROUP KEY_TYPE=com.foo.CKey, VALUE_TYPE=com.foo.C"; CREATE INDEX IF NOT EXISTS idx_A_A_ID ON A(A_ID); CREATE INDEX IF NOT EXISTS idx_B_B_ID ON B(B_ID); CREATE INDEX IF NOT EXISTS idx_B_A_ID ON B(A_ID); CREATE INDEX IF NOT EXISTS idx_B_COL2 ON B(COL2) INLINE SIZE 128; CREATE INDEX IF NOT EXISTS idx_C_C_ID on C(C_ID); CREATE INDEX IF NOT EXISTS idx_C_B_ID on C(B_ID); CREATE INDEX IF NOT EXISTS idx_C_COL6 on C(COL6); inputCacheTemplate is PARTITIONED, backups=1, atomicityMode=ATOMIC,partitionLossPolicy=READ_WRITE_SAFE, writeSyncrhonizationMode=PRIMARY_SYNC, statisticsEnabled=true, affinity=RendezvousAffinityFunction (partitions=256), dataRegionName=dr.input dr.input is specified as: persistenceEnabled=false initialSize=64G maxSize=200G metricsEnabled=true > 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 > > 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-13268) Add indexes manipulation commands to control.sh
[ https://issues.apache.org/jira/browse/IGNITE-13268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Malinovskiy updated IGNITE-13268: -- Release Note: New sontrol.sh cache subcommands added: --indexes_list --indexes_rebuild_status --indexes_force_rebuild > Add indexes manipulation commands to control.sh > --- > > Key: IGNITE-13268 > URL: https://issues.apache.org/jira/browse/IGNITE-13268 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Reporter: Vladimir Malinovskiy >Assignee: Vladimir Malinovskiy >Priority: Major > Fix For: 2.10 > > Time Spent: 20m > Remaining Estimate: 0h > > These subcommands are to be added to the *--cache* command: > h2. --indexes_list > Gets list of indexes info. Although filters can be specified via command > arguments lines of output should still be grepable. > h4. Argument: > * *--node-id* is a UUID of node for which to perform the operation. If node > isn’t specified explicitly it will be chosen by grid. > * *--group-name* is a regular expression corresponding to the group name. > * *--cache-name* is a regular expression corresponding to the name of the > cache. > * *--index-name* is a regular expression that matches the name of the index. > h2. --indexes_rebuild_status > Gets list of indexes that are currently being rebuilt. > h4. Argument: > * *--node-id* is a UUID of node for which to perform the operation. If node > isn’t specified explicitly indexes rebuild info will be collected from all > nodes. > h2. --indexes_force_rebuild > Triggers force rebuild of indexes. This information should be reported in the > output: > * List of caches that weren’t found. > * List of caches that have index rebuild in progress. Indexes rebuild > shouldn’t be restarted for these caches. > * List of caches for which index rebuild was triggered. > Indexes rebuild should be performed asynchronously. > h4. Argument: > * *--node-id* is a UUID of node for which to perform the operation. > Mandatory parameter. > * *--group-names* is a comma-separated list of group names for which to > rebuild indexes. Either this option or --cache-names must be specified. > * *--cache-names* is a comma-separated list of cache names for which to > rebuild indexes. Either this option or --group-names must be specified. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13285) Document control.sh indexes manipulation commands
[
https://issues.apache.org/jira/browse/IGNITE-13285?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Malinovskiy updated IGNITE-13285:
--
Description:
Under IGNITE-13268 3 new cache commands were added:
{code:java}
--indexes_list
--indexes_rebuild_status
--indexes_force_rebuild
{code}
New commands should be documented.
Here is part of cache help that corresponds to the commands:
{code:java}
--cache indexes_list [--node-id nodeId] [--group-name grpRegExp]
[--cache-name cacheRegExp] [--index-name idxNameRegExp]
List all indexes that match specified filters.
Parameters:
--node-id nodeId - Specify node for job execution. If not specified
explicitly, node will be chosen by grid
--group-name regExp - Regular expression allowing filtering by cache
group name
--cache-name regExp - Regular expression allowing filtering by cache name
--index-name regExp - Regular expression allowing filtering by index
name
--cache indexes_rebuild_status [--node-id nodeId]
List all indexes that have index rebuild in progress.
Parameters:
--node-id nodeId - Specify node for job execution. If not specified
explicitly, info will be gathered from all nodes
--cache indexes_force_rebuild --node-id nodeId --cache-name
cacheName1,...cacheNameN|--group-name groupName1,...groupNameN
Triggers rebuild of all indexes for specified caches or cache groups.
Parameters:
--node-id - Specify node for indexes rebuild.
--cache-names - Comma-separated list of cache names for which indexes
should be rebuilt.
--group-names - Comma-separated list of cache group names for which
indexes should be rebuilt.
{code}
was:
Under IGNITE-13268 3 new cache commands were added: "--indexes_list",
"--indexes_rebuild_status" and "--indexes_force_rebuild". New commands should
be documented.
Here is part of cache help that corresponds to the commands:
{code:java}
--cache indexes_list [--node-id nodeId] [--group-name grpRegExp]
[--cache-name cacheRegExp] [--index-name idxNameRegExp]
List all indexes that match specified filters.Parameters:
--node-id nodeId - Specify node for job execution. If not specified
explicitly, node will be chosen by grid
--group-name regExp - Regular expression allowing filtering by cache
group name
--cache-name regExp - Regular expression allowing filtering by cache name
--index-name regExp - Regular expression allowing filtering by index
name --cache indexes_rebuild_status [--node-id nodeId]
List all indexes that have index rebuild in progress.Parameters:
--node-id nodeId - Specify node for job execution. If not specified
explicitly, info will be gathered from all nodes --cache indexes_force_rebuild
--node-id nodeId --cache-name cacheName1,...cacheNameN|--group-name
groupName1,...groupNameN
Triggers rebuild of all indexes for specified caches or cache groups.
Parameters:
--node-id - Specify node for indexes rebuild.
--cache-names - Comma-separated list of cache names for which indexes
should be rebuilt.
--group-names - Comma-separated list of cache group names for which
indexes should be rebuilt.
{code}
> Document control.sh indexes manipulation commands
> -
>
> Key: IGNITE-13285
> URL: https://issues.apache.org/jira/browse/IGNITE-13285
> Project: Ignite
> Issue Type: Task
> Components: control.sh, documentation
>Reporter: Vladimir Malinovskiy
>Priority: Major
> Fix For: 2.10
>
>
> Under IGNITE-13268 3 new cache commands were added:
> {code:java}
> --indexes_list
> --indexes_rebuild_status
> --indexes_force_rebuild
> {code}
> New commands should be documented.
> Here is part of cache help that corresponds to the commands:
> {code:java}
> --cache indexes_list [--node-id nodeId] [--group-name grpRegExp]
> [--cache-name cacheRegExp] [--index-name idxNameRegExp]
> List all indexes that match specified filters.
> Parameters:
> --node-id nodeId - Specify node for job execution. If not specified
> explicitly, node will be chosen by grid
> --group-name regExp - Regular expression allowing filtering by cache
> group name
> --cache-name regExp - Regular expression allowing filtering by cache
> name
> --index-name regExp - Regular expression allowing filtering by index
> name
> --cache indexes_rebuild_status [--node-id nodeId]
> List all indexes that have index rebuild in progress.
> Parameters:
> --node-id nodeId - Specify node for job execution. If not specified
> explicitly, info will be gathered from all nodes
> --cache indexes_force_rebuild --node-id nodeId --cache-name
> cacheName1,...cacheNameN|--group-name groupName1,.
[jira] [Assigned] (IGNITE-12744) Add user attributes to GridRestRequest creation routine
[
https://issues.apache.org/jira/browse/IGNITE-12744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Oleg Ostanin reassigned IGNITE-12744:
-
Assignee: Oleg Ostanin
> Add user attributes to GridRestRequest creation routine
> ---
>
> Key: IGNITE-12744
> URL: https://issues.apache.org/jira/browse/IGNITE-12744
> Project: Ignite
> Issue Type: Improvement
> Components: rest
>Affects Versions: 2.8
>Reporter: Andrey Kuznetsov
>Assignee: Oleg Ostanin
>Priority: Major
>
> Improvement [1] has added user attributes support to Ignite thin clients.
> REST API connections should also support this feature:
> {{GridJettyRestHandler.createRequest}} can read user attributes from HTTP
> request parameters.
> [1] https://issues.apache.org/jira/browse/IGNITE-12049
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13285) Document control.sh indexes manipulation commands
Vladimir Malinovskiy created IGNITE-13285:
-
Summary: Document control.sh indexes manipulation commands
Key: IGNITE-13285
URL: https://issues.apache.org/jira/browse/IGNITE-13285
Project: Ignite
Issue Type: Task
Components: control.sh, documentation
Reporter: Vladimir Malinovskiy
Fix For: 2.10
Under IGNITE-13268 3 new cache commands were added: "--indexes_list",
"--indexes_rebuild_status" and "--indexes_force_rebuild". New commands should
be documented.
Here is part of cache help that corresponds to the commands:
{code:java}
--cache indexes_list [--node-id nodeId] [--group-name grpRegExp]
[--cache-name cacheRegExp] [--index-name idxNameRegExp]
List all indexes that match specified filters.Parameters:
--node-id nodeId - Specify node for job execution. If not specified
explicitly, node will be chosen by grid
--group-name regExp - Regular expression allowing filtering by cache
group name
--cache-name regExp - Regular expression allowing filtering by cache name
--index-name regExp - Regular expression allowing filtering by index
name --cache indexes_rebuild_status [--node-id nodeId]
List all indexes that have index rebuild in progress.Parameters:
--node-id nodeId - Specify node for job execution. If not specified
explicitly, info will be gathered from all nodes --cache indexes_force_rebuild
--node-id nodeId --cache-name cacheName1,...cacheNameN|--group-name
groupName1,...groupNameN
Triggers rebuild of all indexes for specified caches or cache groups.
Parameters:
--node-id - Specify node for indexes rebuild.
--cache-names - Comma-separated list of cache names for which indexes
should be rebuilt.
--group-names - Comma-separated list of cache group names for which
indexes should be rebuilt.
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13268) Add indexes manipulation commands to control.sh
[ https://issues.apache.org/jira/browse/IGNITE-13268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Malinovskiy updated IGNITE-13268: -- Description: These subcommands are to be added to the *--cache* command: h2. --indexes_list Gets list of indexes info. Although filters can be specified via command arguments lines of output should still be grepable. h4. Argument: * *--node-id* is a UUID of node for which to perform the operation. If node isn’t specified explicitly it will be chosen by grid. * *--group-name* is a regular expression corresponding to the group name. * *--cache-name* is a regular expression corresponding to the name of the cache. * *--index-name* is a regular expression that matches the name of the index. h2. --indexes_rebuild_status Gets list of indexes that are currently being rebuilt. h4. Argument: * *--node-id* is a UUID of node for which to perform the operation. If node isn’t specified explicitly indexes rebuild info will be collected from all nodes. h2. --indexes_force_rebuild Triggers force rebuild of indexes. This information should be reported in the output: * List of caches that weren’t found. * List of caches that have index rebuild in progress. Indexes rebuild shouldn’t be restarted for these caches. * List of caches for which index rebuild was triggered. Indexes rebuild should be performed asynchronously. h4. Argument: * *--node-id* is a UUID of node for which to perform the operation. Mandatory parameter. * *--group-names* is a comma-separated list of group names for which to rebuild indexes. Either this option or --cache-names must be specified. * *--cache-names* is a comma-separated list of cache names for which to rebuild indexes. Either this option or --group-names must be specified. was: These subcommands are to be added to the *--cache* command: h2. --indexes_list Gets list of indexes info. Although filters can be specified via command arguments lines of output should still be grepable. h4. Argument: * *--node-id* is a UUID of node for which to perform the operation. If node isn’t specified explicitly it will be chosen by grid. * *--group-name* is a regular expression corresponding to the group name. * *--cache-name* is a regular expression corresponding to the name of the cache. * *--index-name* is a regular expression that matches the name of the index. h2. --indexes-rebuild-status Gets list of indexes that are currently being rebuilt. h4. Argument: * *--node-id* is a UUID of node for which to perform the operation. If node isn’t specified explicitly indexes rebuild info will be collected from all nodes. h2. --indexes_force_rebuild Triggers force rebuild of indexes. This information should be reported in the output: * List of caches that weren’t found. * List of caches that have index rebuild in progress. Indexes rebuild shouldn’t be restarted for these caches. * List of caches for which index rebuild was triggered. Indexes rebuild should be performed asynchronously. h4. Argument: * *--node-id* is a UUID of node for which to perform the operation. Mandatory parameter. * *--group-names* is a comma-separated list of group names for which to rebuild indexes. Either this option or --cache-names must be specified. * *--cache-names* is a comma-separated list of cache names for which to rebuild indexes. Either this option or --group-names must be specified. > Add indexes manipulation commands to control.sh > --- > > Key: IGNITE-13268 > URL: https://issues.apache.org/jira/browse/IGNITE-13268 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Reporter: Vladimir Malinovskiy >Assignee: Vladimir Malinovskiy >Priority: Major > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > These subcommands are to be added to the *--cache* command: > h2. --indexes_list > Gets list of indexes info. Although filters can be specified via command > arguments lines of output should still be grepable. > h4. Argument: > * *--node-id* is a UUID of node for which to perform the operation. If node > isn’t specified explicitly it will be chosen by grid. > * *--group-name* is a regular expression corresponding to the group name. > * *--cache-name* is a regular expression corresponding to the name of the > cache. > * *--index-name* is a regular expression that matches the name of the index. > h2. --indexes_rebuild_status > Gets list of indexes that are currently being rebuilt. > h4. Argument: > * *--node-id* is a UUID of node for which to perform the operation. If node > isn’t specified explicitly indexes rebuild info will be collected from all > nodes. > h2. --indexes_force_rebuild > Triggers force rebuild of indexes. This information should be
[jira] [Commented] (IGNITE-13268) Add indexes manipulation commands to control.sh
[ https://issues.apache.org/jira/browse/IGNITE-13268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162715#comment-17162715 ] Sergey Chugunov commented on IGNITE-13268: -- [~vmalinovskiy], I reviewed the change, it looks good to me. I don't think that we could break anything in hanging PDS indexing suite so it should be safe to merge it. > Add indexes manipulation commands to control.sh > --- > > Key: IGNITE-13268 > URL: https://issues.apache.org/jira/browse/IGNITE-13268 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Reporter: Vladimir Malinovskiy >Assignee: Vladimir Malinovskiy >Priority: Major > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > These subcommands are to be added to the *--cache* command: > h2. --indexes_list > Gets list of indexes info. Although filters can be specified via command > arguments lines of output should still be grepable. > h4. Argument: > * *--node-id* is a UUID of node for which to perform the operation. If node > isn’t specified explicitly it will be chosen by grid. > * *--group-name* is a regular expression corresponding to the group name. > * *--cache-name* is a regular expression corresponding to the name of the > cache. > * *--index-name* is a regular expression that matches the name of the index. > h2. --indexes-rebuild-status > Gets list of indexes that are currently being rebuilt. > h4. Argument: > * *--node-id* is a UUID of node for which to perform the operation. If node > isn’t specified explicitly indexes rebuild info will be collected from all > nodes. > h2. --indexes_force_rebuild > Triggers force rebuild of indexes. This information should be reported in the > output: > * List of caches that weren’t found. > * List of caches that have index rebuild in progress. Indexes rebuild > shouldn’t be restarted for these caches. > * List of caches for which index rebuild was triggered. > Indexes rebuild should be performed asynchronously. > h4. Argument: > * *--node-id* is a UUID of node for which to perform the operation. > Mandatory parameter. > * *--group-names* is a comma-separated list of group names for which to > rebuild indexes. Either this option or --cache-names must be specified. > * *--cache-names* is a comma-separated list of cache names for which to > rebuild indexes. Either this option or --group-names must be specified. > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13278) Forgotten logger isInfoEnabled check.
[
https://issues.apache.org/jira/browse/IGNITE-13278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162688#comment-17162688
]
Vyacheslav Koptilin commented on IGNITE-13278:
--
Hello [~zstan],
The fix looks good to me, merged to the master branch. Thank you!
> Forgotten logger isInfoEnabled check.
> -
>
> Key: IGNITE-13278
> URL: https://issues.apache.org/jira/browse/IGNITE-13278
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.8.1
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In RO tests with enabled -ea we can obtain near assertion:
> {code:java}
> java.lang.AssertionError: Logging at INFO level without checking if INFO
> level is enabled: Cluster state was changed from ACTIVE to ACTIVE
> at
> org.apache.ignite.testframework.junits.logger.GridTestLog4jLogger.info(GridTestLog4jLogger.java:481)
> ~[ignite-core-tests.jar]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13278) Forgotten logger isInfoEnabled check.
[
https://issues.apache.org/jira/browse/IGNITE-13278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-13278:
-
Fix Version/s: 2.10
> Forgotten logger isInfoEnabled check.
> -
>
> Key: IGNITE-13278
> URL: https://issues.apache.org/jira/browse/IGNITE-13278
> Project: Ignite
> Issue Type: Improvement
> Components: general
>Affects Versions: 2.8.1
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Minor
> Fix For: 2.10
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> In RO tests with enabled -ea we can obtain near assertion:
> {code:java}
> java.lang.AssertionError: Logging at INFO level without checking if INFO
> level is enabled: Cluster state was changed from ACTIVE to ACTIVE
> at
> org.apache.ignite.testframework.junits.logger.GridTestLog4jLogger.info(GridTestLog4jLogger.java:481)
> ~[ignite-core-tests.jar]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13280) Improper index usage, fields enumeration not used with pk index creation.
[
https://issues.apache.org/jira/browse/IGNITE-13280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanilovsky Evgeny updated IGNITE-13280:
Description:
For example:
{code:java}
CREATE TABLE PUBLIC.TEST_TABLE (FIRST_NAME VARCHAR, LAST_NAME VARCHAR, ADDRESS
VARCHAR, LANG VARCHAR, CONSTRAINT PK_PERSON PRIMARY KEY (FIRST_NAME,
LAST_NAME));
CREATE INDEX "idx2" ON PUBLIC.TEST_TABLE (LANG, ADDRESS);
{code}
and further explain:
{code:java}
SELECT
"__Z0"."FIRST_NAME" AS "__C0_0",
"__Z0"."LAST_NAME" AS "__C0_1",
"__Z0"."ADDRESS" AS "__C0_2",
"__Z0"."LANG" AS "__C0_3"
FROM "PUBLIC"."TEST_TABLE" "__Z0"
/* PUBLIC.IDX2: ADDRESS > 0 */
WHERE "__Z0"."ADDRESS" > 0
{code}
this is erroneous to use "idx2" here, because first index field LANG not
equals to predicate ADDRESS.
Looks like this bug brings this ticket [1]
[1] https://issues.apache.org/jira/browse/IGNITE-10217
was:
For example:
{code:java}
CREATE TABLE PUBLIC.TEST_TABLE (FIRST_NAME VARCHAR, LAST_NAME VARCHAR, ADDRESS
VARCHAR, LANG VARCHAR, CONSTRAINT PK_PERSON PRIMARY KEY (FIRST_NAME,
LAST_NAME));
CREATE INDEX "idx2" ON PUBLIC.TEST_TABLE (LANG, ADDRESS);
{code}
and further explain:
{code:java}
SELECT
"__Z0"."FIRST_NAME" AS "__C0_0",
"__Z0"."LAST_NAME" AS "__C0_1",
"__Z0"."ADDRESS" AS "__C0_2",
"__Z0"."LANG" AS "__C0_3"
FROM "PUBLIC"."TEST_TABLE" "__Z0"
/* PUBLIC.IDX2: ADDRESS > 0 */
WHERE "__Z0"."ADDRESS" > 0
{code}
this is erroneous to use "idx2" here, because first index field LANG not
equals to predicate ADDRESS.
> Improper index usage, fields enumeration not used with pk index creation.
> -
>
> Key: IGNITE-13280
> URL: https://issues.apache.org/jira/browse/IGNITE-13280
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.8.1
>Reporter: Stanilovsky Evgeny
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For example:
> {code:java}
> CREATE TABLE PUBLIC.TEST_TABLE (FIRST_NAME VARCHAR, LAST_NAME VARCHAR,
> ADDRESS VARCHAR, LANG VARCHAR, CONSTRAINT PK_PERSON PRIMARY KEY (FIRST_NAME,
> LAST_NAME));
> CREATE INDEX "idx2" ON PUBLIC.TEST_TABLE (LANG, ADDRESS);
> {code}
> and further explain:
> {code:java}
> SELECT
> "__Z0"."FIRST_NAME" AS "__C0_0",
> "__Z0"."LAST_NAME" AS "__C0_1",
> "__Z0"."ADDRESS" AS "__C0_2",
> "__Z0"."LANG" AS "__C0_3"
> FROM "PUBLIC"."TEST_TABLE" "__Z0"
> /* PUBLIC.IDX2: ADDRESS > 0 */
> WHERE "__Z0"."ADDRESS" > 0
> {code}
> this is erroneous to use "idx2" here, because first index field LANG not
> equals to predicate ADDRESS.
> Looks like this bug brings this ticket [1]
> [1] https://issues.apache.org/jira/browse/IGNITE-10217
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12822) .NET: Build fails on Xamarin
[
https://issues.apache.org/jira/browse/IGNITE-12822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-12822:
Fix Version/s: (was: 2.10)
> .NET: Build fails on Xamarin
>
>
> Key: IGNITE-12822
> URL: https://issues.apache.org/jira/browse/IGNITE-12822
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>
> * Create new Xamarin Forms app in Visual Studio
> * Add reference to Apache.Ignite NuGet package
> * Try to rebuild all:
> {code}
> C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Community\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(1697,2):
> error XA2002: Can not resolve reference: `System.Configuration`, referenced
> by `Apache.Ignite.Core`. Please add a NuGet package or assembly reference for
> `System.Configuration`, or remove the reference to `Apache.Ignite.Core`.
> {code}
> Xamarin does not include System.Configuration assembly.
> The workaround is to manually add a reference to System.Configuration from
> anywhere (it is not used at runtime, we just need to satisfy the build):
> {code}
>
>
> ..\..\bin\System.Configuration.dll
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12822) .NET: Build fails on Xamarin
[
https://issues.apache.org/jira/browse/IGNITE-12822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-12822:
Priority: Trivial (was: Minor)
> .NET: Build fails on Xamarin
>
>
> Key: IGNITE-12822
> URL: https://issues.apache.org/jira/browse/IGNITE-12822
> Project: Ignite
> Issue Type: Bug
> Components: platforms
>Affects Versions: 2.8
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Trivial
>
> * Create new Xamarin Forms app in Visual Studio
> * Add reference to Apache.Ignite NuGet package
> * Try to rebuild all:
> {code}
> C:\Program Files (x86)\Microsoft Visual
> Studio\2019\Community\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(1697,2):
> error XA2002: Can not resolve reference: `System.Configuration`, referenced
> by `Apache.Ignite.Core`. Please add a NuGet package or assembly reference for
> `System.Configuration`, or remove the reference to `Apache.Ignite.Core`.
> {code}
> Xamarin does not include System.Configuration assembly.
> The workaround is to manually add a reference to System.Configuration from
> anywhere (it is not used at runtime, we just need to satisfy the build):
> {code}
>
>
> ..\..\bin\System.Configuration.dll
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13278) Forgotten logger isInfoEnabled check.
[
https://issues.apache.org/jira/browse/IGNITE-13278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162666#comment-17162666
]
Ignite TC Bot commented on IGNITE-13278:
{panel:title=Branch: [pull/8066/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8066/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=5481130]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=cab115e6-2c11-4097-863e-047ec8346640, topVer=0,
msgTemplate=null, span=null, nodeId8=5ddbcbb8, msg=, type=NODE_JOINED,
tstamp=1595327691235], val2=AffinityTopologyVersion
[topVer=-482993636410590077, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=cab115e6-2c11-4097-863e-047ec8346640, topVer=0,
msgTemplate=null, span=null, nodeId8=5ddbcbb8, msg=, type=NODE_JOINED,
tstamp=1595327691235], val2=AffinityTopologyVersion
[topVer=-482993636410590077, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=7e9b0f07371-b4a1b7ee-9766-4a68-8304-cd7c0e87c14f, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=650aaaee-d190-43ae-9842-2c57c302e234, topVer=0, msgTemplate=null,
span=null, nodeId8=650aaaee, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595327691235]], val2=AffinityTopologyVersion
[topVer=7589365629240099503, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=7e9b0f07371-b4a1b7ee-9766-4a68-8304-cd7c0e87c14f, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=650aaaee-d190-43ae-9842-2c57c302e234, topVer=0, msgTemplate=null,
span=null, nodeId8=650aaaee, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595327691235]], val2=AffinityTopologyVersion
[topVer=7589365629240099503, minorTopVer=0]]] - PASSED{color}
{color:#8b}Service Grid{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5481129]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=a23a9592-04cb-4541-9f5d-1b97c2695eb6, topVer=0,
msgTemplate=null, span=null, nodeId8=bfe40ccf, msg=, type=NODE_JOINED,
tstamp=1595327896479], val2=AffinityTopologyVersion
[topVer=-7283984629064531933, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=a23a9592-04cb-4541-9f5d-1b97c2695eb6, topVer=0,
msgTemplate=null, span=null, nodeId8=bfe40ccf, msg=, type=NODE_JOINED,
tstamp=1595327896479], val2=AffinityTopologyVersion
[topVer=-7283984629064531933, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=4452ef07371-93c2329f-4a95-4db7-8f52-8976022c10d1, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=7a6ad262-64e4-4fd4-8407-b7e15e6d00c2, topVer=0, msgTemplate=null,
span=null, nodeId8=7a6ad262, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595327896479]], val2=AffinityTopologyVersion
[topVer=-1693469491385176071, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=4452ef07371-93c2329f-4a95-4db7-8f52-8976022c10d1, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=7a6ad262-64e4-4fd4-8407-b7e15e6d00c2, topVer=0, msgTemplate=null,
span=null, nodeId8=7a6ad262, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595327896479]], val2=AffinityTopologyVersion
[topVer=-1693469491385176071, minorTopVer=0]]] - PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5481152&buildTypeId=IgniteTests24Java8_RunAll]
> Forgotten logger isInfoEnabled check.
> -
>
> Key: IGNITE-13278
> URL: https://issues.apache.org/jira/browse/IGNITE-13278
[jira] [Updated] (IGNITE-13284) Incorrect version check in GridDhtPartitionsReservation#release
[
https://issues.apache.org/jira/browse/IGNITE-13284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Scherbakov updated IGNITE-13284:
---
Description:
Currently GridDhtPartitionsReservation holds a last server topology version,
but compares it with a current version in _reserve_, causing unnecessary
eviction attempts.
The fix looks easy:
{code}
/**
* Releases all the registered partitions.
*/
@Override public void release() {
for (;;) {
int r = reservations.get();
if (r <= 0)
throw new IllegalStateException("Method 'reserve' must be
called before 'release'.");
if (reservations.compareAndSet(r, r - 1)) {
// If it was the last reservation and topology version changed
-> attempt to evict partitions.
if (r == 1 && !cctx.kernalContext().isStopping() &&
!topVer.equals(cctx.shared().exchange().lastAffinityChangedTopologyVersion(cctx.topology().readyTopologyVersion(
tryEvict(parts.get());
return;
}
}
}
{code}
was:
Currently GridDhtPartitionsReservation holds a last server topology version,
but compares it with a current version in reserve, causing unnecessary eviction
attempts.
The fix looks easy:
{code}
/**
* Releases all the registered partitions.
*/
@Override public void release() {
for (;;) {
int r = reservations.get();
if (r <= 0)
throw new IllegalStateException("Method 'reserve' must be
called before 'release'.");
if (reservations.compareAndSet(r, r - 1)) {
// If it was the last reservation and topology version changed
-> attempt to evict partitions.
if (r == 1 && !cctx.kernalContext().isStopping() &&
!topVer.equals(cctx.shared().exchange().lastAffinityChangedTopologyVersion(cctx.topology().readyTopologyVersion(
tryEvict(parts.get());
return;
}
}
}
{code}
> Incorrect version check in GridDhtPartitionsReservation#release
> ---
>
> Key: IGNITE-13284
> URL: https://issues.apache.org/jira/browse/IGNITE-13284
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Scherbakov
>Priority: Major
> Fix For: 2.10
>
>
> Currently GridDhtPartitionsReservation holds a last server topology version,
> but compares it with a current version in _reserve_, causing unnecessary
> eviction attempts.
> The fix looks easy:
> {code}
> /**
> * Releases all the registered partitions.
> */
> @Override public void release() {
> for (;;) {
> int r = reservations.get();
> if (r <= 0)
> throw new IllegalStateException("Method 'reserve' must be
> called before 'release'.");
> if (reservations.compareAndSet(r, r - 1)) {
> // If it was the last reservation and topology version
> changed -> attempt to evict partitions.
> if (r == 1 && !cctx.kernalContext().isStopping() &&
>
> !topVer.equals(cctx.shared().exchange().lastAffinityChangedTopologyVersion(cctx.topology().readyTopologyVersion(
> tryEvict(parts.get());
> return;
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13284) Incorrect version check in GridDhtPartitionsReservation#release
[
https://issues.apache.org/jira/browse/IGNITE-13284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Scherbakov updated IGNITE-13284:
---
Description:
Currently GridDhtPartitionsReservation holds a last server topology version,
but compares it with a current version in reserve, causing unnecessary eviction
attempts.
The fix looks easy:
{code}
/**
* Releases all the registered partitions.
*/
@Override public void release() {
for (;;) {
int r = reservations.get();
if (r <= 0)
throw new IllegalStateException("Method 'reserve' must be
called before 'release'.");
if (reservations.compareAndSet(r, r - 1)) {
// If it was the last reservation and topology version changed
-> attempt to evict partitions.
if (r == 1 && !cctx.kernalContext().isStopping() &&
!topVer.equals(cctx.shared().exchange().lastAffinityChangedTopologyVersion(cctx.topology().readyTopologyVersion(
tryEvict(parts.get());
return;
}
}
}
{code}
was:Currently GridDhtPartitionsReservation holds a last server topology
version, but compares it with a current version in reserve, causing unnecessary
eviction attempts.
> Incorrect version check in GridDhtPartitionsReservation#release
> ---
>
> Key: IGNITE-13284
> URL: https://issues.apache.org/jira/browse/IGNITE-13284
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Scherbakov
>Priority: Major
> Fix For: 2.10
>
>
> Currently GridDhtPartitionsReservation holds a last server topology version,
> but compares it with a current version in reserve, causing unnecessary
> eviction attempts.
> The fix looks easy:
> {code}
> /**
> * Releases all the registered partitions.
> */
> @Override public void release() {
> for (;;) {
> int r = reservations.get();
> if (r <= 0)
> throw new IllegalStateException("Method 'reserve' must be
> called before 'release'.");
> if (reservations.compareAndSet(r, r - 1)) {
> // If it was the last reservation and topology version
> changed -> attempt to evict partitions.
> if (r == 1 && !cctx.kernalContext().isStopping() &&
>
> !topVer.equals(cctx.shared().exchange().lastAffinityChangedTopologyVersion(cctx.topology().readyTopologyVersion(
> tryEvict(parts.get());
> return;
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13284) Incorrect version check in GridDhtPartitionsReservation#release
Alexey Scherbakov created IGNITE-13284: -- Summary: Incorrect version check in GridDhtPartitionsReservation#release Key: IGNITE-13284 URL: https://issues.apache.org/jira/browse/IGNITE-13284 Project: Ignite Issue Type: Bug Reporter: Alexey Scherbakov Fix For: 2.10 Currently GridDhtPartitionsReservation holds a last server topology version, but compares it with a current version in reserve, causing unnecessary eviction attempts. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13148) Thin Client Continuous Query
[ https://issues.apache.org/jira/browse/IGNITE-13148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162652#comment-17162652 ] Pavel Tupitsyn commented on IGNITE-13148: - Merged to master: 5fe4b38e335f3f07f7cae4b5877b8726eb5f81df > Thin Client Continuous Query > > > Key: IGNITE-13148 > URL: https://issues.apache.org/jira/browse/IGNITE-13148 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Affects Versions: 2.8 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.10 > > Original Estimate: 96h > Time Spent: 51h 40m > Remaining Estimate: 8h 50m > > Add Continuous Queries to thin client protocol. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13148) Thin Client Continuous Query
[ https://issues.apache.org/jira/browse/IGNITE-13148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162647#comment-17162647 ] Pavel Tupitsyn commented on IGNITE-13148: - [~isapego] replied on GitHub - let's keep it as is for now. > Thin Client Continuous Query > > > Key: IGNITE-13148 > URL: https://issues.apache.org/jira/browse/IGNITE-13148 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Affects Versions: 2.8 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.10 > > Original Estimate: 96h > Time Spent: 51.5h > Remaining Estimate: 9h > > Add Continuous Queries to thin client protocol. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13280) Improper index usage, fields enumeration not used with pk index creation.
[
https://issues.apache.org/jira/browse/IGNITE-13280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162645#comment-17162645
]
Ignite TC Bot commented on IGNITE-13280:
{panel:title=Branch: [pull/8067/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=5483698]]
{panel}
{panel:title=Branch: [pull/8067/head] Base: [master] : New Tests
(12)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Queries 1{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5483700]]
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
BasicIndexMultinodeTest.testConditionsWithoutIndexes - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
BasicIndexTest.testConditionsWithoutIndexes - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
BasicIndexMultinodeTest.testCheckThreeFieldsInPk - PASSED{color}
* {color:#013220}IgniteBinaryCacheQueryTestSuite:
BasicIndexTest.testCheckThreeFieldsInPk - PASSED{color}
{color:#8b}Service Grid (legacy mode){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5482940]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=33e51432-b32d-4ca7-9393-8e55e18383c6, topVer=0,
msgTemplate=null, span=null, nodeId8=a0f49b7c, msg=, type=NODE_JOINED,
tstamp=1595360276351], val2=AffinityTopologyVersion
[topVer=4212389184898639918, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=33e51432-b32d-4ca7-9393-8e55e18383c6, topVer=0,
msgTemplate=null, span=null, nodeId8=a0f49b7c, msg=, type=NODE_JOINED,
tstamp=1595360276351], val2=AffinityTopologyVersion
[topVer=4212389184898639918, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=38fe1e27371-b96ff4ea-5ea5-41b7-9ede-976441be1444, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=5cca31fe-ec84-4eb5-925c-2bba985df1cf, topVer=0, msgTemplate=null,
span=null, nodeId8=5cca31fe, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595360276351]], val2=AffinityTopologyVersion
[topVer=8399228418209159273, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=38fe1e27371-b96ff4ea-5ea5-41b7-9ede-976441be1444, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=5cca31fe-ec84-4eb5-925c-2bba985df1cf, topVer=0, msgTemplate=null,
span=null, nodeId8=5cca31fe, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595360276351]], val2=AffinityTopologyVersion
[topVer=8399228418209159273, minorTopVer=0]]] - PASSED{color}
{color:#8b}Service Grid{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5482939]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=51f1051a-25fe-4ae6-8456-53f8dd604e34, topVer=0,
msgTemplate=null, span=null, nodeId8=f9b640a2, msg=, type=NODE_JOINED,
tstamp=1595360216802], val2=AffinityTopologyVersion
[topVer=7972440667466994383, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=51f1051a-25fe-4ae6-8456-53f8dd604e34, topVer=0,
msgTemplate=null, span=null, nodeId8=f9b640a2, msg=, type=NODE_JOINED,
tstamp=1595360216802], val2=AffinityTopologyVersion
[topVer=7972440667466994383, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=6e601e27371-7c60b1e3-e1f2-4f02-b36e-8416688d0e01, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=1bef19f9-6448-40cb-8b35-7af2b7999e61, topVer=0, msgTemplate=null,
span=null, nodeId8=1bef19f9, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1595360216802]], val2=AffinityTopologyVersion
[topVer=-97273456154309028, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=6e601e27371-7c60b1e3-e1f2-4f02-b36e-8416688d0e01, reqs=Sin
[jira] [Commented] (IGNITE-13086) Improve current page replacement mechanism.
[ https://issues.apache.org/jira/browse/IGNITE-13086?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17162633#comment-17162633 ] Aleksey Plekhanov commented on IGNITE-13086: [~zstan], it looks like nano-optimizations and we can't see the difference in benchmarks. I'm not sure it worth the effort. But if you want you can create an additional ticket. I can review and merge it. > Improve current page replacement mechanism. > --- > > Key: IGNITE-13086 > URL: https://issues.apache.org/jira/browse/IGNITE-13086 > Project: Ignite > Issue Type: Improvement > Components: persistence >Affects Versions: 2.8.1 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Fix For: 2.9 > > Attachments: 8.7-fix-replacement400_rand_512val_5touch_oldts.log, > 8.7-replacement400_rand_512val_5touch_oldts.log, > IgnitePdsPageReplacementTestToYard.java, replacement_64_new.jfr.zip, > replacement_64_old.jfr.zip, screenshot-1.png, screenshot-2.png > > Time Spent: 0.5h > Remaining Estimate: 0h > > Experimentally proven that current page replacement functionality has > problems with replace candidate computation. Current implementation obtain 5 > random pages and make further decisions basing this pages last touch > timestamp and some inner flags, however still possible cases when this pages > set can be simply nullified due to inner logic. All improvements need to be > proven, for example, by simple scenario: > 1. put some data until event EVT_PAGE_REPLACEMENT_STARTED is triggered > 2. put 2 times more data than been loaded in p1. > 3. execute fullscan (through ScanQuery) for old\cold data processing > emulation. > 4. start processing only pages which can fit into current mem region. > 5. measure "replacedPages" metric. > (i attach code mention above) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13283) javadoc - enabled vs. disabled event type
Focus Koweissen created IGNITE-13283:
Summary: javadoc - enabled vs. disabled event type
Key: IGNITE-13283
URL: https://issues.apache.org/jira/browse/IGNITE-13283
Project: Ignite
Issue Type: Bug
Components: documentation
Reporter: Focus Koweissen
Javadoc regarding event types is incosistent and confusing.
[EventType|https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/events/EventType.html]:
{noformat}
Note that by default all events in Ignite are enabled
{noformat}
[IgniteConfiguration|https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/configuration/IgniteConfiguration.html#getIncludeEventTypes--]:
{noformat}
Note that by default all events in Ignite are disabled
{noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13282) Fix TcpDiscoveryCoordinatorFailureTest.testClusterFailedNewCoordinatorInitialized()
[ https://issues.apache.org/jira/browse/IGNITE-13282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13282: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Fix > TcpDiscoveryCoordinatorFailureTest.testClusterFailedNewCoordinatorInitialized() > --- > > Key: IGNITE-13282 > URL: https://issues.apache.org/jira/browse/IGNITE-13282 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
