[jira] [Commented] (IGNITE-13175) NPE due to race on cache stop and transaction commit.
[
https://issues.apache.org/jira/browse/IGNITE-13175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17171263#comment-17171263
]
Stanilovsky Evgeny commented on IGNITE-13175:
-
this unclear for me right now, can`t found full stack trace and minimal or
something like this - reproducer.
> NPE due to race on cache stop and transaction commit.
> -
>
> Key: IGNITE-13175
> URL: https://issues.apache.org/jira/browse/IGNITE-13175
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Alexand Polyakov
>Assignee: Maria Makedonskaya
>Priority: Major
> Attachments: IGNITE-13175_reproducer.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If don't stop load and execute stop cache, sometimes throw
> NullPointerException and nodes failed
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.finishUnmarshal(BinaryObjectImpl.java:190)
> at
> org.apache.ignite.internal.processors.cache.transactions.TxEntryValueHolder.unmarshal(TxEntryValueHolder.java:154)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxEntry.unmarshal(IgniteTxEntry.java:971)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.unmarshal(IgniteTxHandler.java:354)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:403)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:386)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:188)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.lambda$null$0(IgniteTxHandler.java:644)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:559)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> transaction use cache context race with stopCache
> {code:java}
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.cleanup(GridCacheContext.java:2058)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.cleanup(GridCacheProcessor.java:467)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCache(GridCacheProcessor.java:1020)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2539)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2518)
> {code}
> there is a reproducer who adds CountDownLatch await to
> IgniteTxEntry#unmarshal which is countDown in GridCacheContext#cleanup
> https://github.com/gridgain/gridgain/tree/sdsb-11837
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-9016) Byte arrays are not working as cache keys
[
https://issues.apache.org/jira/browse/IGNITE-9016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stanislav Lukyanov updated IGNITE-9016:
---
Component/s: cache
> Byte arrays are not working as cache keys
> -
>
> Key: IGNITE-9016
> URL: https://issues.apache.org/jira/browse/IGNITE-9016
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Evgenii Zhuravlev
>Priority: Major
>
> it's not possible to retrieve early inserted data with byte[] key:
> {code:java}
> IgniteCache cache = ignite.getOrCreateCache("test");
> byte[] a = "test".getBytes();
> cache.put(a, a);
> cache.get(a); //returns null
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13323) GridDhtPartitionsExchangeFuture logging improvements
[ https://issues.apache.org/jira/browse/IGNITE-13323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17171045#comment-17171045 ] Andrey N. Gura commented on IGNITE-13323: - [~YAMolochkov], you can just make a copy under mutex and log info after mutex is released. > GridDhtPartitionsExchangeFuture logging improvements > > > Key: IGNITE-13323 > URL: https://issues.apache.org/jira/browse/IGNITE-13323 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.8.1 >Reporter: Yaroslav Molochkov >Assignee: Yaroslav Molochkov >Priority: Major > > Firstly, logging in said class should be improved to address possible cluster > topology/connectivity issues: > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture#processFullMessage, > upon entering that method and before critical section begins we should log > that at info level. This way we won't have to speculate if thread is waiting > on a lock to > not.(org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture#mux) > Secondly, > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture#sendAllPartitions. > Logging should reflect the amount of nodes that should receive messages > (collection that is sent to said method) and the amount of nodes that should > receive the message (or, in other words, we successfully managed to send the > message to a particular node, then sum it up). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-13322) Make GridDhtPartitionsExchangeFuture#srvNodes thread-safe
[ https://issues.apache.org/jira/browse/IGNITE-13322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey N. Gura resolved IGNITE-13322. - Resolution: Not A Problem > Make GridDhtPartitionsExchangeFuture#srvNodes thread-safe > - > > Key: IGNITE-13322 > URL: https://issues.apache.org/jira/browse/IGNITE-13322 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.8.1 >Reporter: Yaroslav Molochkov >Assignee: Yaroslav Molochkov >Priority: Major > > Currently > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture#srvNodes > reference is initialised to the ArrayList, which is not a thread-safe > implementation. > Solution to this ticket must guarantee thread-safety of the srvNodes > collection. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13322) Make GridDhtPartitionsExchangeFuture#srvNodes thread-safe
[
https://issues.apache.org/jira/browse/IGNITE-13322?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17171044#comment-17171044
]
Andrey N. Gura commented on IGNITE-13322:
-
{{GridDhtPartitionsExchangeFuture#srvNodes}} is always accessed under mutex
except of {{init()}} method. So read/write oprrations are already thread-safe.
Issue closed as not a bug.
> Make GridDhtPartitionsExchangeFuture#srvNodes thread-safe
> -
>
> Key: IGNITE-13322
> URL: https://issues.apache.org/jira/browse/IGNITE-13322
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.8.1
>Reporter: Yaroslav Molochkov
>Assignee: Yaroslav Molochkov
>Priority: Major
>
> Currently
> org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture#srvNodes
> reference is initialised to the ArrayList, which is not a thread-safe
> implementation.
> Solution to this ticket must guarantee thread-safety of the srvNodes
> collection.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11894) Add fetchSize to JDBC cache stores
[ https://issues.apache.org/jira/browse/IGNITE-11894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanislav Lukyanov updated IGNITE-11894: Description: JDBC's PreparedStatement accepts a fetchSize parameter which defines how many rows will be loaded from the DB at a time. Currently the only way to change that is by specifying it in a custom implementation of the JdbcDialect::fetchSize method (and even then it seems not be be used in some cases). Would be good to have a fetchSize property in all of JDBC-based cache stores. was: JDBC's PreparedStatement accepts a fetchSize parameter which defines how many rows will be loaded from the DB at a time. Currently the only way to change that is by specifying it in a customer implementation of the JdbcDialect::fetchSize method (and even then it seems not be be used in some cases). Would be good to have a fetchSize property in all of JDBC-based cache stores. > Add fetchSize to JDBC cache stores > -- > > Key: IGNITE-11894 > URL: https://issues.apache.org/jira/browse/IGNITE-11894 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Stanislav Lukyanov >Assignee: Amit Chavan >Priority: Minor > Labels: newbie > Fix For: 2.9 > > > JDBC's PreparedStatement accepts a fetchSize parameter which defines how many > rows will be loaded from the DB at a time. Currently the only way to change > that is by specifying it in a custom implementation of the > JdbcDialect::fetchSize method (and even then it seems not be be used in some > cases). > Would be good to have a fetchSize property in all of JDBC-based cache stores. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-11894) Add fetchSize to JDBC cache stores
[ https://issues.apache.org/jira/browse/IGNITE-11894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170835#comment-17170835 ] Stanislav Lukyanov commented on IGNITE-11894: - [~nizhikov] Are you sure this was implemented? I see that IGNITE-12286 is about an NPE and there is no fetchSize being added. > Add fetchSize to JDBC cache stores > -- > > Key: IGNITE-11894 > URL: https://issues.apache.org/jira/browse/IGNITE-11894 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Stanislav Lukyanov >Assignee: Amit Chavan >Priority: Minor > Labels: newbie > Fix For: 2.9 > > > JDBC's PreparedStatement accepts a fetchSize parameter which defines how many > rows will be loaded from the DB at a time. Currently the only way to change > that is by specifying it in a customer implementation of the > JdbcDialect::fetchSize method (and even then it seems not be be used in some > cases). > Would be good to have a fetchSize property in all of JDBC-based cache stores. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (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:comment-tabpanel=17170832#comment-17170832 ] Anton Kalashnikov commented on IGNITE-13013: [~ibessonov] new changes also LGTM but I have one note - maybe it is better instead of using magic number = 0(when socket not needed) use well-described constant(like PORT_DISABLED or RECEIVED_SOCKET_DISABLE) or at least adding some comments to this number because when I see port equal to 0 it's not obvious which behaviour I should expect. > 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 > > Attachments: image-2020-07-30-18-42-01-266.png > > Time Spent: 10m > Remaining Estimate: 0h > > 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)
[jira] [Created] (IGNITE-13326) .NET: GetJvmDllPathsWindows does not work on .NET Core
Pavel Tupitsyn created IGNITE-13326: --- Summary: .NET: GetJvmDllPathsWindows does not work on .NET Core Key: IGNITE-13326 URL: https://issues.apache.org/jira/browse/IGNITE-13326 Project: Ignite Issue Type: Bug Components: platforms Affects Versions: 2.4 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 2.10 GetJvmDllPathsWindows implementation is hidden with preprocessor directives on .NET Core, because it uses Windows Registry, which is not available by default. We should use Microsoft.Win32.Registry NuGet package to make it work. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13175) NPE due to race on cache stop and transaction commit.
[
https://issues.apache.org/jira/browse/IGNITE-13175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170760#comment-17170760
]
Maria Makedonskaya commented on IGNITE-13175:
-
[~zstan], could you please review fix?
> NPE due to race on cache stop and transaction commit.
> -
>
> Key: IGNITE-13175
> URL: https://issues.apache.org/jira/browse/IGNITE-13175
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Alexand Polyakov
>Assignee: Maria Makedonskaya
>Priority: Major
> Attachments: IGNITE-13175_reproducer.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If don't stop load and execute stop cache, sometimes throw
> NullPointerException and nodes failed
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.finishUnmarshal(BinaryObjectImpl.java:190)
> at
> org.apache.ignite.internal.processors.cache.transactions.TxEntryValueHolder.unmarshal(TxEntryValueHolder.java:154)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxEntry.unmarshal(IgniteTxEntry.java:971)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.unmarshal(IgniteTxHandler.java:354)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:403)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:386)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:188)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.lambda$null$0(IgniteTxHandler.java:644)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:559)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> transaction use cache context race with stopCache
> {code:java}
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.cleanup(GridCacheContext.java:2058)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.cleanup(GridCacheProcessor.java:467)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCache(GridCacheProcessor.java:1020)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2539)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2518)
> {code}
> there is a reproducer who adds CountDownLatch await to
> IgniteTxEntry#unmarshal which is countDown in GridCacheContext#cleanup
> https://github.com/gridgain/gridgain/tree/sdsb-11837
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13175) NPE due to race on cache stop and transaction commit.
[
https://issues.apache.org/jira/browse/IGNITE-13175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maria Makedonskaya updated IGNITE-13175:
Attachment: IGNITE-13175_reproducer.patch
> NPE due to race on cache stop and transaction commit.
> -
>
> Key: IGNITE-13175
> URL: https://issues.apache.org/jira/browse/IGNITE-13175
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Alexand Polyakov
>Assignee: Maria Makedonskaya
>Priority: Major
> Attachments: IGNITE-13175_reproducer.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If don't stop load and execute stop cache, sometimes throw
> NullPointerException and nodes failed
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.finishUnmarshal(BinaryObjectImpl.java:190)
> at
> org.apache.ignite.internal.processors.cache.transactions.TxEntryValueHolder.unmarshal(TxEntryValueHolder.java:154)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxEntry.unmarshal(IgniteTxEntry.java:971)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.unmarshal(IgniteTxHandler.java:354)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:403)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:386)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:188)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.lambda$null$0(IgniteTxHandler.java:644)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:559)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> transaction use cache context race with stopCache
> {code:java}
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.cleanup(GridCacheContext.java:2058)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.cleanup(GridCacheProcessor.java:467)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCache(GridCacheProcessor.java:1020)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2539)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2518)
> {code}
> there is a reproducer who adds CountDownLatch await to
> IgniteTxEntry#unmarshal which is countDown in GridCacheContext#cleanup
> https://github.com/gridgain/gridgain/tree/sdsb-11837
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13175) NPE due to race on cache stop and transaction commit.
[
https://issues.apache.org/jira/browse/IGNITE-13175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170756#comment-17170756
]
Ignite TC Bot commented on IGNITE-13175:
{panel:title=Branch: [pull/8075/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8075/head] Base: [master] : New Tests
(66)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS (Indexing){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5485870]]
* {color:#013220}IgnitePdsWithIndexingCoreTestSuite:
IgniteCacheGroupsWithRestartsTest.testCleaningGarbageAfterCacheDestroyedAndNodeStop_ControlConsoleUtil
- PASSED{color}
{color:#8b}Cache 7{color} [[tests
53|https://ci.ignite.apache.org/viewLog.html?buildId=5485861]]
* {color:#013220}IgniteCacheWithIndexingAndPersistenceTestSuite:
GridCommandHandlerMetadataTest.testMetadataDetails - PASSED{color}
* {color:#013220}IgniteCacheWithIndexingAndPersistenceTestSuite:
GridCommandHandlerMetadataTest.testMetadataList - PASSED{color}
* {color:#013220}IgniteCacheWithIndexingAndPersistenceTestSuite:
GridCommandHandlerIndexingCheckSizeTest.testNoErrorOnCacheWithQueryEntity -
PASSED{color}
* {color:#013220}IgniteCacheWithIndexingAndPersistenceTestSuite:
GridCommandHandlerIndexingTest.testCorruptedIndexPartitionShouldFailValidationWithCrc
- PASSED{color}
* {color:#013220}IgniteCacheWithIndexingAndPersistenceTestSuite:
GridCommandHandlerIndexingTest.testCorruptedIndexPartitionShouldFailValidationWithoutCrc
- PASSED{color}
* {color:#013220}IgniteCacheWithIndexingAndPersistenceTestSuite:
GridCommandHandlerIndexingClusterByClassTest.testValidateIndexesWithCrcNoErrors
- PASSED{color}
* {color:#013220}IgniteCacheWithIndexingAndPersistenceTestSuite:
GridCommandHandlerMetadataTest.testDropJdbcThinConnectionsOnRemove -
PASSED{color}
* {color:#013220}IgniteCacheWithIndexingAndPersistenceTestSuite:
GridCommandHandlerIndexingClusterByClassWithSSLTest.testCheckIndexInlineSizesNoError
- PASSED{color}
* {color:#013220}IgniteCacheWithIndexingAndPersistenceTestSuite:
GridCommandHandlerIndexingClusterByClassTest.testBrokenCacheDataTreeShouldFailValidationWithCacheGroupInfo
- PASSED{color}
* {color:#013220}IgniteCacheWithIndexingAndPersistenceTestSuite:
GridCommandHandlerIndexingClusterByClassTest.testValidateIndexesNoErrors -
PASSED{color}
* {color:#013220}IgniteCacheWithIndexingAndPersistenceTestSuite:
GridCommandHandlerIndexingClusterByClassTest.testBrokenCacheDataTreeShouldFailValidation
- PASSED{color}
... and 42 new tests
{color:#8b}Basic 1{color} [[tests
10|https://ci.ignite.apache.org/viewLog.html?buildId=5485835]]
* {color:#013220}IgniteBasicTestSuite:
CommandHandlerParsingTest.testParseAutoConfirmationFlag - PASSED{color}
* {color:#013220}IgniteBasicTestSuite:
CommandHandlerParsingTest.testParseAndValidateWalActions - PASSED{color}
* {color:#013220}IgniteBasicTestSuite:
CommandHandlerParsingTest.testTransactionArguments - PASSED{color}
* {color:#013220}IgniteBasicTestSuite:
CommandHandlerParsingTest.testValidateIndexArguments - PASSED{color}
* {color:#013220}IgniteBasicTestSuite:
CommandHandlerParsingTest.testConnectionSettings - PASSED{color}
* {color:#013220}IgniteBasicTestSuite:
CommandHandlerParsingTest.testParseAndValidateUserAndPassword - PASSED{color}
* {color:#013220}IgniteBasicTestSuite:
CommandHandlerParsingTest.testParseAndValidateSSLArguments - PASSED{color}
* {color:#013220}IgniteBasicTestSuite:
CommandHandlerParsingTest.testFindAndDeleteGarbage - PASSED{color}
* {color:#013220}IgniteBasicTestSuite:
CommandHandlerParsingTest.testParseVerboseOption - PASSED{color}
* {color:#013220}IgniteBasicTestSuite:
CommandHandlerParsingTest.testKillArguments - PASSED{color}
{color:#8b}Security{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5485904]]
* {color:#013220}SecurityTestSuite: MultipleSSLContextsTest.testConnector -
PASSED{color}
* {color:#013220}SecurityTestSuite:
GridCommandHandlerSslWithSecurityTest.testInputKeyTrustStorePwdOnlyOnce -
PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5485911buildTypeId=IgniteTests24Java8_RunAll]
> NPE due to race on cache stop and transaction commit.
> -
>
> Key: IGNITE-13175
> URL: https://issues.apache.org/jira/browse/IGNITE-13175
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Alexand Polyakov
>Assignee: Maria Makedonskaya
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If don't stop load and execute stop cache, sometimes throw
> NullPointerException and nodes failed
> {code}
> java.lang.NullPointerException: null
> at
>
[jira] [Assigned] (IGNITE-13190) Core defragmentation functions
[ https://issues.apache.org/jira/browse/IGNITE-13190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semyon Danilov reassigned IGNITE-13190: --- Assignee: Semyon Danilov > Core defragmentation functions > -- > > Key: IGNITE-13190 > URL: https://issues.apache.org/jira/browse/IGNITE-13190 > Project: Ignite > Issue Type: Sub-task >Reporter: Sergey Chugunov >Assignee: Semyon Danilov >Priority: Major > Labels: IEP-47 > > The following set of functions covering defragmentation happy-case needed: > * Initialization of defragmentation manager when node is started in > maintenance mode. > * Information about partition files is gathered by defrag mgr. > * For each partition file corresponding file of defragmented partition is > created and initialized. > * Keys are transferred from old partitions to new partitions. > * Checkpointer is aware of new partition files and flushes defragmented > memory to new partition files. > > No fault-tolerance code nor index defragmentation mappings are needed in this > task. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-13321) Control utility doesn't print results to stdout.
[
https://issues.apache.org/jira/browse/IGNITE-13321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy resolved IGNITE-13321.
---
Resolution: Fixed
[~kuaw26] Thank, you.
> Control utility doesn't print results to stdout.
>
>
> Key: IGNITE-13321
> URL: https://issues.apache.org/jira/browse/IGNITE-13321
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Affects Versions: 2.10
>Reporter: Ivan Daschinskiy
>Assignee: Alexey Kuznetsov
>Priority: Blocker
> Fix For: 2.10
>
>
> After merging
> [IGNITE-13262|https://issues.apache.org/jira/browse/IGNITE-13262 ]
> {{control.sh}} doesn't work properly either in dev mode, or in release mode.
> Specifically, no output printed in stdout.
> For example, incorrect output for {{control.sh -baseline set}} after commit
> is:
> {code:sh}
> Control utility [ver. 2.10.0-SNAPSHOT#20200803-sha1:DEV],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:24:33.193,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
>
> {code}
> Correct output for {{control.sh -baseline set}} before commit is:
> {code}
> Control utility [ver. 2.8.1#20200521-sha1:86422096],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:23:55.793,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
> ,
>
> Cluster state: active,
> Current topology version: 3,
> Baseline auto adjustment disabled: softTimeout=30
>Current topology version: 3 (Coordinator: ConsistentId=ducker02, Order=1)
> Baseline nodes:
>ConsistentId=ducker02, State=ONLINE, Order=1,
>ConsistentId=ducker03, State=ONLINE, Order=2,
>ConsistentId=ducker04, State=ONLINE, Order=3,
> ,
>
> Number of baseline nodes: 3,
> Other nodes not found.,
> Command [BASELINE] finished with code: 0,
> Control utility has completed execution at: 2020-08-03T14:23:57.351,
> Execution time: 1558 ms
> {code}
> However, command seems to execute and baseline actually changes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13321) Control utility doesn't print results to stdout.
[
https://issues.apache.org/jira/browse/IGNITE-13321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170731#comment-17170731
]
Alexey Kuznetsov commented on IGNITE-13321:
---
[~ivandasch] I revrted my commit. Please close this issue.
I will rework my fix to not break control utility.
> Control utility doesn't print results to stdout.
>
>
> Key: IGNITE-13321
> URL: https://issues.apache.org/jira/browse/IGNITE-13321
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Affects Versions: 2.10
>Reporter: Ivan Daschinskiy
>Assignee: Alexey Kuznetsov
>Priority: Blocker
> Fix For: 2.10
>
>
> After merging
> [IGNITE-13262|https://issues.apache.org/jira/browse/IGNITE-13262 ]
> {{control.sh}} doesn't work properly either in dev mode, or in release mode.
> Specifically, no output printed in stdout.
> For example, incorrect output for {{control.sh -baseline set}} after commit
> is:
> {code:sh}
> Control utility [ver. 2.10.0-SNAPSHOT#20200803-sha1:DEV],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:24:33.193,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
>
> {code}
> Correct output for {{control.sh -baseline set}} before commit is:
> {code}
> Control utility [ver. 2.8.1#20200521-sha1:86422096],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:23:55.793,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
> ,
>
> Cluster state: active,
> Current topology version: 3,
> Baseline auto adjustment disabled: softTimeout=30
>Current topology version: 3 (Coordinator: ConsistentId=ducker02, Order=1)
> Baseline nodes:
>ConsistentId=ducker02, State=ONLINE, Order=1,
>ConsistentId=ducker03, State=ONLINE, Order=2,
>ConsistentId=ducker04, State=ONLINE, Order=3,
> ,
>
> Number of baseline nodes: 3,
> Other nodes not found.,
> Command [BASELINE] finished with code: 0,
> Control utility has completed execution at: 2020-08-03T14:23:57.351,
> Execution time: 1558 ms
> {code}
> However, command seems to execute and baseline actually changes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Reopened] (IGNITE-13262) Remove GridClientUtils#shutdownNow() as full duplicate of U#shutdownNow
[ https://issues.apache.org/jira/browse/IGNITE-13262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Kuznetsov reopened IGNITE-13262: --- > Remove GridClientUtils#shutdownNow() as full duplicate of U#shutdownNow > --- > > Key: IGNITE-13262 > URL: https://issues.apache.org/jira/browse/IGNITE-13262 > Project: Ignite > Issue Type: Task > Components: general >Affects Versions: 2.8.1 >Reporter: Alexey Kuznetsov >Assignee: Alexey Kuznetsov >Priority: Minor > Fix For: 2.10 > > Original Estimate: 4h > Time Spent: 20m > Remaining Estimate: 3h 40m > > Method o.a.i.internal.client.util.GridClientUtils#shutdownNow is a full > duplicate of U#shutdownNow. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13279) Ignition.start failing with error java.lang.IllegalStateException: Failed to parse version: -1595322995-
[
https://issues.apache.org/jira/browse/IGNITE-13279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170722#comment-17170722
]
Keshava Munegowda commented on IGNITE-13279:
I have created another JIIRA :
https://issues.apache.org/jira/browse/IGNITE-13325
> Ignition.start failing with error java.lang.IllegalStateException: Failed to
> parse version: -1595322995-
>
>
> Key: IGNITE-13279
> URL: https://issues.apache.org/jira/browse/IGNITE-13279
> Project: Ignite
> Issue Type: Bug
> Components: examples, general
>Affects Versions: 2.8.1
>Reporter: Keshava Munegowda
>Priority: Critical
> Fix For: 2.8.1
>
>
> I am using the Apache ignite : apache-ignite-2.8.1-bin
> I started the apache iginite node using : ./bin/ignite.sh
> ./examples/config/example-ignite.xml
> The node is successful started with this message:
> ```
> [root@mdw apache-ignite-2.8.1-bin]# ./bin/ignite.sh
> ./examples/config/example-ignite.xml
> [02:19:43] __
> [02:19:43] / _/ ___/ |/ / _/_ __/ __/
> [02:19:43] _/ // (7 7 // / / / / _/
> [02:19:43] /___/\___/_/|_/___/ /_/ /___/
> [02:19:43]
> [02:19:43] ver. 2.8.1#20200521-sha1:86422096
> [02:19:43] 2020 Copyright(C) Apache Software Foundation
> [02:19:43]
> [02:19:43] Ignite documentation: http://ignite.apache.org
> [02:19:43]
> [02:19:43] Quiet mode.
> [02:19:43] ^-- Logging to file
> '/data/kmg/apache-ignite-2.8.1-bin/work/log/ignite-4135cf96.0.log'
> [02:19:43] ^-- Logging by 'JavaLogger [quiet=true, config=null]'
> [02:19:43] ^-- To see **FULL** console log here add -DIGNITE_QUIET=false or
> "-v" to ignite.\{sh|bat}
> [02:19:43]
> [02:19:43] OS: Linux 3.10.0-1127.el7.x86_64 amd64
> [02:19:43] VM information: OpenJDK Runtime Environment 1.8.0_252-b09 Oracle
> Corporation OpenJDK 64-Bit Server VM 25.252-b09
> [02:19:43] Please set system property '-Djava.net.preferIPv4Stack=true' to
> avoid possible problems in mixed environments.
> [02:19:43] Configured plugins:
> [02:19:43] ^-- None
> [02:19:43]
> [02:19:43] Configured failure handler: [hnd=StopNodeOrHaltFailureHandler
> [tryStop=false, timeout=0, super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT
> [02:19:46] Message queue limit is set to 0 which may lead to potential OOMEs
> when running cache operations in FULL_ASYNC or PRIMARY_SYNC modes due to
> message queues growth on sender and receiver sides.
> [02:19:46] Security status [authentication=off, tls/ssl=off]
> [02:19:48] Performance suggestions for grid (fix if possible)
> [02:19:48] To disable, set -DIGNITE_PERFORMANCE_SUGGESTIONS_DISABLED=true
> [02:19:48] ^-- Disable grid events (remove 'includeEventTypes' from
> configuration)
> [02:19:48] ^-- Enable G1 Garbage Collector (add '-XX:+UseG1GC' to JVM options)
> [02:19:48] ^-- Specify JVM heap max size (add '-Xmx[g|G|m|M|k|K]' to
> JVM options)
> [02:19:48] ^-- Set max direct memory size if getting 'OOME: Direct buffer
> memory' (add '-XX:MaxDirectMemorySize=[g|G|m|M|k|K]' to JVM options)
> [02:19:48] ^-- Disable processing of calls to System.gc() (add
> '-XX:+DisableExplicitGC' to JVM options)
> [02:19:48] ^-- Speed up flushing of dirty pages by OS (alter
> vm.dirty_expire_centisecs parameter by setting to 500)
> [02:19:48] Refer to this page for more performance suggestions:
> https://apacheignite.readme.io/docs/jvm-and-system-tuning
> [02:19:48]
> [02:19:48] To start Console Management & Monitoring run
> ignitevisorcmd.\{sh|bat}
> [02:19:48] Data Regions Configured:
> [02:19:48] ^-- default [initSize=256.0 MiB, maxSize=75.5 GiB,
> persistence=false, lazyMemoryAllocation=true]
> [02:19:48]
> [02:19:48] Ignite node started OK (id=4135cf96)
> [02:19:48] Topology snapshot [ver=1, locNode=4135cf96, servers=1, clients=0,
> state=ACTIVE, CPUs=32, offheap=76.0GB, heap=27.0GB]
> [02:19:48] ^-- Baseline [id=0, size=1, online=1, offline=0]
> ```
> Now, I have benchmarking application, which start the apache iginitition
> using the java API
> Ignition.start("examples/config/example-ignite.xml");
> This method is failing with below error log:
> ```
> 0 [main] DEBUG org.springframework.core.env.StandardEnvironment - Adding
> PropertySource 'systemProperties' with lowest search precedence
> 2 [main] DEBUG org.springframework.core.env.StandardEnvironment - Adding
> PropertySource 'systemEnvironment' with lowest search precedence
> 3 [main] DEBUG org.springframework.core.env.StandardEnvironment - Initialized
> StandardEnvironment with PropertySources [MapPropertySource@1928301845
> {name='systemProperties', properties={java.runtime.name=OpenJDK Runtime
> Environment,
>
[jira] [Updated] (IGNITE-13325) cache.put is failing with java.util.concurrent.ExecutionException: java.lang.IllegalStateException: class org.apache.ignite.internal.processors.cache.CacheStoppedExcept
[
https://issues.apache.org/jira/browse/IGNITE-13325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keshava Munegowda updated IGNITE-13325:
---
Summary: cache.put is failing with java.util.concurrent.ExecutionException:
java.lang.IllegalStateException: class
org.apache.ignite.internal.processors.cache.CacheStoppedException: Failed to
perform cache operation (cache is stopped) (was:
java.util.concurrent.ExecutionException: java.lang.IllegalStateException: class
org.apache.ignite.internal.processors.cache.CacheStoppedException: Failed to
perform cache operation (cache is stopped): )
> cache.put is failing with java.util.concurrent.ExecutionException:
> java.lang.IllegalStateException: class
> org.apache.ignite.internal.processors.cache.CacheStoppedException: Failed to
> perform cache operation (cache is stopped)
> -
>
> Key: IGNITE-13325
> URL: https://issues.apache.org/jira/browse/IGNITE-13325
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8.1
>Reporter: Keshava Munegowda
>Priority: Critical
>
> when the ignite was used in the cluster node mode (not the thin client), the
> cache closed exceptions are observed.
>
> here is full log:
> WARNING: An illegal reflective access operation has occurred
> WARNING: Illegal reflective access by
> org.apache.ignite.internal.util.GridUnsafe$2
> (file:/data/kmg/SBK/build/install/sbk/lib/ignite-core-2.8.1.jar) to field
> java.nio.Buffer.address
> WARNING: Please consider reporting this to the maintainers of
> org.apache.ignite.internal.util.GridUnsafe$2
> WARNING: Use --illegal-access=warn to enable warnings of further illegal
> reflective access operations
> WARNING: All illegal access operations will be denied in a future release
> 0 [main] DEBUG org.springframework.core.env.StandardEnvironment - Adding
> PropertySource 'systemProperties' with lowest search precedence
> 2 [main] DEBUG org.springframework.core.env.StandardEnvironment - Adding
> PropertySource 'systemEnvironment' with lowest search precedence
> 2 [main] DEBUG org.springframework.core.env.StandardEnvironment - Initialized
> StandardEnvironment with PropertySources [MapPropertySource@1220806149
> {name='systemProperties', properties={awt.toolkit=sun.awt.X11.XToolkit,
> java.specification.version=11, sun.cpu.isalist=, sun.jnu.encoding=UTF-8,
>
[jira] [Created] (IGNITE-13325) java.util.concurrent.ExecutionException: java.lang.IllegalStateException: class org.apache.ignite.internal.processors.cache.CacheStoppedException: Failed to perform cac
Keshava Munegowda created IGNITE-13325:
--
Summary: java.util.concurrent.ExecutionException:
java.lang.IllegalStateException: class
org.apache.ignite.internal.processors.cache.CacheStoppedException: Failed to
perform cache operation (cache is stopped):
Key: IGNITE-13325
URL: https://issues.apache.org/jira/browse/IGNITE-13325
Project: Ignite
Issue Type: Bug
Components: cache
Affects Versions: 2.8.1
Reporter: Keshava Munegowda
when the ignite was used in the cluster node mode (not the thin client), the
cache closed exceptions are observed.
here is full log:
WARNING: An illegal reflective access operation has occurred
WARNING: Illegal reflective access by
org.apache.ignite.internal.util.GridUnsafe$2
(file:/data/kmg/SBK/build/install/sbk/lib/ignite-core-2.8.1.jar) to field
java.nio.Buffer.address
WARNING: Please consider reporting this to the maintainers of
org.apache.ignite.internal.util.GridUnsafe$2
WARNING: Use --illegal-access=warn to enable warnings of further illegal
reflective access operations
WARNING: All illegal access operations will be denied in a future release
0 [main] DEBUG org.springframework.core.env.StandardEnvironment - Adding
PropertySource 'systemProperties' with lowest search precedence
2 [main] DEBUG org.springframework.core.env.StandardEnvironment - Adding
PropertySource 'systemEnvironment' with lowest search precedence
2 [main] DEBUG org.springframework.core.env.StandardEnvironment - Initialized
StandardEnvironment with PropertySources [MapPropertySource@1220806149
{name='systemProperties', properties={awt.toolkit=sun.awt.X11.XToolkit,
java.specification.version=11, sun.cpu.isalist=, sun.jnu.encoding=UTF-8,
[jira] [Commented] (IGNITE-13098) TcpCommunicationSpi split to independent classes
[
https://issues.apache.org/jira/browse/IGNITE-13098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170720#comment-17170720
]
Ignite TC Bot commented on IGNITE-13098:
{panel:title=Branch: [pull/8057/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/8057/head] Base: [master] : New Tests
(8)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Service Grid{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5510335]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=46acc15b371-74cb2904-83ac-4347-96c9-27716e55ae2a, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=d7d06a3c-62c6-4a8a-abc7-65fe008865b0, topVer=0, msgTemplate=null,
span=null, nodeId8=d7d06a3c, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1596470772632]], val2=AffinityTopologyVersion
[topVer=-6491574591164370428, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=46acc15b371-74cb2904-83ac-4347-96c9-27716e55ae2a, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=d7d06a3c-62c6-4a8a-abc7-65fe008865b0, topVer=0, msgTemplate=null,
span=null, nodeId8=d7d06a3c, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1596470772632]], val2=AffinityTopologyVersion
[topVer=-6491574591164370428, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=dd270f16-4836-4fa7-9f9c-b9b8be3961ce, topVer=0,
msgTemplate=null, span=null, nodeId8=372ef472, msg=, type=NODE_JOINED,
tstamp=1596470772632], val2=AffinityTopologyVersion
[topVer=-8763859702679294079, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=dd270f16-4836-4fa7-9f9c-b9b8be3961ce, topVer=0,
msgTemplate=null, span=null, nodeId8=372ef472, msg=, type=NODE_JOINED,
tstamp=1596470772632], val2=AffinityTopologyVersion
[topVer=-8763859702679294079, minorTopVer=0]]] - PASSED{color}
{color:#8b}Service Grid (legacy mode){color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=5510336]]
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=dc8cf342-6566-4b21-963e-9e7c97c6f990, topVer=0,
msgTemplate=null, span=null, nodeId8=7e1f90b0, msg=, type=NODE_JOINED,
tstamp=1596470697262], val2=AffinityTopologyVersion
[topVer=4988132546913497014, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryEvent [evtNode=dc8cf342-6566-4b21-963e-9e7c97c6f990, topVer=0,
msgTemplate=null, span=null, nodeId8=7e1f90b0, msg=, type=NODE_JOINED,
tstamp=1596470697262], val2=AffinityTopologyVersion
[topVer=4988132546913497014, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.topologyVersion[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=23d9115b371-c0207a62-1b23-4f7a-bc98-94d1344b04d0, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=c20579c7-aadb-4f7f-82e1-9bef66bda40a, topVer=0, msgTemplate=null,
span=null, nodeId8=c20579c7, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1596470697262]], val2=AffinityTopologyVersion
[topVer=8457328299814147369, minorTopVer=0]]] - PASSED{color}
* {color:#013220}IgniteServiceGridTestSuite:
ServiceDeploymentProcessIdSelfTest.requestId[Test event=IgniteBiTuple
[val1=DiscoveryCustomEvent [customMsg=ServiceChangeBatchRequest
[id=23d9115b371-c0207a62-1b23-4f7a-bc98-94d1344b04d0, reqs=SingletonList
[ServiceUndeploymentRequest []]], affTopVer=null, super=DiscoveryEvent
[evtNode=c20579c7-aadb-4f7f-82e1-9bef66bda40a, topVer=0, msgTemplate=null,
span=null, nodeId8=c20579c7, msg=null, type=DISCOVERY_CUSTOM_EVT,
tstamp=1596470697262]], val2=AffinityTopologyVersion
[topVer=8457328299814147369, minorTopVer=0]]] - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5510358buildTypeId=IgniteTests24Java8_RunAll]
> TcpCommunicationSpi split to independent classes
>
>
> Key: IGNITE-13098
> URL:
[jira] [Resolved] (IGNITE-13279) Ignition.start failing with error java.lang.IllegalStateException: Failed to parse version: -1595322995-
[
https://issues.apache.org/jira/browse/IGNITE-13279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Keshava Munegowda resolved IGNITE-13279.
Fix Version/s: 2.8.1
Resolution: Fixed
> Ignition.start failing with error java.lang.IllegalStateException: Failed to
> parse version: -1595322995-
>
>
> Key: IGNITE-13279
> URL: https://issues.apache.org/jira/browse/IGNITE-13279
> Project: Ignite
> Issue Type: Bug
> Components: examples, general
>Affects Versions: 2.8.1
>Reporter: Keshava Munegowda
>Priority: Critical
> Fix For: 2.8.1
>
>
> I am using the Apache ignite : apache-ignite-2.8.1-bin
> I started the apache iginite node using : ./bin/ignite.sh
> ./examples/config/example-ignite.xml
> The node is successful started with this message:
> ```
> [root@mdw apache-ignite-2.8.1-bin]# ./bin/ignite.sh
> ./examples/config/example-ignite.xml
> [02:19:43] __
> [02:19:43] / _/ ___/ |/ / _/_ __/ __/
> [02:19:43] _/ // (7 7 // / / / / _/
> [02:19:43] /___/\___/_/|_/___/ /_/ /___/
> [02:19:43]
> [02:19:43] ver. 2.8.1#20200521-sha1:86422096
> [02:19:43] 2020 Copyright(C) Apache Software Foundation
> [02:19:43]
> [02:19:43] Ignite documentation: http://ignite.apache.org
> [02:19:43]
> [02:19:43] Quiet mode.
> [02:19:43] ^-- Logging to file
> '/data/kmg/apache-ignite-2.8.1-bin/work/log/ignite-4135cf96.0.log'
> [02:19:43] ^-- Logging by 'JavaLogger [quiet=true, config=null]'
> [02:19:43] ^-- To see **FULL** console log here add -DIGNITE_QUIET=false or
> "-v" to ignite.\{sh|bat}
> [02:19:43]
> [02:19:43] OS: Linux 3.10.0-1127.el7.x86_64 amd64
> [02:19:43] VM information: OpenJDK Runtime Environment 1.8.0_252-b09 Oracle
> Corporation OpenJDK 64-Bit Server VM 25.252-b09
> [02:19:43] Please set system property '-Djava.net.preferIPv4Stack=true' to
> avoid possible problems in mixed environments.
> [02:19:43] Configured plugins:
> [02:19:43] ^-- None
> [02:19:43]
> [02:19:43] Configured failure handler: [hnd=StopNodeOrHaltFailureHandler
> [tryStop=false, timeout=0, super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT
> [02:19:46] Message queue limit is set to 0 which may lead to potential OOMEs
> when running cache operations in FULL_ASYNC or PRIMARY_SYNC modes due to
> message queues growth on sender and receiver sides.
> [02:19:46] Security status [authentication=off, tls/ssl=off]
> [02:19:48] Performance suggestions for grid (fix if possible)
> [02:19:48] To disable, set -DIGNITE_PERFORMANCE_SUGGESTIONS_DISABLED=true
> [02:19:48] ^-- Disable grid events (remove 'includeEventTypes' from
> configuration)
> [02:19:48] ^-- Enable G1 Garbage Collector (add '-XX:+UseG1GC' to JVM options)
> [02:19:48] ^-- Specify JVM heap max size (add '-Xmx[g|G|m|M|k|K]' to
> JVM options)
> [02:19:48] ^-- Set max direct memory size if getting 'OOME: Direct buffer
> memory' (add '-XX:MaxDirectMemorySize=[g|G|m|M|k|K]' to JVM options)
> [02:19:48] ^-- Disable processing of calls to System.gc() (add
> '-XX:+DisableExplicitGC' to JVM options)
> [02:19:48] ^-- Speed up flushing of dirty pages by OS (alter
> vm.dirty_expire_centisecs parameter by setting to 500)
> [02:19:48] Refer to this page for more performance suggestions:
> https://apacheignite.readme.io/docs/jvm-and-system-tuning
> [02:19:48]
> [02:19:48] To start Console Management & Monitoring run
> ignitevisorcmd.\{sh|bat}
> [02:19:48] Data Regions Configured:
> [02:19:48] ^-- default [initSize=256.0 MiB, maxSize=75.5 GiB,
> persistence=false, lazyMemoryAllocation=true]
> [02:19:48]
> [02:19:48] Ignite node started OK (id=4135cf96)
> [02:19:48] Topology snapshot [ver=1, locNode=4135cf96, servers=1, clients=0,
> state=ACTIVE, CPUs=32, offheap=76.0GB, heap=27.0GB]
> [02:19:48] ^-- Baseline [id=0, size=1, online=1, offline=0]
> ```
> Now, I have benchmarking application, which start the apache iginitition
> using the java API
> Ignition.start("examples/config/example-ignite.xml");
> This method is failing with below error log:
> ```
> 0 [main] DEBUG org.springframework.core.env.StandardEnvironment - Adding
> PropertySource 'systemProperties' with lowest search precedence
> 2 [main] DEBUG org.springframework.core.env.StandardEnvironment - Adding
> PropertySource 'systemEnvironment' with lowest search precedence
> 3 [main] DEBUG org.springframework.core.env.StandardEnvironment - Initialized
> StandardEnvironment with PropertySources [MapPropertySource@1928301845
> {name='systemProperties', properties={java.runtime.name=OpenJDK Runtime
> Environment,
> sun.boot.library.path=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.252.b09-2.el7_8.x86_64/jre/lib/amd64,
> java.vm.version=25.252-b09,
[jira] [Commented] (IGNITE-13321) Control utility doesn't print results to stdout.
[
https://issues.apache.org/jira/browse/IGNITE-13321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170716#comment-17170716
]
Ivan Daschinskiy commented on IGNITE-13321:
---
[~kuaw26] Alexey, as a PMC member, may be you can provide quick fix? Can you
revert your commit? This issue blocks ignite functional test activity
(ducktape), because control.sh in master branch is broken.
> Control utility doesn't print results to stdout.
>
>
> Key: IGNITE-13321
> URL: https://issues.apache.org/jira/browse/IGNITE-13321
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Affects Versions: 2.10
>Reporter: Ivan Daschinskiy
>Assignee: Alexey Kuznetsov
>Priority: Blocker
> Fix For: 2.10
>
>
> After merging
> [IGNITE-13262|https://issues.apache.org/jira/browse/IGNITE-13262 ]
> {{control.sh}} doesn't work properly either in dev mode, or in release mode.
> Specifically, no output printed in stdout.
> For example, incorrect output for {{control.sh -baseline set}} after commit
> is:
> {code:sh}
> Control utility [ver. 2.10.0-SNAPSHOT#20200803-sha1:DEV],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:24:33.193,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
>
> {code}
> Correct output for {{control.sh -baseline set}} before commit is:
> {code}
> Control utility [ver. 2.8.1#20200521-sha1:86422096],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:23:55.793,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
> ,
>
> Cluster state: active,
> Current topology version: 3,
> Baseline auto adjustment disabled: softTimeout=30
>Current topology version: 3 (Coordinator: ConsistentId=ducker02, Order=1)
> Baseline nodes:
>ConsistentId=ducker02, State=ONLINE, Order=1,
>ConsistentId=ducker03, State=ONLINE, Order=2,
>ConsistentId=ducker04, State=ONLINE, Order=3,
> ,
>
> Number of baseline nodes: 3,
> Other nodes not found.,
> Command [BASELINE] finished with code: 0,
> Control utility has completed execution at: 2020-08-03T14:23:57.351,
> Execution time: 1558 ms
> {code}
> However, command seems to execute and baseline actually changes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13321) Control utility doesn't print results to stdout.
[
https://issues.apache.org/jira/browse/IGNITE-13321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170683#comment-17170683
]
Alexey Kuznetsov commented on IGNITE-13321:
---
I'll investigate and fix this issue.
> Control utility doesn't print results to stdout.
>
>
> Key: IGNITE-13321
> URL: https://issues.apache.org/jira/browse/IGNITE-13321
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Affects Versions: 2.10
>Reporter: Ivan Daschinskiy
>Assignee: Alexey Kuznetsov
>Priority: Blocker
> Fix For: 2.10
>
>
> After merging
> [IGNITE-13262|https://issues.apache.org/jira/browse/IGNITE-13262 ]
> {{control.sh}} doesn't work properly either in dev mode, or in release mode.
> Specifically, no output printed in stdout.
> For example, incorrect output for {{control.sh -baseline set}} after commit
> is:
> {code:sh}
> Control utility [ver. 2.10.0-SNAPSHOT#20200803-sha1:DEV],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:24:33.193,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
>
> {code}
> Correct output for {{control.sh -baseline set}} before commit is:
> {code}
> Control utility [ver. 2.8.1#20200521-sha1:86422096],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:23:55.793,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
> ,
>
> Cluster state: active,
> Current topology version: 3,
> Baseline auto adjustment disabled: softTimeout=30
>Current topology version: 3 (Coordinator: ConsistentId=ducker02, Order=1)
> Baseline nodes:
>ConsistentId=ducker02, State=ONLINE, Order=1,
>ConsistentId=ducker03, State=ONLINE, Order=2,
>ConsistentId=ducker04, State=ONLINE, Order=3,
> ,
>
> Number of baseline nodes: 3,
> Other nodes not found.,
> Command [BASELINE] finished with code: 0,
> Control utility has completed execution at: 2020-08-03T14:23:57.351,
> Execution time: 1558 ms
> {code}
> However, command seems to execute and baseline actually changes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13324) Create NoOp version of GridEncryptionManager for in-memory grid.
[ https://issues.apache.org/jira/browse/IGNITE-13324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-13324: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Create NoOp version of GridEncryptionManager for in-memory grid. > > > Key: IGNITE-13324 > URL: https://issues.apache.org/jira/browse/IGNITE-13324 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Minor > > GridEncryptionManager starts even on an in-memory grid, this introduces a > minor overhead and it seems better to create a simplified (no-op) version for > the in-memory grid. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13324) Create NoOp version of GridEncryptionManager for in-memory grid.
Pavel Pereslegin created IGNITE-13324: - Summary: Create NoOp version of GridEncryptionManager for in-memory grid. Key: IGNITE-13324 URL: https://issues.apache.org/jira/browse/IGNITE-13324 Project: Ignite Issue Type: Improvement Reporter: Pavel Pereslegin Assignee: Pavel Pereslegin GridEncryptionManager starts even on an in-memory grid, this introduces a minor overhead and it seems better to create a simplified (no-op) version for the in-memory grid. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13324) Create NoOp version of GridEncryptionManager for in-memory grid.
[ https://issues.apache.org/jira/browse/IGNITE-13324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin updated IGNITE-13324: -- Priority: Minor (was: Major) > Create NoOp version of GridEncryptionManager for in-memory grid. > > > Key: IGNITE-13324 > URL: https://issues.apache.org/jira/browse/IGNITE-13324 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Pereslegin >Assignee: Pavel Pereslegin >Priority: Minor > > GridEncryptionManager starts even on an in-memory grid, this introduces a > minor overhead and it seems better to create a simplified (no-op) version for > the in-memory grid. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13321) Control utility doesn't print results to stdout.
[
https://issues.apache.org/jira/browse/IGNITE-13321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170677#comment-17170677
]
Kirill Tkalenko commented on IGNITE-13321:
--
[~kuaw26] I will assign you a ticket because you did IGNITE-13262.
> Control utility doesn't print results to stdout.
>
>
> Key: IGNITE-13321
> URL: https://issues.apache.org/jira/browse/IGNITE-13321
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Affects Versions: 2.10
>Reporter: Ivan Daschinskiy
>Assignee: Alexey Kuznetsov
>Priority: Blocker
> Fix For: 2.10
>
>
> After merging
> [IGNITE-13262|https://issues.apache.org/jira/browse/IGNITE-13262 ]
> {{control.sh}} doesn't work properly either in dev mode, or in release mode.
> Specifically, no output printed in stdout.
> For example, incorrect output for {{control.sh -baseline set}} after commit
> is:
> {code:sh}
> Control utility [ver. 2.10.0-SNAPSHOT#20200803-sha1:DEV],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:24:33.193,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
>
> {code}
> Correct output for {{control.sh -baseline set}} before commit is:
> {code}
> Control utility [ver. 2.8.1#20200521-sha1:86422096],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:23:55.793,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
> ,
>
> Cluster state: active,
> Current topology version: 3,
> Baseline auto adjustment disabled: softTimeout=30
>Current topology version: 3 (Coordinator: ConsistentId=ducker02, Order=1)
> Baseline nodes:
>ConsistentId=ducker02, State=ONLINE, Order=1,
>ConsistentId=ducker03, State=ONLINE, Order=2,
>ConsistentId=ducker04, State=ONLINE, Order=3,
> ,
>
> Number of baseline nodes: 3,
> Other nodes not found.,
> Command [BASELINE] finished with code: 0,
> Control utility has completed execution at: 2020-08-03T14:23:57.351,
> Execution time: 1558 ms
> {code}
> However, command seems to execute and baseline actually changes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-13321) Control utility doesn't print results to stdout.
[
https://issues.apache.org/jira/browse/IGNITE-13321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko reassigned IGNITE-13321:
Assignee: Alexey Kuznetsov (was: Kirill Tkalenko)
> Control utility doesn't print results to stdout.
>
>
> Key: IGNITE-13321
> URL: https://issues.apache.org/jira/browse/IGNITE-13321
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Affects Versions: 2.10
>Reporter: Ivan Daschinskiy
>Assignee: Alexey Kuznetsov
>Priority: Blocker
> Fix For: 2.10
>
>
> After merging
> [IGNITE-13262|https://issues.apache.org/jira/browse/IGNITE-13262 ]
> {{control.sh}} doesn't work properly either in dev mode, or in release mode.
> Specifically, no output printed in stdout.
> For example, incorrect output for {{control.sh -baseline set}} after commit
> is:
> {code:sh}
> Control utility [ver. 2.10.0-SNAPSHOT#20200803-sha1:DEV],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:24:33.193,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
>
> {code}
> Correct output for {{control.sh -baseline set}} before commit is:
> {code}
> Control utility [ver. 2.8.1#20200521-sha1:86422096],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:23:55.793,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
> ,
>
> Cluster state: active,
> Current topology version: 3,
> Baseline auto adjustment disabled: softTimeout=30
>Current topology version: 3 (Coordinator: ConsistentId=ducker02, Order=1)
> Baseline nodes:
>ConsistentId=ducker02, State=ONLINE, Order=1,
>ConsistentId=ducker03, State=ONLINE, Order=2,
>ConsistentId=ducker04, State=ONLINE, Order=3,
> ,
>
> Number of baseline nodes: 3,
> Other nodes not found.,
> Command [BASELINE] finished with code: 0,
> Control utility has completed execution at: 2020-08-03T14:23:57.351,
> Execution time: 1558 ms
> {code}
> However, command seems to execute and baseline actually changes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-13322) Make GridDhtPartitionsExchangeFuture#srvNodes thread-safe
[ https://issues.apache.org/jira/browse/IGNITE-13322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov reassigned IGNITE-13322: --- Assignee: Yaroslav Molochkov > Make GridDhtPartitionsExchangeFuture#srvNodes thread-safe > - > > Key: IGNITE-13322 > URL: https://issues.apache.org/jira/browse/IGNITE-13322 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.8.1 >Reporter: Yaroslav Molochkov >Assignee: Yaroslav Molochkov >Priority: Major > > Currently > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture#srvNodes > reference is initialised to the ArrayList, which is not a thread-safe > implementation. > Solution to this ticket must guarantee thread-safety of the srvNodes > collection. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-13323) GridDhtPartitionsExchangeFuture logging improvements
[ https://issues.apache.org/jira/browse/IGNITE-13323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yaroslav Molochkov reassigned IGNITE-13323: --- Assignee: Yaroslav Molochkov > GridDhtPartitionsExchangeFuture logging improvements > > > Key: IGNITE-13323 > URL: https://issues.apache.org/jira/browse/IGNITE-13323 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.8.1 >Reporter: Yaroslav Molochkov >Assignee: Yaroslav Molochkov >Priority: Major > > Firstly, logging in said class should be improved to address possible cluster > topology/connectivity issues: > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture#processFullMessage, > upon entering that method and before critical section begins we should log > that at info level. This way we won't have to speculate if thread is waiting > on a lock to > not.(org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture#mux) > Secondly, > org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture#sendAllPartitions. > Logging should reflect the amount of nodes that should receive messages > (collection that is sent to said method) and the amount of nodes that should > receive the message (or, in other words, we successfully managed to send the > message to a particular node, then sum it up). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13321) Control utility doesn't print results to stdout.
[
https://issues.apache.org/jira/browse/IGNITE-13321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170672#comment-17170672
]
Kirill Tkalenko commented on IGNITE-13321:
--
OK, you can roll back IGNITE-13262. Then do the right thing.
> Control utility doesn't print results to stdout.
>
>
> Key: IGNITE-13321
> URL: https://issues.apache.org/jira/browse/IGNITE-13321
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Affects Versions: 2.10
>Reporter: Ivan Daschinskiy
>Assignee: Kirill Tkalenko
>Priority: Blocker
> Fix For: 2.10
>
>
> After merging
> [IGNITE-13262|https://issues.apache.org/jira/browse/IGNITE-13262 ]
> {{control.sh}} doesn't work properly either in dev mode, or in release mode.
> Specifically, no output printed in stdout.
> For example, incorrect output for {{control.sh -baseline set}} after commit
> is:
> {code:sh}
> Control utility [ver. 2.10.0-SNAPSHOT#20200803-sha1:DEV],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:24:33.193,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
>
> {code}
> Correct output for {{control.sh -baseline set}} before commit is:
> {code}
> Control utility [ver. 2.8.1#20200521-sha1:86422096],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:23:55.793,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
> ,
>
> Cluster state: active,
> Current topology version: 3,
> Baseline auto adjustment disabled: softTimeout=30
>Current topology version: 3 (Coordinator: ConsistentId=ducker02, Order=1)
> Baseline nodes:
>ConsistentId=ducker02, State=ONLINE, Order=1,
>ConsistentId=ducker03, State=ONLINE, Order=2,
>ConsistentId=ducker04, State=ONLINE, Order=3,
> ,
>
> Number of baseline nodes: 3,
> Other nodes not found.,
> Command [BASELINE] finished with code: 0,
> Control utility has completed execution at: 2020-08-03T14:23:57.351,
> Execution time: 1558 ms
> {code}
> However, command seems to execute and baseline actually changes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (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:comment-tabpanel=17170667#comment-17170667 ] Semyon Danilov commented on IGNITE-13013: - I was able to validate that changes indeed fix the problem for Azure, however it is worth mentioning that working in serverless mode with Azure or AWS requires additional configuration. # IGNITE_HOME must be configured to use temporary dir # Address resolver must be configured for server node (node local address -> node public address) # Default timeouts of functions are really small, thick client won't be able to start so fast > 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 > > Attachments: image-2020-07-30-18-42-01-266.png > > Time Spent: 10m > Remaining Estimate: 0h > > 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)
[jira] [Commented] (IGNITE-13321) Control utility doesn't print results to stdout.
[
https://issues.apache.org/jira/browse/IGNITE-13321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170666#comment-17170666
]
Ivan Daschinskiy commented on IGNITE-13321:
---
Yes, but if set -DQUITE=false, we see output with formatted pattern. This is
not expected behaviour. IgniteLogger is created not for CMD output, so it is
not a good choice right now for control utility.
> Control utility doesn't print results to stdout.
>
>
> Key: IGNITE-13321
> URL: https://issues.apache.org/jira/browse/IGNITE-13321
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Affects Versions: 2.10
>Reporter: Ivan Daschinskiy
>Assignee: Kirill Tkalenko
>Priority: Blocker
> Fix For: 2.10
>
>
> After merging
> [IGNITE-13262|https://issues.apache.org/jira/browse/IGNITE-13262 ]
> {{control.sh}} doesn't work properly either in dev mode, or in release mode.
> Specifically, no output printed in stdout.
> For example, incorrect output for {{control.sh -baseline set}} after commit
> is:
> {code:sh}
> Control utility [ver. 2.10.0-SNAPSHOT#20200803-sha1:DEV],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:24:33.193,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
>
> {code}
> Correct output for {{control.sh -baseline set}} before commit is:
> {code}
> Control utility [ver. 2.8.1#20200521-sha1:86422096],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:23:55.793,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
> ,
>
> Cluster state: active,
> Current topology version: 3,
> Baseline auto adjustment disabled: softTimeout=30
>Current topology version: 3 (Coordinator: ConsistentId=ducker02, Order=1)
> Baseline nodes:
>ConsistentId=ducker02, State=ONLINE, Order=1,
>ConsistentId=ducker03, State=ONLINE, Order=2,
>ConsistentId=ducker04, State=ONLINE, Order=3,
> ,
>
> Number of baseline nodes: 3,
> Other nodes not found.,
> Command [BASELINE] finished with code: 0,
> Control utility has completed execution at: 2020-08-03T14:23:57.351,
> Execution time: 1558 ms
> {code}
> However, command seems to execute and baseline actually changes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13321) Control utility doesn't print results to stdout.
[
https://issues.apache.org/jira/browse/IGNITE-13321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170663#comment-17170663
]
Kirill Tkalenko commented on IGNITE-13321:
--
A little more analyzed, [1] returns {color:red}false{color}, but in [2]
"*cfgUrl*" is not {color:red}null{color}.
[1] - org.apache.ignite.logger.java.JavaLogger#isConfigured
[2] - org.apache.ignite.logger.java.JavaLogger#defaultConfiguration
> Control utility doesn't print results to stdout.
>
>
> Key: IGNITE-13321
> URL: https://issues.apache.org/jira/browse/IGNITE-13321
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Affects Versions: 2.10
>Reporter: Ivan Daschinskiy
>Assignee: Kirill Tkalenko
>Priority: Blocker
> Fix For: 2.10
>
>
> After merging
> [IGNITE-13262|https://issues.apache.org/jira/browse/IGNITE-13262 ]
> {{control.sh}} doesn't work properly either in dev mode, or in release mode.
> Specifically, no output printed in stdout.
> For example, incorrect output for {{control.sh -baseline set}} after commit
> is:
> {code:sh}
> Control utility [ver. 2.10.0-SNAPSHOT#20200803-sha1:DEV],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:24:33.193,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
>
> {code}
> Correct output for {{control.sh -baseline set}} before commit is:
> {code}
> Control utility [ver. 2.8.1#20200521-sha1:86422096],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:23:55.793,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
> ,
>
> Cluster state: active,
> Current topology version: 3,
> Baseline auto adjustment disabled: softTimeout=30
>Current topology version: 3 (Coordinator: ConsistentId=ducker02, Order=1)
> Baseline nodes:
>ConsistentId=ducker02, State=ONLINE, Order=1,
>ConsistentId=ducker03, State=ONLINE, Order=2,
>ConsistentId=ducker04, State=ONLINE, Order=3,
> ,
>
> Number of baseline nodes: 3,
> Other nodes not found.,
> Command [BASELINE] finished with code: 0,
> Control utility has completed execution at: 2020-08-03T14:23:57.351,
> Execution time: 1558 ms
> {code}
> However, command seems to execute and baseline actually changes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13321) Control utility doesn't print results to stdout.
[
https://issues.apache.org/jira/browse/IGNITE-13321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170662#comment-17170662
]
Ivan Daschinskiy commented on IGNITE-13321:
---
1) Firstly, we should fix blocker.
2) When blocker is fixed, we can think about refactoring, beauty of code,
modularization, KISS, SOLID etc. etc.
> Control utility doesn't print results to stdout.
>
>
> Key: IGNITE-13321
> URL: https://issues.apache.org/jira/browse/IGNITE-13321
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Affects Versions: 2.10
>Reporter: Ivan Daschinskiy
>Assignee: Kirill Tkalenko
>Priority: Blocker
> Fix For: 2.10
>
>
> After merging
> [IGNITE-13262|https://issues.apache.org/jira/browse/IGNITE-13262 ]
> {{control.sh}} doesn't work properly either in dev mode, or in release mode.
> Specifically, no output printed in stdout.
> For example, incorrect output for {{control.sh -baseline set}} after commit
> is:
> {code:sh}
> Control utility [ver. 2.10.0-SNAPSHOT#20200803-sha1:DEV],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:24:33.193,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
>
> {code}
> Correct output for {{control.sh -baseline set}} before commit is:
> {code}
> Control utility [ver. 2.8.1#20200521-sha1:86422096],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:23:55.793,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
> ,
>
> Cluster state: active,
> Current topology version: 3,
> Baseline auto adjustment disabled: softTimeout=30
>Current topology version: 3 (Coordinator: ConsistentId=ducker02, Order=1)
> Baseline nodes:
>ConsistentId=ducker02, State=ONLINE, Order=1,
>ConsistentId=ducker03, State=ONLINE, Order=2,
>ConsistentId=ducker04, State=ONLINE, Order=3,
> ,
>
> Number of baseline nodes: 3,
> Other nodes not found.,
> Command [BASELINE] finished with code: 0,
> Control utility has completed execution at: 2020-08-03T14:23:57.351,
> Execution time: 1558 ms
> {code}
> However, command seems to execute and baseline actually changes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13321) Control utility doesn't print results to stdout.
[
https://issues.apache.org/jira/browse/IGNITE-13321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170660#comment-17170660
]
Kirill Tkalenko commented on IGNITE-13321:
--
I think we can think a little about right decision.
> Control utility doesn't print results to stdout.
>
>
> Key: IGNITE-13321
> URL: https://issues.apache.org/jira/browse/IGNITE-13321
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Affects Versions: 2.10
>Reporter: Ivan Daschinskiy
>Assignee: Kirill Tkalenko
>Priority: Blocker
> Fix For: 2.10
>
>
> After merging
> [IGNITE-13262|https://issues.apache.org/jira/browse/IGNITE-13262 ]
> {{control.sh}} doesn't work properly either in dev mode, or in release mode.
> Specifically, no output printed in stdout.
> For example, incorrect output for {{control.sh -baseline set}} after commit
> is:
> {code:sh}
> Control utility [ver. 2.10.0-SNAPSHOT#20200803-sha1:DEV],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:24:33.193,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
>
> {code}
> Correct output for {{control.sh -baseline set}} before commit is:
> {code}
> Control utility [ver. 2.8.1#20200521-sha1:86422096],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:23:55.793,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
> ,
>
> Cluster state: active,
> Current topology version: 3,
> Baseline auto adjustment disabled: softTimeout=30
>Current topology version: 3 (Coordinator: ConsistentId=ducker02, Order=1)
> Baseline nodes:
>ConsistentId=ducker02, State=ONLINE, Order=1,
>ConsistentId=ducker03, State=ONLINE, Order=2,
>ConsistentId=ducker04, State=ONLINE, Order=3,
> ,
>
> Number of baseline nodes: 3,
> Other nodes not found.,
> Command [BASELINE] finished with code: 0,
> Control utility has completed execution at: 2020-08-03T14:23:57.351,
> Execution time: 1558 ms
> {code}
> However, command seems to execute and baseline actually changes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13321) Control utility doesn't print results to stdout.
[
https://issues.apache.org/jira/browse/IGNITE-13321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170655#comment-17170655
]
Ivan Daschinskiy commented on IGNITE-13321:
---
Confirm, that reverting back to bare JUL works. I don't suppose, that here we
should use {{IgniteLogger}} as is. It is used for another purpose, has
additional not needed functionality, add patterns to stdout etc. Currently we
can simply partialy revert offending commit.
> Control utility doesn't print results to stdout.
>
>
> Key: IGNITE-13321
> URL: https://issues.apache.org/jira/browse/IGNITE-13321
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Affects Versions: 2.10
>Reporter: Ivan Daschinskiy
>Assignee: Kirill Tkalenko
>Priority: Blocker
> Fix For: 2.10
>
>
> After merging
> [IGNITE-13262|https://issues.apache.org/jira/browse/IGNITE-13262 ]
> {{control.sh}} doesn't work properly either in dev mode, or in release mode.
> Specifically, no output printed in stdout.
> For example, incorrect output for {{control.sh -baseline set}} after commit
> is:
> {code:sh}
> Control utility [ver. 2.10.0-SNAPSHOT#20200803-sha1:DEV],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:24:33.193,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
>
> {code}
> Correct output for {{control.sh -baseline set}} before commit is:
> {code}
> Control utility [ver. 2.8.1#20200521-sha1:86422096],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:23:55.793,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
> ,
>
> Cluster state: active,
> Current topology version: 3,
> Baseline auto adjustment disabled: softTimeout=30
>Current topology version: 3 (Coordinator: ConsistentId=ducker02, Order=1)
> Baseline nodes:
>ConsistentId=ducker02, State=ONLINE, Order=1,
>ConsistentId=ducker03, State=ONLINE, Order=2,
>ConsistentId=ducker04, State=ONLINE, Order=3,
> ,
>
> Number of baseline nodes: 3,
> Other nodes not found.,
> Command [BASELINE] finished with code: 0,
> Control utility has completed execution at: 2020-08-03T14:23:57.351,
> Execution time: 1558 ms
> {code}
> However, command seems to execute and baseline actually changes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13321) Control utility doesn't print results to stdout.
[
https://issues.apache.org/jira/browse/IGNITE-13321?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy updated IGNITE-13321:
--
Description:
After merging [IGNITE-13262|https://issues.apache.org/jira/browse/IGNITE-13262
] {{control.sh}} doesn't work properly either in dev mode, or in release mode.
Specifically, no output printed in stdout.
For example, incorrect output for {{control.sh -baseline set}} after commit is:
{code:sh}
Control utility [ver. 2.10.0-SNAPSHOT#20200803-sha1:DEV],
2020 Copyright(C) Apache Software Foundation,
User: ducker,
Time: 2020-08-03T14:24:33.193,
Command [BASELINE] started,
Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
{code}
Correct output for {{control.sh -baseline set}} before commit is:
{code}
Control utility [ver. 2.8.1#20200521-sha1:86422096],
2020 Copyright(C) Apache Software Foundation,
User: ducker,
Time: 2020-08-03T14:23:55.793,
Command [BASELINE] started,
Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
,
Cluster state: active,
Current topology version: 3,
Baseline auto adjustment disabled: softTimeout=30
Current topology version: 3 (Coordinator: ConsistentId=ducker02, Order=1)
Baseline nodes:
ConsistentId=ducker02, State=ONLINE, Order=1,
ConsistentId=ducker03, State=ONLINE, Order=2,
ConsistentId=ducker04, State=ONLINE, Order=3,
,
Number of baseline nodes: 3,
Other nodes not found.,
Command [BASELINE] finished with code: 0,
Control utility has completed execution at: 2020-08-03T14:23:57.351,
Execution time: 1558 ms
{code}
However, command seems to execute and baseline actually changes.
was:
After merging [IGNITE-13123|https://issues.apache.org/jira/browse/IGNITE-13123]
{{control.sh}} doesn't work properly either in dev mode, or in release mode.
Specifically, no output printed in stdout.
For example, incorrect output for {{control.sh -baseline set}} after commit is:
{code:sh}
Control utility [ver. 2.10.0-SNAPSHOT#20200803-sha1:DEV],
2020 Copyright(C) Apache Software Foundation,
User: ducker,
Time: 2020-08-03T14:24:33.193,
Command [BASELINE] started,
Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
{code}
Correct output for {{control.sh -baseline set}} before commit is:
{code}
Control utility [ver. 2.8.1#20200521-sha1:86422096],
2020 Copyright(C) Apache Software Foundation,
User: ducker,
Time: 2020-08-03T14:23:55.793,
Command [BASELINE] started,
Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
,
Cluster state: active,
Current topology version: 3,
Baseline auto adjustment disabled: softTimeout=30
Current topology version: 3 (Coordinator: ConsistentId=ducker02, Order=1)
Baseline nodes:
ConsistentId=ducker02, State=ONLINE, Order=1,
ConsistentId=ducker03, State=ONLINE, Order=2,
ConsistentId=ducker04, State=ONLINE, Order=3,
,
Number of baseline nodes: 3,
Other nodes not found.,
Command [BASELINE] finished with code: 0,
Control utility has completed execution at: 2020-08-03T14:23:57.351,
Execution time: 1558 ms
{code}
However, command seems to execute and baseline actually changes.
> Control utility doesn't print results to stdout.
>
>
> Key: IGNITE-13321
> URL: https://issues.apache.org/jira/browse/IGNITE-13321
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Affects Versions: 2.10
>Reporter: Ivan Daschinskiy
>Assignee: Kirill Tkalenko
>Priority: Blocker
> Fix For: 2.10
>
>
> After merging
> [IGNITE-13262|https://issues.apache.org/jira/browse/IGNITE-13262 ]
> {{control.sh}} doesn't work properly either in dev mode, or in release mode.
> Specifically, no output printed in stdout.
> For example, incorrect output for {{control.sh -baseline set}} after commit
> is:
> {code:sh}
> Control utility [ver. 2.10.0-SNAPSHOT#20200803-sha1:DEV],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:24:33.193,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
>
[jira] [Commented] (IGNITE-13321) Control utility doesn't print results to stdout.
[
https://issues.apache.org/jira/browse/IGNITE-13321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170634#comment-17170634
]
Kirill Tkalenko commented on IGNITE-13321:
--
[~ivandasch] I found that the system property is missing
"java.util.logging.config.file".
This is where it is checked:
{code:java}
org.apache.ignite.logger.java.JavaLogger#isConfigured
{code}
> Control utility doesn't print results to stdout.
>
>
> Key: IGNITE-13321
> URL: https://issues.apache.org/jira/browse/IGNITE-13321
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Affects Versions: 2.10
>Reporter: Ivan Daschinskiy
>Assignee: Kirill Tkalenko
>Priority: Blocker
> Fix For: 2.10
>
>
> After merging
> [IGNITE-13123|https://issues.apache.org/jira/browse/IGNITE-13123]
> {{control.sh}} doesn't work properly either in dev mode, or in release mode.
> Specifically, no output printed in stdout.
> For example, incorrect output for {{control.sh -baseline set}} after commit
> is:
> {code:sh}
> Control utility [ver. 2.10.0-SNAPSHOT#20200803-sha1:DEV],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:24:33.193,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
>
> {code}
> Correct output for {{control.sh -baseline set}} before commit is:
> {code}
> Control utility [ver. 2.8.1#20200521-sha1:86422096],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:23:55.793,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
> ,
>
> Cluster state: active,
> Current topology version: 3,
> Baseline auto adjustment disabled: softTimeout=30
>Current topology version: 3 (Coordinator: ConsistentId=ducker02, Order=1)
> Baseline nodes:
>ConsistentId=ducker02, State=ONLINE, Order=1,
>ConsistentId=ducker03, State=ONLINE, Order=2,
>ConsistentId=ducker04, State=ONLINE, Order=3,
> ,
>
> Number of baseline nodes: 3,
> Other nodes not found.,
> Command [BASELINE] finished with code: 0,
> Control utility has completed execution at: 2020-08-03T14:23:57.351,
> Execution time: 1558 ms
> {code}
> However, command seems to execute and baseline actually changes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13321) Control utility doesn't print results to stdout.
[
https://issues.apache.org/jira/browse/IGNITE-13321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170634#comment-17170634
]
Kirill Tkalenko edited comment on IGNITE-13321 at 8/4/20, 7:53 AM:
---
[~ivandasch] I found that the system property is missing
"*java.util.logging.config.file*".
This is where it is checked:
{code:java}
org.apache.ignite.logger.java.JavaLogger#isConfigured
{code}
was (Author: ktkale...@gridgain.com):
[~ivandasch] I found that the system property is missing
"java.util.logging.config.file".
This is where it is checked:
{code:java}
org.apache.ignite.logger.java.JavaLogger#isConfigured
{code}
> Control utility doesn't print results to stdout.
>
>
> Key: IGNITE-13321
> URL: https://issues.apache.org/jira/browse/IGNITE-13321
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Affects Versions: 2.10
>Reporter: Ivan Daschinskiy
>Assignee: Kirill Tkalenko
>Priority: Blocker
> Fix For: 2.10
>
>
> After merging
> [IGNITE-13123|https://issues.apache.org/jira/browse/IGNITE-13123]
> {{control.sh}} doesn't work properly either in dev mode, or in release mode.
> Specifically, no output printed in stdout.
> For example, incorrect output for {{control.sh -baseline set}} after commit
> is:
> {code:sh}
> Control utility [ver. 2.10.0-SNAPSHOT#20200803-sha1:DEV],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:24:33.193,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
>
> {code}
> Correct output for {{control.sh -baseline set}} before commit is:
> {code}
> Control utility [ver. 2.8.1#20200521-sha1:86422096],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:23:55.793,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
> ,
>
> Cluster state: active,
> Current topology version: 3,
> Baseline auto adjustment disabled: softTimeout=30
>Current topology version: 3 (Coordinator: ConsistentId=ducker02, Order=1)
> Baseline nodes:
>ConsistentId=ducker02, State=ONLINE, Order=1,
>ConsistentId=ducker03, State=ONLINE, Order=2,
>ConsistentId=ducker04, State=ONLINE, Order=3,
> ,
>
> Number of baseline nodes: 3,
> Other nodes not found.,
> Command [BASELINE] finished with code: 0,
> Control utility has completed execution at: 2020-08-03T14:23:57.351,
> Execution time: 1558 ms
> {code}
> However, command seems to execute and baseline actually changes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13321) Control utility doesn't print results to stdout.
[
https://issues.apache.org/jira/browse/IGNITE-13321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170614#comment-17170614
]
Kirill Tkalenko edited comment on IGNITE-13321 at 8/4/20, 7:44 AM:
---
Hi, [~ivandasch]!
I tried to analyze code and compare it with 2.8.1 and found that problem is
changing logging in IGNITE-13262, for
{code:java}
org.apache.ignite.internal.client.impl.connection.GridClientTopology#log
org.apache.ignite.internal.client.impl.connection.GridClientConnectionManagerAdapter#log
{code}
If you try to roll back the loggers, everything works.
was (Author: ktkale...@gridgain.com):
Hi, [~ivandasch]!
I tried to analyze code and compare it with 2.8.1 and found that problem is
changing logging in IGNITE-13262, for
{code:java}
org.apache.ignite.internal.client.impl.connection.GridClientTopology#log
org.apache.ignite.internal.client.impl.connection.GridClientConnectionManagerAdapter#log
{code}
> Control utility doesn't print results to stdout.
>
>
> Key: IGNITE-13321
> URL: https://issues.apache.org/jira/browse/IGNITE-13321
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Affects Versions: 2.10
>Reporter: Ivan Daschinskiy
>Assignee: Kirill Tkalenko
>Priority: Blocker
> Fix For: 2.10
>
>
> After merging
> [IGNITE-13123|https://issues.apache.org/jira/browse/IGNITE-13123]
> {{control.sh}} doesn't work properly either in dev mode, or in release mode.
> Specifically, no output printed in stdout.
> For example, incorrect output for {{control.sh -baseline set}} after commit
> is:
> {code:sh}
> Control utility [ver. 2.10.0-SNAPSHOT#20200803-sha1:DEV],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:24:33.193,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
>
> {code}
> Correct output for {{control.sh -baseline set}} before commit is:
> {code}
> Control utility [ver. 2.8.1#20200521-sha1:86422096],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:23:55.793,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
> ,
>
> Cluster state: active,
> Current topology version: 3,
> Baseline auto adjustment disabled: softTimeout=30
>Current topology version: 3 (Coordinator: ConsistentId=ducker02, Order=1)
> Baseline nodes:
>ConsistentId=ducker02, State=ONLINE, Order=1,
>ConsistentId=ducker03, State=ONLINE, Order=2,
>ConsistentId=ducker04, State=ONLINE, Order=3,
> ,
>
> Number of baseline nodes: 3,
> Other nodes not found.,
> Command [BASELINE] finished with code: 0,
> Control utility has completed execution at: 2020-08-03T14:23:57.351,
> Execution time: 1558 ms
> {code}
> However, command seems to execute and baseline actually changes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13321) Control utility doesn't print results to stdout.
[
https://issues.apache.org/jira/browse/IGNITE-13321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170620#comment-17170620
]
Ivan Daschinskiy commented on IGNITE-13321:
---
[~ktkale...@gridgain.com] Thanks for debugging this issue. And sorry for
linking your patch to it. Are you going to fix it or to reassign to other
member of community?
> Control utility doesn't print results to stdout.
>
>
> Key: IGNITE-13321
> URL: https://issues.apache.org/jira/browse/IGNITE-13321
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Affects Versions: 2.10
>Reporter: Ivan Daschinskiy
>Assignee: Kirill Tkalenko
>Priority: Blocker
> Fix For: 2.10
>
>
> After merging
> [IGNITE-13123|https://issues.apache.org/jira/browse/IGNITE-13123]
> {{control.sh}} doesn't work properly either in dev mode, or in release mode.
> Specifically, no output printed in stdout.
> For example, incorrect output for {{control.sh -baseline set}} after commit
> is:
> {code:sh}
> Control utility [ver. 2.10.0-SNAPSHOT#20200803-sha1:DEV],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:24:33.193,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
>
> {code}
> Correct output for {{control.sh -baseline set}} before commit is:
> {code}
> Control utility [ver. 2.8.1#20200521-sha1:86422096],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:23:55.793,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
> ,
>
> Cluster state: active,
> Current topology version: 3,
> Baseline auto adjustment disabled: softTimeout=30
>Current topology version: 3 (Coordinator: ConsistentId=ducker02, Order=1)
> Baseline nodes:
>ConsistentId=ducker02, State=ONLINE, Order=1,
>ConsistentId=ducker03, State=ONLINE, Order=2,
>ConsistentId=ducker04, State=ONLINE, Order=3,
> ,
>
> Number of baseline nodes: 3,
> Other nodes not found.,
> Command [BASELINE] finished with code: 0,
> Control utility has completed execution at: 2020-08-03T14:23:57.351,
> Execution time: 1558 ms
> {code}
> However, command seems to execute and baseline actually changes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13321) Control utility doesn't print results to stdout.
[
https://issues.apache.org/jira/browse/IGNITE-13321?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17170614#comment-17170614
]
Kirill Tkalenko commented on IGNITE-13321:
--
Hi, [~ivandasch]!
I tried to analyze code and compare it with 2.8.1 and found that problem is
changing logging in IGNITE-13262, for
{code:java}
org.apache.ignite.internal.client.impl.connection.GridClientTopology#log
org.apache.ignite.internal.client.impl.connection.GridClientConnectionManagerAdapter#log
{code}
> Control utility doesn't print results to stdout.
>
>
> Key: IGNITE-13321
> URL: https://issues.apache.org/jira/browse/IGNITE-13321
> Project: Ignite
> Issue Type: Bug
> Components: control.sh
>Affects Versions: 2.10
>Reporter: Ivan Daschinskiy
>Assignee: Kirill Tkalenko
>Priority: Blocker
> Fix For: 2.10
>
>
> After merging
> [IGNITE-13123|https://issues.apache.org/jira/browse/IGNITE-13123]
> {{control.sh}} doesn't work properly either in dev mode, or in release mode.
> Specifically, no output printed in stdout.
> For example, incorrect output for {{control.sh -baseline set}} after commit
> is:
> {code:sh}
> Control utility [ver. 2.10.0-SNAPSHOT#20200803-sha1:DEV],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:24:33.193,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
>
> {code}
> Correct output for {{control.sh -baseline set}} before commit is:
> {code}
> Control utility [ver. 2.8.1#20200521-sha1:86422096],
> 2020 Copyright(C) Apache Software Foundation,
> User: ducker,
> Time: 2020-08-03T14:23:55.793,
> Command [BASELINE] started,
> Arguments: --host ducker04 --baseline set ducker02,ducker03,ducker04 --yes,
>
> ,
>
> Cluster state: active,
> Current topology version: 3,
> Baseline auto adjustment disabled: softTimeout=30
>Current topology version: 3 (Coordinator: ConsistentId=ducker02, Order=1)
> Baseline nodes:
>ConsistentId=ducker02, State=ONLINE, Order=1,
>ConsistentId=ducker03, State=ONLINE, Order=2,
>ConsistentId=ducker04, State=ONLINE, Order=3,
> ,
>
> Number of baseline nodes: 3,
> Other nodes not found.,
> Command [BASELINE] finished with code: 0,
> Control utility has completed execution at: 2020-08-03T14:23:57.351,
> Execution time: 1558 ms
> {code}
> However, command seems to execute and baseline actually changes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
