[jira] [Updated] (IGNITE-12701) Disallow silent deactivation in CLI and REST.
[
https://issues.apache.org/jira/browse/IGNITE-12701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-12701:
--
Affects Version/s: (was: 2.9)
2.7.6
> Disallow silent deactivation in CLI and REST.
> -
>
> Key: IGNITE-12701
> URL: https://issues.apache.org/jira/browse/IGNITE-12701
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.7.6
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Disallow silent deactivation through the CLI and REST.
> Skip JMX call
> {code:java}
> void IgniteMXBean#active(boolean active)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12701) Disallow silent deactivation in CLI and REST.
[
https://issues.apache.org/jira/browse/IGNITE-12701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-12701:
--
Fix Version/s: 2.9
> Disallow silent deactivation in CLI and REST.
> -
>
> Key: IGNITE-12701
> URL: https://issues.apache.org/jira/browse/IGNITE-12701
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.9
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Disallow silent deactivation through the CLI and REST.
> Skip JMX call
> {code:java}
> void IgniteMXBean#active(boolean active)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12464) Service metrics
[ https://issues.apache.org/jira/browse/IGNITE-12464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046536#comment-17046536 ] Vladimir Steshin commented on IGNITE-12464: --- [~agura], several service instances share same metrics. Metrics is raised with single or first instance of a service, removed with undeploying of last service instance. > Service metrics > --- > > Key: IGNITE-12464 > URL: https://issues.apache.org/jira/browse/IGNITE-12464 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7.6 >Reporter: Nikolay Izhikov >Assignee: Vladimir Steshin >Priority: Minor > Labels: IEP-35 > Time Spent: 1h 10m > Remaining Estimate: 0h > > We should provide the following metrics for each deployed service: > * -Count of executions- - this number seems useless, because, we can compute > it just by summing all histograms values. > * Histogram of executions duration -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12701) Disallow silent deactivation in CLI and REST.
[
https://issues.apache.org/jira/browse/IGNITE-12701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17042041#comment-17042041
]
Vladimir Steshin edited comment on IGNITE-12701 at 2/27/20 12:31 PM:
-
Changes in public behavior:
1) Involved optional flag 'force' for control.sh (bat) with --deactivate and
--set-sate:
control.sh --deactivate [--force]
control.sh --set-state INACTIVE[--force]
2) Involved optional parameter 'force=true|false' for REST cluster state
requests:
http://127.0.0.1:8092/ignite?cmd=deactivate=true
http://127.0.0.1:8092/ignite?cmd=inactive=true
http://127.0.0.1:8092/ignite?cmd=setstate=INACTIVE=true
Major code changes:
1) Added GridClientClusterStateRequestV2.
2) Deprecated GridClientClusterStateRequest.
3) Added flag ‘force’ for REST in GridRestClusterStateRequest
4) Added flag ‘force’ CLI in DeactivateCommand, ClusterStateChangeCommand.
5) Added IgniteFeatures# FORCED_CHANGE_OF_CLUSTER_STATE.
6) Added checking of deactivation safety: GridClusterStateProcessor#
isDeactivationSafe()
7) Involved o deactivation safety checking in GridClusterStateProcessing and
GridClientClusterStateImpl.
was (Author: vladsz83):
Major changes:
# Added GridClientClusterStateRequestV2.
# Deprecated GridClientClusterStateRequest.
# Added flag ‘force’ for REST in GridRestClusterStateRequest
# Added flag ‘force’ CLI in DeactivateCommand, ClusterStateChangeCommand.
# Added IgniteFeatures# FORCED_CHANGE_OF_CLUSTER_STATE.
# Added checking of deactivation safety: GridClusterStateProcessor#
isDeactivationSafe()
> Disallow silent deactivation in CLI and REST.
> -
>
> Key: IGNITE-12701
> URL: https://issues.apache.org/jira/browse/IGNITE-12701
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.7.6
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Disallow silent deactivation through the CLI and REST.
> Skip JMX call
> {code:java}
> void IgniteMXBean#active(boolean active)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12464) Service metrics
[ https://issues.apache.org/jira/browse/IGNITE-12464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17046536#comment-17046536 ] Vladimir Steshin edited comment on IGNITE-12464 at 2/27/20 11:51 AM: - [~agura], several service instances share same metrics. Metrics are raised with single or first instance of a service, removed with undeploying of last service instance. was (Author: vladsz83): [~agura], several service instances share same metrics. Metrics is raised with single or first instance of a service, removed with undeploying of last service instance. > Service metrics > --- > > Key: IGNITE-12464 > URL: https://issues.apache.org/jira/browse/IGNITE-12464 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7.6 >Reporter: Nikolay Izhikov >Assignee: Vladimir Steshin >Priority: Minor > Labels: IEP-35 > Time Spent: 1h 10m > Remaining Estimate: 0h > > We should provide the following metrics for each deployed service: > * -Count of executions- - this number seems useless, because, we can compute > it just by summing all histograms values. > * Histogram of executions duration -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12701) Disallow silent deactivation in CLI and REST.
[
https://issues.apache.org/jira/browse/IGNITE-12701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17042041#comment-17042041
]
Vladimir Steshin edited comment on IGNITE-12701 at 2/27/20 12:33 PM:
-
Changes in public behavior:
1) Involved optional flag 'force' for control.sh (bat) with --deactivate and
--set-sate:
control.sh --deactivate --force
control.sh --set-state INACTIVE --force
2) Involved optional parameter 'force=true|false' for REST cluster state
requests:
http://127.0.0.1:8092/ignite?cmd=deactivate=true
http://127.0.0.1:8092/ignite?cmd=inactive=true
http://127.0.0.1:8092/ignite?cmd=setstate=INACTIVE=true
Major code changes:
1) Added GridClientClusterStateRequestV2.
2) Deprecated GridClientClusterStateRequest.
3) Added flag ‘force’ for REST in GridRestClusterStateRequest
4) Added flag ‘force’ CLI in DeactivateCommand, ClusterStateChangeCommand.
5) Added IgniteFeatures# FORCED_CHANGE_OF_CLUSTER_STATE.
6) Added checking of deactivation safety: GridClusterStateProcessor#
isDeactivationSafe()
7) Involved o deactivation safety checking in GridClusterStateProcessing and
GridClientClusterStateImpl.
was (Author: vladsz83):
Changes in public behavior:
1) Involved optional flag 'force' for control.sh (bat) with --deactivate and
--set-sate:
control.sh --deactivate [--force]
control.sh --set-state INACTIVE[--force]
2) Involved optional parameter 'force=true|false' for REST cluster state
requests:
http://127.0.0.1:8092/ignite?cmd=deactivate=true
http://127.0.0.1:8092/ignite?cmd=inactive=true
http://127.0.0.1:8092/ignite?cmd=setstate=INACTIVE=true
Major code changes:
1) Added GridClientClusterStateRequestV2.
2) Deprecated GridClientClusterStateRequest.
3) Added flag ‘force’ for REST in GridRestClusterStateRequest
4) Added flag ‘force’ CLI in DeactivateCommand, ClusterStateChangeCommand.
5) Added IgniteFeatures# FORCED_CHANGE_OF_CLUSTER_STATE.
6) Added checking of deactivation safety: GridClusterStateProcessor#
isDeactivationSafe()
7) Involved o deactivation safety checking in GridClusterStateProcessing and
GridClientClusterStateImpl.
> Disallow silent deactivation in CLI and REST.
> -
>
> Key: IGNITE-12701
> URL: https://issues.apache.org/jira/browse/IGNITE-12701
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.7.6
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> Disallow silent deactivation through the CLI and REST.
> Skip JMX call
> {code:java}
> void IgniteMXBean#active(boolean active)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12581) [REFACTORING] Tests parametrization
[ https://issues.apache.org/jira/browse/IGNITE-12581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-12581: - Assignee: Vladimir Steshin > [REFACTORING] Tests parametrization > --- > > Key: IGNITE-12581 > URL: https://issues.apache.org/jira/browse/IGNITE-12581 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Vladimir Steshin >Priority: Minor > > Right now many Ignite tests parametrization implemented via inheritance. > For example: > parent - JdbcThinBulkLoadAbstractSelfTest > extensions - JdbcThinBulkLoadAtomicPartitionedNearSelfTest, > JdbcThinBulkLoadAtomicPartitionedSelfTest, > JdbcThinBulkLoadAtomicReplicatedSelfTest, > JdbcThinBulkLoadTransactionalPartitionedNearSelfTest, > JdbcThinBulkLoadTransactionalPartitionedSelfTest, > JdbcThinBulkLoadTransactionalReplicatedSelfTest. > > Look like we can significantly reduce tests code base, therefore, improve > readability and maintainability without losing any test-cases if we use the > JUnit parameterized approach. > > A contributor can use this ticket as an umbrella one and create a sub-ticket > for each refactored test-classes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12583) Parametrization of JdbcThinBulkLoadAbstractSelfTest
Vladimir Steshin created IGNITE-12583:
-
Summary: Parametrization of JdbcThinBulkLoadAbstractSelfTest
Key: IGNITE-12583
URL: https://issues.apache.org/jira/browse/IGNITE-12583
Project: Ignite
Issue Type: Sub-task
Reporter: Vladimir Steshin
Assignee: Vladimir Steshin
org.apache.ignite.jdbc.thin.JdbcThinBulkLoadAbstractSelfTest is extended
several times using just parameter-assigning-getters like
{code:java}
protected CacheMode cacheMode() { return CacheMode.REPLICATED; }
protected CacheAtomicityMode atomicityMode() { return
CacheAtomicityMode.TRANSACTIONAL;}
protected boolean nearCache() { return false; }
{code}
Should go with params instead.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12595) Parametrization of GridCacheSetAbstractSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-12595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17025961#comment-17025961 ] Vladimir Steshin commented on IGNITE-12595: --- I think this test isn't applicable for parametrization. Found usages of different set of sub-classes in several test suits. Also, the subclasses are split and used within different packages. > Parametrization of GridCacheSetAbstractSelfTest > --- > > Key: IGNITE-12595 > URL: https://issues.apache.org/jira/browse/IGNITE-12595 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Trivial > > org.apache.ignite.internal.processors.cache.datastructures.GridCacheSetAbstractSelfTest > might be used with params. Not the best candidate due to usage/extending in > differect sub-packages. But is still able to reduce tests code base. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12606) Parametrize IgniteTxStoreExceptionAbstractSelfTest
Vladimir Steshin created IGNITE-12606: - Summary: Parametrize IgniteTxStoreExceptionAbstractSelfTest Key: IGNITE-12606 URL: https://issues.apache.org/jira/browse/IGNITE-12606 Project: Ignite Issue Type: Sub-task Reporter: Vladimir Steshin Assignee: Vladimir Steshin IgniteTxStoreExceptionAbstractSelfTest seems to fit well the parametrization. It has only single depth of sub-tests which are used in one place together. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12596) Parametrization of IgniteCacheAbstractExecutionContextTest
[ https://issues.apache.org/jira/browse/IGNITE-12596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17025956#comment-17025956 ] Vladimir Steshin edited comment on IGNITE-12596 at 1/29/20 3:16 PM: I think this test isn't applicable for parametrization. 1) Found different usages of set of sublclasses in test suits: [ IgniteCacheAtomicExecutionContextTest, IgniteCacheReplicatedExecutionContextTest ] in IgniteCacheMvccTestSuite1 and [ IgniteCacheAtomicExecutionContextTest, IgniteCacheReplicatedExecutionContextTest, IgniteCacheTxExecutionContextTest ] in IgniteCacheTestSuite 2) Found additional inheritances of subclasses IgniteCacheAtomicExecutionContextTest. That means it cannot be deleted. was (Author: vladsz83): I think this test isn't applicable for parametrization. * Found different usages of set of sublclasses in test suits: [ IgniteCacheAtomicExecutionContextTest, IgniteCacheReplicatedExecutionContextTest ] in IgniteCacheMvccTestSuite1 and [ IgniteCacheAtomicExecutionContextTest, IgniteCacheReplicatedExecutionContextTest, IgniteCacheTxExecutionContextTest ] in IgniteCacheTestSuite * Found additional inheritances of subclasses IgniteCacheAtomicExecutionContextTest. That means it cannot be deleted. > Parametrization of IgniteCacheAbstractExecutionContextTest > -- > > Key: IGNITE-12596 > URL: https://issues.apache.org/jira/browse/IGNITE-12596 > Project: Ignite > Issue Type: Sub-task > Environment: > org.apache.ignite.internal.processors.cache.context.IgniteCacheAbstractExecutionContextTest > is activated 3 times with just various params via inheritance. The problem > is that the extending classes are included in the target test suits not > always with entire combinations of params. Sometimes only 2 extendins classes > are involved within tests, sometimes 3. I think of using subclasses of > IgniteCacheAbstractExecutionContextTest as set of params. >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12596) Parametrization of IgniteCacheAbstractExecutionContextTest
[ https://issues.apache.org/jira/browse/IGNITE-12596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17025956#comment-17025956 ] Vladimir Steshin edited comment on IGNITE-12596 at 1/29/20 3:16 PM: I think this test isn't applicable for parametrization. * Found different usages of set of sublclasses in test suits: [ IgniteCacheAtomicExecutionContextTest, IgniteCacheReplicatedExecutionContextTest ] in IgniteCacheMvccTestSuite1 and [ IgniteCacheAtomicExecutionContextTest, IgniteCacheReplicatedExecutionContextTest, IgniteCacheTxExecutionContextTest ] in IgniteCacheTestSuite * Found additional inheritances of subclasses IgniteCacheAtomicExecutionContextTest. That means it cannot be deleted. was (Author: vladsz83): I think this test isn't applicable for parametrization. # Found different usages of set of sublclasses in test suits: [ IgniteCacheAtomicExecutionContextTest, IgniteCacheReplicatedExecutionContextTest ] in IgniteCacheMvccTestSuite1 and [ IgniteCacheAtomicExecutionContextTest, IgniteCacheReplicatedExecutionContextTest, IgniteCacheTxExecutionContextTest ] in IgniteCacheTestSuite # Found additional inheritances of subclasses IgniteCacheAtomicExecutionContextTest. That means it cannot be deleted. > Parametrization of IgniteCacheAbstractExecutionContextTest > -- > > Key: IGNITE-12596 > URL: https://issues.apache.org/jira/browse/IGNITE-12596 > Project: Ignite > Issue Type: Sub-task > Environment: > org.apache.ignite.internal.processors.cache.context.IgniteCacheAbstractExecutionContextTest > is activated 3 times with just various params via inheritance. The problem > is that the extending classes are included in the target test suits not > always with entire combinations of params. Sometimes only 2 extendins classes > are involved within tests, sometimes 3. I think of using subclasses of > IgniteCacheAbstractExecutionContextTest as set of params. >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12596) Parametrization of IgniteCacheAbstractExecutionContextTest
[ https://issues.apache.org/jira/browse/IGNITE-12596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17025956#comment-17025956 ] Vladimir Steshin edited comment on IGNITE-12596 at 1/29/20 3:15 PM: I think this test isn't applicable for parametrization. # Found different usages of set of sublclasses in test suits: [ IgniteCacheAtomicExecutionContextTest, IgniteCacheReplicatedExecutionContextTest ] in IgniteCacheMvccTestSuite1 and [ IgniteCacheAtomicExecutionContextTest, IgniteCacheReplicatedExecutionContextTest, IgniteCacheTxExecutionContextTest ] in IgniteCacheTestSuite # Found additional inheritances of subclasses IgniteCacheAtomicExecutionContextTest. That means it cannot be deleted. was (Author: vladsz83): I think this test isn't applicable for parametrization. * Found different usages of set of sublclasses in test suits: [ IgniteCacheAtomicExecutionContextTest, IgniteCacheReplicatedExecutionContextTest ] in IgniteCacheMvccTestSuite1 and [ IgniteCacheAtomicExecutionContextTest, IgniteCacheReplicatedExecutionContextTest, IgniteCacheTxExecutionContextTest ] in IgniteCacheTestSuite # Found additional inheritances of subclasses IgniteCacheAtomicExecutionContextTest. That means it cannot be deleted. > Parametrization of IgniteCacheAbstractExecutionContextTest > -- > > Key: IGNITE-12596 > URL: https://issues.apache.org/jira/browse/IGNITE-12596 > Project: Ignite > Issue Type: Sub-task > Environment: > org.apache.ignite.internal.processors.cache.context.IgniteCacheAbstractExecutionContextTest > is activated 3 times with just various params via inheritance. The problem > is that the extending classes are included in the target test suits not > always with entire combinations of params. Sometimes only 2 extendins classes > are involved within tests, sometimes 3. I think of using subclasses of > IgniteCacheAbstractExecutionContextTest as set of params. >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12596) Parametrization of IgniteCacheAbstractExecutionContextTest
[ https://issues.apache.org/jira/browse/IGNITE-12596?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17025956#comment-17025956 ] Vladimir Steshin commented on IGNITE-12596: --- I think this test isn't applicable for parametrization. * Found different usages of set of sublclasses in test suits: [ IgniteCacheAtomicExecutionContextTest, IgniteCacheReplicatedExecutionContextTest ] in IgniteCacheMvccTestSuite1 and [ IgniteCacheAtomicExecutionContextTest, IgniteCacheReplicatedExecutionContextTest, IgniteCacheTxExecutionContextTest ] in IgniteCacheTestSuite # Found additional inheritances of subclasses IgniteCacheAtomicExecutionContextTest. That means it cannot be deleted. > Parametrization of IgniteCacheAbstractExecutionContextTest > -- > > Key: IGNITE-12596 > URL: https://issues.apache.org/jira/browse/IGNITE-12596 > Project: Ignite > Issue Type: Sub-task > Environment: > org.apache.ignite.internal.processors.cache.context.IgniteCacheAbstractExecutionContextTest > is activated 3 times with just various params via inheritance. The problem > is that the extending classes are included in the target test suits not > always with entire combinations of params. Sometimes only 2 extendins classes > are involved within tests, sometimes 3. I think of using subclasses of > IgniteCacheAbstractExecutionContextTest as set of params. >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12583) Parametrization of JdbcThinBulkLoadAbstractSelfTest
[
https://issues.apache.org/jira/browse/IGNITE-12583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17025859#comment-17025859
]
Vladimir Steshin commented on IGNITE-12583:
---
[~Pavlukhin], thanks. Sure, going to add the param names in the following
refactorings.
> Parametrization of JdbcThinBulkLoadAbstractSelfTest
> ---
>
> Key: IGNITE-12583
> URL: https://issues.apache.org/jira/browse/IGNITE-12583
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> org.apache.ignite.jdbc.thin.JdbcThinBulkLoadAbstractSelfTest is extended
> several times using just parameter-assigning-getters like
> {code:java}
> protected CacheMode cacheMode() { return CacheMode.REPLICATED; }
> protected CacheAtomicityMode atomicityMode() { return
> CacheAtomicityMode.TRANSACTIONAL;}
> protected boolean nearCache() { return false; }
> {code}
> Should go with params instead.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12581) [REFACTORING] Tests parametrization
[ https://issues.apache.org/jira/browse/IGNITE-12581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17025898#comment-17025898 ] Vladimir Steshin commented on IGNITE-12581: --- Suggested test to revise for parametrize possibility are: # CacheContinuousQueryCounterAbstractTest # GridCacheAbstractLocalStoreSelfTest # IgniteCacheNodeJoinAbstractTest # GridAbstractCacheInterceptorRebalanceTest # GridCacheOnCopyFlagAbstractSelfTest # IgniteCacheCopyOnReadDisabledAbstractTest # GridCacheInterceptorAbstractSelfTest # CacheGetsDistributionAbstractTest # CacheStoreSessionListenerReadWriteThroughDisabledAbstractTest # IgniteTxStoreExceptionAbstractSelfTest # GridCacheSetAbstractSelfTest # IgniteCacheAbstractExecutionContextTest # GridCacheAbstractUsersAffinityMapperSelfTest # IgniteCacheExpiryPolicyWithStoreAbstractTest # CacheVersionedEntryAbstractTest # GridCacheEvictionEventAbstractTest # GridCacheAbstractIteratorsSelfTest # CacheStoreUsageMultinodeDynamicStartAbstractTest # GridCacheAbstractFailoverTxSelfTest # CacheStoreUsageMultinodeStaticStartAbstractTest # IgniteCachePeekModesAbstractTest > [REFACTORING] Tests parametrization > --- > > Key: IGNITE-12581 > URL: https://issues.apache.org/jira/browse/IGNITE-12581 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Vladimir Steshin >Priority: Minor > > Right now many Ignite tests parametrization implemented via inheritance. > For example: > parent - JdbcThinBulkLoadAbstractSelfTest > extensions - JdbcThinBulkLoadAtomicPartitionedNearSelfTest, > JdbcThinBulkLoadAtomicPartitionedSelfTest, > JdbcThinBulkLoadAtomicReplicatedSelfTest, > JdbcThinBulkLoadTransactionalPartitionedNearSelfTest, > JdbcThinBulkLoadTransactionalPartitionedSelfTest, > JdbcThinBulkLoadTransactionalReplicatedSelfTest. > > Look like we can significantly reduce tests code base, therefore, improve > readability and maintainability without losing any test-cases if we use the > JUnit parameterized approach. > > A contributor can use this ticket as an umbrella one and create a sub-ticket > for each refactored test-classes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12606) Parametrize IgniteTxStoreExceptionAbstractSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-12606?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17026003#comment-17026003 ] Vladimir Steshin commented on IGNITE-12606: --- Clone of IGNITE-12597 > Parametrize IgniteTxStoreExceptionAbstractSelfTest > -- > > Key: IGNITE-12606 > URL: https://issues.apache.org/jira/browse/IGNITE-12606 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > > IgniteTxStoreExceptionAbstractSelfTest seems to fit well the parametrization. > It has only single depth of sub-tests which are used in one place together. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-12606) Parametrize IgniteTxStoreExceptionAbstractSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-12606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin resolved IGNITE-12606. --- Resolution: Duplicate > Parametrize IgniteTxStoreExceptionAbstractSelfTest > -- > > Key: IGNITE-12606 > URL: https://issues.apache.org/jira/browse/IGNITE-12606 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > > IgniteTxStoreExceptionAbstractSelfTest seems to fit well the parametrization. > It has only single depth of sub-tests which are used in one place together. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IGNITE-12606) Parametrize IgniteTxStoreExceptionAbstractSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-12606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin closed IGNITE-12606. - Ignite Flags: (was: Docs Required,Release Notes Required) > Parametrize IgniteTxStoreExceptionAbstractSelfTest > -- > > Key: IGNITE-12606 > URL: https://issues.apache.org/jira/browse/IGNITE-12606 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Minor > > IgniteTxStoreExceptionAbstractSelfTest seems to fit well the parametrization. > It has only single depth of sub-tests which are used in one place together. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12595) Parametrization of GridCacheSetAbstractSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-12595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-12595: - Assignee: (was: Vladimir Steshin) > Parametrization of GridCacheSetAbstractSelfTest > --- > > Key: IGNITE-12595 > URL: https://issues.apache.org/jira/browse/IGNITE-12595 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Priority: Trivial > > org.apache.ignite.internal.processors.cache.datastructures.GridCacheSetAbstractSelfTest > might be used with params. Not the best candidate due to usage/extending in > differect sub-packages. But is still able to reduce tests code base. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12581) [REFACTORING] Tests parametrization
[ https://issues.apache.org/jira/browse/IGNITE-12581?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17027438#comment-17027438 ] Vladimir Steshin commented on IGNITE-12581: --- Attached file with list (smalltests.txt) of the small tests which can be reviewed for parameterization refactoring. > [REFACTORING] Tests parametrization > --- > > Key: IGNITE-12581 > URL: https://issues.apache.org/jira/browse/IGNITE-12581 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Vladimir Steshin >Priority: Minor > Attachments: smalltests.txt > > > Right now many Ignite tests parametrization implemented via inheritance. > For example: > parent - JdbcThinBulkLoadAbstractSelfTest > extensions - JdbcThinBulkLoadAtomicPartitionedNearSelfTest, > JdbcThinBulkLoadAtomicPartitionedSelfTest, > JdbcThinBulkLoadAtomicReplicatedSelfTest, > JdbcThinBulkLoadTransactionalPartitionedNearSelfTest, > JdbcThinBulkLoadTransactionalPartitionedSelfTest, > JdbcThinBulkLoadTransactionalReplicatedSelfTest. > > Look like we can significantly reduce tests code base, therefore, improve > readability and maintainability without losing any test-cases if we use the > JUnit parameterized approach. > > A contributor can use this ticket as an umbrella one and create a sub-ticket > for each refactored test-classes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12597) IgniteTxStoreExceptionAbstractSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-12597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-12597: - Assignee: (was: Vladimir Steshin) > IgniteTxStoreExceptionAbstractSelfTest > -- > > Key: IGNITE-12597 > URL: https://issues.apache.org/jira/browse/IGNITE-12597 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > org.apache.ignite.internal.processors.cache.GridCacheColocatedTxStoreExceptionSelfTest > might be parametrized. Extending classes wear only params and are executed > in a row -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12596) Parametrization of IgniteCacheAbstractExecutionContextTest
[ https://issues.apache.org/jira/browse/IGNITE-12596?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-12596: - Assignee: (was: Vladimir Steshin) > Parametrization of IgniteCacheAbstractExecutionContextTest > -- > > Key: IGNITE-12596 > URL: https://issues.apache.org/jira/browse/IGNITE-12596 > Project: Ignite > Issue Type: Sub-task > Environment: > org.apache.ignite.internal.processors.cache.context.IgniteCacheAbstractExecutionContextTest > is activated 3 times with just various params via inheritance. The problem > is that the extending classes are included in the target test suits not > always with entire combinations of params. Sometimes only 2 extendins classes > are involved within tests, sometimes 3. I think of using subclasses of > IgniteCacheAbstractExecutionContextTest as set of params. >Reporter: Vladimir Steshin >Priority: Minor > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12614) Disallow silent deactivation of cluster to prevent in-mem data loss.
[ https://issues.apache.org/jira/browse/IGNITE-12614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-12614: -- Description: Currently, anyone is able to deactivate cluster with command line utility (control.sh). Probably with JMX too. That would lead to data loss when the persistence is off. In-memory data is erased during deactivation. Such behavior can be considered as unexpected to user. Suggestions: 1) Disallow silent deactivation of cluster keeping caches. Show a warning like “Your cluster has in-memory cache configured. During deactivation all data from these caches will be cleared!” 2) Add param ‘--force’ which skips the warning message. was: Currently, anyone is able to deactivate cluster with command line utility (control.sh). Probably with JMX too. That would lead to data loss when the persistence is off. In-memory data is erased during deactivation. Such behavior can be considered as unexpected to user. Suggestions: 1) Disallow silent deactivate cluster keeping caches. Show a warning like “Your cluster has in-memory cache configured. During deactivation all data from these caches will be cleared!” 2) Add param ‘--force’ which skips the warning message. > Disallow silent deactivation of cluster to prevent in-mem data loss. > > > Key: IGNITE-12614 > URL: https://issues.apache.org/jira/browse/IGNITE-12614 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Priority: Major > > Currently, anyone is able to deactivate cluster with command line utility > (control.sh). Probably with JMX too. That would lead to data loss when the > persistence is off. In-memory data is erased during deactivation. Such > behavior can be considered as unexpected to user. > Suggestions: > 1)Disallow silent deactivation of cluster keeping caches. Show a warning > like “Your cluster has in-memory cache configured. During deactivation all > data from these caches will be cleared!” > 2)Add param ‘--force’ which skips the warning message. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12614) Disallow silent deactivation of cluster to prevent in-mem data loss.
[ https://issues.apache.org/jira/browse/IGNITE-12614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-12614: - Assignee: Vladimir Steshin > Disallow silent deactivation of cluster to prevent in-mem data loss. > > > Key: IGNITE-12614 > URL: https://issues.apache.org/jira/browse/IGNITE-12614 > Project: Ignite > Issue Type: Bug >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > > Currently, anyone is able to deactivate cluster with command line utility > (control.sh). Probably with JMX too. That would lead to data loss when the > persistence is off. In-memory data is erased during deactivation. Such > behavior can be considered as unexpected to user. > Suggestions: > 1)Disallow silent deactivation of cluster keeping caches. Show a warning > like “Your cluster has in-memory cache configured. During deactivation all > data from these caches will be cleared!” > 2)Add param ‘--force’ which skips the warning message. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12597) IgniteTxStoreExceptionAbstractSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-12597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-12597: - Assignee: (was: Vladimir Steshin) > IgniteTxStoreExceptionAbstractSelfTest > -- > > Key: IGNITE-12597 > URL: https://issues.apache.org/jira/browse/IGNITE-12597 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > org.apache.ignite.internal.processors.cache.GridCacheColocatedTxStoreExceptionSelfTest > might be parametrized. Extending classes wear only params and are executed > in a row -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12597) IgniteTxStoreExceptionAbstractSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-12597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-12597: - Assignee: Vladimir Steshin > IgniteTxStoreExceptionAbstractSelfTest > -- > > Key: IGNITE-12597 > URL: https://issues.apache.org/jira/browse/IGNITE-12597 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > org.apache.ignite.internal.processors.cache.GridCacheColocatedTxStoreExceptionSelfTest > might be parametrized. Extending classes wear only params and are executed > in a row -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12581) [REFACTORING] Tests parametrization
[ https://issues.apache.org/jira/browse/IGNITE-12581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-12581: - Assignee: (was: Vladimir Steshin) > [REFACTORING] Tests parametrization > --- > > Key: IGNITE-12581 > URL: https://issues.apache.org/jira/browse/IGNITE-12581 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Priority: Minor > Attachments: smalltests.txt > > > Right now many Ignite tests parametrization implemented via inheritance. > For example: > parent - JdbcThinBulkLoadAbstractSelfTest > extensions - JdbcThinBulkLoadAtomicPartitionedNearSelfTest, > JdbcThinBulkLoadAtomicPartitionedSelfTest, > JdbcThinBulkLoadAtomicReplicatedSelfTest, > JdbcThinBulkLoadTransactionalPartitionedNearSelfTest, > JdbcThinBulkLoadTransactionalPartitionedSelfTest, > JdbcThinBulkLoadTransactionalReplicatedSelfTest. > > Look like we can significantly reduce tests code base, therefore, improve > readability and maintainability without losing any test-cases if we use the > JUnit parameterized approach. > > A contributor can use this ticket as an umbrella one and create a sub-ticket > for each refactored test-classes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12581) [REFACTORING] Tests parametrization
[ https://issues.apache.org/jira/browse/IGNITE-12581?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-12581: -- Attachment: smalltests.txt > [REFACTORING] Tests parametrization > --- > > Key: IGNITE-12581 > URL: https://issues.apache.org/jira/browse/IGNITE-12581 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Assignee: Vladimir Steshin >Priority: Minor > Attachments: smalltests.txt > > > Right now many Ignite tests parametrization implemented via inheritance. > For example: > parent - JdbcThinBulkLoadAbstractSelfTest > extensions - JdbcThinBulkLoadAtomicPartitionedNearSelfTest, > JdbcThinBulkLoadAtomicPartitionedSelfTest, > JdbcThinBulkLoadAtomicReplicatedSelfTest, > JdbcThinBulkLoadTransactionalPartitionedNearSelfTest, > JdbcThinBulkLoadTransactionalPartitionedSelfTest, > JdbcThinBulkLoadTransactionalReplicatedSelfTest. > > Look like we can significantly reduce tests code base, therefore, improve > readability and maintainability without losing any test-cases if we use the > JUnit parameterized approach. > > A contributor can use this ticket as an umbrella one and create a sub-ticket > for each refactored test-classes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12614) Disallow silent deactivation of cluster to prevent in-mem data loss.
Vladimir Steshin created IGNITE-12614: - Summary: Disallow silent deactivation of cluster to prevent in-mem data loss. Key: IGNITE-12614 URL: https://issues.apache.org/jira/browse/IGNITE-12614 Project: Ignite Issue Type: Bug Reporter: Vladimir Steshin Currently, anyone is able to deactivate cluster with command line utility (control.sh). Probably with JMX too. That would lead to data loss when the persistence is off. In-memory data is erased during deactivation. Such behavior can be considered as unexpected to user. Suggestions: 1) Disallow silent deactivate cluster keeping caches. Show a warning like “Your cluster has in-memory cache configured. During deactivation all data from these caches will be cleared!” 2) Add param ‘--force’ which skips the warning message. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12597) IgniteTxStoreExceptionAbstractSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-12597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-12597: - Assignee: (was: Vladimir Steshin) > IgniteTxStoreExceptionAbstractSelfTest > -- > > Key: IGNITE-12597 > URL: https://issues.apache.org/jira/browse/IGNITE-12597 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > org.apache.ignite.internal.processors.cache.GridCacheColocatedTxStoreExceptionSelfTest > might be parametrized. Extending classes wear only params and are executed > in a row -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12597) IgniteTxStoreExceptionAbstractSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-12597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-12597: - Assignee: Vladimir Steshin > IgniteTxStoreExceptionAbstractSelfTest > -- > > Key: IGNITE-12597 > URL: https://issues.apache.org/jira/browse/IGNITE-12597 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > org.apache.ignite.internal.processors.cache.GridCacheColocatedTxStoreExceptionSelfTest > might be parametrized. Extending classes wear only params and are executed > in a row -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12595) Parametrization of GridCacheSetAbstractSelfTest
Vladimir Steshin created IGNITE-12595: - Summary: Parametrization of GridCacheSetAbstractSelfTest Key: IGNITE-12595 URL: https://issues.apache.org/jira/browse/IGNITE-12595 Project: Ignite Issue Type: Sub-task Reporter: Vladimir Steshin Assignee: Vladimir Steshin org.apache.ignite.internal.processors.cache.datastructures.GridCacheSetAbstractSelfTest might be used with params. Not the best candidate, but is still able to reduce tests code base. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12595) Parametrization of GridCacheSetAbstractSelfTest
[ https://issues.apache.org/jira/browse/IGNITE-12595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-12595: -- Description: org.apache.ignite.internal.processors.cache.datastructures.GridCacheSetAbstractSelfTest might be used with params. Not the best candidate due to usage/extending in differect sub-packages. But is still able to reduce tests code base. (was: org.apache.ignite.internal.processors.cache.datastructures.GridCacheSetAbstractSelfTest might be used with params. Not the best candidate, but is still able to reduce tests code base.) > Parametrization of GridCacheSetAbstractSelfTest > --- > > Key: IGNITE-12595 > URL: https://issues.apache.org/jira/browse/IGNITE-12595 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Trivial > > org.apache.ignite.internal.processors.cache.datastructures.GridCacheSetAbstractSelfTest > might be used with params. Not the best candidate due to usage/extending in > differect sub-packages. But is still able to reduce tests code base. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12596) Parametrization of IgniteCacheAbstractExecutionContextTest
Vladimir Steshin created IGNITE-12596: - Summary: Parametrization of IgniteCacheAbstractExecutionContextTest Key: IGNITE-12596 URL: https://issues.apache.org/jira/browse/IGNITE-12596 Project: Ignite Issue Type: Sub-task Environment: org.apache.ignite.internal.processors.cache.context.IgniteCacheAbstractExecutionContextTest is activated 3 times with just various params via inheritance. The problem is that the extending classes are included in the target test suits not always with entire combinations of params. Sometimes only 2 extendins classes are involved within tests, sometimes 3. I think of using subclasses of IgniteCacheAbstractExecutionContextTest as set of params. Reporter: Vladimir Steshin Assignee: Vladimir Steshin -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12597) IgniteTxStoreExceptionAbstractSelfTest
Vladimir Steshin created IGNITE-12597: - Summary: IgniteTxStoreExceptionAbstractSelfTest Key: IGNITE-12597 URL: https://issues.apache.org/jira/browse/IGNITE-12597 Project: Ignite Issue Type: Sub-task Reporter: Vladimir Steshin Assignee: Vladimir Steshin org.apache.ignite.internal.processors.cache.GridCacheColocatedTxStoreExceptionSelfTest might be parametrized. Extending classes wear only params and are executed in a row -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-12464) Service metrics
[ https://issues.apache.org/jira/browse/IGNITE-12464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin reassigned IGNITE-12464: - Assignee: Vladimir Steshin > Service metrics > --- > > Key: IGNITE-12464 > URL: https://issues.apache.org/jira/browse/IGNITE-12464 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7.6 >Reporter: Nikolay Izhikov >Assignee: Vladimir Steshin >Priority: Minor > Labels: IEP-35 > > We should provide the following metrics for each deployed service: > * -Count of executions- - this number seems useless, because, we can compute > it just by summing all histograms values. > * Histogram of executions duration -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12704) Fail of recognition of default scheme in SQL queries.
Vladimir Steshin created IGNITE-12704:
-
Summary: Fail of recognition of default scheme in SQL queries.
Key: IGNITE-12704
URL: https://issues.apache.org/jira/browse/IGNITE-12704
Project: Ignite
Issue Type: Bug
Reporter: Vladimir Steshin
Got a connectionConnection conn = ...;
// execute() - is just a helper function. Creates prepared statement, pass
params...
// Get all the tables.
List> lst = execute(conn, "select SCHEMA_NAME, TABLE_NAME from
SYS.TABLES");
for( List row : lst ){
String schemaName = (String)row.get(0);
String tableName = (String)row.get(1);
// Shows: "schema: default, table: PERSON"
System.out.println("schema: " + schemName + ", table: " +
tableName));
// Fails with with: java.sql.SQLException: Failed to parse query.
Схема "DEFAULT" не найдена
execute( conn, "drop table "+schemaName + "."+tableName+"'" );
}
I think this case should fail with error like "only cache created tables
can be removed with drop table. ", not with "scheme not found."
SQL-engine is supposed to accept and understand values it returns itself.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12704) Fail of recognition of default scheme in SQL queries.
[
https://issues.apache.org/jira/browse/IGNITE-12704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-12704:
--
Description:
{code:java}
// Got a connection
Connection conn = ...;
// Get all the tables. execute() - is just a helper function. Creates prepared
statement, pass params...
List> lst = execute(conn, "select SCHEMA_NAME, TABLE_NAME from
SYS.TABLES");
for( List row : lst ){
String schemaName = (String)row.get(0);
String tableName = (String)row.get(1);
// Shows: "schema: default, table: PERSON"
System.out.println("schema: " + schemName + ", table: " + tableName));
// Fails with with: java.sql.SQLException: Failed to parse query. Схема
"DEFAULT" не найдена
execute( conn, "drop table "+schemaName + "."+tableName+"'" );
}
I think this case should fail with error like "only cache created tables
can be removed with drop table. ", not with "scheme not found."
SQL-engine is supposed to accept and understand values it returns itself.
was:
Got a connectionConnection conn = ...;
// execute() - is just a helper function. Creates prepared statement, pass
params...
// Get all the tables.
List> lst = execute(conn, "select SCHEMA_NAME, TABLE_NAME from
SYS.TABLES");
for( List row : lst ){
String schemaName = (String)row.get(0);
String tableName = (String)row.get(1);
// Shows: "schema: default, table: PERSON"
System.out.println("schema: " + schemName + ", table: " +
tableName));
// Fails with with: java.sql.SQLException: Failed to parse query.
Схема "DEFAULT" не найдена
execute( conn, "drop table "+schemaName + "."+tableName+"'" );
}
I think this case should fail with error like "only cache created tables
can be removed with drop table. ", not with "scheme not found."
SQL-engine is supposed to accept and understand values it returns itself.
> Fail of recognition of default scheme in SQL queries.
> -
>
> Key: IGNITE-12704
> URL: https://issues.apache.org/jira/browse/IGNITE-12704
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Minor
>
> {code:java}
> // Got a connection
> Connection conn = ...;
> // Get all the tables. execute() - is just a helper function. Creates
> prepared statement, pass params...
> List> lst = execute(conn, "select SCHEMA_NAME, TABLE_NAME from
> SYS.TABLES");
> for( List row : lst ){
> String schemaName = (String)row.get(0);
> String tableName = (String)row.get(1);
> // Shows: "schema: default, table: PERSON"
> System.out.println("schema: " + schemName + ", table: " +
> tableName));
> // Fails with with: java.sql.SQLException: Failed to parse query.
> Схема "DEFAULT" не найдена
> execute( conn, "drop table "+schemaName + "."+tableName+"'" );
> }
>
> I think this case should fail with error like "only cache created tables
> can be removed with drop table. ", not with "scheme not found."
> SQL-engine is supposed to accept and understand values it returns itself.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12704) Fail of recognition of default scheme in SQL queries.
[
https://issues.apache.org/jira/browse/IGNITE-12704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-12704:
--
Description:
{code:java}
// Got a connection
Connection conn = ...;
// Get all the tables. execute() - is just a helper function. Creates prepared
statement, pass params...
List> lst = execute(conn, "select SCHEMA_NAME, TABLE_NAME from
SYS.TABLES");
for( List row : lst ){
String schemaName = (String)row.get(0);
String tableName = (String)row.get(1);
// Shows: "schema: default, table: PERSON"
System.out.println("schema: " + schemName + ", table: " + tableName));
// Fails with with: java.sql.SQLException: Failed to parse query. Схема
"DEFAULT" не найдена
execute( conn, "drop table "+schemaName + "."+tableName+"'" );
}
{code}
I think this case should fail with error like "only cache created tables
can be removed with drop table. ", not with "scheme not found."
SQL-engine is supposed to accept and understand values it returns itself.
was:
{code:java}
// Got a connection
Connection conn = ...;
// Get all the tables. execute() - is just a helper function. Creates prepared
statement, pass params...
List> lst = execute(conn, "select SCHEMA_NAME, TABLE_NAME from
SYS.TABLES");
for( List row : lst ){
String schemaName = (String)row.get(0);
String tableName = (String)row.get(1);
// Shows: "schema: default, table: PERSON"
System.out.println("schema: " + schemName + ", table: " + tableName));
// Fails with with: java.sql.SQLException: Failed to parse query. Схема
"DEFAULT" не найдена
execute( conn, "drop table "+schemaName + "."+tableName+"'" );
}
I think this case should fail with error like "only cache created tables
can be removed with drop table. ", not with "scheme not found."
SQL-engine is supposed to accept and understand values it returns itself.
> Fail of recognition of default scheme in SQL queries.
> -
>
> Key: IGNITE-12704
> URL: https://issues.apache.org/jira/browse/IGNITE-12704
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Minor
>
> {code:java}
> // Got a connection
> Connection conn = ...;
> // Get all the tables. execute() - is just a helper function. Creates
> prepared statement, pass params...
> List> lst = execute(conn, "select SCHEMA_NAME, TABLE_NAME from
> SYS.TABLES");
> for( List row : lst ){
> String schemaName = (String)row.get(0);
> String tableName = (String)row.get(1);
> // Shows: "schema: default, table: PERSON"
> System.out.println("schema: " + schemName + ", table: " +
> tableName));
> // Fails with with: java.sql.SQLException: Failed to parse query.
> Схема "DEFAULT" не найдена
> execute( conn, "drop table "+schemaName + "."+tableName+"'" );
> }
> {code}
> I think this case should fail with error like "only cache created tables
> can be removed with drop table. ", not with "scheme not found."
> SQL-engine is supposed to accept and understand values it returns itself.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12704) Fail of recognition of default scheme in SQL queries.
[
https://issues.apache.org/jira/browse/IGNITE-12704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-12704:
--
Description:
{code:java}
// Got a connection
Connection conn = ...;
// Get all the tables. execute() - is just a helper function. Creates prepared
statement, pass params...
List> lst = execute(conn, "select SCHEMA_NAME, TABLE_NAME from
SYS.TABLES");
for( List row : lst ){
String schemaName = (String)row.get(0);
String tableName = (String)row.get(1);
// Shows: "schema: default, table: PERSON"
System.out.println("schema: " + schemName + ", table: " + tableName));
// Fails with with: java.sql.SQLException: Failed to parse query. Схема
"DEFAULT" не найдена
execute( conn, "drop table "+schemaName + "."+tableName+"'" );
}
{code}
I think this case should fail with error like "only cache created tables
can be removed with drop table. ", not with "scheme not found."
SQL-engine is supposed to accept and understand values it returns itself.
was:
{code:java}
// Got a connection
Connection conn = ...;
// Get all the tables. execute() - is just a helper function. Creates prepared
statement, pass params...
List> lst = execute(conn, "select SCHEMA_NAME, TABLE_NAME from
SYS.TABLES");
for( List row : lst ){
String schemaName = (String)row.get(0);
String tableName = (String)row.get(1);
// Shows: "schema: default, table: PERSON"
System.out.println("schema: " + schemName + ", table: " + tableName));
// Fails with with: java.sql.SQLException: Failed to parse query. Схема
"DEFAULT" не найдена
execute( conn, "drop table "+schemaName + "."+tableName+"'" );
}
{code}
I think this case should fail with error like "only cache created tables
can be removed with drop table. ", not with "scheme not found."
SQL-engine is supposed to accept and understand values it returns itself.
> Fail of recognition of default scheme in SQL queries.
> -
>
> Key: IGNITE-12704
> URL: https://issues.apache.org/jira/browse/IGNITE-12704
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Minor
>
> {code:java}
> // Got a connection
> Connection conn = ...;
> // Get all the tables. execute() - is just a helper function. Creates
> prepared statement, pass params...
> List> lst = execute(conn, "select SCHEMA_NAME, TABLE_NAME from
> SYS.TABLES");
> for( List row : lst ){
>String schemaName = (String)row.get(0);
>String tableName = (String)row.get(1);
> // Shows: "schema: default, table: PERSON"
> System.out.println("schema: " + schemName + ", table: " + tableName));
> // Fails with with: java.sql.SQLException: Failed to parse query. Схема
> "DEFAULT" не найдена
> execute( conn, "drop table "+schemaName + "."+tableName+"'" );
> }
> {code}
> I think this case should fail with error like "only cache created tables
> can be removed with drop table. ", not with "scheme not found."
> SQL-engine is supposed to accept and understand values it returns itself.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12704) Fail of recognition of default scheme in SQL queries.
[
https://issues.apache.org/jira/browse/IGNITE-12704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-12704:
--
Description:
{code:java}
// Got a connection
Connection conn = ...;
// Get all the tables. execute() - is just a helper function. Creates prepared
statement, pass params...
List> lst = execute(conn, "select SCHEMA_NAME, TABLE_NAME from
SYS.TABLES");
for( List row : lst ){
String schemaName = (String)row.get(0);
String tableName = (String)row.get(1);
// Shows: "schema: default, table: PERSON"
System.out.println("schema: " + schemName + ", table: " + tableName));
// Fails with with: java.sql.SQLException: Failed to parse query. Схема
"DEFAULT" не найдена
execute( conn, "drop table "+schemaName + "."+tableName+"'" );
}
{code}
I think this case should fail with error like "only cache created tables can be
removed with drop table. ",
Not with "scheme not found."
SQL-engine is supposed to accept and understand values it returns itself.
was:
{code:java}
// Got a connection
Connection conn = ...;
// Get all the tables. execute() - is just a helper function. Creates prepared
statement, pass params...
List> lst = execute(conn, "select SCHEMA_NAME, TABLE_NAME from
SYS.TABLES");
for( List row : lst ){
String schemaName = (String)row.get(0);
String tableName = (String)row.get(1);
// Shows: "schema: default, table: PERSON"
System.out.println("schema: " + schemName + ", table: " + tableName));
// Fails with with: java.sql.SQLException: Failed to parse query. Схема
"DEFAULT" не найдена
execute( conn, "drop table "+schemaName + "."+tableName+"'" );
}
{code}
I think this case should fail with error like "only cache created tables
can be removed with drop table. ", not with "scheme not found."
SQL-engine is supposed to accept and understand values it returns itself.
> Fail of recognition of default scheme in SQL queries.
> -
>
> Key: IGNITE-12704
> URL: https://issues.apache.org/jira/browse/IGNITE-12704
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Minor
>
> {code:java}
> // Got a connection
> Connection conn = ...;
> // Get all the tables. execute() - is just a helper function. Creates
> prepared statement, pass params...
> List> lst = execute(conn, "select SCHEMA_NAME, TABLE_NAME from
> SYS.TABLES");
> for( List row : lst ){
>String schemaName = (String)row.get(0);
>String tableName = (String)row.get(1);
> // Shows: "schema: default, table: PERSON"
> System.out.println("schema: " + schemName + ", table: " + tableName));
> // Fails with with: java.sql.SQLException: Failed to parse query. Схема
> "DEFAULT" не найдена
> execute( conn, "drop table "+schemaName + "."+tableName+"'" );
> }
> {code}
> I think this case should fail with error like "only cache created tables can
> be removed with drop table. ",
> Not with "scheme not found."
> SQL-engine is supposed to accept and understand values it returns itself.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12464) Service metrics
[ https://issues.apache.org/jira/browse/IGNITE-12464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17042042#comment-17042042 ] Vladimir Steshin commented on IGNITE-12464: --- Major changes: 1) The services are now proxied with IgniteServiceProcessor#LocalInvocationHandler which measures service methods duration. 2) Service metrics are created for each interface method on service deployment, after init(), before execute(). 4) Fixed failed tests which used service class directly instead of its interface. > Service metrics > --- > > Key: IGNITE-12464 > URL: https://issues.apache.org/jira/browse/IGNITE-12464 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7.6 >Reporter: Nikolay Izhikov >Assignee: Vladimir Steshin >Priority: Minor > Labels: IEP-35 > Time Spent: 1h > Remaining Estimate: 0h > > We should provide the following metrics for each deployed service: > * -Count of executions- - this number seems useless, because, we can compute > it just by summing all histograms values. > * Histogram of executions duration -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12701) Disallow silent deactivation in CLI and REST.
[
https://issues.apache.org/jira/browse/IGNITE-12701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17042041#comment-17042041
]
Vladimir Steshin commented on IGNITE-12701:
---
Major changes:
# Added IgniteCluster#state(ClusterState newState, boolean force).
# Deprecated IgniteCluster#state(ClusterState newState).
# Added GridClientClusterStateRequestV2.
# Deprecated GridClientClusterStateRequest.
# Added flag ‘force’ for REST in GridRestClusterStateRequest
# Added flag ‘force’ CLI in DeactivateCommand, ClusterStateChangeCommand.
# Added IgniteFeatures# FORCED_CHANGE_OF_CLUSTER_STATE.
# Added checking of deactivation safety: GridClusterStateProcessor#
isDeactivationSafe()
> Disallow silent deactivation in CLI and REST.
> -
>
> Key: IGNITE-12701
> URL: https://issues.apache.org/jira/browse/IGNITE-12701
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Disallow silent deactivation through the CLI and REST.
> Skip JMX call
> {code:java}
> void IgniteMXBean#active(boolean active)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12464) Service metrics
[ https://issues.apache.org/jira/browse/IGNITE-12464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17042042#comment-17042042 ] Vladimir Steshin edited comment on IGNITE-12464 at 2/21/20 5:13 PM: Major changes: 1) The services are now proxied with IgniteServiceProcessor#LocalInvocationHandler which measures service methods duration. 2) Service metrics are created for each interface method on service deployment, after init(), before execute(). 3) Fixed failed tests which used service class directly instead of its interface. was (Author: vladsz83): Major changes: 1) The services are now proxied with IgniteServiceProcessor#LocalInvocationHandler which measures service methods duration. 2) Service metrics are created for each interface method on service deployment, after init(), before execute(). 4) Fixed failed tests which used service class directly instead of its interface. > Service metrics > --- > > Key: IGNITE-12464 > URL: https://issues.apache.org/jira/browse/IGNITE-12464 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.7.6 >Reporter: Nikolay Izhikov >Assignee: Vladimir Steshin >Priority: Minor > Labels: IEP-35 > Time Spent: 1h > Remaining Estimate: 0h > > We should provide the following metrics for each deployed service: > * -Count of executions- - this number seems useless, because, we can compute > it just by summing all histograms values. > * Histogram of executions duration -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12701) Disallow silent deactivation in CLI and REST.
[
https://issues.apache.org/jira/browse/IGNITE-12701?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17042041#comment-17042041
]
Vladimir Steshin edited comment on IGNITE-12701 at 2/21/20 5:11 PM:
Major changes:
# Added GridClientClusterStateRequestV2.
# Deprecated GridClientClusterStateRequest.
# Added flag ‘force’ for REST in GridRestClusterStateRequest
# Added flag ‘force’ CLI in DeactivateCommand, ClusterStateChangeCommand.
# Added IgniteFeatures# FORCED_CHANGE_OF_CLUSTER_STATE.
# Added checking of deactivation safety: GridClusterStateProcessor#
isDeactivationSafe()
was (Author: vladsz83):
Major changes:
# Added IgniteCluster#state(ClusterState newState, boolean force).
# Deprecated IgniteCluster#state(ClusterState newState).
# Added GridClientClusterStateRequestV2.
# Deprecated GridClientClusterStateRequest.
# Added flag ‘force’ for REST in GridRestClusterStateRequest
# Added flag ‘force’ CLI in DeactivateCommand, ClusterStateChangeCommand.
# Added IgniteFeatures# FORCED_CHANGE_OF_CLUSTER_STATE.
# Added checking of deactivation safety: GridClusterStateProcessor#
isDeactivationSafe()
> Disallow silent deactivation in CLI and REST.
> -
>
> Key: IGNITE-12701
> URL: https://issues.apache.org/jira/browse/IGNITE-12701
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Disallow silent deactivation through the CLI and REST.
> Skip JMX call
> {code:java}
> void IgniteMXBean#active(boolean active)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12701) Disallow silent deactivation in CLI and REST.
Vladimir Steshin created IGNITE-12701:
-
Summary: Disallow silent deactivation in CLI and REST.
Key: IGNITE-12701
URL: https://issues.apache.org/jira/browse/IGNITE-12701
Project: Ignite
Issue Type: Sub-task
Reporter: Vladimir Steshin
Assignee: Vladimir Steshin
Disallow silent deactivation through the CLI and REST.
Skip JMX call
{code:java}
void IgniteMXBean#active(boolean active)
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12779) Split Ignite and IgniteMXBean, make different behavior of the active(boolean)
Vladimir Steshin created IGNITE-12779: - Summary: Split Ignite and IgniteMXBean, make different behavior of the active(boolean) Key: IGNITE-12779 URL: https://issues.apache.org/jira/browse/IGNITE-12779 Project: Ignite Issue Type: Sub-task Reporter: Vladimir Steshin Assignee: Vladimir Steshin To make cluster deactivation through JMX without sudden erasure in-memory data we should: 1) Add _IgniteMXBean#state(String state, boolean force)_. 2) Let _IgniteMXBean#state(String state)_ and _IgniteMXBean#active(boolean active)_ fail when deactivating cluster with in-memory data. 3) Separate implementations _Ignite_ and _IgniteMXBean_ from _IgniteKernal_. They have same method _void active(boolean active)_ which is required with different behavior. In case of _Ignite#active(boolean active)_ it should not fail when deactivating cluster with in-memory data. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12773) Reduce number of cluster deactivation methods in internal API.
[
https://issues.apache.org/jira/browse/IGNITE-12773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-12773:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Reduce number of cluster deactivation methods in internal API.
> --
>
> Key: IGNITE-12773
> URL: https://issues.apache.org/jira/browse/IGNITE-12773
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> To reduce number of cluster deactivation methods in internal API we might:
> {code:java}
> 1.Remove
> GridClientClusterState#active()
> 2.Remove
> GridClientClusterState#active(boolean active)
> 3.Remove
> IGridClusterStateProcessor#changeGlobalState(
> boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 4.Remove
> GridClusterStateProcessor#changeGlobalState(
> final boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
> boolean isAutoAdjust
> )
> 5.Remove
> GridClusterStateProcessor#changeGlobalState(
> final boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 6.Remove
> GridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 7.Add boolean isAutoAdjust to
> IGridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
> boolean isAutoAdjust
> )
> 8.Add @Override to
> IGridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
> boolean isAutoAdjust
> )
> 9. Remove, combine with #8:
> IGridClusterStateProcessor#changeGlobalState0(
> ClusterState state,
> BaselineTopology blt,
> boolean forceChangeBaselineTopology,
> boolean isAutoAdjust
> )
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12773) Reduce number of cluster deactivation methods in internal API.
[
https://issues.apache.org/jira/browse/IGNITE-12773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-12773:
--
Description:
To reduce number of cluster deactivation methods in internal API we might:
{code:java}
1. Remove
GridClientClusterState#active()
2. Remove
GridClientClusterState#active(boolean active)
3. Remove
IGridClusterStateProcessor#changeGlobalState(
boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
4. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
5. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
6. Remove
GridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
7. Add boolean isAutoAdjust to
IGridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
/* here */ boolean isAutoAdjust /* here */
)
8. Add @Override to
/* here */ @Override /* here */
GridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
9. Remove
private IgniteInternalFuture changeGlobalState0(
ClusterState state,
boolean forceDeactivation,
BaselineTopology blt,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
{code}
was:
To reduce number of cluster deactivation methods in internal API we might:
{code:java}
1. Remove
GridClientClusterState#active()
2. Remove
GridClientClusterState#active(boolean active)
3. Remove
IGridClusterStateProcessor#changeGlobalState(
boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
4. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
5. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
6. Remove
GridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
7. Add boolean isAutoAdjust to
IGridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
/* here */ boolean isAutoAdjust /* here */
)
8. Add @Override to
/* here */ @Override /* here */
GridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
9. Remove
private IgniteInternalFuture changeGlobalState0(
ClusterState state,
boolean forceDeactivation,
BaselineTopology blt,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
{code}
> Reduce number of cluster deactivation methods in internal API.
> --
>
> Key: IGNITE-12773
> URL: https://issues.apache.org/jira/browse/IGNITE-12773
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
>
> To reduce number of cluster deactivation methods in internal API we might:
> {code:java}
> 1.Remove
> GridClientClusterState#active()
> 2.Remove
> GridClientClusterState#active(boolean active)
> 3.Remove
> IGridClusterStateProcessor#changeGlobalState(
> boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 4.Remove
> GridClusterStateProcessor#changeGlobalState(
> final boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
> boolean isAutoAdjust
> )
> 5.Remove
> GridClusterStateProcessor#changeGlobalState(
> final boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 6.Remove
> GridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 7.Add boolean isAutoAdjust to
> IGridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
>/* here */ boolean isAutoAdjust /* here */
> )
> 8.Add @Override to
> /* here */ @Override /* here */
> GridClusterStateProcessor#changeGlobalState(
> ClusterState state,
>
[jira] [Updated] (IGNITE-12773) Reduce number of cluster deactivation methods in internal API.
[
https://issues.apache.org/jira/browse/IGNITE-12773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-12773:
--
Description:
To reduce number of cluster deactivation methods in internal API we might:
{code:java}
1. Remove
GridClientClusterState#active()
2. Remove
GridClientClusterState#active(boolean active)
3. Remove
IGridClusterStateProcessor#changeGlobalState(
boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
4. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
5. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
6. Remove
GridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
7. Add boolean isAutoAdjust to
IGridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
/* here */ boolean isAutoAdjust /* here */
)
8. Add @Override to
/* here */ @Override /* here */
GridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
9. Remove
private IgniteInternalFuture changeGlobalState0(
ClusterState state,
boolean forceDeactivation,
BaselineTopology blt,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
{code}
was:
To reduce number of cluster deactivation methods in internal API we might:
{code:java}
1. Remove
GridClientClusterState#active()
2. Remove
GridClientClusterState#active(boolean active)
3. Remove
IGridClusterStateProcessor#changeGlobalState(
boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
4. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
5. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
6. Remove
GridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
7. Add boolean isAutoAdjust to
IGridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
/* here */ boolean isAutoAdjust /* here */
)
8. Add @Override to
/* here */ @Override /* here */
GridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
{code}
> Reduce number of cluster deactivation methods in internal API.
> --
>
> Key: IGNITE-12773
> URL: https://issues.apache.org/jira/browse/IGNITE-12773
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
>
> To reduce number of cluster deactivation methods in internal API we might:
> {code:java}
> 1.Remove
> GridClientClusterState#active()
> 2.Remove
> GridClientClusterState#active(boolean active)
> 3.Remove
> IGridClusterStateProcessor#changeGlobalState(
> boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 4.Remove
> GridClusterStateProcessor#changeGlobalState(
> final boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
> boolean isAutoAdjust
> )
> 5.Remove
> GridClusterStateProcessor#changeGlobalState(
> final boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 6.Remove
> GridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 7.Add boolean isAutoAdjust to
> IGridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
>/* here */ boolean isAutoAdjust /* here */
> )
> 8.Add @Override to
> /* here */ @Override /* here */
> GridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 9. Remove
> private IgniteInternalFuture changeGlobalState0(
> ClusterState state,
> boolean forceDeactivation,
> BaselineTopology
[jira] [Commented] (IGNITE-12773) Reduce number of cluster deactivation methods in internal API.
[
https://issues.apache.org/jira/browse/IGNITE-12773?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17057223#comment-17057223
]
Vladimir Steshin commented on IGNITE-12773:
---
Done all the chages.
> Reduce number of cluster deactivation methods in internal API.
> --
>
> Key: IGNITE-12773
> URL: https://issues.apache.org/jira/browse/IGNITE-12773
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
>
> To reduce number of cluster deactivation methods in internal API we might:
> {code:java}
> 1.Remove
> GridClientClusterState#active()
> 2.Remove
> GridClientClusterState#active(boolean active)
> 3.Remove
> IGridClusterStateProcessor#changeGlobalState(
> boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 4.Remove
> GridClusterStateProcessor#changeGlobalState(
> final boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
> boolean isAutoAdjust
> )
> 5.Remove
> GridClusterStateProcessor#changeGlobalState(
> final boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 6.Remove
> GridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 7.Add boolean isAutoAdjust to
> IGridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
>/* here */ boolean isAutoAdjust /* here */
> )
> 8.Add @Override to
> /* here */ @Override /* here */
> IGridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
> boolean isAutoAdjust
> )
> 9. Remove, combine with #8:
> IGridClusterStateProcessor#changeGlobalState0(
> ClusterState state,
> BaselineTopology blt,
> boolean forceChangeBaselineTopology,
> boolean isAutoAdjust
> )
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12773) Reduce number of cluster deactivation methods in internal API.
[
https://issues.apache.org/jira/browse/IGNITE-12773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-12773:
--
Description:
To reduce number of cluster deactivation methods in internal API we might:
{code:java}
1. Remove
GridClientClusterState#active()
2. Remove
GridClientClusterState#active(boolean active)
3. Remove
IGridClusterStateProcessor#changeGlobalState(
boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
4. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
5. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
6. Remove
GridClusterStateProcessor#changeGlobalState(
ClusterState state,
boolean forceDeactivation,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
7. Add boolean isAutoAdjust to
IGridClusterStateProcessor#changeGlobalState(
ClusterState state,
boolean forceDeactivation,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
/* here */ boolean isAutoAdjust /* here */
)
8. Add @Override to
/* here */ @Override /* here */
GridClusterStateProcessor#changeGlobalState(
ClusterState state,
boolean forceDeactivation,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
{code}
was:
To reduce number of cluster deactivation methods in internal API we might:
1. Remove
GridClientClusterState#active()
2. Remove
GridClientClusterState#active(boolean active)
3. Remove
IGridClusterStateProcessor#changeGlobalState(
boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
4. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
5. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
6. Remove
GridClusterStateProcessor#changeGlobalState(
ClusterState state,
boolean forceDeactivation,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
7. Add boolean isAutoAdjust to
IGridClusterStateProcessor#changeGlobalState(
ClusterState state,
boolean forceDeactivation,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
/* here */ boolean isAutoAdjust /* here */
)
8. Add @Override to
/* here */ @Override /* here */
GridClusterStateProcessor#changeGlobalState(
ClusterState state,
boolean forceDeactivation,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
> Reduce number of cluster deactivation methods in internal API.
> --
>
> Key: IGNITE-12773
> URL: https://issues.apache.org/jira/browse/IGNITE-12773
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
>
> To reduce number of cluster deactivation methods in internal API we might:
> {code:java}
> 1.Remove
> GridClientClusterState#active()
> 2.Remove
> GridClientClusterState#active(boolean active)
> 3.Remove
> IGridClusterStateProcessor#changeGlobalState(
> boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 4.Remove
> GridClusterStateProcessor#changeGlobalState(
> final boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
> boolean isAutoAdjust
> )
> 5.Remove
> GridClusterStateProcessor#changeGlobalState(
> final boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 6.Remove
> GridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> boolean forceDeactivation,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 7.Add boolean isAutoAdjust to
> IGridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> boolean forceDeactivation,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
>/* here */ boolean isAutoAdjust /* here */
> )
> 8.Add @Override to
> /* here */ @Override /* here */
> GridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> boolean forceDeactivation,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12773) Reduce number of cluster deactivation methods in internal API.
Vladimir Steshin created IGNITE-12773: - Summary: Reduce number of cluster deactivation methods in internal API. Key: IGNITE-12773 URL: https://issues.apache.org/jira/browse/IGNITE-12773 Project: Ignite Issue Type: Improvement Reporter: Vladimir Steshin Assignee: Vladimir Steshin To reduce number of cluster deactivation methods in internal API we might: 1. Remove GridClientClusterState#active() 2. Remove GridClientClusterState#active(boolean active) 3. Remove IGridClusterStateProcessor#changeGlobalState( boolean activate, Collection baselineNodes, boolean forceChangeBaselineTopology ) 4. Remove GridClusterStateProcessor#changeGlobalState( final boolean activate, Collection baselineNodes, boolean forceChangeBaselineTopology, boolean isAutoAdjust ) 5. Remove GridClusterStateProcessor#changeGlobalState( final boolean activate, Collection baselineNodes, boolean forceChangeBaselineTopology ) 6. Remove GridClusterStateProcessor#changeGlobalState( ClusterState state, boolean forceDeactivation, Collection baselineNodes, boolean forceChangeBaselineTopology ) 7. Add boolean isAutoAdjust to IGridClusterStateProcessor#changeGlobalState( ClusterState state, boolean forceDeactivation, Collection baselineNodes, boolean forceChangeBaselineTopology, /* here */ boolean isAutoAdjust /* here */ ) 8. Add @Override to /* here */ @Override /* here */ GridClusterStateProcessor#changeGlobalState( ClusterState state, boolean forceDeactivation, Collection baselineNodes, boolean forceChangeBaselineTopology ) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12773) Reduce number of cluster deactivation methods in internal API.
[
https://issues.apache.org/jira/browse/IGNITE-12773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-12773:
--
Description:
To reduce number of cluster deactivation methods in internal API we might:
{code:java}
1. Remove
GridClientClusterState#active()
2. Remove
GridClientClusterState#active(boolean active)
3. Remove
IGridClusterStateProcessor#changeGlobalState(
boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
4. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
5. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
6. Remove
GridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
7. Add boolean isAutoAdjust to
IGridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
/* here */ boolean isAutoAdjust /* here */
)
8. Add @Override to
/* here */ @Override /* here */
IGridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
9. Remove, combine with #8:
IGridClusterStateProcessor#changeGlobalState0(
ClusterState state,
BaselineTopology blt,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
{code}
was:
To reduce number of cluster deactivation methods in internal API we might:
{code:java}
1. Remove
GridClientClusterState#active()
2. Remove
GridClientClusterState#active(boolean active)
3. Remove
IGridClusterStateProcessor#changeGlobalState(
boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
4. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
5. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
6. Remove
GridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
7. Add boolean isAutoAdjust to
IGridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
/* here */ boolean isAutoAdjust /* here */
)
8. Add @Override to
/* here */ @Override /* here */
IGridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
9. Remove, combine with #8:
private IgniteInternalFuture changeGlobalState0(
ClusterState state,
BaselineTopology blt,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
{code}
> Reduce number of cluster deactivation methods in internal API.
> --
>
> Key: IGNITE-12773
> URL: https://issues.apache.org/jira/browse/IGNITE-12773
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
>
> To reduce number of cluster deactivation methods in internal API we might:
> {code:java}
> 1.Remove
> GridClientClusterState#active()
> 2.Remove
> GridClientClusterState#active(boolean active)
> 3.Remove
> IGridClusterStateProcessor#changeGlobalState(
> boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 4.Remove
> GridClusterStateProcessor#changeGlobalState(
> final boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
> boolean isAutoAdjust
> )
> 5.Remove
> GridClusterStateProcessor#changeGlobalState(
> final boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 6.Remove
> GridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 7.Add boolean isAutoAdjust to
> IGridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
>/* here */ boolean isAutoAdjust /* here */
> )
> 8.Add @Override to
> /* here */ @Override /* here */
>
[jira] [Updated] (IGNITE-12773) Reduce number of cluster deactivation methods in internal API.
[
https://issues.apache.org/jira/browse/IGNITE-12773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-12773:
--
Description:
To reduce number of cluster deactivation methods in internal API we might:
{code:java}
1. Remove
GridClientClusterState#active()
2. Remove
GridClientClusterState#active(boolean active)
3. Remove
IGridClusterStateProcessor#changeGlobalState(
boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
4. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
5. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
6. Remove
GridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
7. Add boolean isAutoAdjust to
IGridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
/* here */ boolean isAutoAdjust /* here */
)
8. Add @Override to
/* here */ @Override /* here */
IGridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
9. Remove, combine with #8:
private IgniteInternalFuture changeGlobalState0(
ClusterState state,
BaselineTopology blt,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
{code}
was:
To reduce number of cluster deactivation methods in internal API we might:
{code:java}
1. Remove
GridClientClusterState#active()
2. Remove
GridClientClusterState#active(boolean active)
3. Remove
IGridClusterStateProcessor#changeGlobalState(
boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
4. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
5. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
6. Remove
GridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
7. Add boolean isAutoAdjust to
IGridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
/* here */ boolean isAutoAdjust /* here */
)
8. Add @Override to
/* here */ @Override /* here */
IGridClusterStateProcessor#changeGlobalState(
ClusterState state,
boolean forceDeactivation,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
9. Remove, combine with #8:
private IgniteInternalFuture changeGlobalState0(
ClusterState state,
BaselineTopology blt,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
{code}
> Reduce number of cluster deactivation methods in internal API.
> --
>
> Key: IGNITE-12773
> URL: https://issues.apache.org/jira/browse/IGNITE-12773
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
>
> To reduce number of cluster deactivation methods in internal API we might:
> {code:java}
> 1.Remove
> GridClientClusterState#active()
> 2.Remove
> GridClientClusterState#active(boolean active)
> 3.Remove
> IGridClusterStateProcessor#changeGlobalState(
> boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 4.Remove
> GridClusterStateProcessor#changeGlobalState(
> final boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
> boolean isAutoAdjust
> )
> 5.Remove
> GridClusterStateProcessor#changeGlobalState(
> final boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 6.Remove
> GridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 7.Add boolean isAutoAdjust to
> IGridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
>/* here */ boolean isAutoAdjust /* here */
> )
> 8.Add @Override to
> /* here */
[jira] [Updated] (IGNITE-12773) Reduce number of cluster deactivation methods in internal API.
[
https://issues.apache.org/jira/browse/IGNITE-12773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-12773:
--
Description:
To reduce number of cluster deactivation methods in internal API we might:
{code:java}
1. Remove
GridClientClusterState#active()
2. Remove
GridClientClusterState#active(boolean active)
3. Remove
IGridClusterStateProcessor#changeGlobalState(
boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
4. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
5. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
6. Remove
GridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
7. Add boolean isAutoAdjust to
IGridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
/* here */ boolean isAutoAdjust /* here */
)
8. Add @Override to
/* here */ @Override /* here */
IGridClusterStateProcessor#changeGlobalState(
ClusterState state,
boolean forceDeactivation,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
9. Remove, combine with #8:
private IgniteInternalFuture changeGlobalState0(
ClusterState state,
BaselineTopology blt,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
{code}
was:
To reduce number of cluster deactivation methods in internal API we might:
{code:java}
1. Remove
GridClientClusterState#active()
2. Remove
GridClientClusterState#active(boolean active)
3. Remove
IGridClusterStateProcessor#changeGlobalState(
boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
4. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
5. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
6. Remove
GridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
7. Add boolean isAutoAdjust to
IGridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
/* here */ boolean isAutoAdjust /* here */
)
8. Add @Override to
/* here */ @Override /* here */
IGridClusterStateProcessor#changeGlobalState(
ClusterState state,
boolean forceDeactivation,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
9. Remove, combine with #8:
private IgniteInternalFuture changeGlobalState0(
ClusterState state,
boolean forceDeactivation,
BaselineTopology blt,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
{code}
> Reduce number of cluster deactivation methods in internal API.
> --
>
> Key: IGNITE-12773
> URL: https://issues.apache.org/jira/browse/IGNITE-12773
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
>
> To reduce number of cluster deactivation methods in internal API we might:
> {code:java}
> 1.Remove
> GridClientClusterState#active()
> 2.Remove
> GridClientClusterState#active(boolean active)
> 3.Remove
> IGridClusterStateProcessor#changeGlobalState(
> boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 4.Remove
> GridClusterStateProcessor#changeGlobalState(
> final boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
> boolean isAutoAdjust
> )
> 5.Remove
> GridClusterStateProcessor#changeGlobalState(
> final boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 6.Remove
> GridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 7.Add boolean isAutoAdjust to
> IGridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
>/* here */ boolean
[jira] [Updated] (IGNITE-12773) Reduce number of cluster deactivation methods in internal API.
[
https://issues.apache.org/jira/browse/IGNITE-12773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-12773:
--
Description:
To reduce number of cluster deactivation methods in internal API we might:
{code:java}
1. Remove
GridClientClusterState#active()
2. Remove
GridClientClusterState#active(boolean active)
3. Remove
IGridClusterStateProcessor#changeGlobalState(
boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
4. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
5. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
6. Remove
GridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
7. Add boolean isAutoAdjust to
IGridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
/* here */ boolean isAutoAdjust /* here */
)
8. Add @Override to
/* here */ @Override /* here */
IGridClusterStateProcessor#changeGlobalState(
ClusterState state,
boolean forceDeactivation,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
9. Remove, combine with #8:
private IgniteInternalFuture changeGlobalState0(
ClusterState state,
boolean forceDeactivation,
BaselineTopology blt,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
{code}
was:
To reduce number of cluster deactivation methods in internal API we might:
{code:java}
1. Remove
GridClientClusterState#active()
2. Remove
GridClientClusterState#active(boolean active)
3. Remove
IGridClusterStateProcessor#changeGlobalState(
boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
4. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
5. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
6. Remove
GridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
7. Add boolean isAutoAdjust to
IGridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
/* here */ boolean isAutoAdjust /* here */
)
8. Add @Override to
/* here */ @Override /* here */
GridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
9. Remove
private IgniteInternalFuture changeGlobalState0(
ClusterState state,
boolean forceDeactivation,
BaselineTopology blt,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
{code}
> Reduce number of cluster deactivation methods in internal API.
> --
>
> Key: IGNITE-12773
> URL: https://issues.apache.org/jira/browse/IGNITE-12773
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
>
> To reduce number of cluster deactivation methods in internal API we might:
> {code:java}
> 1.Remove
> GridClientClusterState#active()
> 2.Remove
> GridClientClusterState#active(boolean active)
> 3.Remove
> IGridClusterStateProcessor#changeGlobalState(
> boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 4.Remove
> GridClusterStateProcessor#changeGlobalState(
> final boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
> boolean isAutoAdjust
> )
> 5.Remove
> GridClusterStateProcessor#changeGlobalState(
> final boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 6.Remove
> GridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 7.Add boolean isAutoAdjust to
> IGridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
>/* here */ boolean isAutoAdjust /* here */
> )
> 8.Add @Override to
> /* here
[jira] [Updated] (IGNITE-12773) Reduce number of cluster deactivation methods in internal API.
[
https://issues.apache.org/jira/browse/IGNITE-12773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-12773:
--
Description:
To reduce number of cluster deactivation methods in internal API we might:
{code:java}
1. Remove
GridClientClusterState#active()
2. Remove
GridClientClusterState#active(boolean active)
3. Remove
IGridClusterStateProcessor#changeGlobalState(
boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
4. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
5. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
6. Remove
GridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
7. Add boolean isAutoAdjust to
IGridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
/* here */ boolean isAutoAdjust /* here */
)
8. Add @Override to
/* here */ @Override /* here */
GridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
{code}
was:
To reduce number of cluster deactivation methods in internal API we might:
{code:java}
1. Remove
GridClientClusterState#active()
2. Remove
GridClientClusterState#active(boolean active)
3. Remove
IGridClusterStateProcessor#changeGlobalState(
boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
4. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
5. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
6. Remove
GridClusterStateProcessor#changeGlobalState(
ClusterState state,
boolean forceDeactivation,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
7. Add boolean isAutoAdjust to
IGridClusterStateProcessor#changeGlobalState(
ClusterState state,
boolean forceDeactivation,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
/* here */ boolean isAutoAdjust /* here */
)
8. Add @Override to
/* here */ @Override /* here */
GridClusterStateProcessor#changeGlobalState(
ClusterState state,
boolean forceDeactivation,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
{code}
> Reduce number of cluster deactivation methods in internal API.
> --
>
> Key: IGNITE-12773
> URL: https://issues.apache.org/jira/browse/IGNITE-12773
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
>
> To reduce number of cluster deactivation methods in internal API we might:
> {code:java}
> 1.Remove
> GridClientClusterState#active()
> 2.Remove
> GridClientClusterState#active(boolean active)
> 3.Remove
> IGridClusterStateProcessor#changeGlobalState(
> boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 4.Remove
> GridClusterStateProcessor#changeGlobalState(
> final boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
> boolean isAutoAdjust
> )
> 5.Remove
> GridClusterStateProcessor#changeGlobalState(
> final boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 6.Remove
> GridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 7.Add boolean isAutoAdjust to
> IGridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
>/* here */ boolean isAutoAdjust /* here */
> )
> 8.Add @Override to
> /* here */ @Override /* here */
> GridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12773) Reduce number of cluster deactivation methods in internal API.
[
https://issues.apache.org/jira/browse/IGNITE-12773?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-12773:
--
Description:
To reduce number of cluster deactivation methods in internal API we might:
{code:java}
1. Remove
GridClientClusterState#active()
2. Remove
GridClientClusterState#active(boolean active)
3. Remove
IGridClusterStateProcessor#changeGlobalState(
boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
4. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
5. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
6. Remove
GridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
7. Add boolean isAutoAdjust to
IGridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
8. Add @Override to
IGridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
9. Remove, combine with #8:
IGridClusterStateProcessor#changeGlobalState0(
ClusterState state,
BaselineTopology blt,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
{code}
was:
To reduce number of cluster deactivation methods in internal API we might:
{code:java}
1. Remove
GridClientClusterState#active()
2. Remove
GridClientClusterState#active(boolean active)
3. Remove
IGridClusterStateProcessor#changeGlobalState(
boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
4. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
5. Remove
GridClusterStateProcessor#changeGlobalState(
final boolean activate,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
6. Remove
GridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology
)
7. Add boolean isAutoAdjust to
IGridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
/* here */ boolean isAutoAdjust /* here */
)
8. Add @Override to
/* here */ @Override /* here */
IGridClusterStateProcessor#changeGlobalState(
ClusterState state,
Collection baselineNodes,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
9. Remove, combine with #8:
IGridClusterStateProcessor#changeGlobalState0(
ClusterState state,
BaselineTopology blt,
boolean forceChangeBaselineTopology,
boolean isAutoAdjust
)
{code}
> Reduce number of cluster deactivation methods in internal API.
> --
>
> Key: IGNITE-12773
> URL: https://issues.apache.org/jira/browse/IGNITE-12773
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Minor
>
> To reduce number of cluster deactivation methods in internal API we might:
> {code:java}
> 1.Remove
> GridClientClusterState#active()
> 2.Remove
> GridClientClusterState#active(boolean active)
> 3.Remove
> IGridClusterStateProcessor#changeGlobalState(
> boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 4.Remove
> GridClusterStateProcessor#changeGlobalState(
> final boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
> boolean isAutoAdjust
> )
> 5.Remove
> GridClusterStateProcessor#changeGlobalState(
> final boolean activate,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 6.Remove
> GridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology
> )
> 7.Add boolean isAutoAdjust to
> IGridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
> boolean forceChangeBaselineTopology,
> boolean isAutoAdjust
> )
> 8.Add @Override to
> IGridClusterStateProcessor#changeGlobalState(
> ClusterState state,
> Collection baselineNodes,
>
[jira] [Updated] (IGNITE-12779) Split implementations of Ignite and IgniteMXBean, make behavior of their active(boolean) different
[
https://issues.apache.org/jira/browse/IGNITE-12779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-12779:
--
Description:
To make cluster deactivation through JMX without sudden erasure of in-memory
data we should:
1) Set IgniteMXBean.active(false) and IgniteMXBean.state("inactive") throwing
an exception if deactivation would clear in-memory data.
2) Extract IgniteMXBean from IgniteKernal.
3) Add IgniteMXBean.state(String, boolean)
Additionally, as discussed, improve comments _"If {@code true}, cluster
deactivation will be forced."_ :
add a link to full description.
was:
To make cluster deactivation through JMX without sudden erasure of in-memory
data we should:
1) Set IgniteMXBean.active(false) and IgniteMXBean.state("inactive") throwing
an exception if deactivation would clear in-memory data.
2) Extract IgniteMXBean from IgniteKernal.
3) Add IgniteMXBean.state(String, boolean)
> Split implementations of Ignite and IgniteMXBean, make behavior of their
> active(boolean) different
> ---
>
> Key: IGNITE-12779
> URL: https://issues.apache.org/jira/browse/IGNITE-12779
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> To make cluster deactivation through JMX without sudden erasure of in-memory
> data we should:
> 1) Set IgniteMXBean.active(false) and IgniteMXBean.state("inactive") throwing
> an exception if deactivation would clear in-memory data.
> 2) Extract IgniteMXBean from IgniteKernal.
> 3) Add IgniteMXBean.state(String, boolean)
> Additionally, as discussed, improve comments _"If {@code true}, cluster
> deactivation will be forced."_ :
> add a link to full description.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12779) Split implementations of Ignite and IgniteMXBean, make behavior of their active(boolean) different
[
https://issues.apache.org/jira/browse/IGNITE-12779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-12779:
--
Description:
To make cluster deactivation through JMX without sudden erasure of in-memory
data we should:
1) Set IgniteMXBean.active(false) and IgniteMXBean.state("inactive") throwing
an exception if deactivation would clear in-memory data.
2) Extract IgniteMXBean from IgniteKernal.
3) Add IgniteMXBean.state(String, boolean)
Additionally, as discussed, improve comments
_If {@code true}, cluster deactivation will be forced._ :
add a link to full description.
was:
To make cluster deactivation through JMX without sudden erasure of in-memory
data we should:
1) Set IgniteMXBean.active(false) and IgniteMXBean.state("inactive") throwing
an exception if deactivation would clear in-memory data.
2) Extract IgniteMXBean from IgniteKernal.
3) Add IgniteMXBean.state(String, boolean)
Additionally, as discussed, improve comments _"If {@code true}, cluster
deactivation will be forced."_ :
add a link to full description.
> Split implementations of Ignite and IgniteMXBean, make behavior of their
> active(boolean) different
> ---
>
> Key: IGNITE-12779
> URL: https://issues.apache.org/jira/browse/IGNITE-12779
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> To make cluster deactivation through JMX without sudden erasure of in-memory
> data we should:
> 1) Set IgniteMXBean.active(false) and IgniteMXBean.state("inactive") throwing
> an exception if deactivation would clear in-memory data.
> 2) Extract IgniteMXBean from IgniteKernal.
> 3) Add IgniteMXBean.state(String, boolean)
> Additionally, as discussed, improve comments
> _If {@code true}, cluster deactivation will be forced._ :
> add a link to full description.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12779) Split implementations of Ignite and IgniteMXBean, make behavior of their active(boolean) different
[
https://issues.apache.org/jira/browse/IGNITE-12779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-12779:
--
Description:
To make cluster deactivation through JMX without sudden erasure of in-memory
data we should:
1) Set IgniteMXBean.active(false) and IgniteMXBean.state("inactive") throwing
an exception if deactivation would clear in-memory data.
2) Extract IgniteMXBean from IgniteKernal.
3) Add IgniteMXBean.state(String, boolean)
Additionally, as discussed, we should improve comments
{code:java}
/** If {@code true}, cluster deactivation will be forced. */
{code}
Let's add a link to a full description.
was:
To make cluster deactivation through JMX without sudden erasure of in-memory
data we should:
1) Set IgniteMXBean.active(false) and IgniteMXBean.state("inactive") throwing
an exception if deactivation would clear in-memory data.
2) Extract IgniteMXBean from IgniteKernal.
3) Add IgniteMXBean.state(String, boolean)
Additionally, as discussed, improve comments
{code:java}
/** If {@code true}, cluster deactivation will be forced. */
{code}
- add a link to full description.
> Split implementations of Ignite and IgniteMXBean, make behavior of their
> active(boolean) different
> ---
>
> Key: IGNITE-12779
> URL: https://issues.apache.org/jira/browse/IGNITE-12779
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> To make cluster deactivation through JMX without sudden erasure of in-memory
> data we should:
> 1) Set IgniteMXBean.active(false) and IgniteMXBean.state("inactive") throwing
> an exception if deactivation would clear in-memory data.
> 2) Extract IgniteMXBean from IgniteKernal.
> 3) Add IgniteMXBean.state(String, boolean)
> Additionally, as discussed, we should improve comments
> {code:java}
> /** If {@code true}, cluster deactivation will be forced. */
> {code}
> Let's add a link to a full description.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12779) Split implementations of Ignite and IgniteMXBean, make behavior of their active(boolean) different
[
https://issues.apache.org/jira/browse/IGNITE-12779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-12779:
--
Description:
To make cluster deactivation through JMX without sudden erasure of in-memory
data we should:
1) Set IgniteMXBean.active(false) and IgniteMXBean.state("inactive") throwing
an exception if deactivation would clear in-memory data.
2) Extract IgniteMXBean from IgniteKernal.
3) Add IgniteMXBean.state(String, boolean)
Additionally, as discussed, improve comments
{code:java}
/** If {@code true}, cluster deactivation will be forced. */
{code}
- add a link to full description.
was:
To make cluster deactivation through JMX without sudden erasure of in-memory
data we should:
1) Set IgniteMXBean.active(false) and IgniteMXBean.state("inactive") throwing
an exception if deactivation would clear in-memory data.
2) Extract IgniteMXBean from IgniteKernal.
3) Add IgniteMXBean.state(String, boolean)
Additionally, as discussed, improve comments
_If {@code true}, cluster deactivation will be forced._ :
add a link to full description.
> Split implementations of Ignite and IgniteMXBean, make behavior of their
> active(boolean) different
> ---
>
> Key: IGNITE-12779
> URL: https://issues.apache.org/jira/browse/IGNITE-12779
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> To make cluster deactivation through JMX without sudden erasure of in-memory
> data we should:
> 1) Set IgniteMXBean.active(false) and IgniteMXBean.state("inactive") throwing
> an exception if deactivation would clear in-memory data.
> 2) Extract IgniteMXBean from IgniteKernal.
> 3) Add IgniteMXBean.state(String, boolean)
> Additionally, as discussed, improve comments
> {code:java}
> /** If {@code true}, cluster deactivation will be forced. */
> {code}
> - add a link to full description.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12779) Split implementations of Ignite and IgniteMXBean, make behavior of their active(boolean) different
[
https://issues.apache.org/jira/browse/IGNITE-12779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-12779:
--
Description:
To make cluster deactivation through JMX without sudden erasure of in-memory
data we should:
1) Set IgniteMXBean.active(false) and IgniteMXBean.state("inactive") throwing
an exception if deactivation would clear in-memory data.
2) Extract IgniteMXBean from IgniteKernal.
3) Add IgniteMXBean.state(String, boolean)
Additionally, as discussed, we should improve comments
{code:java}
/** If {@code true}, cluster deactivation will be forced. */
{code}
Let's add a link to a full description.
was:
To make cluster deactivation through JMX without sudden erasure of in-memory
data we should:
1) Set IgniteMXBean.active(false) and IgniteMXBean.state("inactive") throwing
an exception if deactivation would clear in-memory data.
2) Extract IgniteMXBean from IgniteKernal.
3) Add IgniteMXBean.state(String, boolean)
Additionally, as discussed, we should improve comments
{code:java}
/** If {@code true}, cluster deactivation will be forced. */
{code}
Let's add a link to a full description.
> Split implementations of Ignite and IgniteMXBean, make behavior of their
> active(boolean) different
> ---
>
> Key: IGNITE-12779
> URL: https://issues.apache.org/jira/browse/IGNITE-12779
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> To make cluster deactivation through JMX without sudden erasure of in-memory
> data we should:
> 1) Set IgniteMXBean.active(false) and IgniteMXBean.state("inactive") throwing
> an exception if deactivation would clear in-memory data.
> 2) Extract IgniteMXBean from IgniteKernal.
> 3) Add IgniteMXBean.state(String, boolean)
> Additionally, as discussed, we should improve comments
> {code:java}
> /** If {@code true}, cluster deactivation will be forced. */
> {code}
> Let's add a link to a full description.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12779) Split implementations of Ignite and IgniteMXBean, make different behavior of their active(boolean)
[ https://issues.apache.org/jira/browse/IGNITE-12779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-12779: -- Summary: Split implementations of Ignite and IgniteMXBean, make different behavior of their active(boolean) (was: Split Ignite and IgniteMXBean, make different behavior of the active(boolean)) > Split implementations of Ignite and IgniteMXBean, make different behavior of > their active(boolean) > -- > > Key: IGNITE-12779 > URL: https://issues.apache.org/jira/browse/IGNITE-12779 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > To make cluster deactivation through JMX without sudden erasure in-memory > data we should: > 1)Add _IgniteMXBean#state(String state, boolean force)_. > 2)Let _IgniteMXBean#state(String state)_ and _IgniteMXBean#active(boolean > active)_ fail when deactivating cluster with in-memory data. > 3)Separate implementations _Ignite_ and _IgniteMXBean_ from > _IgniteKernal_. They have same method _void active(boolean active)_ which is > required with different behavior. In case of _Ignite#active(boolean active)_ > it should not fail when deactivating cluster with in-memory data. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12779) Split implementations of Ignite and IgniteMXBean, make behavior of their active(boolean) different
[ https://issues.apache.org/jira/browse/IGNITE-12779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-12779: -- Summary: Split implementations of Ignite and IgniteMXBean, make behavior of their active(boolean) different (was: Split implementations of Ignite and IgniteMXBean, make different behavior of their active(boolean)) > Split implementations of Ignite and IgniteMXBean, make behavior of their > active(boolean) different > --- > > Key: IGNITE-12779 > URL: https://issues.apache.org/jira/browse/IGNITE-12779 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > To make cluster deactivation through JMX without sudden erasure in-memory > data we should: > 1)Add _IgniteMXBean#state(String state, boolean force)_. > 2)Let _IgniteMXBean#state(String state)_ and _IgniteMXBean#active(boolean > active)_ fail when deactivating cluster with in-memory data. > 3)Separate implementations _Ignite_ and _IgniteMXBean_ from > _IgniteKernal_. They have same method _void active(boolean active)_ which is > required with different behavior. In case of _Ignite#active(boolean active)_ > it should not fail when deactivating cluster with in-memory data. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-12464) Service metrics
[ https://issues.apache.org/jira/browse/IGNITE-12464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-12464: -- Comment: was deleted (was: Major changes: 1) The services are now proxied with IgniteServiceProcessor#LocalInvocationHandler which measures service methods duration. 2) Service metrics are created for each interface method on service deployment, after init(), before execute(). 3) Fixed failed tests which used service class directly instead of its interface.) > Service metrics > --- > > Key: IGNITE-12464 > URL: https://issues.apache.org/jira/browse/IGNITE-12464 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.8 >Reporter: Nikolay Izhikov >Assignee: Vladimir Steshin >Priority: Minor > Labels: IEP-35 > Time Spent: 17.5h > Remaining Estimate: 0h > > We should provide the following metrics for each deployed service: > * -Count of executions- - this number seems useless, because, we can compute > it just by summing all histograms values. > * Histogram of executions duration -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12739) Optimistic serializable transactions may fail infinitely when read-through is enabled
[ https://issues.apache.org/jira/browse/IGNITE-12739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-12739: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Optimistic serializable transactions may fail infinitely when read-through is > enabled > - > > Key: IGNITE-12739 > URL: https://issues.apache.org/jira/browse/IGNITE-12739 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Goncharuk >Assignee: Vladimir Steshin >Priority: Major > Attachments: ReplicatedOptimisticTxTest.java > > Time Spent: 50m > Remaining Estimate: 0h > > In current design it is possible that the same key-value pair will be stored > with different versions on primary and backup nodes. For example, a > read-through is invoked separately on primary backup and values are stored > with node local version. > With this precondition, if an optimistic serializable transaction is started > from a backup node, the serializable check version is read from backup, but > validated on primary node, which will fail the transaction with optimistic > read/write conflict exception until the versions are overwritten to the same > value (for example, via a pessimistic transaction). > While we need to additionally investigate whether we want to change the > read-through logic to ensure the same value and version on all nodes, this > particular scenario should be fixed by always enforcing reading from a > primary node inside an optimistic serializable transaction. > The reproducer is attached. A known workaround is to disable read load > balancing by setting "-DIGNITE_READ_LOAD_BALANCING=false" system property. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12739) Optimistic serializable transactions may fail infinitely when read-through is enabled
[ https://issues.apache.org/jira/browse/IGNITE-12739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-12739: -- Fix Version/s: 2.9 > Optimistic serializable transactions may fail infinitely when read-through is > enabled > - > > Key: IGNITE-12739 > URL: https://issues.apache.org/jira/browse/IGNITE-12739 > Project: Ignite > Issue Type: Bug >Reporter: Alexey Goncharuk >Assignee: Vladimir Steshin >Priority: Major > Fix For: 2.9 > > Attachments: ReplicatedOptimisticTxTest.java > > Time Spent: 50m > Remaining Estimate: 0h > > In current design it is possible that the same key-value pair will be stored > with different versions on primary and backup nodes. For example, a > read-through is invoked separately on primary backup and values are stored > with node local version. > With this precondition, if an optimistic serializable transaction is started > from a backup node, the serializable check version is read from backup, but > validated on primary node, which will fail the transaction with optimistic > read/write conflict exception until the versions are overwritten to the same > value (for example, via a pessimistic transaction). > While we need to additionally investigate whether we want to change the > read-through logic to ensure the same value and version on all nodes, this > particular scenario should be fixed by always enforcing reading from a > primary node inside an optimistic serializable transaction. > The reproducer is attached. A known workaround is to disable read load > balancing by setting "-DIGNITE_READ_LOAD_BALANCING=false" system property. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12739) Optimistic serializable transactions may fail infinitely when read-through is enabled
[ https://issues.apache.org/jira/browse/IGNITE-12739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-12739: -- Affects Version/s: 2.8 > Optimistic serializable transactions may fail infinitely when read-through is > enabled > - > > Key: IGNITE-12739 > URL: https://issues.apache.org/jira/browse/IGNITE-12739 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.8 >Reporter: Alexey Goncharuk >Assignee: Vladimir Steshin >Priority: Major > Fix For: 2.9 > > Attachments: ReplicatedOptimisticTxTest.java > > Time Spent: 50m > Remaining Estimate: 0h > > In current design it is possible that the same key-value pair will be stored > with different versions on primary and backup nodes. For example, a > read-through is invoked separately on primary backup and values are stored > with node local version. > With this precondition, if an optimistic serializable transaction is started > from a backup node, the serializable check version is read from backup, but > validated on primary node, which will fail the transaction with optimistic > read/write conflict exception until the versions are overwritten to the same > value (for example, via a pessimistic transaction). > While we need to additionally investigate whether we want to change the > read-through logic to ensure the same value and version on all nodes, this > particular scenario should be fixed by always enforcing reading from a > primary node inside an optimistic serializable transaction. > The reproducer is attached. A known workaround is to disable read load > balancing by setting "-DIGNITE_READ_LOAD_BALANCING=false" system property. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12779) Split implementations of Ignite and IgniteMXBean, make behavior of their active(boolean) different
[
https://issues.apache.org/jira/browse/IGNITE-12779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-12779:
--
Description:
To make cluster deactivation through JMX without sudden erasure of in-memory
data we should:
1) Set IgniteMXBean.active(false) and IgniteMXBean.state("inactive") throwing
an exception if deactivation would clear in-memory data.
2) Extract IgniteMXBean from IgniteKernal.
3) Add IgniteMXBean.state(String, boolean)
was:
To make cluster deactivation through JMX without sudden erasure in-memory data
we should:
1) Set IgniteMXBean.active(false) and IgniteMXBean.state("inactive") throwing
an exception if deactivation would clear in-memory data.
2) Extract IgniteMXBean from IgniteKernal.
3) Add IgniteMXBean.state(String, boolean)
> Split implementations of Ignite and IgniteMXBean, make behavior of their
> active(boolean) different
> ---
>
> Key: IGNITE-12779
> URL: https://issues.apache.org/jira/browse/IGNITE-12779
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 2.8
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> To make cluster deactivation through JMX without sudden erasure of in-memory
> data we should:
> 1) Set IgniteMXBean.active(false) and IgniteMXBean.state("inactive") throwing
> an exception if deactivation would clear in-memory data.
> 2) Extract IgniteMXBean from IgniteKernal.
> 3) Add IgniteMXBean.state(String, boolean)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13016) Fix backward checking of failed node.
[
https://issues.apache.org/jira/browse/IGNITE-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13016:
--
Description:
We should fix 3 drawbacks in the backward checking of failed node:
1) It has hardcoded timeout 100ms:
{code:java}
private boolean ServerImpls.isConnectionRefused(SocketAddress addr) {
try (Socket sock = new Socket()) {
sock.connect(addr, 100);
}
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false;
}
return false;
}
{code}
2) Maximal interval to check previous node in the ring is:
{code:java}
TcpDiscoveryHandshakeResponse res =
new TcpDiscoveryHandshakeResponse(...);
...
// We got message from previous in less than double
connection check interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now;
if (ok) {
// Check case when previous node suddenly died.
This will speed up
// node failing.
...
}
res.previousNodeAlive(ok);
{code}
was:
Backward checking of failed node rely on hardcoced timeout 100ms:
{code:java}
private boolean ServerImpls.isConnectionRefused(SocketAddress addr) {
try (Socket sock = new Socket()) {
sock.connect(addr, 100);
}
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false;
}
return false;
}
{code}
We should make it bound to configurable params like
IgniteConfiguration.failureDetectionTimeout.
Also, the maximal interval to chech previous node is
Summary: Fix backward checking of failed node. (was: Remove hardcoded
values/timeouts from backward checking of failed node.)
> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
>
> We should fix 3 drawbacks in the backward checking of failed node:
> 1) It has hardcoded timeout 100ms:
> {code:java}
> private boolean ServerImpls.isConnectionRefused(SocketAddress addr) {
> try (Socket sock = new Socket()) {
> sock.connect(addr, 100);
> }
> catch (ConnectException e) {
> return true;
> }
> catch (IOException e) {
> return false;
> }
> return false;
> }
> {code}
> 2) Maximal interval to check previous node in the ring is:
> {code:java}
> TcpDiscoveryHandshakeResponse res =
> new TcpDiscoveryHandshakeResponse(...);
> ...
> // We got message from previous in less than double
> connection check interval.
> boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now;
> if (ok) {
> // Check case when previous node suddenly died.
> This will speed up
> // node failing.
> ...
> }
> res.previousNodeAlive(ok);
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13016) Fix backward checking of failed node.
[
https://issues.apache.org/jira/browse/IGNITE-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13016:
--
Description:
We should fix 3 drawbacks in the backward checking of failed node:
1) It has hardcoded timeout 100ms:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
...
sock.connect(addr, 100);
...
}
{code}
2) Maximal interval to check previous node should be reconsidered, bound to
configurable params:
{code:java}
TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
...
// We got message from previous in less than double connection check
interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 *
CON_CHECK_INTERVAL', not a failureDetectionTimeout.
if (ok) {
// Check case when previous node suddenly died. This will speed up
// node failing.
...
}
res.previousNodeAlive(ok);
{code}
3) Any negative result of the connection checking should be considered as node
failed. Currently, we look only at refused connection. Any other exceptions,
including a timeout, are treated as living connection:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
...
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false;//Why a timeout doesn't mean lost connection?
}
return false;
}
{code}
was:
We should fix 3 drawbacks in the backward checking of failed node:
1) It has hardcoded timeout 100ms:
{code:java}
private boolean ServerImpls.isConnectionRefused(SocketAddress addr) {
try (Socket sock = new Socket()) {
sock.connect(addr, 100);
}
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false;
}
return false;
}
{code}
2) Maximal interval to check previous node in the ring is:
{code:java}
TcpDiscoveryHandshakeResponse res =
new TcpDiscoveryHandshakeResponse(...);
...
// We got message from previous in less than double
connection check interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now;
if (ok) {
// Check case when previous node suddenly died.
This will speed up
// node failing.
...
}
res.previousNodeAlive(ok);
{code}
> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
>
> We should fix 3 drawbacks in the backward checking of failed node:
> 1) It has hardcoded timeout 100ms:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
> sock.connect(addr, 100);
>...
> }
> {code}
> 2) Maximal interval to check previous node should be reconsidered, bound to
> configurable params:
> {code:java}
>TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
>...
>// We got message from previous in less than double connection check
> interval.
>boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 *
> CON_CHECK_INTERVAL', not a failureDetectionTimeout.
>if (ok) {
> // Check case when previous node suddenly died. This will speed up
> // node failing.
> ...
> }
> res.previousNodeAlive(ok);
> {code}
> 3) Any negative result of the connection checking should be considered as
> node failed. Currently, we look only at refused connection. Any other
> exceptions, including a timeout, are treated as living connection:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
>catch (ConnectException e) {
> return true;
>}
>catch (IOException e) {
> return false;//Why a timeout doesn't mean lost connection?
>}
>return false;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13016) Fix backward checking of failed node.
[
https://issues.apache.org/jira/browse/IGNITE-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13016:
--
Description:
We should fix 3 drawbacks in the backward checking of failed node:
1) It has hardcoded timeout 100ms:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
...
sock.connect(addr, 100);
...
}
{code}
2) Maximal interval to check previous node should be reconsidered. It should
rely on configurable param:
{code:java}
TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
...
// We got message from previous in less than double connection check
interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 *
CON_CHECK_INTERVAL', not a failureDetectionTimeout.
if (ok) {
// Check case when previous node suddenly died. This will speed up
// node failing.
...
}
res.previousNodeAlive(ok);
{code}
3) Any negative result of the connection checking should be considered as node
failed. Currently, we look only at refused connection. Any other exceptions,
including a timeout, are treated as living connection:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
...
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false;//Why a timeout doesn't mean lost connection?
}
return false;
}
{code}
was:
We should fix 3 drawbacks in the backward checking of failed node:
1) It has hardcoded timeout 100ms:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
...
sock.connect(addr, 100);
...
}
{code}
2) Maximal interval to check previous node should be reconsidered, bound to
configurable params:
{code:java}
TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
...
// We got message from previous in less than double connection check
interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 *
CON_CHECK_INTERVAL', not a failureDetectionTimeout.
if (ok) {
// Check case when previous node suddenly died. This will speed up
// node failing.
...
}
res.previousNodeAlive(ok);
{code}
3) Any negative result of the connection checking should be considered as node
failed. Currently, we look only at refused connection. Any other exceptions,
including a timeout, are treated as living connection:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
...
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false;//Why a timeout doesn't mean lost connection?
}
return false;
}
{code}
> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
>
> We should fix 3 drawbacks in the backward checking of failed node:
> 1) It has hardcoded timeout 100ms:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
> sock.connect(addr, 100);
>...
> }
> {code}
> 2) Maximal interval to check previous node should be reconsidered. It should
> rely on configurable param:
> {code:java}
>TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
>...
>// We got message from previous in less than double connection check
> interval.
>boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 *
> CON_CHECK_INTERVAL', not a failureDetectionTimeout.
>if (ok) {
> // Check case when previous node suddenly died. This will speed up
> // node failing.
> ...
> }
> res.previousNodeAlive(ok);
> {code}
> 3) Any negative result of the connection checking should be considered as
> node failed. Currently, we look only at refused connection. Any other
> exceptions, including a timeout, are treated as living connection:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
>catch (ConnectException e) {
> return true;
>}
>catch (IOException e) {
> return false;//Why a timeout doesn't mean lost connection?
>}
>return false;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13017) Remove hardcoded delay from re-marking failed node as alive.
[
https://issues.apache.org/jira/browse/IGNITE-13017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13017:
--
Labels: iep-45 (was: )
> Remove hardcoded delay from re-marking failed node as alive.
>
>
> Key: IGNITE-13017
> URL: https://issues.apache.org/jira/browse/IGNITE-13017
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
>
> We should remove hardcoded timeout from:
> {code:java}
> boolean
> ServerImpl.CrossRingMessageSendState.markLastFailedNodeAlive() {
> if (state == RingMessageSendState.FORWARD_PASS || state ==
> RingMessageSendState.BACKWARD_PASS) {
>...
> if (--failedNodes <= 0) {
> ...
> state = RingMessageSendState.STARTING_POINT;
> try {
> Thread.sleep(200);
> }
> catch (InterruptedException e) {
> Thread.currentThread().interrupt();
> }
> }
> return true;
> }
> return false;
> }
> {code}
> This can bring additional 200ms to duration of failed node detection.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13017) Remove hardcoded delay from re-marking failed node as alive.
[
https://issues.apache.org/jira/browse/IGNITE-13017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13017:
--
Summary: Remove hardcoded delay from re-marking failed node as alive.
(was: Remove delay of 200ms from re-marking failed node as alive.)
> Remove hardcoded delay from re-marking failed node as alive.
>
>
> Key: IGNITE-13017
> URL: https://issues.apache.org/jira/browse/IGNITE-13017
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>
> We should remove hardcoded timeout from:
> {code:java}
> boolean
> ServerImpl.CrossRingMessageSendState.markLastFailedNodeAlive() {
> if (state == RingMessageSendState.FORWARD_PASS || state ==
> RingMessageSendState.BACKWARD_PASS) {
>...
> if (--failedNodes <= 0) {
> ...
> state = RingMessageSendState.STARTING_POINT;
> try {
> Thread.sleep(200);
> }
> catch (InterruptedException e) {
> Thread.currentThread().interrupt();
> }
> }
> return true;
> }
> return false;
> }
> {code}
> This can bring additional 200ms to duration of failed node detection.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13017) Remove delay of 200ms from re-marking failed node as alive.
Vladimir Steshin created IGNITE-13017:
-
Summary: Remove delay of 200ms from re-marking failed node as
alive.
Key: IGNITE-13017
URL: https://issues.apache.org/jira/browse/IGNITE-13017
Project: Ignite
Issue Type: Sub-task
Reporter: Vladimir Steshin
Assignee: Vladimir Steshin
We should remove hardcoded timeout from:
{code:java}
boolean ServerImpl.CrossRingMessageSendState.markLastFailedNodeAlive() {
if (state == RingMessageSendState.FORWARD_PASS || state ==
RingMessageSendState.BACKWARD_PASS) {
...
if (--failedNodes <= 0) {
...
state = RingMessageSendState.STARTING_POINT;
try {
Thread.sleep(200);
}
catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
}
return true;
}
return false;
}
{code}
This can bring additional 200ms to duration of failed node detection.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13016) Remove hardcoded values/timeouts from backward checking of failed node.
[
https://issues.apache.org/jira/browse/IGNITE-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13016:
--
Labels: iep-45 (was: )
> Remove hardcoded values/timeouts from backward checking of failed node.
> ---
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
>
> Backward checking of failed node rely on hardcoced timeout 100ms:
> {code:java}
> private boolean ServerImpls.isConnectionRefused(SocketAddress addr) {
> try (Socket sock = new Socket()) {
> sock.connect(addr, 100);
> }
> catch (ConnectException e) {
> return true;
> }
> catch (IOException e) {
> return false;
> }
> return false;
> }
> {code}
> We should make it bound to configurable params like
> IgniteConfiguration.failureDetectionTimeout
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13016) Remove hardcoded values/timeouts from backward checking of failed node.
Vladimir Steshin created IGNITE-13016:
-
Summary: Remove hardcoded values/timeouts from backward checking
of failed node.
Key: IGNITE-13016
URL: https://issues.apache.org/jira/browse/IGNITE-13016
Project: Ignite
Issue Type: Sub-task
Reporter: Vladimir Steshin
Assignee: Vladimir Steshin
Backward checking of failed node rely on hardcoced timeout 100ms:
{code:java}
private boolean ServerImpls.isConnectionRefused(SocketAddress addr) {
try (Socket sock = new Socket()) {
sock.connect(addr, 100);
}
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false;
}
return false;
}
{code}
We should make it bound to configurable params like
IgniteConfiguration.failureDetectionTimeout
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13016) Fix backward checking of failed node.
[
https://issues.apache.org/jira/browse/IGNITE-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13016:
--
Description:
We should fix 3 drawbacks in the backward checking of failed node:
1) It has hardcoded timeout 100ms:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
...
sock.connect(addr, 100);
...
}
{code}
2) Maximal interval to check previous node should be reconsidered. It should
rely on configurable param:
{code:java}
TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
...
// We got message from previous in less than double connection check
interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 *
CON_CHECK_INTERVAL', not a failureDetectionTimeout.
if (ok) {
// Check case when previous node suddenly died. This will speed up
// node failing.
...
}
res.previousNodeAlive(ok);
{code}
3) Any negative result of the connection checking should be considered as node
failed. Currently, we look only at refused connection. Any other exceptions,
including a timeout, are treated as living connection:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
...
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false;//Why a timeout doesn't mean lost connection?
}
return false;
}
{code}
was:
We should fix 3 drawbacks in the backward checking of failed node:
1) It has hardcoded timeout 100ms:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
...
sock.connect(addr, 100);
...
}
{code}
2) Maximal interval to check previous node should be reconsidered. It should
rely on configurable param:
{code:java}
TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
...
// We got message from previous in less than double connection check
interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 *
CON_CHECK_INTERVAL', not a failureDetectionTimeout.
if (ok) {
// Check case when previous node suddenly died. This will speed up
// node failing.
...
}
res.previousNodeAlive(ok);
{code}
3) Any negative result of the connection checking should be considered as node
failed. Currently, we look only at refused connection. Any other exceptions,
including a timeout, are treated as living connection:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
...
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false;//Why a timeout doesn't mean lost connection?
}
return false;
}
{code}
> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
>
> We should fix 3 drawbacks in the backward checking of failed node:
> 1) It has hardcoded timeout 100ms:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
> sock.connect(addr, 100);
>...
> }
> {code}
> 2) Maximal interval to check previous node should be reconsidered. It should
> rely on configurable param:
> {code:java}
>TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
>...
>// We got message from previous in less than double connection check
> interval.
>boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 *
> CON_CHECK_INTERVAL', not a failureDetectionTimeout.
>if (ok) {
> // Check case when previous node suddenly died. This will speed up
> // node failing.
> ...
> }
> res.previousNodeAlive(ok);
> {code}
> 3) Any negative result of the connection checking should be considered as
> node failed. Currently, we look only at refused connection. Any other
> exceptions, including a timeout, are treated as living connection:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
>catch (ConnectException e) {
> return true;
>}
>catch (IOException e) {
> return false;//Why a timeout doesn't mean lost connection?
>}
>return false;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13016) Fix backward checking of failed node.
[
https://issues.apache.org/jira/browse/IGNITE-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13016:
--
Description:
We should fix 3 drawbacks in the backward checking of failed node:
1) We should replace hardcoded timeout 100ms with a parameter like
failureDetectionTimeout:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
...
sock.connect(addr, 100);
...
}
{code}
2) Maximal interval to check previous node should be reconsidered. It should
rely on configurable param:
{code:java}
TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
...
// We got message from previous in less than double connection check
interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 *
CON_CHECK_INTERVAL', not a failureDetectionTimeout.
if (ok) {
// Check case when previous node suddenly died. This will speed up
// node failing.
...
}
res.previousNodeAlive(ok);
{code}
3) Any negative result of the connection checking should be considered as node
failed. Currently, we look only at refused connection. Any other exceptions,
including a timeout, are treated as living connection:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
...
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false;//Why a timeout doesn't mean lost connection?
}
return false;
}
{code}
was:
We should fix 3 drawbacks in the backward checking of failed node:
1) It has hardcoded timeout 100ms:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
...
sock.connect(addr, 100);
...
}
{code}
2) Maximal interval to check previous node should be reconsidered. It should
rely on configurable param:
{code:java}
TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
...
// We got message from previous in less than double connection check
interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 *
CON_CHECK_INTERVAL', not a failureDetectionTimeout.
if (ok) {
// Check case when previous node suddenly died. This will speed up
// node failing.
...
}
res.previousNodeAlive(ok);
{code}
3) Any negative result of the connection checking should be considered as node
failed. Currently, we look only at refused connection. Any other exceptions,
including a timeout, are treated as living connection:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
...
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false;//Why a timeout doesn't mean lost connection?
}
return false;
}
{code}
> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
>
> We should fix 3 drawbacks in the backward checking of failed node:
> 1) We should replace hardcoded timeout 100ms with a parameter like
> failureDetectionTimeout:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
> sock.connect(addr, 100);
>...
> }
> {code}
> 2) Maximal interval to check previous node should be reconsidered. It should
> rely on configurable param:
> {code:java}
>TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
>...
>// We got message from previous in less than double connection check
> interval.
>boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 *
> CON_CHECK_INTERVAL', not a failureDetectionTimeout.
>if (ok) {
> // Check case when previous node suddenly died. This will speed up
> // node failing.
> ...
> }
> res.previousNodeAlive(ok);
> {code}
> 3) Any negative result of the connection checking should be considered as
> node failed. Currently, we look only at refused connection. Any other
> exceptions, including a timeout, are treated as living connection:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
>catch (ConnectException e) {
> return true;
>}
>catch (IOException e) {
> return false;//Why a timeout doesn't mean lost connection?
>}
>return false;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13018) Get rid of duplicated checking of failed node.
Vladimir Steshin created IGNITE-13018: - Summary: Get rid of duplicated checking of failed node. Key: IGNITE-13018 URL: https://issues.apache.org/jira/browse/IGNITE-13018 Project: Ignite Issue Type: Sub-task Reporter: Vladimir Steshin Assignee: Vladimir Steshin Failed node checking should be simplified to one step: ping node (send a message) from previous one in the ring and wait for response within IgniteConfiguration.failureDetectionTimeout. If node doesn't respond, we should consider it failed. Extra steps of connection checking may seriously delay failure detection, bring confusion and weird behavior. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13018) Get rid of duplicated checking of failed node.
[ https://issues.apache.org/jira/browse/IGNITE-13018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13018: -- Labels: iep-45 (was: ) > Get rid of duplicated checking of failed node. > -- > > Key: IGNITE-13018 > URL: https://issues.apache.org/jira/browse/IGNITE-13018 > Project: Ignite > Issue Type: Sub-task >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: iep-45 > > Failed node checking should be simplified to one step: ping node (send a > message) from previous one in the ring and wait for response within > IgniteConfiguration.failureDetectionTimeout. If node doesn't respond, we > should consider it failed. Extra steps of connection checking may seriously > delay failure detection, bring confusion and weird behavior. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13016) Remove hardcoded values/timeouts from backward checking of failed node.
[
https://issues.apache.org/jira/browse/IGNITE-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13016:
--
Description:
Backward checking of failed node rely on hardcoced timeout 100ms:
{code:java}
private boolean ServerImpls.isConnectionRefused(SocketAddress addr) {
try (Socket sock = new Socket()) {
sock.connect(addr, 100);
}
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false;
}
return false;
}
{code}
We should make it bound to configurable params like
IgniteConfiguration.failureDetectionTimeout.
Also, the maximal interval to chech previous node is
was:
Backward checking of failed node rely on hardcoced timeout 100ms:
{code:java}
private boolean ServerImpls.isConnectionRefused(SocketAddress addr) {
try (Socket sock = new Socket()) {
sock.connect(addr, 100);
}
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false;
}
return false;
}
{code}
We should make it bound to configurable params like
IgniteConfiguration.failureDetectionTimeout
> Remove hardcoded values/timeouts from backward checking of failed node.
> ---
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
>
> Backward checking of failed node rely on hardcoced timeout 100ms:
> {code:java}
> private boolean ServerImpls.isConnectionRefused(SocketAddress addr) {
> try (Socket sock = new Socket()) {
> sock.connect(addr, 100);
> }
> catch (ConnectException e) {
> return true;
> }
> catch (IOException e) {
> return false;
> }
> return false;
> }
> {code}
> We should make it bound to configurable params like
> IgniteConfiguration.failureDetectionTimeout.
> Also, the maximal interval to chech previous node is
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13016) Fix backward checking of failed node.
[
https://issues.apache.org/jira/browse/IGNITE-13016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13016:
--
Description:
We should fix 3 drawbacks in the backward checking of failed node:
1) We should replace hardcoded timeout 100ms with a parameter like
failureDetectionTimeout:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
...
sock.connect(addr, 100);
...
}
{code}
2) Maximal interval to check previous node should be reconsidered. It should
rely on configurable param like failureDetectionTimeout:
{code:java}
TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
...
// We got message from previous in less than double connection check
interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 *
CON_CHECK_INTERVAL', not a failureDetectionTimeout?
if (ok) {
// Check case when previous node suddenly died. This will speed up
// node failing.
...
}
res.previousNodeAlive(ok);
{code}
3) Any negative result of the connection checking should be considered as node
failed. Currently, we look only at refused connection. Any other exceptions,
including a timeout, are treated as living connection:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
...
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false;//Why a timeout doesn't mean lost connection?
}
return false;
}
{code}
was:
We should fix 3 drawbacks in the backward checking of failed node:
1) We should replace hardcoded timeout 100ms with a parameter like
failureDetectionTimeout:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
...
sock.connect(addr, 100);
...
}
{code}
2) Maximal interval to check previous node should be reconsidered. It should
rely on configurable param:
{code:java}
TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
...
// We got message from previous in less than double connection check
interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 *
CON_CHECK_INTERVAL', not a failureDetectionTimeout.
if (ok) {
// Check case when previous node suddenly died. This will speed up
// node failing.
...
}
res.previousNodeAlive(ok);
{code}
3) Any negative result of the connection checking should be considered as node
failed. Currently, we look only at refused connection. Any other exceptions,
including a timeout, are treated as living connection:
{code:java}
private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
...
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false;//Why a timeout doesn't mean lost connection?
}
return false;
}
{code}
> Fix backward checking of failed node.
> -
>
> Key: IGNITE-13016
> URL: https://issues.apache.org/jira/browse/IGNITE-13016
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
>
> We should fix 3 drawbacks in the backward checking of failed node:
> 1) We should replace hardcoded timeout 100ms with a parameter like
> failureDetectionTimeout:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
> sock.connect(addr, 100);
>...
> }
> {code}
> 2) Maximal interval to check previous node should be reconsidered. It should
> rely on configurable param like failureDetectionTimeout:
> {code:java}
>TcpDiscoveryHandshakeResponse res = new TcpDiscoveryHandshakeResponse(...);
>...
>// We got message from previous in less than double connection check
> interval.
>boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; //Why '2 *
> CON_CHECK_INTERVAL', not a failureDetectionTimeout?
>if (ok) {
> // Check case when previous node suddenly died. This will speed up
> // node failing.
> ...
> }
> res.previousNodeAlive(ok);
> {code}
> 3) Any negative result of the connection checking should be considered as
> node failed. Currently, we look only at refused connection. Any other
> exceptions, including a timeout, are treated as living connection:
> {code:java}
> private boolean ServerImpl.isConnectionRefused(SocketAddress addr) {
>...
>catch (ConnectException e) {
> return true;
>}
>catch (IOException e) {
> return false;//Why a timeout doesn't mean lost connection?
>}
>return false;
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13012) Make node connection checking rely on the configuration. Simplify node ping routine.
[ https://issues.apache.org/jira/browse/IGNITE-13012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13012: -- Labels: iep-45 (was: ) > Make node connection checking rely on the configuration. Simplify node ping > routine. > > > Key: IGNITE-13012 > URL: https://issues.apache.org/jira/browse/IGNITE-13012 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: iep-45 > > Current noted-to-node connection checking has several drawbacks: > 1)Minimal connection checking interval is not bound to failure detection > parameters: > static int ServerImpls.CON_CHECK_INTERVAL = 500; > 2)Connection checking is made as ability of periodical message sending > (TcpDiscoveryConnectionCheckMessage). It is bound to own time (ServerImpl. > RingMessageWorker.lastTimeConnCheckMsgSent), not to common time of last sent > message. This is weird because any discovery message actually checks > connection. And TpDiscoveryConnectionCheckMessage is just an addition when > message queue is empty for a long time. > 3)Period of Node-to-Node connection checking can be sometimes shortened > for strange reason: if no sent or received message appears within > failureDetectionTimeout. Here, despite we have minimal period of connection > checking (ServerImpls.CON_CHECK_INTERVAL), we can also send > TpDiscoveryConnectionCheckMessage before this period exhausted. Moreover, > this premature node ping relies also on time of last received message. > Imagine: if node 2 receives no message from node 1 within some time it > decides to do extra ping node 3 not waiting for regular ping interval. Such > behavior makes confusion and gives no additional guaranties. > 4)If #3 happens, node writes in the log on INFO: “Local node seems to be > disconnected from topology …” whereas it is not actually disconnected. User > can see this message if he typed failureDetectionTimeout < 500ms. I wouldn’t > like seeing INFO in a log saying a node is might be disconnected. This sounds > like some troubles raised in network. But not as everything is OK. > Suggestions: > 1)Make connection check interval be based on failureDetectionTimeout or > similar params. > 2)Make connection check interval rely on common time of last sent > message. Not on dedicated time. > 3)Remove additional, random, quickened connection checking. > 4)Do not worry user with “Node disconnected” when everything is OK. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13012) Make node connection checking rely on the configuration. Simplify node ping routine.
Vladimir Steshin created IGNITE-13012: - Summary: Make node connection checking rely on the configuration. Simplify node ping routine. Key: IGNITE-13012 URL: https://issues.apache.org/jira/browse/IGNITE-13012 Project: Ignite Issue Type: Improvement Reporter: Vladimir Steshin Assignee: Vladimir Steshin Current noted-to-node connection checking has several drawbacks: 1) Minimal connection checking interval is not bound to failure detection parameters: static int ServerImpls.CON_CHECK_INTERVAL = 500; 2) Connection checking is made as ability of periodical message sending (TcpDiscoveryConnectionCheckMessage). It is bound to own time (ServerImpl. RingMessageWorker.lastTimeConnCheckMsgSent), not to common time of last sent message. This is weird because any discovery message actually checks connection. And TpDiscoveryConnectionCheckMessage is just an addition when message queue is empty for a long time. 3) Period of Node-to-Node connection checking can be sometimes shortened for strange reason: if no sent or received message appears within failureDetectionTimeout. Here, despite we have minimal period of connection checking (ServerImpls.CON_CHECK_INTERVAL), we can also send TpDiscoveryConnectionCheckMessage before this period exhausted. Moreover, this premature node ping relies also on time of last received message. Imagine: if node 2 receives no message from node 1 within some time it decides to do extra ping node 3 not waiting for regular ping interval. Such behavior makes confusion and gives no additional guaranties. 4) If #3 happens, node writes in the log on INFO: “Local node seems to be disconnected from topology …” whereas it is not actually disconnected. User can see this message if he typed failureDetectionTimeout < 500ms. I wouldn’t like seeing INFO in a log saying a node is might be disconnected. This sounds like some troubles raised in network. But not as everything is OK. Suggestions: 1) Make connection check interval be based on failureDetectionTimeout or similar params. 2) Make connection check interval rely on common time of last sent message. Not on dedicated time. 3) Remove additional, random, quickened connection checking. 4) Do not worry user with “Node disconnected” when everything is OK. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13012) Make node connection checking rely on the configuration. Simplify node ping routine.
[ https://issues.apache.org/jira/browse/IGNITE-13012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13012: -- Description: Current noted-to-node connection checking has several drawbacks: 1) Minimal connection checking interval is not bound to failure detection parameters: static int ServerImpls.CON_CHECK_INTERVAL = 500; 2) Connection checking is made as ability of periodical message sending (TcpDiscoveryConnectionCheckMessage). It is bound to own time (ServerImpl. RingMessageWorker.lastTimeConnCheckMsgSent), not to common time of last sent message. This is weird because any discovery message actually checks connection. And TpDiscoveryConnectionCheckMessage is just an addition when message queue is empty for a long time. 3) Period of Node-to-Node connection checking can be sometimes shortened for strange reason: if no sent or received message appears within failureDetectionTimeout. Here, despite we have minimal period of connection checking (ServerImpls.CON_CHECK_INTERVAL), we can also send TpDiscoveryConnectionCheckMessage before this period exhausted. Moreover, this premature node ping relies also on time of last received message. Imagine: if node 2 receives no message from node 1 within some time it decides to do extra ping node 3 not waiting for regular ping interval. Such behavior makes confusion and gives no additional guaranties. 4) If #3 happens, node writes in the log on INFO: “Local node seems to be disconnected from topology …” whereas it is not actually disconnected. User can see this message if he typed failureDetectionTimeout < 500ms. I wouldn’t like seeing INFO in a log saying a node is might be disconnected. This sounds like some troubles raised in network. But not as everything is OK. Suggestions: 1) Make connection check interval be based on failureDetectionTimeout or similar params. 2) Make connection check interval rely on common time of last sent message. Not on dedicated time. 3) Remove additional, random, quickened connection checking. 4) Do not worry user with “Node disconnected” when everything is OK. was: Current noted-to-node connection checking has several drawbacks: 1) Minimal connection checking interval is not bound to failure detection parameters: static int ServerImpls.CON_CHECK_INTERVAL = 500; 2) Connection checking is made as ability of periodical message sending (TcpDiscoveryConnectionCheckMessage). It is bound to own time (ServerImpl. RingMessageWorker.lastTimeConnCheckMsgSent), not to common time of last sent message. This is weird because any discovery message actually checks connection. And TpDiscoveryConnectionCheckMessage is just an addition when message queue is empty for a long time. 3) Period of Node-to-Node connection checking can be sometimes shortened for strange reason: if no sent or received message appears within failureDetectionTimeout. Here, despite we have minimal period of connection checking (ServerImpls.CON_CHECK_INTERVAL), we can also send TpDiscoveryConnectionCheckMessage before this period exhausted. Moreover, this premature node ping relies also on time of last received message. Imagine: if node 2 receives no message from node 1 within some time it decides to do extra ping node 3 not waiting for regular ping interval. Such behavior makes confusion and gives no additional guaranties. 4) If #3 happens, node writes in the log on INFO: “Local node seems to be disconnected from topology …” whereas it is not actually disconnected. User can see this message if he typed failureDetectionTimeout < 500ms. I wouldn’t like seeing INFO in a log saying a node is might be disconnected. This sounds like some troubles raised in network. But not as everything is OK. Suggestions: 1) Make connection check interval be based on failureDetectionTimeout or similar params. 2) Make connection check interval rely on common time of last sent message. Not on dedicated time. 3) Remove additional, random, quickened connection checking. 4) Do not worry user with “Node disconnected” when everything is OK. > Make node connection checking rely on the configuration. Simplify node ping > routine. > > > Key: IGNITE-13012 > URL: https://issues.apache.org/jira/browse/IGNITE-13012 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: iep-45 > > Current noted-to-node connection checking has several drawbacks: > 1)Minimal connection checking interval is not bound to failure detection > parameters: > static int ServerImpls.CON_CHECK_INTERVAL = 500; > 2)Connection checking is made as
[jira] [Updated] (IGNITE-13012) Make node connection checking rely on the configuration. Simplify node ping routine.
[ https://issues.apache.org/jira/browse/IGNITE-13012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13012: -- Description: Current noted-to-node connection checking has several drawbacks: 1) Minimal connection checking interval is not bound to failure detection parameters: static int ServerImpls.CON_CHECK_INTERVAL = 500; 2) Connection checking is made as ability of periodical message sending (TcpDiscoveryConnectionCheckMessage). It is bound to own time (ServerImpl. RingMessageWorker.lastTimeConnCheckMsgSent), not to common time of last sent message. This is weird because any discovery message actually checks connection. And TpDiscoveryConnectionCheckMessage is just an addition when message queue is empty for a long time. 3) Period of Node-to-Node connection checking can be sometimes shortened for strange reason: if no sent or received message appears within failureDetectionTimeout. Here, despite we have minimal period of connection checking (ServerImpls.CON_CHECK_INTERVAL), we can also send TpDiscoveryConnectionCheckMessage before this period exhausted. Moreover, this premature node ping relies also on time of last received message. Imagine: if node 2 receives no message from node 1 within some time it decides to do extra ping node 3 not waiting for regular ping interval. Such behavior makes confusion and gives no additional guaranties. 4) If #3 happens, node writes in the log on INFO: “Local node seems to be disconnected from topology …” whereas it is not actually disconnected. User can see this message if he typed failureDetectionTimeout < 500ms. I wouldn’t like seeing INFO in a log saying a node is might be disconnected. This sounds like some troubles raised in network. But not as everything is OK. Suggestions: 1) Make connection check interval be based on failureDetectionTimeout or similar params. 2) Make connection check interval rely on common time of last sent message. Not on dedicated time. 3) Remove additional, random, quickened connection checking. 4) Do not worry user with “Node disconnected” when everything is OK. was: Current noted-to-node connection checking has several drawbacks: 1) Minimal connection checking interval is not bound to failure detection parameters: static int ServerImpls.CON_CHECK_INTERVAL = 500; 2) Connection checking is made as ability of periodical message sending (TcpDiscoveryConnectionCheckMessage). It is bound to own time (ServerImpl. RingMessageWorker.lastTimeConnCheckMsgSent), not to common time of last sent message. This is weird because any discovery message actually checks connection. And TpDiscoveryConnectionCheckMessage is just an addition when message queue is empty for a long time. 3) Period of Node-to-Node connection checking can be sometimes shortened for strange reason: if no sent or received message appears within failureDetectionTimeout. Here, despite we have minimal period of connection checking (ServerImpls.CON_CHECK_INTERVAL), we can also send TpDiscoveryConnectionCheckMessage before this period exhausted. Moreover, this premature node ping relies also on time of last received message. Imagine: if node 2 receives no message from node 1 within some time it decides to do extra ping node 3 not waiting for regular ping interval. Such behavior makes confusion and gives no additional guaranties. See `ServerImpl.connectionChecking()` 4) If #3 happens, node writes in the log on INFO: “Local node seems to be disconnected from topology …” whereas it is not actually disconnected. User can see this message if he typed failureDetectionTimeout < 500ms. I wouldn’t like seeing INFO in a log saying a node is might be disconnected. This sounds like some troubles raised in network. But not as everything is OK. Suggestions: 1) Make connection check interval be based on failureDetectionTimeout or similar params. 2) Make connection check interval rely on common time of last sent message. Not on dedicated time. 3) Remove additional, random, quickened connection checking. 4) Do not worry user with “Node disconnected” when everything is OK. > Make node connection checking rely on the configuration. Simplify node ping > routine. > > > Key: IGNITE-13012 > URL: https://issues.apache.org/jira/browse/IGNITE-13012 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: iep-45 > > Current noted-to-node connection checking has several drawbacks: > 1)Minimal connection checking interval is not bound to failure detection > parameters: > static int ServerImpls.CON_CHECK_INTERVAL = 500; > 2)
[jira] [Updated] (IGNITE-13012) Make node connection checking rely on the configuration. Simplify node ping routine.
[ https://issues.apache.org/jira/browse/IGNITE-13012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13012: -- Description: Current noted-to-node connection checking has several drawbacks: 1) Minimal connection checking interval is not bound to failure detection parameters: static int ServerImpls.CON_CHECK_INTERVAL = 500; 2) Connection checking is made as ability of periodical message sending (TcpDiscoveryConnectionCheckMessage). It is bound to own time (ServerImpl. RingMessageWorker.lastTimeConnCheckMsgSent), not to common time of last sent message. This is weird because any discovery message actually checks connection. And TpDiscoveryConnectionCheckMessage is just an addition when message queue is empty for a long time. 3) Period of Node-to-Node connection checking can be sometimes shortened for strange reason: if no sent or received message appears within failureDetectionTimeout. Here, despite we have minimal period of connection checking (ServerImpls.CON_CHECK_INTERVAL), we can also send TpDiscoveryConnectionCheckMessage before this period exhausted. Moreover, this premature node ping relies also on time of last received message. Imagine: if node 2 receives no message from node 1 within some time it decides to do extra ping node 3 not waiting for regular ping interval. Such behavior makes confusion and gives no additional guaranties. See `ServerImpl.connectionChecking()` 4) If #3 happens, node writes in the log on INFO: “Local node seems to be disconnected from topology …” whereas it is not actually disconnected. User can see this message if he typed failureDetectionTimeout < 500ms. I wouldn’t like seeing INFO in a log saying a node is might be disconnected. This sounds like some troubles raised in network. But not as everything is OK. Suggestions: 1) Make connection check interval be based on failureDetectionTimeout or similar params. 2) Make connection check interval rely on common time of last sent message. Not on dedicated time. 3) Remove additional, random, quickened connection checking. 4) Do not worry user with “Node disconnected” when everything is OK. was: Current noted-to-node connection checking has several drawbacks: 1) Minimal connection checking interval is not bound to failure detection parameters: static int ServerImpls.CON_CHECK_INTERVAL = 500; 2) Connection checking is made as ability of periodical message sending (TcpDiscoveryConnectionCheckMessage). It is bound to own time (ServerImpl. RingMessageWorker.lastTimeConnCheckMsgSent), not to common time of last sent message. This is weird because any discovery message actually checks connection. And TpDiscoveryConnectionCheckMessage is just an addition when message queue is empty for a long time. 3) Period of Node-to-Node connection checking can be sometimes shortened for strange reason: if no sent or received message appears within failureDetectionTimeout. Here, despite we have minimal period of connection checking (ServerImpls.CON_CHECK_INTERVAL), we can also send TpDiscoveryConnectionCheckMessage before this period exhausted. Moreover, this premature node ping relies also on time of last received message. Imagine: if node 2 receives no message from node 1 within some time it decides to do extra ping node 3 not waiting for regular ping interval. Such behavior makes confusion and gives no additional guaranties. 4) If #3 happens, node writes in the log on INFO: “Local node seems to be disconnected from topology …” whereas it is not actually disconnected. User can see this message if he typed failureDetectionTimeout < 500ms. I wouldn’t like seeing INFO in a log saying a node is might be disconnected. This sounds like some troubles raised in network. But not as everything is OK. Suggestions: 1) Make connection check interval be based on failureDetectionTimeout or similar params. 2) Make connection check interval rely on common time of last sent message. Not on dedicated time. 3) Remove additional, random, quickened connection checking. 4) Do not worry user with “Node disconnected” when everything is OK. > Make node connection checking rely on the configuration. Simplify node ping > routine. > > > Key: IGNITE-13012 > URL: https://issues.apache.org/jira/browse/IGNITE-13012 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: iep-45 > > Current noted-to-node connection checking has several drawbacks: > 1)Minimal connection checking interval is not bound to failure detection > parameters: > static int ServerImpls.CON_CHECK_INTERVAL = 500; > 2)
[jira] [Updated] (IGNITE-13014) Remove double checking of node availability. Fix hardcoded values.
[ https://issues.apache.org/jira/browse/IGNITE-13014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13014: -- Description: For the present, we have duplicated checking of node availability. This prolongs node failure detection and gives no additional benefits. There are mesh and hardcoded values in this routine. Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping node 2 and asks Node 3 to establish permanent connection instead of node 2. Despite node 2 has been already pinged within configured timeouts, node 3 try to connect to node 2 too. Disadvantages: 1) Possible long detection of node failure up to ServerImpl.CON_CHECK_INTERVAL + 2 * IgniteConfiguretion.failureDetectionTimeout + 300ms. See ‘WostCase.txt’ 2) Unexpected, not-configurable decision to check availability of previous node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘: // We got message from previous in less than double connection check interval. boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; If ‘ok == true’ node 3 checks node 2. 3) Double node checking brings several not-configurable hardcoded delays: Node 3 checks node 2 with hardcoded timeout 100ms: ServerImpl.isConnectionRefused(): sock.connect(addr, 100); Checking availability of previous node considers any exception but ConnectionException (connection refused) as existing connection. Even a timeout. See ServerImpl.isConnectionRefused(). was: For the present, we have duplicated checking of node availability. This prolongs node failure detection and gives no additional benefits. There are mesh and hardcoded values in this routine. Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping node 2 and asks Node 3 to establish permanent connection instead of node 2. Despite node 2 has been already pinged within configured timeouts, node 3 try to connect to node 2 too. Disadvantages: 1) Possible long detection of node failure up to ServerImpl.CON_CHECK_INTERVAL + 2 * IgniteConfiguretion.failureDetectionTimeout + 300ms. See ‘WostCase.txt’ 2) Unexpected, not-configurable decision to check availability of previous node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘: // We got message from previous in less than double connection check interval. boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; If ‘ok == true’ node 3 checks node 2. 3) Double node checking brings several not-configurable hardcoded delays: Node 3 checks node 2 with hardcoded timeout 100ms: ServerImpl.isConnectionRefused(): sock.connect(addr, 100); Checking availability of previous node considers any exception but ConnectionException (connection refused) as existing connection. Even a timeout. See ServerImpl.isConnectionRefused(). > Remove double checking of node availability. Fix hardcoded values. > -- > > Key: IGNITE-13014 > URL: https://issues.apache.org/jira/browse/IGNITE-13014 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > > For the present, we have duplicated checking of node availability. This > prolongs node failure detection and gives no additional benefits. There are > mesh and hardcoded values in this routine. > Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping > node 2 and asks Node 3 to establish permanent connection instead of node 2. > Despite node 2 has been already pinged within configured timeouts, node 3 try > to connect to node 2 too. > Disadvantages: > 1)Possible long detection of node failure up to > ServerImpl.CON_CHECK_INTERVAL + 2 * > IgniteConfiguretion.failureDetectionTimeout + 300ms. See ‘WostCase.txt’ > 2)Unexpected, not-configurable decision to check availability of previous > node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘: > // We got message from previous in less than double connection check interval. > boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; > If ‘ok == true’ node 3 checks node 2. > 3)Double node checking brings several not-configurable hardcoded delays: > Node 3 checks node 2 with hardcoded timeout 100ms: > ServerImpl.isConnectionRefused(): > sock.connect(addr, 100); > Checking availability of previous node considers any exception but > ConnectionException (connection refused) as existing connection. Even a > timeout. See ServerImpl.isConnectionRefused(). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13014) Remove long, double checking of node availability. Fix hardcoded values.
Vladimir Steshin created IGNITE-13014: - Summary: Remove long, double checking of node availability. Fix hardcoded values. Key: IGNITE-13014 URL: https://issues.apache.org/jira/browse/IGNITE-13014 Project: Ignite Issue Type: Improvement Reporter: Vladimir Steshin Assignee: Vladimir Steshin For the present, we have duplicated checking of node availability. This prolongs node failure detection and gives no additional benefits. There are mesh and hardcoded values in this routine. Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping node 2 and asks Node 3 to establish permanent connection instead of node 2. Despite node 2 has been already pinged within configured timeouts, node 3 try to connect to node 2 too. Disadvantages: 1) Possible long detection of node failure up to ServerImpl.CON_CHECK_INTERVAL + 2 * IgniteConfiguretion.failureDetectionTimeout + 300ms. See ‘WostCase.txt’ 2) Unexpected, not-configurable decision to check availability of previous node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘: // We got message from previous in less than double connection check interval. boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; If ‘ok == true’ node 3 checks node 2. 3) Double node checking brings several not-configurable hardcoded delays: Node 3 checks node 2 with hardcoded timeout 100ms: ServerImpl.isConnectionRefused(): sock.connect(addr, 100); Checking availability of previous node considers any exception but ConnectionException (connection refused) as existing connection. Even a timeout. See ServerImpl.isConnectionRefused(). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13014) Remove double checking of node availability. Fix hardcoded values.
[ https://issues.apache.org/jira/browse/IGNITE-13014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13014: -- Attachment: WostCase.txt > Remove double checking of node availability. Fix hardcoded values. > -- > > Key: IGNITE-13014 > URL: https://issues.apache.org/jira/browse/IGNITE-13014 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Attachments: WostCase.txt > > > For the present, we have duplicated checking of node availability. This > prolongs node failure detection and gives no additional benefits. There are > mesh and hardcoded values in this routine. > Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping > node 2 and asks Node 3 to establish permanent connection instead of node 2. > Despite node 2 has been already pinged within configured timeouts, node 3 try > to connect to node 2 too. > Disadvantages: > 1)Possible long detection of node failure up to > ServerImpl.CON_CHECK_INTERVAL + 2 * > IgniteConfiguretion.failureDetectionTimeout + 300ms. See ‘WostCase.txt’ > 2)Unexpected, not-configurable decision to check availability of previous > node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘: > // We got message from previous in less than double connection check interval. > boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; > If ‘ok == true’ node 3 checks node 2. > 3)Double node checking brings several not-configurable hardcoded delays: > Node 3 checks node 2 with hardcoded timeout 100ms: > ServerImpl.isConnectionRefused(): > sock.connect(addr, 100); > Checking availability of previous node considers any exception but > ConnectionException (connection refused) as existing connection. Even a > timeout. See ServerImpl.isConnectionRefused(). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13014) Remove double checking of node availability. Fix hardcoded values.
[ https://issues.apache.org/jira/browse/IGNITE-13014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13014: -- Summary: Remove double checking of node availability. Fix hardcoded values. (was: Remove long, double checking of node availability. Fix hardcoded values.) > Remove double checking of node availability. Fix hardcoded values. > -- > > Key: IGNITE-13014 > URL: https://issues.apache.org/jira/browse/IGNITE-13014 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > > For the present, we have duplicated checking of node availability. This > prolongs node failure detection and gives no additional benefits. There are > mesh and hardcoded values in this routine. > Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping > node 2 and asks Node 3 to establish permanent connection instead of node 2. > Despite node 2 has been already pinged within configured timeouts, node 3 try > to connect to node 2 too. > Disadvantages: > 1)Possible long detection of node failure up to > ServerImpl.CON_CHECK_INTERVAL + 2 * > IgniteConfiguretion.failureDetectionTimeout + 300ms. See ‘WostCase.txt’ > 2)Unexpected, not-configurable decision to check availability of previous > node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘: > // We got message from previous in less than double connection check interval. > boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; > If ‘ok == true’ node 3 checks node 2. > 3)Double node checking brings several not-configurable hardcoded delays: > Node 3 checks node 2 with hardcoded timeout 100ms: > ServerImpl.isConnectionRefused(): > sock.connect(addr, 100); > Checking availability of previous node considers any exception but > ConnectionException (connection refused) as existing connection. Even a > timeout. See ServerImpl.isConnectionRefused(). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13014) Remove double checking of node availability. Fix hardcoded values.
[ https://issues.apache.org/jira/browse/IGNITE-13014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-13014: -- Labels: iep-45 (was: ) > Remove double checking of node availability. Fix hardcoded values. > -- > > Key: IGNITE-13014 > URL: https://issues.apache.org/jira/browse/IGNITE-13014 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Steshin >Assignee: Vladimir Steshin >Priority: Major > Labels: iep-45 > Attachments: WostCase.txt > > > For the present, we have duplicated checking of node availability. This > prolongs node failure detection and gives no additional benefits. There are > mesh and hardcoded values in this routine. > Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping > node 2 and asks Node 3 to establish permanent connection instead of node 2. > Despite node 2 has been already pinged within configured timeouts, node 3 try > to connect to node 2 too. > Disadvantages: > 1)Possible long detection of node failure up to > ServerImpl.CON_CHECK_INTERVAL + 2 * > IgniteConfiguretion.failureDetectionTimeout + 300ms. See ‘WostCase.txt’ > 2)Unexpected, not-configurable decision to check availability of previous > node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘: > // We got message from previous in less than double connection check interval. > boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now; > If ‘ok == true’ node 3 checks node 2. > 3)Double node checking brings several not-configurable hardcoded delays: > Node 3 checks node 2 with hardcoded timeout 100ms: > ServerImpl.isConnectionRefused(): > sock.connect(addr, 100); > Checking availability of previous node considers any exception but > ConnectionException (connection refused) as existing connection. Even a > timeout. See ServerImpl.isConnectionRefused(). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13014) Remove double checking of node availability. Fix hardcoded values.
[
https://issues.apache.org/jira/browse/IGNITE-13014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13014:
--
Description:
For the present, we have duplicated checking of node availability. This
prolongs node failure detection and gives no additional benefits. There are
mesh and hardcoded values in this routine.
Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping
node 2 and asks Node 3 to establish permanent connection instead of node 2.
Despite node 2 has been already pinged within configured timeouts, node 3 try
to connect to node 2 too.
Disadvantages:
1) Possible long detection of node failure up to
ServerImpl.CON_CHECK_INTERVAL + 2 * IgniteConfiguretion.failureDetectionTimeout
+ 300ms. See ‘WostCase.txt’
2) Unexpected, not-configurable decision to check availability of previous
node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘:
// We got message from previous in less than double connection check interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now;
If ‘ok == true’ node 3 checks node 2.
3) Double node checking brings several not-configurable hardcoded delays:
Node 3 checks node 2 with hardcoded timeout 100ms:
ServerImpl.isConnectionRefused():
sock.connect(addr, 100);
4) Node 1 marks Node 2 alive anew with hardcoded 200ms. See
ServerImpl.CrossRingMessageSendState.markLastFailedNodeAlive():
{code:java}
try {
Thread.sleep(200);
}
catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
{code}
5) Checking availability of previous node considers any exception but
ConnectionException (connection refused) as existing connection. Even a
timeout. See ServerImpl.isConnectionRefused():
{code:java}
try (Socket sock = new Socket()) {
sock.connect(addr, 100);
}
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false; //Consideres as OK.
}
{code}
was:
For the present, we have duplicated checking of node availability. This
prolongs node failure detection and gives no additional benefits. There are
mesh and hardcoded values in this routine.
Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping
node 2 and asks Node 3 to establish permanent connection instead of node 2.
Despite node 2 has been already pinged within configured timeouts, node 3 try
to connect to node 2 too.
Disadvantages:
1) Possible long detection of node failure up to
ServerImpl.CON_CHECK_INTERVAL + 2 * IgniteConfiguretion.failureDetectionTimeout
+ 300ms. See ‘WostCase.txt’
2) Unexpected, not-configurable decision to check availability of previous
node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘:
// We got message from previous in less than double connection check interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now;
If ‘ok == true’ node 3 checks node 2.
3) Double node checking brings several not-configurable hardcoded delays:
Node 3 checks node 2 with hardcoded timeout 100ms:
ServerImpl.isConnectionRefused():
sock.connect(addr, 100);
4) Node 1 marks Node 2 alive anew with hardcoded 200ms. See
ServerImpl.CrossRingMessageSendState.markLastFailedNodeAlive():
{code:java}
try {
Thread.sleep(200);
}
catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
{code}
5) Checking availability of previous node considers any exception but
ConnectionException (connection refused) as existing connection. Even a
timeout. See ServerImpl.isConnectionRefused():
{code:java}
try (Socket sock = new Socket()) {
sock.connect(addr, 100);
}
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false; //Consideres as OK.
}
{code}
> Remove double checking of node availability. Fix hardcoded values.
> --
>
> Key: IGNITE-13014
> URL: https://issues.apache.org/jira/browse/IGNITE-13014
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Attachments: WostCase.txt
>
>
> For the present, we have duplicated checking of node availability. This
> prolongs node failure detection and gives no additional benefits. There are
> mesh and hardcoded values in this routine.
> Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping
> node 2 and asks Node 3 to establish permanent connection instead of node 2.
> Despite node 2 has been already pinged within configured timeouts, node 3 try
> to connect to node 2 too.
> Disadvantages:
> 1)Possible long detection of node failure up to
> ServerImpl.CON_CHECK_INTERVAL + 2 *
> IgniteConfiguretion.failureDetectionTimeout
[jira] [Updated] (IGNITE-13014) Remove double checking of node availability. Fix hardcoded values.
[
https://issues.apache.org/jira/browse/IGNITE-13014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13014:
--
Description:
For the present, we have duplicated checking of node availability. This
prolongs node failure detection and gives no additional benefits. There are
mesh and hardcoded values in this routine.
Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping
node 2 and asks Node 3 to establish permanent connection instead of node 2.
Despite node 2 has been already pinged within configured timeouts, node 3 try
to connect to node 2 too.
Disadvantages:
1) Possible long detection of node failure up to
ServerImpl.CON_CHECK_INTERVAL + 2 * IgniteConfiguretion.failureDetectionTimeout
+ 300ms. See ‘WostCase.txt’
2) Unexpected, not-configurable decision to check availability of previous
node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘:
// We got message from previous in less than double connection check interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now;
If ‘ok == true’ node 3 checks node 2.
3) Double node checking brings several not-configurable hardcoded delays:
Node 3 checks node 2 with hardcoded timeout 100ms:
ServerImpl.isConnectionRefused():
sock.connect(addr, 100);
4) Node 1 marks Node 2 alive anew with hardcoded 200ms. See
ServerImpl.CrossRingMessageSendState.markLastFailedNodeAlive():
{code:java}
try {
Thread.sleep(200);
}
catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
{code}
5) Checking availability of previous node considers any exception but
ConnectionException (connection refused) as existing connection. Even a
timeout. See ServerImpl.isConnectionRefused():
{code:java}
try (Socket sock = new Socket()) {
sock.connect(addr, 100);
}
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false; //Consideres as OK.
}
{code}
was:
For the present, we have duplicated checking of node availability. This
prolongs node failure detection and gives no additional benefits. There are
mesh and hardcoded values in this routine.
Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping
node 2 and asks Node 3 to establish permanent connection instead of node 2.
Despite node 2 has been already pinged within configured timeouts, node 3 try
to connect to node 2 too.
Disadvantages:
1) Possible long detection of node failure up to
ServerImpl.CON_CHECK_INTERVAL + 2 * IgniteConfiguretion.failureDetectionTimeout
+ 300ms. See ‘WostCase.txt’
2) Unexpected, not-configurable decision to check availability of previous
node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘:
// We got message from previous in less than double connection check interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now;
If ‘ok == true’ node 3 checks node 2.
3) Double node checking brings several not-configurable hardcoded delays:
Node 3 checks node 2 with hardcoded timeout 100ms:
ServerImpl.isConnectionRefused():
sock.connect(addr, 100);
Checking availability of previous node considers any exception but
ConnectionException (connection refused) as existing connection. Even a
timeout. See ServerImpl.isConnectionRefused().
> Remove double checking of node availability. Fix hardcoded values.
> --
>
> Key: IGNITE-13014
> URL: https://issues.apache.org/jira/browse/IGNITE-13014
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Attachments: WostCase.txt
>
>
> For the present, we have duplicated checking of node availability. This
> prolongs node failure detection and gives no additional benefits. There are
> mesh and hardcoded values in this routine.
> Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping
> node 2 and asks Node 3 to establish permanent connection instead of node 2.
> Despite node 2 has been already pinged within configured timeouts, node 3 try
> to connect to node 2 too.
> Disadvantages:
> 1)Possible long detection of node failure up to
> ServerImpl.CON_CHECK_INTERVAL + 2 *
> IgniteConfiguretion.failureDetectionTimeout + 300ms. See ‘WostCase.txt’
> 2)Unexpected, not-configurable decision to check availability of previous
> node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘:
> // We got message from previous in less than double connection check interval.
> boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now;
> If ‘ok == true’ node 3 checks node 2.
> 3)Double node checking brings several not-configurable hardcoded delays:
> Node 3 checks node 2 with
[jira] [Updated] (IGNITE-13014) Remove double checking of node availability. Fix hardcoded values.
[
https://issues.apache.org/jira/browse/IGNITE-13014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13014:
--
Description:
For the present, we have duplicated checking of node availability. This
prolongs node failure detection and gives no additional benefits. There are
mesh and hardcoded values in this routine.
Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping
node 2 and asks Node 3 to establish permanent connection instead of node 2.
Despite node 2 has been already pinged within configured timeouts, node 3 try
to connect to node 2 too.
Disadvantages:
1) Possible long detection of node failure up to
ServerImpl.CON_CHECK_INTERVAL + 2 * IgniteConfiguretion.failureDetectionTimeout
+ 300ms. See ‘WostCase.txt’
2) Unexpected, not-configurable decision to check availability of previous
node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘:
{code:java}
// We got message from previous in less than double connection check interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now;
{code}
If ‘ok == true’ node 3 checks node 2.
3) Double node checking brings several not-configurable hardcoded delays:
Node 3 checks node 2 with hardcoded timeout 100ms:
ServerImpl.isConnectionRefused():
{code:java}
sock.connect(addr, 100);
{code}
4) Node 1 marks Node 2 alive anew with hardcoded 200ms. See
ServerImpl.CrossRingMessageSendState.markLastFailedNodeAlive():
{code:java}
try {
Thread.sleep(200);
}
catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
{code}
5) Checking availability of previous node considers any exception but
ConnectionException (connection refused) as existing connection. Even a
timeout. See ServerImpl.isConnectionRefused():
{code:java}
try (Socket sock = new Socket()) {
sock.connect(addr, 100);
}
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false; //Consideres as OK.
}
{code}
was:
For the present, we have duplicated checking of node availability. This
prolongs node failure detection and gives no additional benefits. There are
mesh and hardcoded values in this routine.
Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping
node 2 and asks Node 3 to establish permanent connection instead of node 2.
Despite node 2 has been already pinged within configured timeouts, node 3 try
to connect to node 2 too.
Disadvantages:
1) Possible long detection of node failure up to
ServerImpl.CON_CHECK_INTERVAL + 2 * IgniteConfiguretion.failureDetectionTimeout
+ 300ms. See ‘WostCase.txt’
2) Unexpected, not-configurable decision to check availability of previous
node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘:
// We got message from previous in less than double connection check interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now;
If ‘ok == true’ node 3 checks node 2.
3) Double node checking brings several not-configurable hardcoded delays:
Node 3 checks node 2 with hardcoded timeout 100ms:
ServerImpl.isConnectionRefused():
sock.connect(addr, 100);
4) Node 1 marks Node 2 alive anew with hardcoded 200ms. See
ServerImpl.CrossRingMessageSendState.markLastFailedNodeAlive():
{code:java}
try {
Thread.sleep(200);
}
catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
{code}
5) Checking availability of previous node considers any exception but
ConnectionException (connection refused) as existing connection. Even a
timeout. See ServerImpl.isConnectionRefused():
{code:java}
try (Socket sock = new Socket()) {
sock.connect(addr, 100);
}
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false; //Consideres as OK.
}
{code}
> Remove double checking of node availability. Fix hardcoded values.
> --
>
> Key: IGNITE-13014
> URL: https://issues.apache.org/jira/browse/IGNITE-13014
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Attachments: WostCase.txt
>
>
> For the present, we have duplicated checking of node availability. This
> prolongs node failure detection and gives no additional benefits. There are
> mesh and hardcoded values in this routine.
> Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping
> node 2 and asks Node 3 to establish permanent connection instead of node 2.
> Despite node 2 has been already pinged within configured timeouts, node 3 try
> to connect to node 2 too.
> Disadvantages:
> 1)Possible long detection of node failure up to
> ServerImpl.CON_CHECK_INTERVAL + 2 *
> IgniteConfiguretion.failureDetectionTimeout + 300ms. See ‘WostCase.txt’
> 2)Unexpected,
[jira] [Updated] (IGNITE-13014) Remove double checking of node availability. Fix hardcoded values.
[
https://issues.apache.org/jira/browse/IGNITE-13014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin updated IGNITE-13014:
--
Description:
For the present, we have double checking of node availability. This prolongs
node failure detection and gives no additional benefits. There are mesh and
hardcoded values in this routine.
Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping
node 2 and asks Node 3 to establish permanent connection instead of node 2.
Node 3 may try to check node 2 too. Or may not.
Proposal:
Do not check failed node second time. Keep failure detection within expected
timeouts (IgniteConfiguration.failureDetectionTimeout).
Drawbacks:
1) Possible long detection of node failure up to
ServerImpl.CON_CHECK_INTERVAL + 2 * IgniteConfiguretion.failureDetectionTimeout
+ 300ms. See ‘WostCase.txt’
2) Unexpected, not-configurable decision to check availability of previous
node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘:
{code:java}
// We got message from previous in less than double connection check interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now;
{code}
If ‘ok == true’ node 3 checks node 2.
3) Several not-configurable hardcoded delays:
Node 3 checks node 2 with hardcoded timeout 100ms:
ServerImpl.isConnectionRefused():
{code:java}
sock.connect(addr, 100);
{code}
Node 1 marks Node 2 alive anew with hardcoded 200ms. See
ServerImpl.CrossRingMessageSendState.markLastFailedNodeAlive():
{code:java}
try {
Thread.sleep(200);
}
catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
{code}
4) Checking availability of previous node considers any exception but
ConnectionException (connection refused) as existing connection. Even a
timeout. See ServerImpl.isConnectionRefused():
{code:java}
try (Socket sock = new Socket()) {
sock.connect(addr, 100);
}
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false; //Consideres as OK.
}
{code}
was:
For the present, we have duplicated checking of node availability. This
prolongs node failure detection and gives no additional benefits. There are
mesh and hardcoded values in this routine.
Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping
node 2 and asks Node 3 to establish permanent connection instead of node 2.
Despite node 2 has been already pinged within configured timeouts, node 3 try
to connect to node 2 too.
Disadvantages:
1) Possible long detection of node failure up to
ServerImpl.CON_CHECK_INTERVAL + 2 * IgniteConfiguretion.failureDetectionTimeout
+ 300ms. See ‘WostCase.txt’
2) Unexpected, not-configurable decision to check availability of previous
node based on ‘2 * ServerImpl.CON_CHECK_INTERVAL‘:
{code:java}
// We got message from previous in less than double connection check interval.
boolean ok = rcvdTime + CON_CHECK_INTERVAL * 2 >= now;
{code}
If ‘ok == true’ node 3 checks node 2.
3) Double node checking brings several not-configurable hardcoded delays:
Node 3 checks node 2 with hardcoded timeout 100ms:
ServerImpl.isConnectionRefused():
{code:java}
sock.connect(addr, 100);
{code}
4) Node 1 marks Node 2 alive anew with hardcoded 200ms. See
ServerImpl.CrossRingMessageSendState.markLastFailedNodeAlive():
{code:java}
try {
Thread.sleep(200);
}
catch (InterruptedException e) {
Thread.currentThread().interrupt();
}
{code}
5) Checking availability of previous node considers any exception but
ConnectionException (connection refused) as existing connection. Even a
timeout. See ServerImpl.isConnectionRefused():
{code:java}
try (Socket sock = new Socket()) {
sock.connect(addr, 100);
}
catch (ConnectException e) {
return true;
}
catch (IOException e) {
return false; //Consideres as OK.
}
{code}
> Remove double checking of node availability. Fix hardcoded values.
> --
>
> Key: IGNITE-13014
> URL: https://issues.apache.org/jira/browse/IGNITE-13014
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
> Labels: iep-45
> Attachments: WostCase.txt
>
>
> For the present, we have double checking of node availability. This prolongs
> node failure detection and gives no additional benefits. There are mesh and
> hardcoded values in this routine.
> Let's imagine node 2 doesn't answer any more. Node 1 becomes unable to ping
> node 2 and asks Node 3 to establish permanent connection instead of node 2.
> Node 3 may try to check node 2 too. Or may not.
> Proposal:
> Do not check failed node second time. Keep failure detection within expected
> timeouts (IgniteConfiguration.failureDetectionTimeout).
> Drawbacks:
> 1)Possible long detection of
