[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=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{color}
{panel}
[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=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=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=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=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],
[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=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=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=5483919buildTypeId=IgniteTests24Java8_RunAll]
> Rewrite creation of IgniteInClosure and IgniteOutClosure as lambda expression
>
[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=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=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=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=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=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=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=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=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
[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
[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=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=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=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=5481152buildTypeId=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=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=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=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=SingletonList
[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=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)
[jira] [Updated] (IGNITE-9974) Drop Hadoop assemblies
[ https://issues.apache.org/jira/browse/IGNITE-9974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-9974: -- Fix Version/s: (was: 2.9) > Drop Hadoop assemblies > -- > > Key: IGNITE-9974 > URL: https://issues.apache.org/jira/browse/IGNITE-9974 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7 >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > After dropping Hadoop binaries from release delivery (see IGNITE-9953) it is > required to drop assemblies and corresponding files / profiles if exist. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12033) Callbacks from striped pool due to async/await may hang cluster
[
https://issues.apache.org/jira/browse/IGNITE-12033?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-12033:
---
Fix Version/s: (was: 2.9)
2.10
> Callbacks from striped pool due to async/await may hang cluster
> ---
>
> Key: IGNITE-12033
> URL: https://issues.apache.org/jira/browse/IGNITE-12033
> Project: Ignite
> Issue Type: Bug
> Components: cache, platforms
>Affects Versions: 2.7.5
>Reporter: Ilya Kasnacheev
>Priority: Critical
> Fix For: 2.10
>
>
> Discussed on dev-list:
> http://apache-ignite-developers.2346864.n4.nabble.com/Re-EXTERNAL-Re-Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td42921.html
> *Must use the public pool for callbacks as the most obvious step.*
>
> http://apache-ignite-users.70518.x6.nabble.com/Replace-or-Put-after-PutAsync-causes-Ignite-to-hang-td27871.html#a28051
> There's a reproducer project. Long story short, .Net can invoke cache
> operations with future callbacks, which will be invoked from striped pool. If
> such callbacks are to use cache operations, those will be possibly sheduled
> to the same stripe and cause a deadlock.
> The code is very simple:
> {code}
> Console.WriteLine("PutAsync");
> await cache.PutAsync(1, "Test");
> Console.WriteLine("Replace");
> cache.Replace(1, "Testing"); // Hangs here
> Console.WriteLine("Wait");
> await Task.Delay(Timeout.Infinite);
> {code}
> async/await should absolutely not allow any client code to be run from
> stripes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12794) Scan query fails with an assertion error: Unexpected row key
[
https://issues.apache.org/jira/browse/IGNITE-12794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162525#comment-17162525
]
Aleksey Plekhanov commented on IGNITE-12794:
Moved to the next release due to inactivity.
> Scan query fails with an assertion error: Unexpected row key
>
>
> Key: IGNITE-12794
> URL: https://issues.apache.org/jira/browse/IGNITE-12794
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.9
>
> Attachments: ScanQueryExample.java
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Scan query fails with an exception:
> {noformat}
> Exception in thread "main" java.lang.AssertionError: Unexpected row key
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:548)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:512)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3045)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2997)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:127)
> at scan.ScanQueryExample.main(ScanQueryExample.java:31)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)"
> {noformat}
> The issue is reproduced when performing concurrent scan queries and updates.
> A reproducer is attached. You will need to enable asserts in order to
> reproduce this issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12794) Scan query fails with an assertion error: Unexpected row key
[
https://issues.apache.org/jira/browse/IGNITE-12794?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-12794:
---
Fix Version/s: (was: 2.9)
2.10
> Scan query fails with an assertion error: Unexpected row key
>
>
> Key: IGNITE-12794
> URL: https://issues.apache.org/jira/browse/IGNITE-12794
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Denis Mekhanikov
>Assignee: Denis Mekhanikov
>Priority: Major
> Fix For: 2.10
>
> Attachments: ScanQueryExample.java
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Scan query fails with an exception:
> {noformat}
> Exception in thread "main" java.lang.AssertionError: Unexpected row key
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:548)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.unswap(GridCacheMapEntry.java:512)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.advance(GridCacheQueryManager.java:3045)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager$ScanQueryIterator.onHasNext(GridCacheQueryManager.java:2997)
> at
> org.apache.ignite.internal.util.GridCloseableIteratorAdapter.hasNextX(GridCloseableIteratorAdapter.java:53)
> at
> org.apache.ignite.internal.util.lang.GridIteratorAdapter.hasNext(GridIteratorAdapter.java:45)
> at
> org.apache.ignite.internal.processors.cache.QueryCursorImpl.getAll(QueryCursorImpl.java:127)
> at scan.ScanQueryExample.main(ScanQueryExample.java:31)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)"
> {noformat}
> The issue is reproduced when performing concurrent scan queries and updates.
> A reproducer is attached. You will need to enable asserts in order to
> reproduce this issue.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11970) Excessive use of memory in continuous queries
[ https://issues.apache.org/jira/browse/IGNITE-11970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-11970: --- Fix Version/s: (was: 2.9) 2.10 > Excessive use of memory in continuous queries > - > > Key: IGNITE-11970 > URL: https://issues.apache.org/jira/browse/IGNITE-11970 > Project: Ignite > Issue Type: Bug >Reporter: Igor Belyakov >Assignee: Igor Belyakov >Priority: Critical > Fix For: 2.10 > > Time Spent: 40m > Remaining Estimate: 0h > > When we prepare to send an entry into the continuous query's filter and > listener, we store it in an instance of CacheContinuousQueryEventBuffer.Batch. > The batch is an array of entries of size > IGNITE_CONTINUOUS_QUERY_SERVER_BUFFER_SIZE (default is 1000) that stores the > currently received entries (we need it for the case of concurrent updates to > make sure that we preserve the order of update counters). > The issue is that when we process a part of the array we keep the links to > the processed entries until we exhaust the array (after when we finally clear > it). Because of that we may store up to 999 garbage objects which can be a > lot if the entries are big. > Need to clear the entries right after we've processed them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-11970) Excessive use of memory in continuous queries
[ https://issues.apache.org/jira/browse/IGNITE-11970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162522#comment-17162522 ] Aleksey Plekhanov commented on IGNITE-11970: Moved to the next release due to inactivity. > Excessive use of memory in continuous queries > - > > Key: IGNITE-11970 > URL: https://issues.apache.org/jira/browse/IGNITE-11970 > Project: Ignite > Issue Type: Bug >Reporter: Igor Belyakov >Assignee: Igor Belyakov >Priority: Critical > Fix For: 2.9 > > Time Spent: 40m > Remaining Estimate: 0h > > When we prepare to send an entry into the continuous query's filter and > listener, we store it in an instance of CacheContinuousQueryEventBuffer.Batch. > The batch is an array of entries of size > IGNITE_CONTINUOUS_QUERY_SERVER_BUFFER_SIZE (default is 1000) that stores the > currently received entries (we need it for the case of concurrent updates to > make sure that we preserve the order of update counters). > The issue is that when we process a part of the array we keep the links to > the processed entries until we exhaust the array (after when we finally clear > it). Because of that we may store up to 999 garbage objects which can be a > lot if the entries are big. > Need to clear the entries right after we've processed them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (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:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-12930:
---
Priority: Critical (was: Major)
> DistributedProcess fails node if unable to send single message to coordinator
> -
>
> Key: IGNITE-12930
> URL: https://issues.apache.org/jira/browse/IGNITE-12930
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: Amelchev Nikita
>Priority: Critical
> Fix For: 2.9
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> The
> [DistributedProcess|https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/util/distributed/DistributedProcess.java]
> fails the local node ({{FailureHandler}} CRITICAL_ERROR thrown) if unable to
> send a message to the coordinator (e.g. the coordinator fails right before
> the single message is sent).
> {code:java}
> try {
> ctx.io().sendToGridTopic(p.crdId,
> GridTopic.TOPIC_DISTRIBUTED_PROCESS, singleMsg, SYSTEM_POOL);
> }
> catch (IgniteCheckedException e) {
> log.error("Unable to send message to coordinator.", e);
> ctx.failure().process(new FailureContext(CRITICAL_ERROR,
> new Exception("Unable to send message to coordinator.",
> e)));
> }
> {code}
> h4. Expected behaviour
> If the {{ClusterTopologyCheckedException}} occurs need to wait for the
> NODE_LEFT event of the coordinator node and re-init the distributed process
> future.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13028) Spring Data integration doesn't introspect the fields of the key object
[
https://issues.apache.org/jira/browse/IGNITE-13028?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-13028:
---
Fix Version/s: (was: 2.9)
2.10
> Spring Data integration doesn't introspect the fields of the key object
> ---
>
> Key: IGNITE-13028
> URL: https://issues.apache.org/jira/browse/IGNITE-13028
> Project: Ignite
> Issue Type: Improvement
> Components: spring, springdata
>Affects Versions: 2.8
>Reporter: Denis A. Magda
>Priority: Major
> Labels: newbie
> Fix For: 2.10
>
>
> Suppose you have key and value POJOs associated with Ignite caches/tables:
> * Key:
> https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/model/CityKey.java
> * Value:
> https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/model/City.java
> The key object includes a couple of fields ({{id}} and {{countryCode}}) that
> are not visible to the Spring's query-autogeneration feature. For instance,
> you have to use direct queries if want to get [all the cities with a specific
> value of {{id}}
> field|https://github.com/GridGain-Demos/ignite-spring-data-demo/blob/master/src/main/java/org/gridgain/demo/springdata/dao/CityRepository.java#L42]:
> {code:java}
> @Query("SELECT * FROM City WHERE id = ?")
> public Cache.Entry findById(int id);
> {code}
> If the query-autogeneration feature could introspect the metadata of the key,
> then you would not need to fall back to the direct queries and would add the
> following query to the repository:
> {code:java}
> public Cache.Entry findById(int id);
> {code}
> The same issue exists if a key is of a primitive type (Integer, String, etc.)
> To reproduce you can use this project:
> https://github.com/GridGain-Demos/ignite-spring-data-demo
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11238) Possible hang on exchange
[
https://issues.apache.org/jira/browse/IGNITE-11238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-11238:
---
Fix Version/s: (was: 2.9)
2.10
> Possible hang on exchange
> -
>
> Key: IGNITE-11238
> URL: https://issues.apache.org/jira/browse/IGNITE-11238
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Igor Seliverstov
>Priority: Critical
> Fix For: 2.10
>
>
> Currently we may hang on exchange for a while (two network timeouts) waiting
> for release a latch (see
> {{GridDhtPartitionsExchangeFuture#waitPartitionRelease releaseLatch}}) in
> case a processing topology version has not been added to discovery history
> yet but client acknowledge already received by coordinator:
> {code:java}
> [2019-02-06
> 17:43:17,009][ERROR][sys-#43%mvcc.CacheMvccPartitionedSqlCoordinatorFailoverTest0%][ExchangeLatchManager]
> Topology AffinityTopologyVersion [topVer=24, minorTopVer=0] not found in
> discovery history ; consider increasing IGNITE_DISCOVERY_HISTORY_SIZE
> property. Current value is -1
> class org.apache.ignite.IgniteException: Topology AffinityTopologyVersion
> [topVer=24, minorTopVer=0] not found in discovery history ; consider
> increasing IGNITE_DISCOVERY_HISTORY_SIZE property. Current value is -1
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.latch.ExchangeLatchManager.aliveNodesForTopologyVer(ExchangeLatchManager.java:260)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.latch.ExchangeLatchManager.getLatchCoordinator(ExchangeLatchManager.java:302)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.latch.ExchangeLatchManager.processAck(ExchangeLatchManager.java:351)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.latch.ExchangeLatchManager.lambda$new$0(ExchangeLatchManager.java:121)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1561)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1189)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$4200(GridIoManager.java:127)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$8.run(GridIoManager.java:1086)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> This way the received ack won't be processed, so, we will be waiting for
> retry:
> {code:java}
> // Try to resend ack.
> releaseLatch.countDown();
> {code}
> To solve the issue we need to test whether the version is present in
> discovery history and put it into a pending map if i isn't so (see
> {{ExchangeLatchManager#pendingAcks}})
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-10010) Node halted if second node was stopped, then cache destroyed, then second node returned
[
https://issues.apache.org/jira/browse/IGNITE-10010?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-10010:
---
Fix Version/s: (was: 2.9)
2.10
> Node halted if second node was stopped, then cache destroyed, then second
> node returned
> ---
>
> Key: IGNITE-10010
> URL: https://issues.apache.org/jira/browse/IGNITE-10010
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Sergey Kozlov
>Assignee: Alexey Goncharuk
>Priority: Critical
> Fix For: 2.10
>
> Attachments: PersistenceNodeRestartAfterCacheDropSelfTest.java,
> ignite-gridparitition-nullpointer.zip
>
>
> Partitions cache sizes1. Start 2 nodes with PDS
> 2. Activate cluster
> 3. Connect sqlline.
> 4. Create table {{create table t1(a int, b varchar, primary key(a)) with
> "ATOMICITY=TRANSACTIONAL_SNAPSHOT,backups=1";}}
> 5. Stop node 1
> 6. Drop table {{drop table t1;}}
> 7. Start node 1
> 8. Node 2 stopped by handler:
> {noformat}
> c:\Work\apache-ignite-2.7.0-SNAPSHOT-bin>bin\ignite.bat server.xml -v -J-DID=1
> Ignite Command Line Startup, ver. 2.7.0-SNAPSHOT#19700101-sha1:DEV
> 2018 Copyright(C) Apache Software Foundation
> [18:04:22,745][INFO][main][IgniteKernal]
> >>>__
> >>> / _/ ___/ |/ / _/_ __/ __/
> >>> _/ // (7 7// / / / / _/
> >>> /___/\___/_/|_/___/ /_/ /___/
> >>>
> >>> ver. 2.7.0-SNAPSHOT#19700101-sha1:DEV
> >>> 2018 Copyright(C) Apache Software Foundation
> >>>
> >>> Ignite documentation: http://ignite.apache.org
> [18:04:22,745][INFO][main][IgniteKernal] Config URL:
> file:/c:/Work/apache-ignite-2.7.0-SNAPSHOT-bin/server.xml
> [18:04:22,760][INFO][main][IgniteKernal] IgniteConfiguration
> [igniteInstanceName=null, pubPoolSize=8, svcPoolSize=8, cal
> lbackPoolSize=8, stripedPoolSize=8, sysPoolSize=8, mgmtPoolSize=4,
> igfsPoolSize=8, dataStreamerPoolSize=8, utilityCacheP
> oolSize=8, utilityCacheKeepAliveTime=6, p2pPoolSize=2, qryPoolSize=8,
> igniteHome=c:\Work\apache-ignite-2.7.0-SNAPSHO
> T-bin, igniteWorkDir=c:\Work\apache-ignite-2.7.0-SNAPSHOT-bin\work,
> mbeanSrv=com.sun.jmx.mbeanserver.JmxMBeanServer@6f94
> fa3e, nodeId=d02069db-6d0b-4a40-b185-1d95fa330853, marsh=BinaryMarshaller [],
> marshLocJobs=false, daemon=false, p2pEnabl
> ed=false, netTimeout=5000, sndRetryDelay=1000, sndRetryCnt=3,
> metricsHistSize=1, metricsUpdateFreq=2000, metricsExpT
> ime=9223372036854775807, discoSpi=TcpDiscoverySpi [addrRslvr=null,
> sockTimeout=0, ackTimeout=0, marsh=null, reconCnt=10,
> reconDelay=2000, maxAckTimeout=60, forceSrvMode=false,
> clientReconnectDisabled=false, internalLsnr=null], segPlc=ST
> OP, segResolveAttempts=2, waitForSegOnStart=true, allResolversPassReq=true,
> segChkFreq=1, commSpi=TcpCommunicationSp
> i [connectGate=null,
> connPlc=org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$FirstConnectionPolicy@22ff4249,
> enableForcibleNodeKill=false, enableTroubleshootingLog=false, locAddr=null,
> locHost=null, locPort=47100, locPortRange=1
> 00, shmemPort=-1, directBuf=true, directSndBuf=false, idleConnTimeout=60,
> connTimeout=5000, maxConnTimeout=60, r
> econCnt=10, sockSndBuf=32768, sockRcvBuf=32768, msgQueueLimit=0,
> slowClientQueueLimit=0, nioSrvr=null, shmemSrv=null, us
> ePairedConnections=false, connectionsPerNode=1, tcpNoDelay=true,
> filterReachableAddresses=false, ackSndThreshold=32, una
> ckedMsgsBufSize=0, sockWriteTimeout=2000, boundTcpPort=-1,
> boundTcpShmemPort=-1, selectorsCnt=4, selectorSpins=0, addrRs
> lvr=null, ctxInitLatch=java.util.concurrent.CountDownLatch@2d1ef81a[Count =
> 1], stopping=false], evtSpi=org.apache.ignit
> e.spi.eventstorage.NoopEventStorageSpi@4c402120, colSpi=NoopCollisionSpi [],
> deploySpi=LocalDeploymentSpi [], indexingSp
> i=org.apache.ignite.spi.indexing.noop.NoopIndexingSpi@815b41f,
> addrRslvr=null, encryptionSpi=org.apache.ignite.spi.encry
> ption.noop.NoopEncryptionSpi@5542c4ed, clientMode=false,
> rebalanceThreadPoolSize=1, txCfg=TransactionConfiguration [txSe
> rEnabled=false, dfltIsolation=REPEATABLE_READ, dfltConcurrency=PESSIMISTIC,
> dfltTxTimeout=0, txTimeoutOnPartitionMapExch
> ange=0, pessimisticTxLogSize=0, pessimisticTxLogLinger=1,
> tmLookupClsName=null, txManagerFactory=null, useJtaSync=fa
> lse], cacheSanityCheckEnabled=true, discoStartupDelay=6,
> deployMode=SHARED, p2pMissedCacheSize=100, locHost=127.0.0.
> 1, timeSrvPortBase=31100, timeSrvPortRange=100,
> failureDetectionTimeout=1, sysWorkerBlockedTimeout=null, clientFailu
> reDetectionTimeout=3, metricsLogFreq=6, hadoopCfg=null,
> connectorCfg=ConnectorConfiguration [jettyPath=null, hos
> t=null, port=11211, noDelay=true, directBuf=false,
[jira] [Updated] (IGNITE-12456) Cluster Data Store grid gets Corrupted for Load test
[
https://issues.apache.org/jira/browse/IGNITE-12456?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-12456:
---
Fix Version/s: (was: 2.9)
2.10
> Cluster Data Store grid gets Corrupted for Load test
>
>
> Key: IGNITE-12456
> URL: https://issues.apache.org/jira/browse/IGNITE-12456
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.7
>Reporter: Ravi Kumar Powli
>Assignee: Alexey Goncharuk
>Priority: Critical
> Fix For: 2.10
>
> Attachments: default-config.xml
>
>
> We have Apache Ignite 3 node cluster setup with Amazon S3 Based Discovery.we
> are into AWS cloud environment with Microservice model with 8
> microservices.we are using Ignite for session data store.While performing
> load test we are facing data grid issues if the number of clients reached 40
> , Once data grid got corrupted we will lost the session store data and
> Application will not respond due to session data also corrupted and all the
> instances will auto scaled down to initial size 8.We need to restart Apache
> Ignite to make the Application up.Please find the attached Apache Ignite
> Configuration for your reference.
> This is Impacting the scalability for the micro-services. It is very evident
> that the current state based architecture will not scale beyond a certain TPS
> and the state store, especially Ignite becomes the single point of failure,
> stalling the full Micro-service cluster.
> Apache Ignite Version : 2.7.0
> {code}
> 07:24:46,678][SEVERE][tcp-disco-msg-worker-#2%DataStoreIgniteCache%|#2%DataStoreIgniteCache%][G]
> Blocked system-critical thread has been detected. This can lead to
> cluster-wide undefined behaviour [threadName=sys-stripe-5,
> blockedFor=21s]07:24:46,678][SEVERE][tcp-disco-msg-worker-#2%DataStoreIgniteCache%|#2%DataStoreIgniteCache%][G]
> Blocked system-critical thread has been detected. This can lead to
> cluster-wide undefined behaviour [threadName=sys-stripe-5,
> blockedFor=21s][07:24:46,680][SEVERE][tcp-disco-msg-worker-#2%DataStoreIgniteCache%|#2%DataStoreIgniteCache%][]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_BLOCKED, err=class o.a.i.IgniteException: GridWorker
> [name=sys-stripe-5, igniteInstanceName=DataStoreIgniteCache, finished=false,
> heartbeatTs=1575271465499]]]class org.apache.ignite.IgniteException:
> GridWorker [name=sys-stripe-5, igniteInstanceName=DataStoreIgniteCache,
> finished=false, heartbeatTs=1575271465499] at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1831)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1826)
> at
> org.apache.ignite.internal.worker.WorkersRegistry.onIdle(WorkersRegistry.java:233)
> at
> org.apache.ignite.internal.util.worker.GridWorker.onIdle(GridWorker.java:297)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.lambda$new$0(ServerImpl.java:2663)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorker.body(ServerImpl.java:7181)
> at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$RingMessageWorker.body(ServerImpl.java:2700)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120) at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$MessageWorkerThread.body(ServerImpl.java:7119)
> at
> org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:62)[07:24:52,692][SEVERE][tcp-disco-msg-worker-#2%DataStoreIgniteCache%|#2%DataStoreIgniteCache%][G]
> Blocked system-critical thread has been detected. This can lead to
> cluster-wide undefined behaviour [threadName=ttl-cleanup-worker,
> blockedFor=27s][07:24:52,692][SEVERE][tcp-disco-msg-worker-#2%DataStoreIgniteCache%|#2%DataStoreIgniteCache%][]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=[SYSTEM_WORKER_BLOCKED]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_BLOCKED, err=class o.a.i.IgniteException: GridWorker
> [name=ttl-cleanup-worker, igniteInstanceName=DataStoreIgniteCache,
> finished=false, heartbeatTs=1575271465044]]]class
> org.apache.ignite.IgniteException: GridWorker [name=ttl-cleanup-worker,
> igniteInstanceName=DataStoreIgniteCache, finished=false,
> heartbeatTs=1575271465044] at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1831)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance$2.apply(IgnitionEx.java:1826)
> at
>
[jira] [Updated] (IGNITE-12404) .NET: Adopt nullable reference types
[ https://issues.apache.org/jira/browse/IGNITE-12404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-12404: --- Fix Version/s: (was: 2.9) 2.10 > .NET: Adopt nullable reference types > > > Key: IGNITE-12404 > URL: https://issues.apache.org/jira/browse/IGNITE-12404 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Critical > Labels: .NET > Fix For: 3.0, 2.10 > > Original Estimate: 40h > Remaining Estimate: 40h > > .NET 5 is due on November 2020. Microsoft recommends adopting nullable > annotations on public APIs before that date to all library authors: > * https://devblogs.microsoft.com/dotnet/embracing-nullable-reference-types/ > * https://stu.dev/csharp8-doing-unsupported-things/ > * https://www.youtube.com/watch?v=TJiLhRPgyq4=youtu.be > The adoption can be performed on any language version by using special > attributes in the source code (no binary dependency required): > https://github.com/manuelroemer/Nullable -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (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 ] Aleksey Plekhanov updated IGNITE-8409: -- Fix Version/s: (was: 2.9) 2.10 > 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] [Updated] (IGNITE-11302) idleConnectionTimeout TcpComm different on server and client (client default > server custom) lead to wait until client timeout on server side
[
https://issues.apache.org/jira/browse/IGNITE-11302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-11302:
---
Fix Version/s: (was: 2.9)
2.10
> idleConnectionTimeout TcpComm different on server and client (client default
> > server custom) lead to wait until client timeout on server side
> --
>
> Key: IGNITE-11302
> URL: https://issues.apache.org/jira/browse/IGNITE-11302
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: ARomantsov
>Assignee: Dmitriy Sorokin
>Priority: Critical
> Fix For: 2.10
>
>
> Server config:
> {code:xml}
>
> class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
>
>
>
> Client config
>
> class="org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi">
>
>
> {code}
> Server wait until default idleConnectionTimeout (10 m) for client fail.
> If both config with idleConnectionTimeout=1 s - ignite worked according to
> config
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11687) Concurrent WAL replay & log may fail with CRC error on read
[
https://issues.apache.org/jira/browse/IGNITE-11687?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-11687:
---
Fix Version/s: (was: 2.9)
2.10
> Concurrent WAL replay & log may fail with CRC error on read
> ---
>
> Key: IGNITE-11687
> URL: https://issues.apache.org/jira/browse/IGNITE-11687
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Reporter: Alexey Goncharuk
>Assignee: Anton Kalashnikov
>Priority: Critical
> Fix For: 2.10
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The cause is the way {{end}} is calculated for WAL iterator:
> {code}
> if (hnd != null)
> end = hnd.position();
> {code}
> {code}
> @Override public FileWALPointer position() {
> lock.lock();
> try {
> return new FileWALPointer(getSegmentId(), (int)written, 0);
> }
> finally {
> lock.unlock();
> }
> }
> {code}
> Consider a partially written entry. In this case, {{written}} has been
> already updated, concurrent WAL replay will attempt to read the incompletely
> written record and since {{end}} is not null, iterator will fail with CRC
> error.
> The issue may be rarely reproduced by {{IgniteWalSerializerVersionTest}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12852) Comma in field is not supported by COPY command
[ https://issues.apache.org/jira/browse/IGNITE-12852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-12852: --- Fix Version/s: (was: 2.9) 2.10 > Comma in field is not supported by COPY command > --- > > Key: IGNITE-12852 > URL: https://issues.apache.org/jira/browse/IGNITE-12852 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: YuJue Li >Assignee: YuJue Li >Priority: Critical > Fix For: 2.10 > > Time Spent: 0.5h > Remaining Estimate: 0h > > CREATE TABLE test(a int,b varchar(100),c int,PRIMARY key(a)); > > a.csv: > 1,"a,b",2 > > COPY FROM '/data/a.csv' INTO test (a,b,c) FORMAT CSV; > > The copy command fails because there is a comma in the second field,but this > is a fully legal and compliant CSV format -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-6324) Transactional cache data partially available after crash.
[ https://issues.apache.org/jira/browse/IGNITE-6324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17162508#comment-17162508 ] Aleksey Plekhanov commented on IGNITE-6324: --- Moved to the next release due to inactivity. > Transactional cache data partially available after crash. > - > > Key: IGNITE-6324 > URL: https://issues.apache.org/jira/browse/IGNITE-6324 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 1.9, 2.1 >Reporter: Stanilovsky Evgeny >Priority: Critical > Fix For: 2.9 > > Attachments: InterruptCommitedThreadTest.java > > Time Spent: 10m > Remaining Estimate: 0h > > If InterruptedException raise in client code during pds store operations we > can obtain inconsistent cache after restart. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-6324) Transactional cache data partially available after crash.
[ https://issues.apache.org/jira/browse/IGNITE-6324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-6324: -- Fix Version/s: (was: 2.9) 2.10 > Transactional cache data partially available after crash. > - > > Key: IGNITE-6324 > URL: https://issues.apache.org/jira/browse/IGNITE-6324 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 1.9, 2.1 >Reporter: Stanilovsky Evgeny >Priority: Critical > Fix For: 2.10 > > Attachments: InterruptCommitedThreadTest.java > > Time Spent: 10m > Remaining Estimate: 0h > > If InterruptedException raise in client code during pds store operations we > can obtain inconsistent cache after restart. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10417) notifyDiscoveryListener() call can be lost.
[ https://issues.apache.org/jira/browse/IGNITE-10417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-10417: --- Fix Version/s: (was: 2.9) 2.10 > notifyDiscoveryListener() call can be lost. > --- > > Key: IGNITE-10417 > URL: https://issues.apache.org/jira/browse/IGNITE-10417 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.7 >Reporter: Pavel Voronkin >Assignee: Pavel Voronkin >Priority: Critical > Fix For: 2.10 > > > 1) ServerImpl:5455 notifyDiscoveryListener can not be called in case of > spiState != CONNECTED, for example DISCONNECTING which is valid state > nevetheless inside notifyDiscoveryListener we check spiState == CONNECTED || > spiState == DISCONNECTING, also we need to improve logging in > notifyDiscoveryListener(). > 2) Improve logging on duplicated custom discovery event. > 3) Add assert if msg.creatorNodeId() doesn't exist in topology this is bad > behaviour taht should lead to node fail. > > > > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-3212) Servers get stuck with the warning "Failed to wait for initial partition map exchange" during falover test
[
https://issues.apache.org/jira/browse/IGNITE-3212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-3212:
--
Fix Version/s: (was: 2.9)
2.10
> Servers get stuck with the warning "Failed to wait for initial partition map
> exchange" during falover test
> --
>
> Key: IGNITE-3212
> URL: https://issues.apache.org/jira/browse/IGNITE-3212
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.6
>Reporter: Ksenia Rybakova
>Priority: Critical
> Fix For: 3.0, 2.10
>
>
> Servers being restarted during failover test get stuck after some time with
> the warning "Failed to wait for initial partition map exchange".
> {noformat}
> [08:44:41,303][INFO ][disco-event-worker-#80%null%][GridDiscoveryManager]
> Added new node to topology: TcpDiscoveryNode
> [id=db557f04-43b7-4e28-ae0d-d4dcf4139c89, addrs=
> [10.20.0.222, 127.0.0.1], sockAddrs=[fosters-222/10.20.0.222:47503,
> /10.20.0.222:47503, /127.0.0.1:47503], discPort=47503, order=44, intOrder=32,
> lastExchangeTime=1464
> 363880917, loc=false, ver=1.6.0#20160525-sha1:48321a40, isClient=false]
> [08:44:41,304][INFO ][disco-event-worker-#80%null%][GridDiscoveryManager]
> Topology snapshot [ver=44, servers=19, clients=1, CPUs=64, heap=160.0GB]
> [08:45:11,455][INFO ][disco-event-worker-#80%null%][GridDiscoveryManager]
> Added new node to topology: TcpDiscoveryNode
> [id=6fae61a7-c1c1-40e5-8ad0-8bf5d6c86eb7, addrs=
> [10.20.0.223, 127.0.0.1], sockAddrs=[fosters-223/10.20.0.223:47503,
> /10.20.0.223:47503, /127.0.0.1:47503], discPort=47503, order=45, intOrder=33,
> lastExchangeTime=1464
> 363910999, loc=false, ver=1.6.0#20160525-sha1:48321a40, isClient=false]
> [08:45:11,455][INFO ][disco-event-worker-#80%null%][GridDiscoveryManager]
> Topology snapshot [ver=45, servers=20, clients=1, CPUs=64, heap=170.0GB]
> [08:45:19,942][INFO ][ignite-update-notifier-timer][GridUpdateNotifier]
> Update status is not available.
> [08:46:20,370][WARN ][main][GridCachePartitionExchangeManager] Failed to wait
> for initial partition map exchange. Possible reasons are:
> ^-- Transactions in deadlock.
> ^-- Long running transactions (ignore if this is the case).
> ^-- Unreleased explicit locks.
> [08:48:30,375][WARN ][main][GridCachePartitionExchangeManager] Still waiting
> for initial partition map exchange ...
> {noformat}
> "Failed to wait for partition release future" warnings are on other nodes.
> {noformat}
> [08:09:45,822][WARN
> ][exchange-worker-#82%null%][GridDhtPartitionsExchangeFuture] Failed to wait
> for partition release future [topVer=AffinityTopologyVersion [topVer=29,
> minorTopVer=0], node=cab5d0e0-7365-4774-8f99-d9f131c5d896]. Dumping pending
> objects that might be the cause:
> [08:09:45,822][WARN
> ][exchange-worker-#82%null%][GridCachePartitionExchangeManager] Ready
> affinity version: AffinityTopologyVersion [topVer=28, minorTopVer=1]
> [08:09:45,826][WARN
> ][exchange-worker-#82%null%][GridCachePartitionExchangeManager] Last exchange
> future: GridDhtPartitionsExchangeFuture ...
> {noformat}
> Load config:
> - 1 client, 20 servers (5 servers per 1 host)
> - warmup 60
> - duration 66h
> - preload 5M
> - key range 10M
> - operations: PUT PUT_ALL GET GET_ALL INVOKE INVOKE_ALL REMOVE REMOVE_ALL
> PUT_IF_ABSENT REPLACE
> - backups count 3
> - 3 servers restart every 15 min with 30 sec step, pause between stop and
> start 5min
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-9764) Node may hang on start if cluster state is in transition
[
https://issues.apache.org/jira/browse/IGNITE-9764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-9764:
--
Fix Version/s: (was: 2.9)
2.10
> Node may hang on start if cluster state is in transition
>
>
> Key: IGNITE-9764
> URL: https://issues.apache.org/jira/browse/IGNITE-9764
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexey Goncharuk
>Priority: Critical
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.10
>
> Attachments: JoinNodeToTransitionStateClusterTest.java
>
>
> The following sequence of events may cause node hang on start
> Node starts, detects cluster state transition and waits for it to complete
> {code}
> "start-node-1" #11804 prio=5 os_prio=0 tid=0x7f9cc4022000 nid=0x1094
> waiting on condition [0x7f9ffc4c2000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1084)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2033)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1728)
> - locked <0x9467c890> (a
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1156)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:654)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:917)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:855)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:843)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.startGrid(GridAbstractTest.java:809)
> at
> org.apache.ignite.internal.processors.cache.IgniteClusterActivateDeactivateTest.lambda$testConcurrentJoinAndActivate$4(IgniteClusterActivateDeactivateTest.java:539)
> at
> org.apache.ignite.internal.processors.cache.IgniteClusterActivateDeactivateTest$$Lambda$99/295822519.call(Unknown
> Source)
> at
> org.apache.ignite.testframework.GridTestThread.run(GridTestThread.java:86)
> {code}
> Nio thread that is to process a message that would complete the exchange is
> attempting to create a session and get a local node ID
> {code}
> "grid-nio-worker-tcp-comm-3-#9833%cache.IgniteClusterActivateDeactivateTest3%"
> #11875 prio=5 os_prio=0 tid=0x7f9c8009e800 nid=0x10dc waiting on
> condition [0x7f9ff4d76000]
>java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for (a
> java.util.concurrent.CountDownLatch$Sync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(AbstractQueuedSynchronizer.java:997)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(AbstractQueuedSynchronizer.java:1304)
> at java.util.concurrent.CountDownLatch.await(CountDownLatch.java:231)
> at
> org.apache.ignite.internal.util.IgniteUtils.await(IgniteUtils.java:7577)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.getSpiContext(TcpCommunicationSpi.java:2266)
> at
> org.apache.ignite.spi.IgniteSpiAdapter.getLocalNode(IgniteSpiAdapter.java:156)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.safeLocalNodeId(TcpCommunicationSpi.java:4006)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.nodeIdMessage(TcpCommunicationSpi.java:3999)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi.access$300(TcpCommunicationSpi.java:271)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$2.onConnected(TcpCommunicationSpi.java:412)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onSessionOpened(GridNioFilterChain.java:251)
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedSessionOpened(GridNioFilterAdapter.java:88)
> at
> org.apache.ignite.internal.util.nio.GridNioCodecFilter.onSessionOpened(GridNioCodecFilter.java:67)
> at
[jira] [Updated] (IGNITE-2176) Not valid exceptions in case when example can't works with remote node started with server classpath (Java 8)
[
https://issues.apache.org/jira/browse/IGNITE-2176?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-2176:
--
Fix Version/s: (was: 2.9)
2.10
> Not valid exceptions in case when example can't works with remote node
> started with server classpath (Java 8)
> -
>
> Key: IGNITE-2176
> URL: https://issues.apache.org/jira/browse/IGNITE-2176
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 1.5.0.final, 2.7.5
> Environment: jdk 1.7
> OS X 10.10.2
>Reporter: Ilya Suntsov
>Assignee: Alexey Goncharuk
>Priority: Major
> Fix For: 2.10
>
>
> Steps for reproduce:
> 1. Start one node from IDEA and one more from terminal
> 2. Run StreamVisitorExample (Java 8):
> Exception:
> {noformat}
> Exception in thread "pub-#2%null%" class
> org.apache.ignite.binary.BinaryInvalidTypeException:
> org.apache.ignite.examples.java8.streaming.StreamVisitorExample
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:467)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1330)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1284)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readClass(BinaryReaderExImpl.java:339)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.readFixedType(BinaryFieldAccessor.java:835)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read(BinaryFieldAccessor.java:645)
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:696)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1450)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1646)
> at
> org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read(BinaryFieldAccessor.java:645)
> at
> org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:696)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1450)
> at
> org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:267)
> at
> org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal(BinaryMarshaller.java:112)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.processRequest(DataStreamProcessor.java:271)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor.access$000(DataStreamProcessor.java:49)
> at
> org.apache.ignite.internal.processors.datastreamer.DataStreamProcessor$1.onMessage(DataStreamProcessor.java:76)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:819)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$1600(GridIoManager.java:103)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$5.run(GridIoManager.java:782)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> Caused by: java.lang.ClassNotFoundException:
> org.apache.ignite.examples.java8.streaming.StreamVisitorExample
> at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
> at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:331)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:348)
> at
> org.apache.ignite.internal.util.IgniteUtils.forName(IgniteUtils.java:8172)
> at
> org.apache.ignite.internal.MarshallerContextAdapter.getClass(MarshallerContextAdapter.java:185)
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:458)
> ... 22 more
> {noformat}
> 3. Run StreamTransformerExample (Java 8)
> Exception:
> {noformat}
> Exception in thread "pub-#2%null%" class
> org.apache.ignite.binary.BinaryInvalidTypeException:
> org.apache.ignite.examples.java8.streaming.StreamTransformerExample
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:467)
> at
> org.apache.ignite.internal.binary.BinaryUtils.doReadClass(BinaryUtils.java:1330)
> at
>
[jira] [Updated] (IGNITE-12131) MMAP mode should be disabled by default for WAL manager
[ https://issues.apache.org/jira/browse/IGNITE-12131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-12131: --- Fix Version/s: (was: 2.9) 2.10 > MMAP mode should be disabled by default for WAL manager > --- > > Key: IGNITE-12131 > URL: https://issues.apache.org/jira/browse/IGNITE-12131 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey N. Gura >Assignee: Andrey N. Gura >Priority: Major > Fix For: 2.10 > > Time Spent: 10m > Remaining Estimate: 0h > > MMAP mode has a bunch of problems (see for example > http://www.mapdb.org/blog/mmap_files_alloc_and_jvm_crash/ ) > Users are increasingly stumbling over these issues especially in virtualized > environments. > MMAP should be disabled by default because it requires additional care from > user stand point. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13013) Thick client must not open server sockets when used by serverless functions
[ https://issues.apache.org/jira/browse/IGNITE-13013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-13013: --- Fix Version/s: (was: 2.9) 2.10 > Thick client must not open server sockets when used by serverless functions > --- > > Key: IGNITE-13013 > URL: https://issues.apache.org/jira/browse/IGNITE-13013 > Project: Ignite > Issue Type: Improvement > Components: networking >Affects Versions: 2.8 >Reporter: Denis A. Magda >Assignee: Ivan Bessonov >Priority: Critical > Fix For: 2.10 > > > A thick client fails to start if being used inside of a serverless function > such as AWS Lamda or Azure Functions. Cloud providers prohibit opening > network ports to accept connections on the function's end. In short, the > function can only connect to a remote address. > To reproduce, you can follow this tutorial and swap the thin client (used in > the tutorial) with the thick one: > https://www.gridgain.com/docs/tutorials/serverless/azure_functions_tutorial > The thick client needs to support a mode when the communication SPI doesn't > create a server socket if the client is used for serverless computing. This > improvement looks like an extra task of this initiative: > https://issues.apache.org/jira/browse/IGNITE-12438 -- This message was sent by Atlassian Jira (v8.3.4#803005)
