[jira] [Commented] (IGNITE-12827) OutOfMemory exception when calling grid service from .NET with user type array parameter
[
https://issues.apache.org/jira/browse/IGNITE-12827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102199#comment-17102199
]
Ignite TC Bot commented on IGNITE-12827:
{panel:title=Branch: [pull/7679/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 5{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5289336]]
* IgniteCacheTestSuite5:
CacheSerializableTransactionsTest.testConflictResolution - Test has low fail
rate in base branch 0,0% and is not flaky
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5287831buildTypeId=IgniteTests24Java8_RunAll]
> OutOfMemory exception when calling grid service from .NET with user type
> array parameter
>
>
> Key: IGNITE-12827
> URL: https://issues.apache.org/jira/browse/IGNITE-12827
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: sbcf
> Fix For: 2.9
>
> Attachments: ignite-12827-vs-2.8.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Calling a grid service from .NET with a parameter of user type array leads to
> Java OutOfMemory exception.
> +*Reproducer*+:
> * Limit JVM heap with 128 MB.
> * Create a .NET or Java service with a parameter of type
> *array of* Parameter {
> Id: int,
> *array of* ParameterValue {
> PeriodId: int,
> Value: double?
> }
> }
> * Call service with an array of 200 Parameters
> +*Expected*+:
> 128 MB of heap must be enough to call Java or .NET service with 200
> Parameters.
>
> +*Actual*+:
> Java OutOfMemory exception on 21st Parameter
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12932) Thin client cluster discovery
[
https://issues.apache.org/jira/browse/IGNITE-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102167#comment-17102167
]
Ignite TC Bot commented on IGNITE-12932:
{panel:title=Branch: [pull/7744/head] Base: [master] : Possible Blockers
(9)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}MVCC Cache 7{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5289583]]
{color:#d04437}PDS (Indexing){color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5289557]]
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5289516]]
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoveryCommunicationFailureTest.testCommunicationFailureResolve_KillCoordinator_5
- Test has low fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoveryCommunicationFailureTest.testNoOpCommunicationErrorResolve_5
- Test has low fail rate in base branch 1,3% and is not flaky
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoveryCommunicationFailureTest.testNoOpCommunicationErrorResolve_4
- Test has low fail rate in base branch 0,0% and is not flaky
* ZookeeperDiscoverySpiTestSuite1:
ZookeeperDiscoveryClientDisconnectTest.testConnectionCheck - Test has low fail
rate in base branch 0,0% and is not flaky
{color:#d04437}MVCC Cache 1{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5289577]]
{color:#d04437}Data Structures{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5289554]]
* IgniteCacheDataStructuresSelfTestSuite:
GridCachePartitionedQueueEntryMoveSelfTest.testQueue - Test has low fail rate
in base branch 0,0% and is not flaky
{color:#d04437}Cache 1{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5289542]]
* IgniteBinaryCacheTestSuite:
DataStreamProcessorPersistenceBinarySelfTest.testTryFlush - Test has low fail
rate in base branch 1,3% and is not flaky
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5289593buildTypeId=IgniteTests24Java8_RunAll]
> Thin client cluster discovery
> -
>
> Key: IGNITE-12932
> URL: https://issues.apache.org/jira/browse/IGNITE-12932
> Project: Ignite
> Issue Type: New Feature
> Components: thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Fix For: 2.9
>
> Original Estimate: 336h
> Time Spent: 10m
> Remaining Estimate: 4h
>
> Thin clients should be able to discover all server nodes automatically when
> connected to any of them, and maintain an up to date list of servers at all
> times.
> See
> [IEP-44|https://cwiki.apache.org/confluence/display/IGNITE/IEP-44%3A+Thin+client+cluster+discovery]
> for more details.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12982) NullPointerException on TcpCommunicationMetricsListener for some of the cases
[
https://issues.apache.org/jira/browse/IGNITE-12982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102136#comment-17102136
]
Andrey N. Gura commented on IGNITE-12982:
-
[~mmuzaf] We never assign {{null}} to the {{metricsLsnr}} field, so it is just
impossible that node worked correctly and problem arrives on shutdown only.
I see a race between {{onMessageSent}} method invocation from NIO thread (NIO
server is already started at this moment in {{spiStart}} method) and
{{metricsLsnr}} field initialization (see
{{TcpCommunicationSpi.onContextInitialization0}} method). But it should be
checked.
Please, share your findings if you'll investigate this. It could be tricky to
solve all possible problems here.
> NullPointerException on TcpCommunicationMetricsListener for some of the cases
> -
>
> Key: IGNITE-12982
> URL: https://issues.apache.org/jira/browse/IGNITE-12982
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Priority: Major
> Fix For: 2.9
>
>
> The code block below throws an {{NullPointerException}} for some of the
> cases. Investigation required.
> {code}
> @Override public void onMessageSent(GridNioSession ses, Message
> msg) {
> Object consistentId = ses.meta(CONSISTENT_ID_META);
> if (consistentId != null)
> metricsLsnr.onMessageSent(msg, consistentId);
> }
> {code}
> {code}
> [2020-05-04
> 18:12:12,991][ERROR][grid-nio-worker-tcp-comm-0-#543%snapshot.IgniteClusterSnapshotSelfTest2%][TestRecordingCommunicationSpi]
> Failed to process selector key [ses=GridSelectorNioSessionImpl
> [worker=DirectNioClientWorker [super=AbstractNioClientWorker [idx=0,
> bytesRcvd=42, bytesSent=18, bytesRcvd0=42, bytesSent0=18, select=true,
> super=GridWorker [name=grid-nio-worker-tcp-comm-0,
> igniteInstanceName=snapshot.IgniteClusterSnapshotSelfTest2, finished=false,
> heartbeatTs=1588605131981, hashCode=1038334332, interrupted=false,
> runner=grid-nio-worker-tcp-comm-0-#543%snapshot.IgniteClusterSnapshotSelfTest2%]]],
> writeBuf=java.nio.DirectByteBuffer[pos=10 lim=32768 cap=32768],
> readBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
> inRecovery=GridNioRecoveryDescriptor [acked=0, resendCnt=0, rcvCnt=0,
> sentCnt=0, reserved=true, lastAck=0, nodeLeft=false, node=TcpDiscoveryNode
> [id=7f78d082-6ce9-42b1-ab08-da1fde40,
> consistentId=snapshot.IgniteClusterSnapshotSelfTest0, addrs=ArrayList
> [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47500], discPort=47500, order=1,
> intOrder=1, lastExchangeTime=1588605131971, loc=false,
> ver=2.9.0#20200428-sha1:e551fa71, isClient=false], connected=true,
> connectCnt=0, queueLimit=4096, reserveCnt=1, pairedConnections=false],
> outRecovery=GridNioRecoveryDescriptor [acked=0, resendCnt=0, rcvCnt=0,
> sentCnt=0, reserved=true, lastAck=0, nodeLeft=false, node=TcpDiscoveryNode
> [id=7f78d082-6ce9-42b1-ab08-da1fde40,
> consistentId=snapshot.IgniteClusterSnapshotSelfTest0, addrs=ArrayList
> [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47500], discPort=47500, order=1,
> intOrder=1, lastExchangeTime=1588605131971, loc=false,
> ver=2.9.0#20200428-sha1:e551fa71, isClient=false], connected=true,
> connectCnt=0, queueLimit=4096, reserveCnt=1, pairedConnections=false],
> closeSocket=true,
> outboundMessagesQueueSizeMetric=o.a.i.i.processors.metric.impl.LongAdderMetric@69a257d1,
> super=GridNioSessionImpl [locAddr=/127.0.0.1:47102,
> rmtAddr=/127.0.0.1:50655, createTime=1588605131981, closeTime=0,
> bytesSent=18, bytesRcvd=42, bytesSent0=18, bytesRcvd0=42,
> sndSchedTime=1588605131981, lastSndTime=1588605131981,
> lastRcvTime=1588605131981, readsPaused=false,
> filterChain=FilterChain[filters=[GridNioCodecFilter
> [parser=o.a.i.i.util.nio.GridDirectParser@fc19b0b, directMode=true],
> GridConnectionBytesVerifyFilter], accepted=true, markedForClose=true]]]
> java.lang.NullPointerException
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$1.onMessageSent(TcpCommunicationSpi.java:803)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$1.onMessageSent(TcpCommunicationSpi.java:472)
> at
> org.apache.ignite.internal.util.nio.GridNioServer.onMessageWritten(GridNioServer.java:1764)
> at
> org.apache.ignite.internal.util.nio.GridNioServer.access$1800(GridNioServer.java:99)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processWrite0(GridNioServer.java:1665)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processWrite(GridNioServer.java:1365)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2437)
[jira] [Issue Comment Deleted] (IGNITE-12932) Thin client cluster discovery
[
https://issues.apache.org/jira/browse/IGNITE-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-12932:
Comment: was deleted
(was: {panel:title=Branch: [pull/7744/head] Base: [master] : Possible Blockers
(11)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Long Running){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5285574]]
* exe:
5,2).TestWithExpiryPolicyThrowCorrectExceptionOnVersionsOlderThan150 -
Test has low fail rate in base branch 0,0% and is not flaky
* exe:
6,2).TestWithExpiryPolicyThrowCorrectExceptionOnVersionsOlderThan150 -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Platform .NET (NuGet)*{color} [[tests 0 Exit Code , Compilation
Error |https://ci.ignite.apache.org/viewLog.html?buildId=5285575]]
{color:#d04437}Platform .NET (Inspections)*{color} [[tests 0 Failure on metric
|https://ci.ignite.apache.org/viewLog.html?buildId=5285572]]
{color:#d04437}Platform .NET{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=5285570]]
* exe:
ClientClusterDiscoveryTests.TestPartitionAwarenessRoutesRequestsToNewlyJoinedNodes
- History for base branch is absent.
* exe:
ClientClusterDiscoveryTests.TestPartitionAwarenessRoutesRequestsToNewlyJoinedNodes
- History for base branch is absent.
* exe:
PartitionAwarenessTest.CacheGet_NewNodeEnteredTopology_RequestIsRoutedToNewNode
- History for base branch is absent.
{color:#d04437}Cache 2{color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5285550]]
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5285571]]
{color:#d04437}Thin client: PHP{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5285535]]
{color:#d04437}PDS (Compatibility)*{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5285563]]
* IgniteCompatibilityBasicTestSuite:
FoldersReuseCompatibilityTest.testFoldersReuseCompatibility_2_2 - Test has low
fail rate in base branch 1,3% and is not flaky
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5285600buildTypeId=IgniteTests24Java8_RunAll])
> Thin client cluster discovery
> -
>
> Key: IGNITE-12932
> URL: https://issues.apache.org/jira/browse/IGNITE-12932
> Project: Ignite
> Issue Type: New Feature
> Components: thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Fix For: 2.9
>
> Original Estimate: 336h
> Time Spent: 10m
> Remaining Estimate: 4h
>
> Thin clients should be able to discover all server nodes automatically when
> connected to any of them, and maintain an up to date list of servers at all
> times.
> See
> [IEP-44|https://cwiki.apache.org/confluence/display/IGNITE/IEP-44%3A+Thin+client+cluster+discovery]
> for more details.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-12932) Thin client cluster discovery
[
https://issues.apache.org/jira/browse/IGNITE-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-12932:
Comment: was deleted
(was: {panel:title=Branch: [pull/7744/head] Base: [master] : Possible Blockers
(15)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5288611]]
{color:#d04437}Cache 7{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5288602]]
* IgniteCacheTestSuite7:
CacheRentingStateRepairTest.testRentingStateRepairAfterRestart - Test has low
fail rate in base branch 0,0% and is not flaky
{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5288571]]
* ZookeeperDiscoverySpiTestSuite2:
GridCommandHandlerTest.testCacheIdleVerifyPrintLostPartitions - Test has low
fail rate in base branch 0,0% and is not flaky
{color:#d04437}Platform .NET{color} [[tests
8|https://ci.ignite.apache.org/viewLog.html?buildId=5288617]]
* exe:
ClientClusterDiscoveryTestsBase.TestClientDiscoversJoinedServersAndRemovesDisconnected
- History for base branch is absent.
* exe:
ClientClusterDiscoveryTestsBase.TestClientWithOneEndpointDiscoversAllServers -
History for base branch is absent.
* exe:
ClientClusterDiscoveryTestsBase.TestClientDiscoversJoinedServersAndRemovesDisconnected
- History for base branch is absent.
* exe:
ClientClusterDiscoveryTests.TestPartitionAwarenessRoutesRequestsToNewlyJoinedNodes
- History for base branch is absent.
* exe:
ClientClusterDiscoveryTests.TestThinClientDoesNotDiscoverThickClientNodes -
History for base branch is absent.
* exe:
ClientClusterDiscoveryTests.TestClientMaintainsConnectionWhenOriginalNodeLeaves
- History for base branch is absent.
* exe: ClientClusterDiscoveryTests.TestDiscoveryWithoutClientConnectorOnServer
- History for base branch is absent.
* exe: ClientClusterDiscoveryTests.TestClientDiscoveryWithRandomTopologyChanges
- History for base branch is absent.
{color:#d04437}Data Structures{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5288608]]
* IgniteCacheDataStructuresSelfTestSuite:
ReplicatedImplicitTransactionalReadRepairTest.test[getEntry=true, async=true] -
Test has low fail rate in base branch 0,0% and is not flaky
* IgniteCacheDataStructuresSelfTestSuite:
ReplicatedImplicitTransactionalReadRepairTest.test[getEntry=false, async=false]
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteCacheDataStructuresSelfTestSuite:
ReplicatedImplicitTransactionalReadRepairTest.test[getEntry=false, async=true]
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteCacheDataStructuresSelfTestSuite:
ReplicatedImplicitTransactionalReadRepairTest.test[getEntry=true, async=false]
- Test has low fail rate in base branch 0,0% and is not flaky
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5288647buildTypeId=IgniteTests24Java8_RunAll])
> Thin client cluster discovery
> -
>
> Key: IGNITE-12932
> URL: https://issues.apache.org/jira/browse/IGNITE-12932
> Project: Ignite
> Issue Type: New Feature
> Components: thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Fix For: 2.9
>
> Original Estimate: 336h
> Time Spent: 10m
> Remaining Estimate: 4h
>
> Thin clients should be able to discover all server nodes automatically when
> connected to any of them, and maintain an up to date list of servers at all
> times.
> See
> [IEP-44|https://cwiki.apache.org/confluence/display/IGNITE/IEP-44%3A+Thin+client+cluster+discovery]
> for more details.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-12932) Thin client cluster discovery
[
https://issues.apache.org/jira/browse/IGNITE-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-12932:
Comment: was deleted
(was: {panel:title=Branch: [pull/7744/head] Base: [master] : Possible Blockers
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 7{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5286384]]
* IgniteCacheWithIndexingAndPersistenceTestSuite:
GridCommandHandlerIndexingClusterByClassWithSSLTest.testValidateIndexesNoErrors
- Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests 0 Out Of Memory Error
|https://ci.ignite.apache.org/viewLog.html?buildId=5286353]]
{color:#d04437}ZooKeeper (Discovery) 4{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5286408]]
* ZookeeperDiscoverySpiTestSuite4:
DistributedMetaStoragePersistentTest.testInactiveClusterWrite - Test has low
fail rate in base branch 0,0% and is not flaky
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0 Exit Code ,
TC_SERVICE_MESSAGE |https://ci.ignite.apache.org/viewLog.html?buildId=5286400]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5286429buildTypeId=IgniteTests24Java8_RunAll])
> Thin client cluster discovery
> -
>
> Key: IGNITE-12932
> URL: https://issues.apache.org/jira/browse/IGNITE-12932
> Project: Ignite
> Issue Type: New Feature
> Components: thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Fix For: 2.9
>
> Original Estimate: 336h
> Time Spent: 10m
> Remaining Estimate: 4h
>
> Thin clients should be able to discover all server nodes automatically when
> connected to any of them, and maintain an up to date list of servers at all
> times.
> See
> [IEP-44|https://cwiki.apache.org/confluence/display/IGNITE/IEP-44%3A+Thin+client+cluster+discovery]
> for more details.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12932) Thin client cluster discovery
[
https://issues.apache.org/jira/browse/IGNITE-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17102020#comment-17102020
]
Ignite TC Bot commented on IGNITE-12932:
{panel:title=Branch: [pull/7744/head] Base: [master] : Possible Blockers
(15)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5288611]]
{color:#d04437}Cache 7{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5288602]]
* IgniteCacheTestSuite7:
CacheRentingStateRepairTest.testRentingStateRepairAfterRestart - Test has low
fail rate in base branch 0,0% and is not flaky
{color:#d04437}ZooKeeper (Discovery) 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5288571]]
* ZookeeperDiscoverySpiTestSuite2:
GridCommandHandlerTest.testCacheIdleVerifyPrintLostPartitions - Test has low
fail rate in base branch 0,0% and is not flaky
{color:#d04437}Platform .NET{color} [[tests
8|https://ci.ignite.apache.org/viewLog.html?buildId=5288617]]
* exe:
ClientClusterDiscoveryTestsBase.TestClientDiscoversJoinedServersAndRemovesDisconnected
- History for base branch is absent.
* exe:
ClientClusterDiscoveryTestsBase.TestClientWithOneEndpointDiscoversAllServers -
History for base branch is absent.
* exe:
ClientClusterDiscoveryTestsBase.TestClientDiscoversJoinedServersAndRemovesDisconnected
- History for base branch is absent.
* exe:
ClientClusterDiscoveryTests.TestPartitionAwarenessRoutesRequestsToNewlyJoinedNodes
- History for base branch is absent.
* exe:
ClientClusterDiscoveryTests.TestThinClientDoesNotDiscoverThickClientNodes -
History for base branch is absent.
* exe:
ClientClusterDiscoveryTests.TestClientMaintainsConnectionWhenOriginalNodeLeaves
- History for base branch is absent.
* exe: ClientClusterDiscoveryTests.TestDiscoveryWithoutClientConnectorOnServer
- History for base branch is absent.
* exe: ClientClusterDiscoveryTests.TestClientDiscoveryWithRandomTopologyChanges
- History for base branch is absent.
{color:#d04437}Data Structures{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5288608]]
* IgniteCacheDataStructuresSelfTestSuite:
ReplicatedImplicitTransactionalReadRepairTest.test[getEntry=true, async=true] -
Test has low fail rate in base branch 0,0% and is not flaky
* IgniteCacheDataStructuresSelfTestSuite:
ReplicatedImplicitTransactionalReadRepairTest.test[getEntry=false, async=false]
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteCacheDataStructuresSelfTestSuite:
ReplicatedImplicitTransactionalReadRepairTest.test[getEntry=false, async=true]
- Test has low fail rate in base branch 0,0% and is not flaky
* IgniteCacheDataStructuresSelfTestSuite:
ReplicatedImplicitTransactionalReadRepairTest.test[getEntry=true, async=false]
- Test has low fail rate in base branch 0,0% and is not flaky
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5288647buildTypeId=IgniteTests24Java8_RunAll]
> Thin client cluster discovery
> -
>
> Key: IGNITE-12932
> URL: https://issues.apache.org/jira/browse/IGNITE-12932
> Project: Ignite
> Issue Type: New Feature
> Components: thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Fix For: 2.9
>
> Original Estimate: 336h
> Time Spent: 10m
> Remaining Estimate: 4h
>
> Thin clients should be able to discover all server nodes automatically when
> connected to any of them, and maintain an up to date list of servers at all
> times.
> See
> [IEP-44|https://cwiki.apache.org/confluence/display/IGNITE/IEP-44%3A+Thin+client+cluster+discovery]
> for more details.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12991) Calcite integration. Pass cancel flag to VolcanoPlanner
Igor Seliverstov created IGNITE-12991:
-
Summary: Calcite integration. Pass cancel flag to VolcanoPlanner
Key: IGNITE-12991
URL: https://issues.apache.org/jira/browse/IGNITE-12991
Project: Ignite
Issue Type: Improvement
Reporter: Igor Seliverstov
see {{AbstractRelOptPlanner.java:91}}, here {{CancelFlag}} is used to cancel
planning loop. We need to pass it into a newly created context and bind its
state with {{PlanningContext#queryCancel}} to break possible infinite planning
loop. See also {{PlanningContext#unwrap}}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12942) control.sh add command for checking that inline size is same on all cluster nodes
[ https://issues.apache.org/jira/browse/IGNITE-12942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101948#comment-17101948 ] Ivan Rakov commented on IGNITE-12942: - [~antonovsergey93] Thanks for your contribution. Merged to master. > control.sh add command for checking that inline size is same on all cluster > nodes > - > > Key: IGNITE-12942 > URL: https://issues.apache.org/jira/browse/IGNITE-12942 > Project: Ignite > Issue Type: New Feature >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > We should check that the inline size is the same for the index on all nodes > in the cluster. > 1. Check inline_size of secondary indexes on node join. Warn to log if they > differ and propose a recreate problem index. > 2. Introduce a new command to control.sh (control.sh --cache > check_index_inline_sizes). The command will check inline sizes of secondary > indexes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12985) Fix unguarded log.info/log.debug/log.trace usages
[
https://issues.apache.org/jira/browse/IGNITE-12985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Goncharuk updated IGNITE-12985:
--
Fix Version/s: 2.9
> Fix unguarded log.info/log.debug/log.trace usages
> -
>
> Key: IGNITE-12985
> URL: https://issues.apache.org/jira/browse/IGNITE-12985
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are multiple places in code where
> {{log.info()/log.debug()/log.trace()}} are called without checking {{if
> (log.isInfoEnabled)}}. These leads to polluted logs when INFO/DEBUG/TRACE is
> disabled.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12932) Thin client cluster discovery
[ https://issues.apache.org/jira/browse/IGNITE-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-12932: Remaining Estimate: 4h (was: 48h) > Thin client cluster discovery > - > > Key: IGNITE-12932 > URL: https://issues.apache.org/jira/browse/IGNITE-12932 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Fix For: 2.9 > > Original Estimate: 336h > Time Spent: 10m > Remaining Estimate: 4h > > Thin clients should be able to discover all server nodes automatically when > connected to any of them, and maintain an up to date list of servers at all > times. > See > [IEP-44|https://cwiki.apache.org/confluence/display/IGNITE/IEP-44%3A+Thin+client+cluster+discovery] > for more details. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12932) Thin client cluster discovery
[ https://issues.apache.org/jira/browse/IGNITE-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-12932: Remaining Estimate: 48h (was: 335h 50m) > Thin client cluster discovery > - > > Key: IGNITE-12932 > URL: https://issues.apache.org/jira/browse/IGNITE-12932 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Fix For: 2.9 > > Original Estimate: 336h > Time Spent: 10m > Remaining Estimate: 48h > > Thin clients should be able to discover all server nodes automatically when > connected to any of them, and maintain an up to date list of servers at all > times. > See > [IEP-44|https://cwiki.apache.org/confluence/display/IGNITE/IEP-44%3A+Thin+client+cluster+discovery] > for more details. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12932) Thin client cluster discovery
[ https://issues.apache.org/jira/browse/IGNITE-12932?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101772#comment-17101772 ] Pavel Tupitsyn commented on IGNITE-12932: - [~isapego] [~ashapkin] PR ready, please have a look. > Thin client cluster discovery > - > > Key: IGNITE-12932 > URL: https://issues.apache.org/jira/browse/IGNITE-12932 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Fix For: 2.9 > > Original Estimate: 336h > Time Spent: 10m > Remaining Estimate: 335h 50m > > Thin clients should be able to discover all server nodes automatically when > connected to any of them, and maintain an up to date list of servers at all > times. > See > [IEP-44|https://cwiki.apache.org/confluence/display/IGNITE/IEP-44%3A+Thin+client+cluster+discovery] > for more details. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12983) Logging exceptions inside IgniteSecurityProcessor#withContext(java.util.UUID)
[ https://issues.apache.org/jira/browse/IGNITE-12983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101717#comment-17101717 ] Nikolay Izhikov commented on IGNITE-12983: -- Merged to master. Cherry-picked to 2.8.1 [~garus.d.g] Thanks for the contribution. > Logging exceptions inside IgniteSecurityProcessor#withContext(java.util.UUID) > - > > Key: IGNITE-12983 > URL: https://issues.apache.org/jira/browse/IGNITE-12983 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Fix For: 2.9, 2.8.1 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > We should write down to log all exception inside > IgniteSecurityProcessor#withContext(java.util.UUID). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12983) Logging exceptions inside IgniteSecurityProcessor#withContext(java.util.UUID)
[ https://issues.apache.org/jira/browse/IGNITE-12983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov updated IGNITE-12983: - Fix Version/s: 2.8.1 > Logging exceptions inside IgniteSecurityProcessor#withContext(java.util.UUID) > - > > Key: IGNITE-12983 > URL: https://issues.apache.org/jira/browse/IGNITE-12983 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Fix For: 2.9, 2.8.1 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > We should write down to log all exception inside > IgniteSecurityProcessor#withContext(java.util.UUID). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12765) Slim binary release and docker image for Apache Ignite
[
https://issues.apache.org/jira/browse/IGNITE-12765?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101689#comment-17101689
]
Ilya Kasnacheev commented on IGNITE-12765:
--
We will need to build it as a separate phase on TeamCity. It's not hard to
configure, I will do that once it is merged.
One -Dignite.edition per deliverable.
> Slim binary release and docker image for Apache Ignite
> --
>
> Key: IGNITE-12765
> URL: https://issues.apache.org/jira/browse/IGNITE-12765
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Ilya Kasnacheev
>Priority: Blocker
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 1. Prepare Apache Ignite "slim" distribution (example:
> https://github.com/apache/ignite/tree/ignite-slim)
> 2. Update configuration and check Apache Ignite RELEASE TeamCity Suite
> according to a new additional package distribution.
> See - discussion on dev-list
> http://apache-ignite-developers.2346864.n4.nabble.com/Slim-binary-release-and-docker-image-for-Apache-Ignite-td45110.html
> {code}
> libs:
> core/shmem/jcache
> ignite-indexing
> ignite-spring
> libs/optional:
> ignite-compress
> ignite-rest-http
> ignite-spring-data_2.2
> ignite-log4j2
> ignite-log4j
> ignite-slf4j
> ignite-opencensus
> ignite-kubernetes
> ignite-urideploy
> ignite-jta
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12982) NullPointerException on TcpCommunicationMetricsListener for some of the cases
[
https://issues.apache.org/jira/browse/IGNITE-12982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101629#comment-17101629
]
Maxim Muzafarov commented on IGNITE-12982:
--
[~agura]
Actually I have no reproducer for this issue. It happens from time to time on a
cluster shutdown.
> NullPointerException on TcpCommunicationMetricsListener for some of the cases
> -
>
> Key: IGNITE-12982
> URL: https://issues.apache.org/jira/browse/IGNITE-12982
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Priority: Major
> Fix For: 2.9
>
>
> The code block below throws an {{NullPointerException}} for some of the
> cases. Investigation required.
> {code}
> @Override public void onMessageSent(GridNioSession ses, Message
> msg) {
> Object consistentId = ses.meta(CONSISTENT_ID_META);
> if (consistentId != null)
> metricsLsnr.onMessageSent(msg, consistentId);
> }
> {code}
> {code}
> [2020-05-04
> 18:12:12,991][ERROR][grid-nio-worker-tcp-comm-0-#543%snapshot.IgniteClusterSnapshotSelfTest2%][TestRecordingCommunicationSpi]
> Failed to process selector key [ses=GridSelectorNioSessionImpl
> [worker=DirectNioClientWorker [super=AbstractNioClientWorker [idx=0,
> bytesRcvd=42, bytesSent=18, bytesRcvd0=42, bytesSent0=18, select=true,
> super=GridWorker [name=grid-nio-worker-tcp-comm-0,
> igniteInstanceName=snapshot.IgniteClusterSnapshotSelfTest2, finished=false,
> heartbeatTs=1588605131981, hashCode=1038334332, interrupted=false,
> runner=grid-nio-worker-tcp-comm-0-#543%snapshot.IgniteClusterSnapshotSelfTest2%]]],
> writeBuf=java.nio.DirectByteBuffer[pos=10 lim=32768 cap=32768],
> readBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
> inRecovery=GridNioRecoveryDescriptor [acked=0, resendCnt=0, rcvCnt=0,
> sentCnt=0, reserved=true, lastAck=0, nodeLeft=false, node=TcpDiscoveryNode
> [id=7f78d082-6ce9-42b1-ab08-da1fde40,
> consistentId=snapshot.IgniteClusterSnapshotSelfTest0, addrs=ArrayList
> [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47500], discPort=47500, order=1,
> intOrder=1, lastExchangeTime=1588605131971, loc=false,
> ver=2.9.0#20200428-sha1:e551fa71, isClient=false], connected=true,
> connectCnt=0, queueLimit=4096, reserveCnt=1, pairedConnections=false],
> outRecovery=GridNioRecoveryDescriptor [acked=0, resendCnt=0, rcvCnt=0,
> sentCnt=0, reserved=true, lastAck=0, nodeLeft=false, node=TcpDiscoveryNode
> [id=7f78d082-6ce9-42b1-ab08-da1fde40,
> consistentId=snapshot.IgniteClusterSnapshotSelfTest0, addrs=ArrayList
> [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47500], discPort=47500, order=1,
> intOrder=1, lastExchangeTime=1588605131971, loc=false,
> ver=2.9.0#20200428-sha1:e551fa71, isClient=false], connected=true,
> connectCnt=0, queueLimit=4096, reserveCnt=1, pairedConnections=false],
> closeSocket=true,
> outboundMessagesQueueSizeMetric=o.a.i.i.processors.metric.impl.LongAdderMetric@69a257d1,
> super=GridNioSessionImpl [locAddr=/127.0.0.1:47102,
> rmtAddr=/127.0.0.1:50655, createTime=1588605131981, closeTime=0,
> bytesSent=18, bytesRcvd=42, bytesSent0=18, bytesRcvd0=42,
> sndSchedTime=1588605131981, lastSndTime=1588605131981,
> lastRcvTime=1588605131981, readsPaused=false,
> filterChain=FilterChain[filters=[GridNioCodecFilter
> [parser=o.a.i.i.util.nio.GridDirectParser@fc19b0b, directMode=true],
> GridConnectionBytesVerifyFilter], accepted=true, markedForClose=true]]]
> java.lang.NullPointerException
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$1.onMessageSent(TcpCommunicationSpi.java:803)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$1.onMessageSent(TcpCommunicationSpi.java:472)
> at
> org.apache.ignite.internal.util.nio.GridNioServer.onMessageWritten(GridNioServer.java:1764)
> at
> org.apache.ignite.internal.util.nio.GridNioServer.access$1800(GridNioServer.java:99)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processWrite0(GridNioServer.java:1665)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processWrite(GridNioServer.java:1365)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2437)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2201)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1842)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> [2020-05-04
>
[jira] [Commented] (IGNITE-12982) NullPointerException on TcpCommunicationMetricsListener for some of the cases
[
https://issues.apache.org/jira/browse/IGNITE-12982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101623#comment-17101623
]
Andrey N. Gura commented on IGNITE-12982:
-
[~mmuzaf] It seems that I already saw something similar. How did you reproduce
this NPE?
> NullPointerException on TcpCommunicationMetricsListener for some of the cases
> -
>
> Key: IGNITE-12982
> URL: https://issues.apache.org/jira/browse/IGNITE-12982
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Priority: Major
> Fix For: 2.9
>
>
> The code block below throws an {{NullPointerException}} for some of the
> cases. Investigation required.
> {code}
> @Override public void onMessageSent(GridNioSession ses, Message
> msg) {
> Object consistentId = ses.meta(CONSISTENT_ID_META);
> if (consistentId != null)
> metricsLsnr.onMessageSent(msg, consistentId);
> }
> {code}
> {code}
> [2020-05-04
> 18:12:12,991][ERROR][grid-nio-worker-tcp-comm-0-#543%snapshot.IgniteClusterSnapshotSelfTest2%][TestRecordingCommunicationSpi]
> Failed to process selector key [ses=GridSelectorNioSessionImpl
> [worker=DirectNioClientWorker [super=AbstractNioClientWorker [idx=0,
> bytesRcvd=42, bytesSent=18, bytesRcvd0=42, bytesSent0=18, select=true,
> super=GridWorker [name=grid-nio-worker-tcp-comm-0,
> igniteInstanceName=snapshot.IgniteClusterSnapshotSelfTest2, finished=false,
> heartbeatTs=1588605131981, hashCode=1038334332, interrupted=false,
> runner=grid-nio-worker-tcp-comm-0-#543%snapshot.IgniteClusterSnapshotSelfTest2%]]],
> writeBuf=java.nio.DirectByteBuffer[pos=10 lim=32768 cap=32768],
> readBuf=java.nio.DirectByteBuffer[pos=0 lim=32768 cap=32768],
> inRecovery=GridNioRecoveryDescriptor [acked=0, resendCnt=0, rcvCnt=0,
> sentCnt=0, reserved=true, lastAck=0, nodeLeft=false, node=TcpDiscoveryNode
> [id=7f78d082-6ce9-42b1-ab08-da1fde40,
> consistentId=snapshot.IgniteClusterSnapshotSelfTest0, addrs=ArrayList
> [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47500], discPort=47500, order=1,
> intOrder=1, lastExchangeTime=1588605131971, loc=false,
> ver=2.9.0#20200428-sha1:e551fa71, isClient=false], connected=true,
> connectCnt=0, queueLimit=4096, reserveCnt=1, pairedConnections=false],
> outRecovery=GridNioRecoveryDescriptor [acked=0, resendCnt=0, rcvCnt=0,
> sentCnt=0, reserved=true, lastAck=0, nodeLeft=false, node=TcpDiscoveryNode
> [id=7f78d082-6ce9-42b1-ab08-da1fde40,
> consistentId=snapshot.IgniteClusterSnapshotSelfTest0, addrs=ArrayList
> [127.0.0.1], sockAddrs=HashSet [/127.0.0.1:47500], discPort=47500, order=1,
> intOrder=1, lastExchangeTime=1588605131971, loc=false,
> ver=2.9.0#20200428-sha1:e551fa71, isClient=false], connected=true,
> connectCnt=0, queueLimit=4096, reserveCnt=1, pairedConnections=false],
> closeSocket=true,
> outboundMessagesQueueSizeMetric=o.a.i.i.processors.metric.impl.LongAdderMetric@69a257d1,
> super=GridNioSessionImpl [locAddr=/127.0.0.1:47102,
> rmtAddr=/127.0.0.1:50655, createTime=1588605131981, closeTime=0,
> bytesSent=18, bytesRcvd=42, bytesSent0=18, bytesRcvd0=42,
> sndSchedTime=1588605131981, lastSndTime=1588605131981,
> lastRcvTime=1588605131981, readsPaused=false,
> filterChain=FilterChain[filters=[GridNioCodecFilter
> [parser=o.a.i.i.util.nio.GridDirectParser@fc19b0b, directMode=true],
> GridConnectionBytesVerifyFilter], accepted=true, markedForClose=true]]]
> java.lang.NullPointerException
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$1.onMessageSent(TcpCommunicationSpi.java:803)
> at
> org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi$1.onMessageSent(TcpCommunicationSpi.java:472)
> at
> org.apache.ignite.internal.util.nio.GridNioServer.onMessageWritten(GridNioServer.java:1764)
> at
> org.apache.ignite.internal.util.nio.GridNioServer.access$1800(GridNioServer.java:99)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processWrite0(GridNioServer.java:1665)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$DirectNioClientWorker.processWrite(GridNioServer.java:1365)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.processSelectedKeysOptimized(GridNioServer.java:2437)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.bodyInternal(GridNioServer.java:2201)
> at
> org.apache.ignite.internal.util.nio.GridNioServer$AbstractNioClientWorker.body(GridNioServer.java:1842)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
> at java.lang.Thread.run(Thread.java:748)
> [2020-05-04
>
[jira] [Updated] (IGNITE-12617) PME-free switch should wait for recovery only at affected nodes.
[
https://issues.apache.org/jira/browse/IGNITE-12617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Scherbakov updated IGNITE-12617:
---
Reviewer: Alexey Scherbakov
> PME-free switch should wait for recovery only at affected nodes.
>
>
> Key: IGNITE-12617
> URL: https://issues.apache.org/jira/browse/IGNITE-12617
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-45
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Since IGNITE-9913, new-topology operations allowed immediately after
> cluster-wide recovery finished.
> But is there any reason to wait for a cluster-wide recovery if only one node
> failed?
> In this case, we should recover only the failed node's backups.
> Unfortunately, {{RendezvousAffinityFunction}} tends to spread the node's
> backup partitions to the whole cluster. In this case, we, obviously, have to
> wait for cluster-wide recovery on switch.
> But what if only some nodes will be the backups for every primary?
> In case nodes combined into virtual cells where, for each partition, backups
> located at the same cell with primaries, it's possible to finish the switch
> outside the affected cell before tx recovery finish.
> This optimization will allow us to start and even finish new operations
> outside the failed cell without a cluster-wide switch finish (broken cell
> recovery) waiting.
> In other words, switch (when left/fail + baseline + rebalanced) will have
> little effect on the operation's (not related to failed cell) latency.
> In other words
> - We should wait for tx recovery before finishing the switch only on a broken
> cell.
> - We should wait for replicated caches tx recovery everywhere since every
> node is a backup of a failed one.
> - Upcoming operations related to the broken cell (including all replicated
> caches operations) will require a cluster-wide switch finish to be processed.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12986) Redis mget command is broken
[
https://issues.apache.org/jira/browse/IGNITE-12986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-12986:
Assignee: Vyacheslav Koptilin
> Redis mget command is broken
>
>
> Key: IGNITE-12986
> URL: https://issues.apache.org/jira/browse/IGNITE-12986
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Vishnu Bharathi
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.9
>
>
> When trying to use the redis layer for ignite, noticed that the data returned
> by the mget command is inconsistent. Hence the mget command is broken. To
> demostrate here is an example
> {code}
> 127.0.0.1:11211> set a 1
> OK
> 127.0.0.1:11211> set b 2
> OK
> 127.0.0.1:11211> set c 3
> OK
> (0.98s)
> 127.0.0.1:11211> mget a b c
> 1) "1"
> 2) "2"
> 3) "3"
> 127.0.0.1:11211> mget c b a
> 1) "1"
> 2) "2"
> 3) "3"
> 127.0.0.1:11211> mget a c b
> 1) "1"
> 2) "2"
> 3) "3"
> {code}
> If you notice, the order of the values returned does not match the order of
> the values returned.
> In order to demonstrate the expected behaviour, will run the same commands
> against a real redis instance and paste the output below.
> {code}
> 127.0.0.1:6379> set a 1
> OK
> 127.0.0.1:6379> set b 2
> OK
> 127.0.0.1:6379> set c 3
> OK
> 127.0.0.1:6379> mget a b c
> 1) "1"
> 2) "2"
> 3) "3"
> 127.0.0.1:6379> mget c b a
> 1) "3"
> 2) "2"
> 3) "1"
> 127.0.0.1:6379> mget a c b
> 1) "1"
> 2) "3"
> 3) "2"
> {code}
> This is not only happening on the redis-cli, it is also happening when using
> redis client libraries.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12986) Redis mget command is broken
[
https://issues.apache.org/jira/browse/IGNITE-12986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101591#comment-17101591
]
Vyacheslav Koptilin commented on IGNITE-12986:
--
Well, the documentation does not explicitly guarantee that the command should
preserve the order of keys and I think the right answer is yes, this command
has to provide such a guarantee [1]. Otherwise, the user wouldn't know how to
match keys and values.
[1] [https://redis.io/commands/mget]
I will take a look at this issue.
> Redis mget command is broken
>
>
> Key: IGNITE-12986
> URL: https://issues.apache.org/jira/browse/IGNITE-12986
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Vishnu Bharathi
>Priority: Major
> Fix For: 2.9
>
>
> When trying to use the redis layer for ignite, noticed that the data returned
> by the mget command is inconsistent. Hence the mget command is broken. To
> demostrate here is an example
> {code}
> 127.0.0.1:11211> set a 1
> OK
> 127.0.0.1:11211> set b 2
> OK
> 127.0.0.1:11211> set c 3
> OK
> (0.98s)
> 127.0.0.1:11211> mget a b c
> 1) "1"
> 2) "2"
> 3) "3"
> 127.0.0.1:11211> mget c b a
> 1) "1"
> 2) "2"
> 3) "3"
> 127.0.0.1:11211> mget a c b
> 1) "1"
> 2) "2"
> 3) "3"
> {code}
> If you notice, the order of the values returned does not match the order of
> the values returned.
> In order to demonstrate the expected behaviour, will run the same commands
> against a real redis instance and paste the output below.
> {code}
> 127.0.0.1:6379> set a 1
> OK
> 127.0.0.1:6379> set b 2
> OK
> 127.0.0.1:6379> set c 3
> OK
> 127.0.0.1:6379> mget a b c
> 1) "1"
> 2) "2"
> 3) "3"
> 127.0.0.1:6379> mget c b a
> 1) "3"
> 2) "2"
> 3) "1"
> 127.0.0.1:6379> mget a c b
> 1) "1"
> 2) "3"
> 3) "2"
> {code}
> This is not only happening on the redis-cli, it is also happening when using
> redis client libraries.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12986) Redis mget command is broken
[
https://issues.apache.org/jira/browse/IGNITE-12986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-12986:
-
Affects Version/s: 2.8
> Redis mget command is broken
>
>
> Key: IGNITE-12986
> URL: https://issues.apache.org/jira/browse/IGNITE-12986
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8
>Reporter: Vishnu Bharathi
>Priority: Major
> Fix For: 2.9
>
>
> When trying to use the redis layer for ignite, noticed that the data returned
> by the mget command is inconsistent. Hence the mget command is broken. To
> demostrate here is an example
> {code}
> 127.0.0.1:11211> set a 1
> OK
> 127.0.0.1:11211> set b 2
> OK
> 127.0.0.1:11211> set c 3
> OK
> (0.98s)
> 127.0.0.1:11211> mget a b c
> 1) "1"
> 2) "2"
> 3) "3"
> 127.0.0.1:11211> mget c b a
> 1) "1"
> 2) "2"
> 3) "3"
> 127.0.0.1:11211> mget a c b
> 1) "1"
> 2) "2"
> 3) "3"
> {code}
> If you notice, the order of the values returned does not match the order of
> the values returned.
> In order to demonstrate the expected behaviour, will run the same commands
> against a real redis instance and paste the output below.
> {code}
> 127.0.0.1:6379> set a 1
> OK
> 127.0.0.1:6379> set b 2
> OK
> 127.0.0.1:6379> set c 3
> OK
> 127.0.0.1:6379> mget a b c
> 1) "1"
> 2) "2"
> 3) "3"
> 127.0.0.1:6379> mget c b a
> 1) "3"
> 2) "2"
> 3) "1"
> 127.0.0.1:6379> mget a c b
> 1) "1"
> 2) "3"
> 3) "2"
> {code}
> This is not only happening on the redis-cli, it is also happening when using
> redis client libraries.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12986) Redis mget command is broken
[
https://issues.apache.org/jira/browse/IGNITE-12986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-12986:
-
Fix Version/s: 2.9
> Redis mget command is broken
>
>
> Key: IGNITE-12986
> URL: https://issues.apache.org/jira/browse/IGNITE-12986
> Project: Ignite
> Issue Type: Bug
>Reporter: Vishnu Bharathi
>Priority: Major
> Fix For: 2.9
>
>
> When trying to use the redis layer for ignite, noticed that the data returned
> by the mget command is inconsistent. Hence the mget command is broken. To
> demostrate here is an example
> {code}
> 127.0.0.1:11211> set a 1
> OK
> 127.0.0.1:11211> set b 2
> OK
> 127.0.0.1:11211> set c 3
> OK
> (0.98s)
> 127.0.0.1:11211> mget a b c
> 1) "1"
> 2) "2"
> 3) "3"
> 127.0.0.1:11211> mget c b a
> 1) "1"
> 2) "2"
> 3) "3"
> 127.0.0.1:11211> mget a c b
> 1) "1"
> 2) "2"
> 3) "3"
> {code}
> If you notice, the order of the values returned does not match the order of
> the values returned.
> In order to demonstrate the expected behaviour, will run the same commands
> against a real redis instance and paste the output below.
> {code}
> 127.0.0.1:6379> set a 1
> OK
> 127.0.0.1:6379> set b 2
> OK
> 127.0.0.1:6379> set c 3
> OK
> 127.0.0.1:6379> mget a b c
> 1) "1"
> 2) "2"
> 3) "3"
> 127.0.0.1:6379> mget c b a
> 1) "3"
> 2) "2"
> 3) "1"
> 127.0.0.1:6379> mget a c b
> 1) "1"
> 2) "3"
> 3) "2"
> {code}
> This is not only happening on the redis-cli, it is also happening when using
> redis client libraries.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12989) TxRecovery should log statuses to TimeBag
[ https://issues.apache.org/jira/browse/IGNITE-12989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-12989: -- Summary: TxRecovery should log statuses to TimeBag (was: Tx recovery should log statuses to TimeBag) > TxRecovery should log statuses to TimeBag > - > > Key: IGNITE-12989 > URL: https://issues.apache.org/jira/browse/IGNITE-12989 > Project: Ignite > Issue Type: Task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-45 > Fix For: 2.9 > > > Timings, counters and other important info should be logged via TimeBag. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12990) Remove static thread group from IgniteSpiThread
Alexey Goncharuk created IGNITE-12990: - Summary: Remove static thread group from IgniteSpiThread Key: IGNITE-12990 URL: https://issues.apache.org/jira/browse/IGNITE-12990 Project: Ignite Issue Type: Improvement Reporter: Alexey Goncharuk This is a follow-up ticket for IGNITE-12554. The static thread group has not been removed from IgniteSpiThread which still prevents node start after the thread group destroy. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12989) Tx recovery should log statuses to TimeBag
Anton Vinogradov created IGNITE-12989: - Summary: Tx recovery should log statuses to TimeBag Key: IGNITE-12989 URL: https://issues.apache.org/jira/browse/IGNITE-12989 Project: Ignite Issue Type: Task Reporter: Anton Vinogradov Assignee: Anton Vinogradov Fix For: 2.9 Timings, counters and other important info should be logged via TimeBag. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12554) Ignite instance couldn't be restarted if it's parent thread group has been called destroy once
[
https://issues.apache.org/jira/browse/IGNITE-12554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101559#comment-17101559
]
Ivan Pavlukhin commented on IGNITE-12554:
-
[~agoncharuk], I do not mind if you take it over. I have a great deal of doubts
that I will have a time for it in near future.
> Ignite instance couldn't be restarted if it's parent thread group has been
> called destroy once
> --
>
> Key: IGNITE-12554
> URL: https://issues.apache.org/jira/browse/IGNITE-12554
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7.6
>Reporter: ha faculty
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.9
>
> Attachments: NodeRestartTesting.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am using an inhouse platform which manage the life cycle of ignite instance
> by calling ignition.start() and ignition.stop() from a web application.
> it could be started without issue for the first time. however, if it stop the
> ignite by calling ignition.stop() and followed by destroying the parent
> thread group which starting it.
> Calling ignition.start() in the 2nd time will throw the following exception
> Exception in thread "kickOff" java.lang.IllegalThreadStateExceptionException
> in thread "kickOff" java.lang.IllegalThreadStateException at
> java.lang.ThreadGroup.addUnstarted(ThreadGroup.java:867) at
> java.lang.Thread.init(Thread.java:405) at
> java.lang.Thread.init(Thread.java:349) at
> java.lang.Thread.(Thread.java:599) at
> org.apache.ignite.thread.IgniteThread.(IgniteThread.java:96) at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.start(StripedExecutor.java:474)
> at
> org.apache.ignite.internal.util.StripedExecutor.(StripedExecutor.java:121)
> at
> org.apache.ignite.internal.util.StripedExecutor.(StripedExecutor.java:80)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1842)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:565) at
> org.apache.ignite.Ignition.start(Ignition.java:305) at
> com.faculty.poc.ignite.app.NodeRestartTesting.run(NodeRestartTesting.java:60)
> at java.lang.Thread.run(Thread.java:748)
> Please find my demo code for this issue.
> Walk through into Ignite code, it should be caused by a static thread group
> created in IgniteThread class. (private static final ThreadGroup DFLT_GRP =
> new ThreadGroup("ignite")
> Destroyed the parent thread group which start the ignite instance will result
> in causing the DFLT_GRP go into destroyed state. Therefore, when Ignite was
> start ifor the 2nd time, this static thread group has been destroyed and no
> longer able to run the ignite.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12969) TxRecovery discovery listener should implement HighPriorityListener
[ https://issues.apache.org/jira/browse/IGNITE-12969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-12969: -- Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > TxRecovery discovery listener should implement HighPriorityListener > --- > > Key: IGNITE-12969 > URL: https://issues.apache.org/jira/browse/IGNITE-12969 > Project: Ignite > Issue Type: Task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-45 > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently, tx recovery may be delayed because it starts at a low priority > discovery listener. > Tx recovery listener now 16th position at discovery listeners list. > List size is 35 and execution time between lsnrs[0] and lsnrs[34] may be > greater than 300 ms according to local benchmarks. > This does not mean that currently tx recovery may be delayed by 300 ms, but > it already delayed for some time (up to 50ms according to local benchmarks) > and this delay may grow from version to version. > A good case is to implement this listener as HighPriorityListener, this will > guarantee priority for further versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12973) Support inlining of BigDecimal
[ https://issues.apache.org/jira/browse/IGNITE-12973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeniy Rudenko reassigned IGNITE-12973: Assignee: (was: Evgeniy Rudenko) > Support inlining of BigDecimal > -- > > Key: IGNITE-12973 > URL: https://issues.apache.org/jira/browse/IGNITE-12973 > Project: Ignite > Issue Type: Improvement >Reporter: Evgeniy Rudenko >Priority: Major > Fix For: 2.9 > > > SQL currently doesn't support inlining for indexes over BigDecimal although > there seem to be no strong reason for that. It is quite often that decimal > types are used in FinTech apps and inability to efficiently use them in SQL > conditions can make migration to SQL a lot harder. > Need to implement support for BigDecimal inlining. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12988) c++ thin client installer misses some headers
Bastien Durel created IGNITE-12988:
--
Summary: c++ thin client installer misses some headers
Key: IGNITE-12988
URL: https://issues.apache.org/jira/browse/IGNITE-12988
Project: Ignite
Issue Type: Bug
Components: build, examples, thin client
Affects Versions: 2.8
Reporter: Bastien Durel
Hello,
After building and installing (with make install) the c++ module for ignite,
some header files are missing, so the most simple example cannot compile :
{code:java}
make: Entering directory '/home/bastien/project/webix/cpp'
g++ -I/usr/local/include -c -o data.o data.cpp
In file included from
/usr/local/include/ignite/impl/binary/binary_writer_impl.h:32,
from /usr/local/include/ignite/binary/binary_raw_writer.h:30,
from /usr/local/include/ignite/impl/thin/writable.h:21,
from /usr/local/include/ignite/thin/cache/cache_client.h:28,
from /usr/local/include/ignite/thin/ignite_client.h:31,
from data.cpp:3:
/usr/local/include/ignite/impl/binary/binary_utils.h:30:10: fatal error:
ignite/binary/binary_enum_entry.h: No such file or directory
30 | #include
| ^~~
compilation terminated.
make: *** [: data.o] Error 1
{code}
To make the first thin client example compile, I had to manually copy
`binary_enum_entry.h` and `binary_enum.h` to /usr/local/include/ignite/binary/
Using the deb file from [http://apache.org/dist/ignite/deb/] leads to the same
results.
While trying to compile a non-thin client, I ran into a similar issue with
which is not installed, but I did not push this way.
By the way, the examples on
[https://apacheignite-cpp.readme.io/docs/thin-client] reffers to a non-existant
include file :
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12973) Support inlining of BigDecimal
[ https://issues.apache.org/jira/browse/IGNITE-12973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101544#comment-17101544 ] Evgeniy Rudenko commented on IGNITE-12973: -- Couldn't implement update because of the slow work of H2's ValueDecimal. > Support inlining of BigDecimal > -- > > Key: IGNITE-12973 > URL: https://issues.apache.org/jira/browse/IGNITE-12973 > Project: Ignite > Issue Type: Improvement >Reporter: Evgeniy Rudenko >Assignee: Evgeniy Rudenko >Priority: Major > Fix For: 2.9 > > > SQL currently doesn't support inlining for indexes over BigDecimal although > there seem to be no strong reason for that. It is quite often that decimal > types are used in FinTech apps and inability to efficiently use them in SQL > conditions can make migration to SQL a lot harder. > Need to implement support for BigDecimal inlining. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12969) TxRecovery discovery listener should implement HighPriorityListener
[ https://issues.apache.org/jira/browse/IGNITE-12969?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-12969: -- Description: Currently, tx recovery may be delayed because it starts at a low priority discovery listener. Tx recovery listener now 16th position at discovery listeners list. List size is 35 and execution time between lsnrs[0] and lsnrs[34] may be greater than 300 ms according to local benchmarks. This does not mean that currently tx recovery may be delayed by 300 ms, but it already delayed for some time (up to 50ms according to local benchmarks) and this delay may grow from version to version. A good case is to implement this listener as HighPriorityListener, this will guarantee priority for further versions. was:Currently, tx recovery delayed for 300+ ms because it starts at a low priority discovery listener. > TxRecovery discovery listener should implement HighPriorityListener > --- > > Key: IGNITE-12969 > URL: https://issues.apache.org/jira/browse/IGNITE-12969 > Project: Ignite > Issue Type: Task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-45 > Fix For: 2.9 > > > Currently, tx recovery may be delayed because it starts at a low priority > discovery listener. > Tx recovery listener now 16th position at discovery listeners list. > List size is 35 and execution time between lsnrs[0] and lsnrs[34] may be > greater than 300 ms according to local benchmarks. > This does not mean that currently tx recovery may be delayed by 300 ms, but > it already delayed for some time (up to 50ms according to local benchmarks) > and this delay may grow from version to version. > A good case is to implement this listener as HighPriorityListener, this will > guarantee priority for further versions. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12962) Blacklist and whitelist of classes allowed to deserialize via HTTP-REST should be supported
[
https://issues.apache.org/jira/browse/IGNITE-12962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101534#comment-17101534
]
Pavel Pereslegin edited comment on IGNITE-12962 at 5/7/20, 10:32 AM:
-
[~alex_pl], could you review the proposed changes?
was (Author: xtern):
[~alex_pl], review the proposed changes, please.
> Blacklist and whitelist of classes allowed to deserialize via HTTP-REST
> should be supported
> ---
>
> Key: IGNITE-12962
> URL: https://issues.apache.org/jira/browse/IGNITE-12962
> Project: Ignite
> Issue Type: Improvement
> Components: rest
>Reporter: Aleksey Plekhanov
>Assignee: Pavel Pereslegin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Since we have the ability to deserialize custom objects (implemented by
> IGNITE-12857) we should have the ability to limit the scope of classes
> allowed to safe deserialization.
> There are already two system properties used for such purpose in Ignite:
> {code:java}
> /** Defines path to the file that contains list of classes allowed to safe
> deserialization.*/
> public static final String IGNITE_MARSHALLER_WHITELIST =
> "IGNITE_MARSHALLER_WHITELIST";
> /** Defines path to the file that contains list of classes disallowed to safe
> deserialization.*/
> public static final String IGNITE_MARSHALLER_BLACKLIST =
> "IGNITE_MARSHALLER_BLACKLIST";{code}
> HTTP-REST should support these properties too.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12962) Blacklist and whitelist of classes allowed to deserialize via HTTP-REST should be supported
[
https://issues.apache.org/jira/browse/IGNITE-12962?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101526#comment-17101526
]
Ignite TC Bot commented on IGNITE-12962:
{panel:title=Branch: [pull/7773/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5285460buildTypeId=IgniteTests24Java8_RunAll]
> Blacklist and whitelist of classes allowed to deserialize via HTTP-REST
> should be supported
> ---
>
> Key: IGNITE-12962
> URL: https://issues.apache.org/jira/browse/IGNITE-12962
> Project: Ignite
> Issue Type: Improvement
> Components: rest
>Reporter: Aleksey Plekhanov
>Assignee: Pavel Pereslegin
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Since we have the ability to deserialize custom objects (implemented by
> IGNITE-12857) we should have the ability to limit the scope of classes
> allowed to safe deserialization.
> There are already two system properties used for such purpose in Ignite:
> {code:java}
> /** Defines path to the file that contains list of classes allowed to safe
> deserialization.*/
> public static final String IGNITE_MARSHALLER_WHITELIST =
> "IGNITE_MARSHALLER_WHITELIST";
> /** Defines path to the file that contains list of classes disallowed to safe
> deserialization.*/
> public static final String IGNITE_MARSHALLER_BLACKLIST =
> "IGNITE_MARSHALLER_BLACKLIST";{code}
> HTTP-REST should support these properties too.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12554) Ignite instance couldn't be restarted if it's parent thread group has been called destroy once
[
https://issues.apache.org/jira/browse/IGNITE-12554?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101524#comment-17101524
]
Alexey Goncharuk commented on IGNITE-12554:
---
[~Pavlukhin] the issue has not been fixed as a similar static thread group is
present in {{IgniteSpiThread}}, a simple test case shows this. Do you mind
taking care of it or should I take it over?
> Ignite instance couldn't be restarted if it's parent thread group has been
> called destroy once
> --
>
> Key: IGNITE-12554
> URL: https://issues.apache.org/jira/browse/IGNITE-12554
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7.6
>Reporter: ha faculty
>Assignee: Ivan Pavlukhin
>Priority: Major
> Fix For: 2.9
>
> Attachments: NodeRestartTesting.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> I am using an inhouse platform which manage the life cycle of ignite instance
> by calling ignition.start() and ignition.stop() from a web application.
> it could be started without issue for the first time. however, if it stop the
> ignite by calling ignition.stop() and followed by destroying the parent
> thread group which starting it.
> Calling ignition.start() in the 2nd time will throw the following exception
> Exception in thread "kickOff" java.lang.IllegalThreadStateExceptionException
> in thread "kickOff" java.lang.IllegalThreadStateException at
> java.lang.ThreadGroup.addUnstarted(ThreadGroup.java:867) at
> java.lang.Thread.init(Thread.java:405) at
> java.lang.Thread.init(Thread.java:349) at
> java.lang.Thread.(Thread.java:599) at
> org.apache.ignite.thread.IgniteThread.(IgniteThread.java:96) at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.start(StripedExecutor.java:474)
> at
> org.apache.ignite.internal.util.StripedExecutor.(StripedExecutor.java:121)
> at
> org.apache.ignite.internal.util.StripedExecutor.(StripedExecutor.java:80)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1842)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589) at
> org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:565) at
> org.apache.ignite.Ignition.start(Ignition.java:305) at
> com.faculty.poc.ignite.app.NodeRestartTesting.run(NodeRestartTesting.java:60)
> at java.lang.Thread.run(Thread.java:748)
> Please find my demo code for this issue.
> Walk through into Ignite code, it should be caused by a static thread group
> created in IgniteThread class. (private static final ThreadGroup DFLT_GRP =
> new ThreadGroup("ignite")
> Destroyed the parent thread group which start the ignite instance will result
> in causing the DFLT_GRP go into destroyed state. Therefore, when Ignite was
> start ifor the 2nd time, this static thread group has been destroyed and no
> longer able to run the ignite.
>
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12983) Logging exceptions inside IgniteSecurityProcessor#withContext(java.util.UUID)
[
https://issues.apache.org/jira/browse/IGNITE-12983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101502#comment-17101502
]
Ignite TC Bot commented on IGNITE-12983:
{panel:title=Branch: [pull/7772/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5285340buildTypeId=IgniteTests24Java8_RunAll]
> Logging exceptions inside IgniteSecurityProcessor#withContext(java.util.UUID)
> -
>
> Key: IGNITE-12983
> URL: https://issues.apache.org/jira/browse/IGNITE-12983
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Garus
>Assignee: Denis Garus
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We should write down to log all exception inside
> IgniteSecurityProcessor#withContext(java.util.UUID).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12407) Java thin client: implement API for activation/deactivation and WAL enabling/disabling
[ https://issues.apache.org/jira/browse/IGNITE-12407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101480#comment-17101480 ] Amelchev Nikita commented on IGNITE-12407: -- [~alex_pl], LGTM. > Java thin client: implement API for activation/deactivation and WAL > enabling/disabling > -- > > Key: IGNITE-12407 > URL: https://issues.apache.org/jira/browse/IGNITE-12407 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: thin > Time Spent: 20m > Remaining Estimate: 0h > > Implement ClusterAPI methods already supported by protocol: > isActive() > setActive(active flag) > isWalEnabled(cacheName) > enableWal(cacheName) > disableWal(cacheName) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12987) Remove TC badge from README.md
[ https://issues.apache.org/jira/browse/IGNITE-12987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Pavlukhin reassigned IGNITE-12987: --- Assignee: Ivan Pavlukhin > Remove TC badge from README.md > -- > > Key: IGNITE-12987 > URL: https://issues.apache.org/jira/browse/IGNITE-12987 > Project: Ignite > Issue Type: Task >Reporter: Ivan Pavlukhin >Assignee: Ivan Pavlukhin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently TC badge in main > [README|https://github.com/apache/ignite/blob/master/README.md] seems to be > not very useful because a build status is not seen directly (is says "no > permissions to get data"). Moreover TC results are not very representative > because integration tests are not stable by nature and we rely on TC bot > checks instead of plain TC status. > Let's remove this badge. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12987) Remove TC badge from README.md
Ivan Pavlukhin created IGNITE-12987: --- Summary: Remove TC badge from README.md Key: IGNITE-12987 URL: https://issues.apache.org/jira/browse/IGNITE-12987 Project: Ignite Issue Type: Task Reporter: Ivan Pavlukhin Currently TC badge in main [README|https://github.com/apache/ignite/blob/master/README.md] seems to be not very useful because a build status is not seen directly (is says "no permissions to get data"). Moreover TC results are not very representative because integration tests are not stable by nature and we rely on TC bot checks instead of plain TC status. Let's remove this badge. -- This message was sent by Atlassian Jira (v8.3.4#803005)
