[jira] [Updated] (IGNITE-13071) Improve test coverage for read-only cluster state
[ https://issues.apache.org/jira/browse/IGNITE-13071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-13071: Labels: read-only-mode (was: ) > Improve test coverage for read-only cluster state > - > > Key: IGNITE-13071 > URL: https://issues.apache.org/jira/browse/IGNITE-13071 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Labels: read-only-mode > Fix For: 2.9 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > It would be nice to extend test coverage for this feature. > We don't have tests for: > * data structures > * cache destroy/create > * cache clear > * DDL requests > * Cache updates from task/deployed service > * Updates to metastorage/distributed metastorage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11889) Add security permissions cluster state change operations
[ https://issues.apache.org/jira/browse/IGNITE-11889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-11889: Labels: read-only-mode (was: ) > Add security permissions cluster state change operations > > > Key: IGNITE-11889 > URL: https://issues.apache.org/jira/browse/IGNITE-11889 > Project: Ignite > Issue Type: Bug > Components: security >Reporter: Sergey Antonov >Priority: Major > Labels: read-only-mode > > We should add security permissions for cluster state change operations: > * Cluster activation/deactivation. > * Set/change baseline topology. > * Enable/disable read-only mode. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11863) .NET: Add cluster read-only mode API (status, run-time change)
[ https://issues.apache.org/jira/browse/IGNITE-11863?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-11863: Labels: .NET read-only-mode (was: .NET) > .NET: Add cluster read-only mode API (status, run-time change) > -- > > Key: IGNITE-11863 > URL: https://issues.apache.org/jira/browse/IGNITE-11863 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Sergey Antonov >Priority: Major > Labels: .NET, read-only-mode > > We would introduce at IGNITE-11256 new methods in IgniteCluster. > We need their support in .Net side. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12136) Test ClusterReadOnlyModeTest is flaky.
[ https://issues.apache.org/jira/browse/IGNITE-12136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-12136: Labels: read-only-mode (was: ) > Test ClusterReadOnlyModeTest is flaky. > -- > > Key: IGNITE-12136 > URL: https://issues.apache.org/jira/browse/IGNITE-12136 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Labels: read-only-mode > Fix For: 2.8 > > Time Spent: 20m > Remaining Estimate: 0h > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=4535823271211432266=testDetails_IgniteTests24Java8=%3Cdefault%3E -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13076) Cluster read-only mode doesn't affect LOCAL caches
[
https://issues.apache.org/jira/browse/IGNITE-13076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-13076:
Labels: read-only-mode (was: )
> Cluster read-only mode doesn't affect LOCAL caches
> --
>
> Key: IGNITE-13076
> URL: https://issues.apache.org/jira/browse/IGNITE-13076
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Sergey Antonov
>Priority: Major
> Labels: read-only-mode
> Fix For: 2.9
>
>
> You can make data modification operations with LOCAL cache even if cluster in
> a {{ACTIVE_READ_ONLY}} state.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13144) Improve ClusterState enum and other minor improvements for the cluster read-only mode.
[
https://issues.apache.org/jira/browse/IGNITE-13144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-13144:
Labels: read-only-mode (was: )
> Improve ClusterState enum and other minor improvements for the cluster
> read-only mode.
> --
>
> Key: IGNITE-13144
> URL: https://issues.apache.org/jira/browse/IGNITE-13144
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Labels: read-only-mode
> Fix For: 2.9
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> We have {{boolean ClusterState#active(ClusterState)}} static method. It would
> be better to have an instance method {{boolean active()}}.
> Also, we have ClusterState#lesserOf static method. It needs for internal
> purposes. So we must move this method in an internal package.
> We introduced new compute requests for getting/change cluster state from the
> client node as internal classes of GridClusterStateProcessor. We should move
> them to separate public classes for maintainability purposes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13138) Add REST tests for the new cluster state change API
[ https://issues.apache.org/jira/browse/IGNITE-13138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-13138: Labels: read-only-mode test (was: test) > Add REST tests for the new cluster state change API > --- > > Key: IGNITE-13138 > URL: https://issues.apache.org/jira/browse/IGNITE-13138 > Project: Ignite > Issue Type: Improvement > Components: rest >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Labels: read-only-mode, test > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > I didn't find tests for a new REST commands introduced in an IGNITE-12225. It > must be fixed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11866) Add ability to activate cluster in read-only mode
[ https://issues.apache.org/jira/browse/IGNITE-11866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-11866: Ignite Flags: (was: Docs Required) > Add ability to activate cluster in read-only mode > - > > Key: IGNITE-11866 > URL: https://issues.apache.org/jira/browse/IGNITE-11866 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > > After IGNITE-11256 we have cluster read-only mode. We should have ability to > activate cluster and enable read-only mode like atomic operation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-11256) Implement read-only mode for grid
[ https://issues.apache.org/jira/browse/IGNITE-11256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-11256: Labels: important read-only-mode (was: important) > Implement read-only mode for grid > - > > Key: IGNITE-11256 > URL: https://issues.apache.org/jira/browse/IGNITE-11256 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Scherbakov >Assignee: Sergey Antonov >Priority: Major > Labels: important, read-only-mode > Fix For: 2.9 > > Time Spent: 4h 10m > Remaining Estimate: 0h > > Should be triggered from control.sh utility. > Useful for maintenance work, for example checking partition consistency > (idle_verify) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12225) Add enum for cluster state
[
https://issues.apache.org/jira/browse/IGNITE-12225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-12225:
Labels: read-only-mode (was: )
> Add enum for cluster state
> --
>
> Key: IGNITE-12225
> URL: https://issues.apache.org/jira/browse/IGNITE-12225
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Labels: read-only-mode
> Fix For: 2.9
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> We have 3 cluster states at the moment: inactive, active, read-only.
> For getting current cluster state and changing them {{IgniteCluster}} has
> methods:
> * {{boolean active()}}, {{void active(boolean active)}} - for cluster
> activation/deactivation
> * {{boolean readOnly()}}, {{void readOnly(boolean readOnly)}} - for
> enabling/disabling read-only mode.
> Also we have control.sh commans for changing cluster state:
> * {{--activate}}
> * {{--deactivate}}
> * {{--read-only-on}}
> * {{--read-only-off}}
> For me current API looks unuseful. My proposal:
> # Create enum {{ClusterState}} with values {{ACTIVE}}, {{INACTIVE}},
> {{READ-ONLY}}.
> # Add methods to {{IgniteCluster}}:
> #* {{ClusterState state()}} returns current cluster state
> #* {{void state(ClusterState newState)}} changes cluster state to
> {{newState}} state
> # Mark as deprecated the following methods in {{IgniteCluster}}: {{boolean
> active()}}, {{void active(boolean active)}},
> # Add new command to control.sh: {{control.sh --set-state
> (ACTIVE|INACTIVE|READ-ONLY)}} [--yes]
> # Add warn message that command is depricated in control.sh. Commands:
> --activate, --deactivate,
> # Remove commands from control.sh: --read-only-on, --read-only-off (no one
> release wasn't published with this functional)
> # Add new methods to {{IgniteConfiguration}}:
> #* {{ClusterState getClusterStateOnStart()}}
> #* {{IgniteConfiguration setClusterStateOnStart(ClusterState state)}}
> # Deprecate methods in {{IgniteConfiguration}}:
> #* {{boolean isActiveOnStart()}}
> #* {{IgniteConfiguration setActiveOnStart(boolean activeOnStart)}}
> # Depracate ClusterActivationEvent and introduce new ClusterStateChangeEvent.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13144) Improve ClusterState enum and other minor improvements for the cluster read-only mode.
[
https://issues.apache.org/jira/browse/IGNITE-13144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140713#comment-17140713
]
Sergey Antonov commented on IGNITE-13144:
-
[~alex_pl] Thank you for the your review. I fixed most of them and answered
others. Could you look again, please?
> Improve ClusterState enum and other minor improvements for the cluster
> read-only mode.
> --
>
> Key: IGNITE-13144
> URL: https://issues.apache.org/jira/browse/IGNITE-13144
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> We have {{boolean ClusterState#active(ClusterState)}} static method. It would
> be better to have an instance method {{boolean active()}}.
> Also, we have ClusterState#lesserOf static method. It needs for internal
> purposes. So we must move this method in an internal package.
> We introduced new compute requests for getting/change cluster state from the
> client node as internal classes of GridClusterStateProcessor. We should move
> them to separate public classes for maintainability purposes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13144) Improve ClusterState enum and other minor improvements for the cluster read-only mode.
[
https://issues.apache.org/jira/browse/IGNITE-13144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-13144:
Description:
We have {{boolean ClusterState#active(ClusterState)}} static method. It would
be better to have an instance method {{boolean active()}}.
Also, we have ClusterState#lesserOf static method. It needs for internal
purposes. So we must move this method in an internal package.
We introduced new compute requests for getting/change cluster state from the
client node as internal classes of GridClusterStateProcessor. We should move
them to separate public classes for maintainability purposes.
was:
We have {{boolean ClusterState#active(ClusterState)}} static method. It would
be better to have an instance method {{boolean active()}}.
Also, we have ClusterState#lesserOf static method. It needs for internal
purposes. So we must move this method in an internal package.
We introduced new compute requests for getting/change cluster state from the
client node as internal classes of GridClusterStateProcessor. We should move
them to separate public classes for the maintainability purposes.
> Improve ClusterState enum and other minor improvements for the cluster
> read-only mode.
> --
>
> Key: IGNITE-13144
> URL: https://issues.apache.org/jira/browse/IGNITE-13144
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have {{boolean ClusterState#active(ClusterState)}} static method. It would
> be better to have an instance method {{boolean active()}}.
> Also, we have ClusterState#lesserOf static method. It needs for internal
> purposes. So we must move this method in an internal package.
> We introduced new compute requests for getting/change cluster state from the
> client node as internal classes of GridClusterStateProcessor. We should move
> them to separate public classes for maintainability purposes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13144) Improve ClusterState enum and other minor improvements for the cluster read-only mode.
[
https://issues.apache.org/jira/browse/IGNITE-13144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-13144:
Description:
We have {{boolean ClusterState#active(ClusterState)}} static method. It would
be better to have an instance method {{boolean active()}}.
Also, we have ClusterState#lesserOf static method. It needs for internal
purposes. So we must move this method in an internal package.
We introduced new compute requests for getting/change cluster state from the
client node as internal classes of GridClusterStateProcessor. We should move
them to separate public classes for the maintainability purposes.
was:
We have {{boolean ClusterState#active(ClusterState)}} static method. It would
be better to have an instance method {{boolean active()}}.
Also, we have ClusterState#lesserOf static method. It needs for internal
purposes. So we must move this method in an internal package.
> Improve ClusterState enum and other minor improvements for the cluster
> read-only mode.
> --
>
> Key: IGNITE-13144
> URL: https://issues.apache.org/jira/browse/IGNITE-13144
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have {{boolean ClusterState#active(ClusterState)}} static method. It would
> be better to have an instance method {{boolean active()}}.
> Also, we have ClusterState#lesserOf static method. It needs for internal
> purposes. So we must move this method in an internal package.
> We introduced new compute requests for getting/change cluster state from the
> client node as internal classes of GridClusterStateProcessor. We should move
> them to separate public classes for the maintainability purposes.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13144) Improve ClusterState enum and other minor improvements for the cluster read-only mode.
[
https://issues.apache.org/jira/browse/IGNITE-13144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-13144:
Summary: Improve ClusterState enum and other minor improvements for the
cluster read-only mode. (was: Improve ClusterState enum)
> Improve ClusterState enum and other minor improvements for the cluster
> read-only mode.
> --
>
> Key: IGNITE-13144
> URL: https://issues.apache.org/jira/browse/IGNITE-13144
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have {{boolean ClusterState#active(ClusterState)}} static method. It would
> be better to have an instance method {{boolean active()}}.
> Also, we have ClusterState#lesserOf static method. It needs for internal
> purposes. So we must move this method in an internal package.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13144) Improve ClusterState enum
[
https://issues.apache.org/jira/browse/IGNITE-13144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-13144:
Description:
We have {{boolean ClusterState#active(ClusterState)}} static method. It would
be better to have an instance method {{boolean active()}}.
Also, we have ClusterState#lesserOf static method. It needs for internal
purposes. So we must move this method in an internal package.
was:We have {{boolean ClusterState#active(ClusterState)}} static method. It
would be better to have an instance method {{boolean active()}}. Also I'd like
to add methods {{boolean inactive()}} and {{boolean readOnly()}} to
{{ClusterState}} class.
> Improve ClusterState enum
> -
>
> Key: IGNITE-13144
> URL: https://issues.apache.org/jira/browse/IGNITE-13144
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have {{boolean ClusterState#active(ClusterState)}} static method. It would
> be better to have an instance method {{boolean active()}}.
> Also, we have ClusterState#lesserOf static method. It needs for internal
> purposes. So we must move this method in an internal package.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13144) Improve ClusterState enum
[
https://issues.apache.org/jira/browse/IGNITE-13144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-13144:
Summary: Improve ClusterState enum (was: Add flag methods to the
ClusterState enum)
> Improve ClusterState enum
> -
>
> Key: IGNITE-13144
> URL: https://issues.apache.org/jira/browse/IGNITE-13144
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.9
>
>
> We have {{boolean ClusterState#active(ClusterState)}} static method. It would
> be better to have an instance method {{boolean active()}}. Also I'd like to
> add methods {{boolean inactive()}} and {{boolean readOnly()}} to
> {{ClusterState}} class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13144) Add flag methods to the ClusterState enum
[
https://issues.apache.org/jira/browse/IGNITE-13144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-13144:
Summary: Add flag methods to the ClusterState enum (was: Add attribute
methods to ClusterState enum)
> Add flag methods to the ClusterState enum
> -
>
> Key: IGNITE-13144
> URL: https://issues.apache.org/jira/browse/IGNITE-13144
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.9
>
>
> We have {{boolean ClusterState#active(ClusterState)}} static method. It would
> be better to have an instance method {{boolean active()}}. Also I'd like to
> add methods {{boolean inactive()}} and {{boolean readOnly()}} to
> {{ClusterState}} class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13144) Add attribute methods to ClusterState enum
Sergey Antonov created IGNITE-13144:
---
Summary: Add attribute methods to ClusterState enum
Key: IGNITE-13144
URL: https://issues.apache.org/jira/browse/IGNITE-13144
Project: Ignite
Issue Type: Improvement
Reporter: Sergey Antonov
Assignee: Sergey Antonov
Fix For: 2.9
We have {{boolean ClusterState#active(ClusterState)}} static method. It would
be better to have an instance method {{boolean active()}}. Also I'd like to add
methods {{boolean inactive()}} and {{boolean readOnly()}} to {{ClusterState}}
class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-11256) Implement read-only mode for grid
[ https://issues.apache.org/jira/browse/IGNITE-11256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-11256: Ignite Flags: Docs Required,Release Notes Required (was: Docs Required) Release Note: Introduced new cluster-wide state: read-only. In this state caches available for cache read operations. Cache operations with data modification (update, remove, clear, create, destroy and etc.) don't allow. > Implement read-only mode for grid > - > > Key: IGNITE-11256 > URL: https://issues.apache.org/jira/browse/IGNITE-11256 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Scherbakov >Assignee: Sergey Antonov >Priority: Major > Labels: important > Fix For: 2.9 > > Time Spent: 4h 10m > Remaining Estimate: 0h > > Should be triggered from control.sh utility. > Useful for maintenance work, for example checking partition consistency > (idle_verify) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12225) Add enum for cluster state
[
https://issues.apache.org/jira/browse/IGNITE-12225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-12225:
Docs Text:
Changes in a public API:
# Introduced {{ClusterState}} enum.
# *{{org.apache.ignite.IgniteCluster}}*:
## Introduced new method for the cluster state change: {{void
state(ClusterState)}}
## Introduced new method for the getting current cluster state: {{ClusterState
state()}}
## Deprecated methods {{void active(boolean)}} and {{boolean active()}}. Use a
new methods described above.
# *Control utility ({{control.sh}})*:
## Introduced new command for the cluster state change: {{control.sh
--set-state INACTIVE|ACTIVE|ACTIVE_READ_ONLY [--yes]}}
## Deprecated activate/deactivate commands {{control.sh --activate}},
{{control.sh --deactivate}}
# *REST*:
## Introduced new command for changing cluster state:
##* Request: {{http://host:port/ignite?cmd=setstate=}}
##* Response: {{
{"successStatus":0,"error":null,"sessionToken":null,"response":"setstate done"}
}}
## Introduced new command for getting current cluster state:
##* Request: {{http://host:port/ignite?cmd=state}}
##* Response: {{
{"successStatus":0,"error":null,"sessionToken":null,"response":"ACTIVE"} }}
# *{{org.apache.ignite.IgniteConfiguration}}*:
## Introduced new property {{clusterStateOnStart}}. This property has the same
behaviour as {{activeOnStart}} for in-memory clusters and {{autoActivation}}
for the persistent clusters. The default value of a new property is
{{DFLT_STATE_ON_START}} ({{ACTIVE}}).
## Deprecated {{activeOnStart}} and {{autoActivation}} properties and related
with them default values {{DFLT_ACTIVE_ON_START}}, {{DFLT_AUTO_ACTIVATION}}.
# *IgniteEvents*:
## Introduced a new cluster state change event {{ClusterStateChangeEvent}}.
## Deprecated {{ClusterActivationEvent}} event.
Release Note: Introduced a new public API for the cluster state change
(activation/deactivation and etc.). Added ability to activate clusters in a
read-only mode.
> Add enum for cluster state
> --
>
> Key: IGNITE-12225
> URL: https://issues.apache.org/jira/browse/IGNITE-12225
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> We have 3 cluster states at the moment: inactive, active, read-only.
> For getting current cluster state and changing them {{IgniteCluster}} has
> methods:
> * {{boolean active()}}, {{void active(boolean active)}} - for cluster
> activation/deactivation
> * {{boolean readOnly()}}, {{void readOnly(boolean readOnly)}} - for
> enabling/disabling read-only mode.
> Also we have control.sh commans for changing cluster state:
> * {{--activate}}
> * {{--deactivate}}
> * {{--read-only-on}}
> * {{--read-only-off}}
> For me current API looks unuseful. My proposal:
> # Create enum {{ClusterState}} with values {{ACTIVE}}, {{INACTIVE}},
> {{READ-ONLY}}.
> # Add methods to {{IgniteCluster}}:
> #* {{ClusterState state()}} returns current cluster state
> #* {{void state(ClusterState newState)}} changes cluster state to
> {{newState}} state
> # Mark as deprecated the following methods in {{IgniteCluster}}: {{boolean
> active()}}, {{void active(boolean active)}},
> # Add new command to control.sh: {{control.sh --set-state
> (ACTIVE|INACTIVE|READ-ONLY)}} [--yes]
> # Add warn message that command is depricated in control.sh. Commands:
> --activate, --deactivate,
> # Remove commands from control.sh: --read-only-on, --read-only-off (no one
> release wasn't published with this functional)
> # Add new methods to {{IgniteConfiguration}}:
> #* {{ClusterState getClusterStateOnStart()}}
> #* {{IgniteConfiguration setClusterStateOnStart(ClusterState state)}}
> # Deprecate methods in {{IgniteConfiguration}}:
> #* {{boolean isActiveOnStart()}}
> #* {{IgniteConfiguration setActiveOnStart(boolean activeOnStart)}}
> # Depracate ClusterActivationEvent and introduce new ClusterStateChangeEvent.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12225) Add enum for cluster state
[
https://issues.apache.org/jira/browse/IGNITE-12225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17130535#comment-17130535
]
Sergey Antonov commented on IGNITE-12225:
-
Changes in a public API:
# Introduced {{ClusterState}} enum.
# *{{org.apache.ignite.IgniteCluster}}*:
## Introduced new method for the cluster state change: {{void
state(ClusterState)}}
## Introduced new method for the getting current cluster state: {{ClusterState
state()}}
## Deprecated methods {{void active(boolean)}} and {{boolean active()}}. Use a
new methods described above.
# *Control utility ({{control.sh}})*:
## Introduced new command for the cluster state change: {{control.sh
--set-state INACTIVE|ACTIVE|ACTIVE_READ_ONLY [--yes]}}
## Deprecated activate/deactivate commands {{control.sh --activate}},
{{control.sh --deactivate}}
# *REST*:
## Introduced new command for changing cluster state:
##* Request: {{http://host:port/ignite?cmd=setstate=}}
##* Response: {{
{"successStatus":0,"error":null,"sessionToken":null,"response":"setstate done"}
}}
## Introduced new command for getting current cluster state:
##* Request: {{http://host:port/ignite?cmd=state}}
##* Response: {{
{"successStatus":0,"error":null,"sessionToken":null,"response":"ACTIVE"} }}
# *{{org.apache.ignite.IgniteConfiguration}}*:
## Introduced new property {{clusterStateOnStart}}. This property has the same
behaviour as {{activeOnStart}} for in-memory clusters and {{autoActivation}}
for the persistent clusters. The default value of a new property is
{{DFLT_STATE_ON_START}} ({{ACTIVE}}).
## Deprecated {{activeOnStart}} and {{autoActivation}} properties and related
with them default values {{DFLT_ACTIVE_ON_START}}, {{DFLT_AUTO_ACTIVATION}}.
# *IgniteEvents*:
## Introduced a new cluster state change event {{ClusterStateChangeEvent}}.
## Deprecated {{ClusterActivationEvent}} event.
> Add enum for cluster state
> --
>
> Key: IGNITE-12225
> URL: https://issues.apache.org/jira/browse/IGNITE-12225
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> We have 3 cluster states at the moment: inactive, active, read-only.
> For getting current cluster state and changing them {{IgniteCluster}} has
> methods:
> * {{boolean active()}}, {{void active(boolean active)}} - for cluster
> activation/deactivation
> * {{boolean readOnly()}}, {{void readOnly(boolean readOnly)}} - for
> enabling/disabling read-only mode.
> Also we have control.sh commans for changing cluster state:
> * {{--activate}}
> * {{--deactivate}}
> * {{--read-only-on}}
> * {{--read-only-off}}
> For me current API looks unuseful. My proposal:
> # Create enum {{ClusterState}} with values {{ACTIVE}}, {{INACTIVE}},
> {{READ-ONLY}}.
> # Add methods to {{IgniteCluster}}:
> #* {{ClusterState state()}} returns current cluster state
> #* {{void state(ClusterState newState)}} changes cluster state to
> {{newState}} state
> # Mark as deprecated the following methods in {{IgniteCluster}}: {{boolean
> active()}}, {{void active(boolean active)}},
> # Add new command to control.sh: {{control.sh --set-state
> (ACTIVE|INACTIVE|READ-ONLY)}} [--yes]
> # Add warn message that command is depricated in control.sh. Commands:
> --activate, --deactivate,
> # Remove commands from control.sh: --read-only-on, --read-only-off (no one
> release wasn't published with this functional)
> # Add new methods to {{IgniteConfiguration}}:
> #* {{ClusterState getClusterStateOnStart()}}
> #* {{IgniteConfiguration setClusterStateOnStart(ClusterState state)}}
> # Deprecate methods in {{IgniteConfiguration}}:
> #* {{boolean isActiveOnStart()}}
> #* {{IgniteConfiguration setActiveOnStart(boolean activeOnStart)}}
> # Depracate ClusterActivationEvent and introduce new ClusterStateChangeEvent.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13138) Add REST tests for the new cluster state change API
[ https://issues.apache.org/jira/browse/IGNITE-13138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-13138: Reviewer: Stanilovsky Evgeny > Add REST tests for the new cluster state change API > --- > > Key: IGNITE-13138 > URL: https://issues.apache.org/jira/browse/IGNITE-13138 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > I didn't find tests for a new REST commands introduced in an IGNITE-12225. It > must be fixed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13138) Add REST tests for the new cluster state change API
[ https://issues.apache.org/jira/browse/IGNITE-13138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17130410#comment-17130410 ] Sergey Antonov commented on IGNITE-13138: - [~zstan] Could you look at my tests please. > Add REST tests for the new cluster state change API > --- > > Key: IGNITE-13138 > URL: https://issues.apache.org/jira/browse/IGNITE-13138 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > I didn't find tests for a new REST commands introduced in an IGNITE-12225. It > must be fixed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13138) Add REST tests for the new cluster state change API
[ https://issues.apache.org/jira/browse/IGNITE-13138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-13138: Description: I didn't find tests for a new REST commands introduced in an IGNITE-12225. It must be fixed. (was: I didn't find tests for a new REST commands introduced in an IGNITE-12225. We must fix them.) > Add REST tests for the new cluster state change API > --- > > Key: IGNITE-13138 > URL: https://issues.apache.org/jira/browse/IGNITE-13138 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.9 > > > I didn't find tests for a new REST commands introduced in an IGNITE-12225. It > must be fixed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13138) Add REST tests for the new cluster state change API
Sergey Antonov created IGNITE-13138: --- Summary: Add REST tests for the new cluster state change API Key: IGNITE-13138 URL: https://issues.apache.org/jira/browse/IGNITE-13138 Project: Ignite Issue Type: Improvement Reporter: Sergey Antonov Assignee: Sergey Antonov Fix For: 2.9 I didn't find tests for a new REST commands introduced in an IGNITE-12225. We must fix them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13071) Improve test coverage for read-only cluster state
[ https://issues.apache.org/jira/browse/IGNITE-13071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17126675#comment-17126675 ] Sergey Antonov commented on IGNITE-13071: - [~ivan.glukos] Could you too please. > Improve test coverage for read-only cluster state > - > > Key: IGNITE-13071 > URL: https://issues.apache.org/jira/browse/IGNITE-13071 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.9 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > It would be nice to extend test coverage for this feature. > We don't have tests for: > * data structures > * cache destroy/create > * cache clear > * DDL requests > * Cache updates from task/deployed service > * Updates to metastorage/distributed metastorage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13071) Improve test coverage for read-only cluster state
[
https://issues.apache.org/jira/browse/IGNITE-13071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17126048#comment-17126048
]
Sergey Antonov commented on IGNITE-13071:
-
[~zstan] I made fixes according to your comments. Please look again.
> don`t find datastreamer tests, may be miss ?
No, I didn't write datastreamer tests because we already have them - see
{{ClusterReadOnlyModeTest#testDataStreamer*}} tests.
> Improve test coverage for read-only cluster state
> -
>
> Key: IGNITE-13071
> URL: https://issues.apache.org/jira/browse/IGNITE-13071
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> It would be nice to extend test coverage for this feature.
> We don't have tests for:
> * data structures
> * cache destroy/create
> * cache clear
> * DDL requests
> * Cache updates from task/deployed service
> * Updates to metastorage/distributed metastorage.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-13071) Improve test coverage for read-only cluster state
[ https://issues.apache.org/jira/browse/IGNITE-13071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17125749#comment-17125749 ] Sergey Antonov commented on IGNITE-13071: - [~zstan] Could you look at my changes, please? > Improve test coverage for read-only cluster state > - > > Key: IGNITE-13071 > URL: https://issues.apache.org/jira/browse/IGNITE-13071 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > It would be nice to extend test coverage for this feature. > We don't have tests for: > * data structures > * cache destroy/create > * cache clear > * DDL requests > * Cache updates from task/deployed service > * Updates to metastorage/distributed metastorage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13071) Improve test coverage for read-only cluster state
[ https://issues.apache.org/jira/browse/IGNITE-13071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-13071: Ignite Flags: (was: Docs Required,Release Notes Required) > Improve test coverage for read-only cluster state > - > > Key: IGNITE-13071 > URL: https://issues.apache.org/jira/browse/IGNITE-13071 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > It would be nice to extend test coverage for this feature. > We don't have tests for: > * data structures > * cache destroy/create > * cache clear > * DDL requests > * Cache updates from task/deployed service > * Updates to metastorage/distributed metastorage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13102) IgniteCache#isClosed() returns false on server node even if the cache had been closed before.
[
https://issues.apache.org/jira/browse/IGNITE-13102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-13102:
Summary: IgniteCache#isClosed() returns false on server node even if the
cache had been closed before. (was: IgniteCache#isClosed() returns false on
server node even if the cache had closed before.)
> IgniteCache#isClosed() returns false on server node even if the cache had
> been closed before.
> -
>
> Key: IGNITE-13102
> URL: https://issues.apache.org/jira/browse/IGNITE-13102
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.8, 2.8.1
>Reporter: Sergey Antonov
>Priority: Major
> Fix For: 2.9
>
>
> IgniteCache#isClosed() still returns {{false}} even after
> {{IgniteCache#close()}}. Only server nodes affect by this problem.
> Simple reproducer:
> {code:java}
> @Test
> public void test() throws Exception {
> IgniteEx node = startGrid(0);
> IgniteCache cache =
> node.getOrCreateCache(DEFAULT_CACHE_NAME);
> assertFalse(cache.isClosed());
> cache.close();
> // java.lang.AssertionError
> assertTrue(cache.isClosed());
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13102) IgniteCache#isClosed() returns false on server node even if the cache had closed before.
Sergey Antonov created IGNITE-13102:
---
Summary: IgniteCache#isClosed() returns false on server node even
if the cache had closed before.
Key: IGNITE-13102
URL: https://issues.apache.org/jira/browse/IGNITE-13102
Project: Ignite
Issue Type: Bug
Affects Versions: 2.8.1, 2.8
Reporter: Sergey Antonov
Fix For: 2.9
IgniteCache#isClosed() still returns {{false}} even after
{{IgniteCache#close()}}. Only server nodes affect by this problem.
Simple reproducer:
{code:java}
@Test
public void test() throws Exception {
IgniteEx node = startGrid(0);
IgniteCache cache =
node.getOrCreateCache(DEFAULT_CACHE_NAME);
assertFalse(cache.isClosed());
cache.close();
// java.lang.AssertionError
assertTrue(cache.isClosed());
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (IGNITE-13091) Cluster read-only mode allows to create caches
[
https://issues.apache.org/jira/browse/IGNITE-13091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov closed IGNITE-13091.
---
> Cluster read-only mode allows to create caches
> --
>
> Key: IGNITE-13091
> URL: https://issues.apache.org/jira/browse/IGNITE-13091
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Sergey Antonov
>Priority: Major
>
> You can create a cache if cluster in a read-only mode.
> See {{CacheCreateDestroyClusterReadOnlyModeTest#testCacheCreateDenied}} test.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-13091) Cluster read-only mode allows to create caches
[
https://issues.apache.org/jira/browse/IGNITE-13091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov resolved IGNITE-13091.
-
Resolution: Duplicate
WIll be fixed under IGNITE-13071
> Cluster read-only mode allows to create caches
> --
>
> Key: IGNITE-13091
> URL: https://issues.apache.org/jira/browse/IGNITE-13091
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Sergey Antonov
>Priority: Major
>
> You can create a cache if cluster in a read-only mode.
> See {{CacheCreateDestroyClusterReadOnlyModeTest#testCacheCreateDenied}} test.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13091) Cluster read-only mode allows to create caches
[
https://issues.apache.org/jira/browse/IGNITE-13091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-13091:
Fix Version/s: (was: 2.9)
> Cluster read-only mode allows to create caches
> --
>
> Key: IGNITE-13091
> URL: https://issues.apache.org/jira/browse/IGNITE-13091
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9
>Reporter: Sergey Antonov
>Priority: Major
>
> You can create a cache if cluster in a read-only mode.
> See {{CacheCreateDestroyClusterReadOnlyModeTest#testCacheCreateDenied}} test.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13091) Cluster read-only mode allows to create caches
Sergey Antonov created IGNITE-13091:
---
Summary: Cluster read-only mode allows to create caches
Key: IGNITE-13091
URL: https://issues.apache.org/jira/browse/IGNITE-13091
Project: Ignite
Issue Type: Bug
Affects Versions: 2.9
Reporter: Sergey Antonov
Fix For: 2.9
You can create a cache if cluster in a read-only mode.
See {{CacheCreateDestroyClusterReadOnlyModeTest#testCacheCreateDenied}} test.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13079) Replace deprecated cluster activation methods in tests.
Sergey Antonov created IGNITE-13079:
---
Summary: Replace deprecated cluster activation methods in tests.
Key: IGNITE-13079
URL: https://issues.apache.org/jira/browse/IGNITE-13079
Project: Ignite
Issue Type: Improvement
Reporter: Sergey Antonov
After we IGNITE-12225 we have a new API for a changing cluster state. We must
replace deprecated methods ({{IgniteCluster#active()}},
{{IgniteCluster#active(boolean)}} and etc) to a new API
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13076) Cluster read-only mode doesn't affect LOCAL caches
Sergey Antonov created IGNITE-13076:
---
Summary: Cluster read-only mode doesn't affect LOCAL caches
Key: IGNITE-13076
URL: https://issues.apache.org/jira/browse/IGNITE-13076
Project: Ignite
Issue Type: Bug
Affects Versions: 2.9
Reporter: Sergey Antonov
Fix For: 2.9
You can make data modification operations with LOCAL cache even if cluster in a
{{ACTIVE_READ_ONLY}} state.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13071) Improve test coverage for read-only cluster state
[ https://issues.apache.org/jira/browse/IGNITE-13071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-13071: Description: It would be nice to extend test coverage for this feature. We don't have tests for: * data structures * cache destroy/create * cache clear * DDL requests * Cache updates from task/deployed service * Updates to metastorage/distributed metastorage. was: It would be nice to extend test coverage for this feature. We don't have tests for: * data structures * cache destroy/create * cache clear * DDL requests * Cache updates from task/deployed service > Improve test coverage for read-only cluster state > - > > Key: IGNITE-13071 > URL: https://issues.apache.org/jira/browse/IGNITE-13071 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.9 > > > It would be nice to extend test coverage for this feature. > We don't have tests for: > * data structures > * cache destroy/create > * cache clear > * DDL requests > * Cache updates from task/deployed service > * Updates to metastorage/distributed metastorage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13071) Improve test coverage for read-only cluster state
Sergey Antonov created IGNITE-13071: --- Summary: Improve test coverage for read-only cluster state Key: IGNITE-13071 URL: https://issues.apache.org/jira/browse/IGNITE-13071 Project: Ignite Issue Type: Improvement Reporter: Sergey Antonov Assignee: Sergey Antonov Fix For: 2.9 It would be nice to extend test coverage for this feature. We don't have tests for: * data structures * cache destroy/create * cache clear * DDL requests * Cache updates from task/deployed service -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13047) Ignite node must return Ignition#KILL_EXIT_CODE exit code, if node had stopped by StopNodeFailureHandler or StopNodeOrHaltFailureHandler
Sergey Antonov created IGNITE-13047: --- Summary: Ignite node must return Ignition#KILL_EXIT_CODE exit code, if node had stopped by StopNodeFailureHandler or StopNodeOrHaltFailureHandler Key: IGNITE-13047 URL: https://issues.apache.org/jira/browse/IGNITE-13047 Project: Ignite Issue Type: Improvement Reporter: Sergey Antonov Ignite process must be finished with exit code 130 [1] if the node had stopped by StopNodeFailureHandler or StopNodeOrHaltFailureHanlder. [1] https://ignite.apache.org/releases/latest/javadoc/org/apache/ignite/Ignition.html#KILL_EXIT_CODE -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13004) Fix wrong comparison in TcpCommunicationSpi#closeConnections(UUID)
[
https://issues.apache.org/jira/browse/IGNITE-13004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17106085#comment-17106085
]
Sergey Antonov commented on IGNITE-13004:
-
[~amashenkov] Could you review my changes?
> Fix wrong comparison in TcpCommunicationSpi#closeConnections(UUID)
> --
>
> Key: IGNITE-13004
> URL: https://issues.apache.org/jira/browse/IGNITE-13004
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.9, 2.8.1
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.9
>
>
> In IGNITE-12774 was introduced a bug in comparison:
> {code:java}
> for (ConnectionKey connKey : clientFuts.keySet()) {
> if (!nodeId.equals(connKey))
> continue;
> {code}
> The right code is:
> {code:java}
> for (ConnectionKey connKey : clientFuts.keySet()) {
> if (!nodeId.equals(connKey.nodeId()))
> continue;
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13004) Fix wrong comparison in TcpCommunicationSpi#closeConnections(UUID)
Sergey Antonov created IGNITE-13004:
---
Summary: Fix wrong comparison in
TcpCommunicationSpi#closeConnections(UUID)
Key: IGNITE-13004
URL: https://issues.apache.org/jira/browse/IGNITE-13004
Project: Ignite
Issue Type: Bug
Affects Versions: 2.9, 2.8.1
Reporter: Sergey Antonov
Assignee: Sergey Antonov
Fix For: 2.9
In IGNITE-12774 was introduced a bug in comparison:
{code:java}
for (ConnectionKey connKey : clientFuts.keySet()) {
if (!nodeId.equals(connKey))
continue;
{code}
The right code is:
{code:java}
for (ConnectionKey connKey : clientFuts.keySet()) {
if (!nodeId.equals(connKey.nodeId()))
continue;
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12985) Fix unguarded log.info/log.debug/log.trace usages
[
https://issues.apache.org/jira/browse/IGNITE-12985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17101077#comment-17101077
]
Sergey Antonov commented on IGNITE-12985:
-
[~agoncharuk] Could you review my changes please?
> Fix unguarded log.info/log.debug/log.trace usages
> -
>
> Key: IGNITE-12985
> URL: https://issues.apache.org/jira/browse/IGNITE-12985
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are multiple places in code where
> {{log.info()/log.debug()/log.trace()}} are called without checking {{if
> (log.isInfoEnabled)}}. These leads to polluted logs when INFO/DEBUG/TRACE is
> disabled.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12985) Fix unguarded log.info/log.debug/log.trace usages
[
https://issues.apache.org/jira/browse/IGNITE-12985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-12985:
Description: There are multiple places in code where
{{log.info()/log.debug()/log.trace()}} are called without checking {{if
(log.isInfoEnabled)}}. These leads to polluted logs when INFO/DEBUG/TRACE is
disabled. (was: There are multiple places in code where
{{log.info()/log.debug()/log.trace()}} is called without checking {{if
(log.isInfoEnabled)}}. This leads to polluted logs when INFO/DEBUG/TRACE is
disabled.)
> Fix unguarded log.info/log.debug/log.trace usages
> -
>
> Key: IGNITE-12985
> URL: https://issues.apache.org/jira/browse/IGNITE-12985
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are multiple places in code where
> {{log.info()/log.debug()/log.trace()}} are called without checking {{if
> (log.isInfoEnabled)}}. These leads to polluted logs when INFO/DEBUG/TRACE is
> disabled.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12985) Fix unguarded log.info/log.debug/log.trace usages
[
https://issues.apache.org/jira/browse/IGNITE-12985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-12985:
Ignite Flags: (was: Docs Required,Release Notes Required)
> Fix unguarded log.info/log.debug/log.trace usages
> -
>
> Key: IGNITE-12985
> URL: https://issues.apache.org/jira/browse/IGNITE-12985
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are multiple places in code where
> {{log.info()/log.debug()/log.trace()}} is called without checking {{if
> (log.isInfoEnabled)}}. This leads to polluted logs when INFO/DEBUG/TRACE is
> disabled.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12985) Fix unguarded log.info/log.debug/log.trace usages
Sergey Antonov created IGNITE-12985:
---
Summary: Fix unguarded log.info/log.debug/log.trace usages
Key: IGNITE-12985
URL: https://issues.apache.org/jira/browse/IGNITE-12985
Project: Ignite
Issue Type: Improvement
Reporter: Sergey Antonov
Assignee: Sergey Antonov
There are multiple places in code where {{log.info()/log.debug()/log.trace()}}
is called without checking {{if (log.isInfoEnabled)}}. This leads to polluted
logs when INFO/DEBUG/TRACE is disabled.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12793) Deadlock in the System Pool on Metadata processing
[
https://issues.apache.org/jira/browse/IGNITE-12793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-12793:
Description:
I've recently tried to apply Ilya's idea
(https://issues.apache.org/jira/browse/IGNITE-12663) of minimizing thread pools
and tried to set system pool to 3 in my own tests.
It caused deadlock on a client node and I think it can happen not only on such
small pool values.
Details are following:
I'm not using persistence currently (if it matters).
On the client note I use ignite compute to call a job on every server node
(there are 3 server nodes in the tests).
Then I've found in logs:
{noformat}
[10:55:21] : [Step 1/1] [2020-03-13 10:55:21,773]
grid-timeout-worker-#8
[WARN] [o.a.i.i.IgniteKernal] - Possible thread pool starvation detected (no
task completed in last 3ms, is system thread pool size large enough?)
[10:55:21] : [Step 1/1] ^-- System thread pool [active=3, idle=0, qSize=9]
{noformat}
I see in threaddumps that all 3 system pool workers do the same - processing of
job responses:
{noformat}
"sys-#26" #605 daemon prio=5 os_prio=0 tid=0x64a0a800 nid=0x1f34
waiting on condition [0x7b91d000]
java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:177)
at
org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:140)
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl.metadata(CacheObjectBinaryProcessorImpl.java:749)
at
org.apache.ignite.internal.processors.cache.binary.CacheObjectBinaryProcessorImpl$1.metadata(CacheObjectBinaryProcessorImpl.java:250)
at
org.apache.ignite.internal.binary.BinaryContext.metadata(BinaryContext.java:1169)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.getOrCreateSchema(BinaryReaderExImpl.java:2005)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:285)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.(BinaryReaderExImpl.java:184)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1797)
at
org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:2160)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2091)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1914)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.readField(BinaryReaderExImpl.java:1982)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor$DefaultFinalClassAccessor.read0(BinaryFieldAccessor.java:702)
at
org.apache.ignite.internal.binary.BinaryFieldAccessor.read(BinaryFieldAccessor.java:187)
at
org.apache.ignite.internal.binary.BinaryClassDescriptor.read(BinaryClassDescriptor.java:887)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1762)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadObject(BinaryUtils.java:1797)
at
org.apache.ignite.internal.binary.BinaryUtils.deserializeOrUnmarshal(BinaryUtils.java:2160)
at
org.apache.ignite.internal.binary.BinaryUtils.doReadCollection(BinaryUtils.java:2091)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1914)
at
org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1714)
at
org.apache.ignite.internal.binary.GridBinaryMarshaller.deserialize(GridBinaryMarshaller.java:306)
at
org.apache.ignite.internal.binary.BinaryMarshaller.unmarshal0(BinaryMarshaller.java:100)
at
org.apache.ignite.marshaller.AbstractNodeNameAwareMarshaller.unmarshal(AbstractNodeNameAwareMarshaller.java:80)
at
org.apache.ignite.internal.util.IgniteUtils.unmarshal(IgniteUtils.java:10493)
at
org.apache.ignite.internal.processors.task.GridTaskWorker.onResponse(GridTaskWorker.java:828)
at
org.apache.ignite.internal.processors.task.GridTaskProcessor.processJobExecuteResponse(GridTaskProcessor.java:1134)
{noformat}
As I found analyzing this stack trace, unmarshalling a user object the first
time(per type) causes Binary metadata request (despite I've registered this
type in BinaryConfiguration.setTypeConfiguration)
And all this futures will be completed after consequent MetadataResponseMessage
will be received and processed on the client node. But
MetadataResponseMessage(GridTopic.TOPIC_METADATA_REQ) is also processing in
system pool. (I see that method GridIoManager#processRegularMessage routes it
to the System Pool).
So it causes deadlock
[jira] [Created] (IGNITE-12955) Document a new command control.sh --cache check_index_inline_sizes
Sergey Antonov created IGNITE-12955: --- Summary: Document a new command control.sh --cache check_index_inline_sizes Key: IGNITE-12955 URL: https://issues.apache.org/jira/browse/IGNITE-12955 Project: Ignite Issue Type: New Feature Components: documentation Reporter: Sergey Antonov Fix For: 2.9 Please look at IGNITE-12942 and devlist discussion linked to IGNITE-12942 for all information. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12942) control.sh add command for checking that inline size is same on all cluster nodes
[ https://issues.apache.org/jira/browse/IGNITE-12942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-12942: Release Note: Added "--cache check_index_inline_sizes" command to control utility. The command checks that indexes inline size the same on all cluster nodes. The command could be useful for analyzing performance problems with SQL queries. > control.sh add command for checking that inline size is same on all cluster > nodes > - > > Key: IGNITE-12942 > URL: https://issues.apache.org/jira/browse/IGNITE-12942 > Project: Ignite > Issue Type: New Feature >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > We should check that the inline size is the same for the index on all nodes > in the cluster. > 1. Check inline_size of secondary indexes on node join. Warn to log if they > differ and propose a recreate problem index. > 2. Introduce a new command to control.sh (control.sh --cache > check_index_inline_sizes). The command will check inline sizes of secondary > indexes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12942) control.sh add command for checking that inline size is same on all cluster nodes
Sergey Antonov created IGNITE-12942: --- Summary: control.sh add command for checking that inline size is same on all cluster nodes Key: IGNITE-12942 URL: https://issues.apache.org/jira/browse/IGNITE-12942 Project: Ignite Issue Type: New Feature Reporter: Sergey Antonov Assignee: Sergey Antonov Fix For: 2.9 We should check that the inline size is the same for the index on all nodes in the cluster. 1. Check inline_size of secondary indexes on node join. Warn to log if they differ and propose a recreate problem index. 2. Introduce a new command to control.sh (control.sh --cache check_index_inline_sizes). The command will check inline sizes of secondary indexes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-8717) Move persisted cache configuration to metastore and introduce cache configuration versioning
[ https://issues.apache.org/jira/browse/IGNITE-8717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov reassigned IGNITE-8717: -- Assignee: (was: Sergey Antonov) > Move persisted cache configuration to metastore and introduce cache > configuration versioning > > > Key: IGNITE-8717 > URL: https://issues.apache.org/jira/browse/IGNITE-8717 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently, we persist cache configuration to local files which resulted in > several inconsistencies when a node misses configuration update (create > index, cache destroy, etc). > I think the cache configuration should be saved to the metastore the same way > as baseline topology is saved. Same mechanics should be used for conflicting > configuration updates resolution. > Along with cache configuration, it also makes sense to move marshaller and > binary metadata to the metastore. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12710) Extension log in rebuild indexes to search problems
[ https://issues.apache.org/jira/browse/IGNITE-12710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071748#comment-17071748 ] Sergey Antonov commented on IGNITE-12710: - [~amashenkov] Fixed. Please take a look again! > Extension log in rebuild indexes to search problems > --- > > Key: IGNITE-12710 > URL: https://issues.apache.org/jira/browse/IGNITE-12710 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.9 > > Time Spent: 40m > Remaining Estimate: 0h > > We should have the ability to get extended information about rebuild indexes: > cache, cache id, cache group, cache group id, index name, index type, index > size. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12845) GridNioServer can infinitely lose some events
[
https://issues.apache.org/jira/browse/IGNITE-12845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17071590#comment-17071590
]
Sergey Antonov commented on IGNITE-12845:
-
[~alex_pl] I didn't find any {{Set#contains(Object)}} usages in
{{sun.nio.ch.SelectorImpl}} in jdk8 (1.8.0_191).
> GridNioServer can infinitely lose some events
> --
>
> Key: IGNITE-12845
> URL: https://issues.apache.org/jira/browse/IGNITE-12845
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Priority: Major
>
> With enabled optimization (IGNITE_NO_SELECTOR_OPTS = false, by default)
> {{GridNioServer}} can lose some events for a channel (depending on JDK
> version and OS). It can lead to connected applications hang. Reproducer:
> {code:java}
> public void testConcurrentLoad() throws Exception {
> startGrid(0);
> try (IgniteClient client = Ignition.startClient(new
> ClientConfiguration().setAddresses("127.0.0.1:10800"))) {
> ClientCache cache =
> client.getOrCreateCache(DEFAULT_CACHE_NAME);
> GridTestUtils.runMultiThreaded(
> () -> {
> for (int i = 0; i < 1000; i++)
> cache.put(i, i);
> }, 5, "run-async");
> }
> }
> {code}
> This reproducer hangs eventually on MacOS (tested with JDK 8, 11, 12, 13,
> 14), hangs on some Linux environments (for example passed more than 100 times
> on desktop Linux system with JDK 8, but hangs on team-city agents with JDK 8,
> 11) and never hanged (passed more than 100 times) on windows system, but
> passes on all systems and JDK versions when system property
> {{IGNITE_NO_SELECTOR_OPTS = true}} is set.
>
> The root cause: optimized {{SelectedSelectionKeySet}} always returns
> {{false}} for {{contains()}} method. The {{contains()}} method used by
> {{sun.nio.ch.SelectorImpl.processReadyEvents()}} method:
> {code:java}
> if (selectedKeys.contains(ski)) {
> if (ski.translateAndUpdateReadyOps(rOps)) {
> return 1;
> }
> } else {
> ski.translateAndSetReadyOps(rOps);
> if ((ski.nioReadyOps() & ski.nioInterestOps()) != 0) {
> selectedKeys.add(ski);
> return 1;
> }
> }
> {code}
> So, for fair implementation, if a selection key is contained in the selected
> keys set, then ready operations flags are updated, but for
> {{SelectedSelectionKeySet}} ready operations flags will be always overridden
> and new selector key will be added even if it's already contained in the set.
> Some {{SelectorImpl}} implementations can pass several events for one
> selector key to {{processReadyEvents}} method (for example, MacOs
> implementation {{KQueueSelectorImpl}} works in such a way). In this case,
> duplicated selector keys will be added to {{selectedKeys}} and all events
> except last will be lost.
> Two bad things happen in {{GridNioServer}} due to described above reasons:
> # Some event flags are lost and the worker doesn't process corresponding
> action (for attached reproducer "channel is ready for reading" event is lost
> and the workers never read the channel after some point in time).
> # Duplicated selector keys with the same event flags (for attached
> reproducer it's "channel is ready for writing" event, this duplication leads
> to wrong processing of {{GridSelectorNioSessionImpl#procWrite}} flag, which
> will be {{false}} in some cases, but at the same time selector key's
> {{interestedOps}} will contain {{OP_WRITE}} operation and this operation
> never be excluded)
> Possible solutions:
> * Fair implementation of {{SelectedSelectionKeySet.contains}} method (this
> will solve all problems but can be resource consuming)
> * Always set {{GridSelectorNioSessionImpl#procWrite}} to {{true}} when
> adding {{OP_WRITE}} to {{interestedOps}} (for example in
> {{AbstractNioClientWorker.registerWrite()}} method). In this case, some
> "channel is ready for reading" events (but not data) still can be lost, but
> not infinitely, and eventually data will be read.
> * Exclude {{OP_WRITE}} from {{interestedOps}} even if
> {{GridSelectorNioSessionImpl#procWrite}} is {{false}} when there are no write
> requests in the queue (see {{GridNioServer.stopPollingForWrite()}} method).
> This solution has the same shortcomings as the previous one.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12710) Extension log in rebuild indexes to search problems
[ https://issues.apache.org/jira/browse/IGNITE-12710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17069111#comment-17069111 ] Sergey Antonov commented on IGNITE-12710: - [~amashenkov] I fixed your comments. Can you review the changes again please? > Extension log in rebuild indexes to search problems > --- > > Key: IGNITE-12710 > URL: https://issues.apache.org/jira/browse/IGNITE-12710 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.9 > > Time Spent: 20m > Remaining Estimate: 0h > > We should have the ability to get extended information about rebuild indexes: > cache, cache id, cache group, cache group id, index name, index type, index > size. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12831) Invoking destroy of local cache on one node destroys local caches with the same name on all other nodes
[
https://issues.apache.org/jira/browse/IGNITE-12831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066904#comment-17066904
]
Sergey Antonov edited comment on IGNITE-12831 at 3/25/20, 5:35 PM:
---
[~shishkovilja]
{quote}Expected behaviour: local cache should be destroyed only on the node
invoking destroy.{quote}
Your expectation is not valid. Look at the documentation [1]:
LOCAL mode is the most light weight mode of cache operation, as no data is
distributed to other cache nodes. It is ideal for scenarios where data is
either read-only, or can be periodically refreshed at some expiration
frequency. It also works very well with read-through behavior where data is
loaded from persistent storage on misses. *Other than distribution, local
caches still have all the features of a distributed cache, such as automatic
data eviction, expiration, disk swapping, data querying, and transactions.*
If you want to change that behavior please start a discussion on the dev list.
[1] https://apacheignite.readme.io/docs/cache-modes#local-mode
was (Author: antonovsergey93):
[~shishkovilja]
{quote}Expected behaviour: local cache should be destroyed only on the node
invoking destroy.{quote}
Your expectation is not valid. Look at the documentation [1]:
LOCAL mode is the most light weight mode of cache operation, as no data is
distributed to other cache nodes. It is ideal for scenarios where data is
either read-only, or can be periodically refreshed at some expiration
frequency. It also works very well with read-through behavior where data is
loaded from persistent storage on misses.* Other than distribution, local
caches still have all the features of a distributed cache, such as automatic
data eviction, expiration, disk swapping, data querying, and transactions.*
If you want to change that behavior please start a discussion on the dev list.
[1] https://apacheignite.readme.io/docs/cache-modes#local-mode
> Invoking destroy of local cache on one node destroys local caches with the
> same name on all other nodes
> ---
>
> Key: IGNITE-12831
> URL: https://issues.apache.org/jira/browse/IGNITE-12831
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8, 2.7.6
>Reporter: Ilya Shishkov
>Priority: Major
> Attachments: MyLocalCacheDestroyReproducer.java
>
>
> If you create caches with cache mode CacheMode.LOCAL and same name, but on
> different nodes, then all those caches will be destroyed after invoking
> destroy of cache on one of the cluster nodes.
> Expected behaviour: local cache should be destroyed only on the node invoking
> destroy.
> Reproducer in attachment.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12831) Invoking destroy of local cache on one node destroys local caches with the same name on all other nodes
[
https://issues.apache.org/jira/browse/IGNITE-12831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17066904#comment-17066904
]
Sergey Antonov commented on IGNITE-12831:
-
[~shishkovilja]
{quote}Expected behaviour: local cache should be destroyed only on the node
invoking destroy.{quote}
Your expectation is not valid. Look at the documentation [1]:
LOCAL mode is the most light weight mode of cache operation, as no data is
distributed to other cache nodes. It is ideal for scenarios where data is
either read-only, or can be periodically refreshed at some expiration
frequency. It also works very well with read-through behavior where data is
loaded from persistent storage on misses.* Other than distribution, local
caches still have all the features of a distributed cache, such as automatic
data eviction, expiration, disk swapping, data querying, and transactions.*
If you want to change that behavior please start a discussion on the dev list.
[1] https://apacheignite.readme.io/docs/cache-modes#local-mode
> Invoking destroy of local cache on one node destroys local caches with the
> same name on all other nodes
> ---
>
> Key: IGNITE-12831
> URL: https://issues.apache.org/jira/browse/IGNITE-12831
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8, 2.7.6
>Reporter: Ilya Shishkov
>Priority: Major
> Attachments: MyLocalCacheDestroyReproducer.java
>
>
> If you create caches with cache mode CacheMode.LOCAL and same name, but on
> different nodes, then all those caches will be destroyed after invoking
> destroy of cache on one of the cluster nodes.
> Expected behaviour: local cache should be destroyed only on the node invoking
> destroy.
> Reproducer in attachment.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12774) Transaction hangs after too many open files NIO exception
[
https://issues.apache.org/jira/browse/IGNITE-12774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17062452#comment-17062452
]
Sergey Antonov commented on IGNITE-12774:
-
[~agoncharuk] No, I don't. But I created ticket IGNITE-12803 for investigation.
> Transaction hangs after too many open files NIO exception
> -
>
> Key: IGNITE-12774
> URL: https://issues.apache.org/jira/browse/IGNITE-12774
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Transaction hung after “Open too many files” error and never been finished.
> {code:java}
> import java.net.SocketException;
> import java.util.concurrent.atomic.AtomicBoolean;
> import org.apache.ignite.cluster.ClusterNode;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.failure.StopNodeOrHaltFailureHandler;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.lang.IgniteInClosure;
> import org.apache.ignite.plugin.extensions.communication.Message;
> import org.apache.ignite.spi.IgniteSpiException;
> import org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import org.apache.ignite.transactions.Transaction;
> import org.apache.ignite.transactions.TransactionConcurrency;
> import org.apache.ignite.transactions.TransactionIsolation;
> import static org.apache.ignite.cache.CacheAtomicityMode.TRANSACTIONAL;
> import static org.apache.ignite.cache.CacheMode.PARTITIONED;
> public class TooManyOpenFilesTest extends GridCommonAbstractTest {
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> return super.getConfiguration(igniteInstanceName)
> .setFailureHandler(new StopNodeOrHaltFailureHandler())
> .setCommunicationSpi(new TooManyOpenFilesTcpCommunicationSpi())
> .setConsistentId(igniteInstanceName);
> }
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> stopAllGrids();
> cleanPersistenceDir();
> }
> @Override protected void afterTest() throws Exception {
> stopAllGrids();
> cleanPersistenceDir();
> super.afterTest();
> }
> public void test() throws Exception {
> IgniteEx crd = startGrids(3);
> crd.cluster().active(true);
> crd.getOrCreateCache(new
> CacheConfiguration<>().setName(DEFAULT_CACHE_NAME).setAtomicityMode(TRANSACTIONAL).setBackups(1).setCacheMode(PARTITIONED));
> TooManyOpenFilesTcpCommunicationSpi spi =
> (TooManyOpenFilesTcpCommunicationSpi)grid(2).context().config().getCommunicationSpi();
> try (Transaction tx =
> grid(1).transactions().txStart(TransactionConcurrency.PESSIMISTIC,
> TransactionIsolation.REPEATABLE_READ)) {
> IgniteCache cache =
> grid(1).cache(DEFAULT_CACHE_NAME);
> cache.put(1, 1);
> spi.throwException.set(true);
> cache.put(2, 2);
> cache.put(3, 2);
> cache.put(4, 2);
> // hungs here.
> tx.commit();
> }
> for (int i=0; i < 3 ; i++) {
> assertEquals(1, grid(i).cache(DEFAULT_CACHE_NAME).get(1));
> assertEquals(2, grid(i).cache(DEFAULT_CACHE_NAME).get(2));
> }
> }
> private static class TooManyOpenFilesTcpCommunicationSpi extends
> TcpCommunicationSpi {
> private final AtomicBoolean throwException = new AtomicBoolean();
> /** {@inheritDoc} */
> @Override public void sendMessage(ClusterNode node, Message msg)
> throws IgniteSpiException {
> if (throwException.get())
> throw getException(node);
> super.sendMessage(node, msg);
> }
> /** {@inheritDoc} */
> @Override public void sendMessage(
> ClusterNode node,
> Message msg,
> IgniteInClosure ackC
> ) throws IgniteSpiException {
> if (throwException.get())
> throw getException(node);
> super.sendMessage(node, msg, ackC);
> }
> private IgniteSpiException getException(ClusterNode node) {
> String checkedExceptionMsg = "Failed to connect to node (is node
> still alive?). " +
> "Make sure that each ComputeTask and cache Transaction has a
> timeout set " +
> "in order to prevent parties from waiting forever in case of
> network issues " +
> "[nodeId=" + node.id() + ", addrs=null]";
>
[jira] [Updated] (IGNITE-12803) Investigate exception message on too many open files in different OS.
[ https://issues.apache.org/jira/browse/IGNITE-12803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-12803: Environment: (was: In IGNITE-12774 we introduced node failing if we got "too many open files" during open connection. I'm not sure that in all OS we will get that message. We need to investigate it.) > Investigate exception message on too many open files in different OS. > - > > Key: IGNITE-12803 > URL: https://issues.apache.org/jira/browse/IGNITE-12803 > Project: Ignite > Issue Type: Task >Reporter: Sergey Antonov >Priority: Major > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12803) Investigate exception message on too many open files in different OS.
[ https://issues.apache.org/jira/browse/IGNITE-12803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-12803: Description: In IGNITE-12774 we introduced node failing if we got "too many open files" during open connection. I'm not sure that in all OS we will get that message. We need to investigate it. > Investigate exception message on too many open files in different OS. > - > > Key: IGNITE-12803 > URL: https://issues.apache.org/jira/browse/IGNITE-12803 > Project: Ignite > Issue Type: Task >Reporter: Sergey Antonov >Priority: Major > > In IGNITE-12774 we introduced node failing if we got "too many open files" > during open connection. I'm not sure that in all OS we will get that message. > We need to investigate it. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12803) Investigate exception message on too many open files in different OS.
Sergey Antonov created IGNITE-12803: --- Summary: Investigate exception message on too many open files in different OS. Key: IGNITE-12803 URL: https://issues.apache.org/jira/browse/IGNITE-12803 Project: Ignite Issue Type: Task Environment: In IGNITE-12774 we introduced node failing if we got "too many open files" during open connection. I'm not sure that in all OS we will get that message. We need to investigate it. Reporter: Sergey Antonov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12761) Add ability to disable check crc sums of stored pages due to invalidate_indexes.
[ https://issues.apache.org/jira/browse/IGNITE-12761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-12761: Fix Version/s: 2.9 > Add ability to disable check crc sums of stored pages due to > invalidate_indexes. > > > Key: IGNITE-12761 > URL: https://issues.apache.org/jira/browse/IGNITE-12761 > Project: Ignite > Issue Type: Bug >Reporter: Philipp Masharov >Assignee: Philipp Masharov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Add additional param to validate_indexes command > org.apache.ignite.internal.commandline.cache.CacheSubcommands#VALIDATE_INDEXES*like > here: > org.apache.ignite.internal.commandline.cache.argument.IdleVerifyCommandArg#CHECK_CRC > now by default this check is always enabled, need to be configurable like the > same one in IdleVerifyCommandArg -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12774) Transaction hangs after too many open files NIO exception
[
https://issues.apache.org/jira/browse/IGNITE-12774?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17057570#comment-17057570
]
Sergey Antonov commented on IGNITE-12774:
-
[~akalashnikov] Could you review my changes please?
> Transaction hangs after too many open files NIO exception
> -
>
> Key: IGNITE-12774
> URL: https://issues.apache.org/jira/browse/IGNITE-12774
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Transaction hung after “Open too many files” error and never been finished.
> {code:java}
> import java.net.SocketException;
> import java.util.concurrent.atomic.AtomicBoolean;
> import org.apache.ignite.cluster.ClusterNode;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.failure.StopNodeOrHaltFailureHandler;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.lang.IgniteInClosure;
> import org.apache.ignite.plugin.extensions.communication.Message;
> import org.apache.ignite.spi.IgniteSpiException;
> import org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import org.apache.ignite.transactions.Transaction;
> import org.apache.ignite.transactions.TransactionConcurrency;
> import org.apache.ignite.transactions.TransactionIsolation;
> import static org.apache.ignite.cache.CacheAtomicityMode.TRANSACTIONAL;
> import static org.apache.ignite.cache.CacheMode.PARTITIONED;
> public class TooManyOpenFilesTest extends GridCommonAbstractTest {
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> return super.getConfiguration(igniteInstanceName)
> .setFailureHandler(new StopNodeOrHaltFailureHandler())
> .setCommunicationSpi(new TooManyOpenFilesTcpCommunicationSpi())
> .setConsistentId(igniteInstanceName);
> }
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> stopAllGrids();
> cleanPersistenceDir();
> }
> @Override protected void afterTest() throws Exception {
> stopAllGrids();
> cleanPersistenceDir();
> super.afterTest();
> }
> public void test() throws Exception {
> IgniteEx crd = startGrids(3);
> crd.cluster().active(true);
> crd.getOrCreateCache(new
> CacheConfiguration<>().setName(DEFAULT_CACHE_NAME).setAtomicityMode(TRANSACTIONAL).setBackups(1).setCacheMode(PARTITIONED));
> TooManyOpenFilesTcpCommunicationSpi spi =
> (TooManyOpenFilesTcpCommunicationSpi)grid(2).context().config().getCommunicationSpi();
> try (Transaction tx =
> grid(1).transactions().txStart(TransactionConcurrency.PESSIMISTIC,
> TransactionIsolation.REPEATABLE_READ)) {
> IgniteCache cache =
> grid(1).cache(DEFAULT_CACHE_NAME);
> cache.put(1, 1);
> spi.throwException.set(true);
> cache.put(2, 2);
> cache.put(3, 2);
> cache.put(4, 2);
> // hungs here.
> tx.commit();
> }
> for (int i=0; i < 3 ; i++) {
> assertEquals(1, grid(i).cache(DEFAULT_CACHE_NAME).get(1));
> assertEquals(2, grid(i).cache(DEFAULT_CACHE_NAME).get(2));
> }
> }
> private static class TooManyOpenFilesTcpCommunicationSpi extends
> TcpCommunicationSpi {
> private final AtomicBoolean throwException = new AtomicBoolean();
> /** {@inheritDoc} */
> @Override public void sendMessage(ClusterNode node, Message msg)
> throws IgniteSpiException {
> if (throwException.get())
> throw getException(node);
> super.sendMessage(node, msg);
> }
> /** {@inheritDoc} */
> @Override public void sendMessage(
> ClusterNode node,
> Message msg,
> IgniteInClosure ackC
> ) throws IgniteSpiException {
> if (throwException.get())
> throw getException(node);
> super.sendMessage(node, msg, ackC);
> }
> private IgniteSpiException getException(ClusterNode node) {
> String checkedExceptionMsg = "Failed to connect to node (is node
> still alive?). " +
> "Make sure that each ComputeTask and cache Transaction has a
> timeout set " +
> "in order to prevent parties from waiting forever in case of
> network issues " +
> "[nodeId=" + node.id() + ", addrs=null]";
> return new
[jira] [Updated] (IGNITE-12774) Transaction hangs after too many open files NIO exception
[
https://issues.apache.org/jira/browse/IGNITE-12774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-12774:
Fix Version/s: 2.9
> Transaction hangs after too many open files NIO exception
> -
>
> Key: IGNITE-12774
> URL: https://issues.apache.org/jira/browse/IGNITE-12774
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Transaction hung after “Open too many files” error and never been finished.
> {code:java}
> import java.net.SocketException;
> import java.util.concurrent.atomic.AtomicBoolean;
> import org.apache.ignite.cluster.ClusterNode;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.failure.StopNodeOrHaltFailureHandler;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.lang.IgniteInClosure;
> import org.apache.ignite.plugin.extensions.communication.Message;
> import org.apache.ignite.spi.IgniteSpiException;
> import org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import org.apache.ignite.transactions.Transaction;
> import org.apache.ignite.transactions.TransactionConcurrency;
> import org.apache.ignite.transactions.TransactionIsolation;
> import static org.apache.ignite.cache.CacheAtomicityMode.TRANSACTIONAL;
> import static org.apache.ignite.cache.CacheMode.PARTITIONED;
> public class TooManyOpenFilesTest extends GridCommonAbstractTest {
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> return super.getConfiguration(igniteInstanceName)
> .setFailureHandler(new StopNodeOrHaltFailureHandler())
> .setCommunicationSpi(new TooManyOpenFilesTcpCommunicationSpi())
> .setConsistentId(igniteInstanceName);
> }
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> stopAllGrids();
> cleanPersistenceDir();
> }
> @Override protected void afterTest() throws Exception {
> stopAllGrids();
> cleanPersistenceDir();
> super.afterTest();
> }
> public void test() throws Exception {
> IgniteEx crd = startGrids(3);
> crd.cluster().active(true);
> crd.getOrCreateCache(new
> CacheConfiguration<>().setName(DEFAULT_CACHE_NAME).setAtomicityMode(TRANSACTIONAL).setBackups(1).setCacheMode(PARTITIONED));
> TooManyOpenFilesTcpCommunicationSpi spi =
> (TooManyOpenFilesTcpCommunicationSpi)grid(2).context().config().getCommunicationSpi();
> try (Transaction tx =
> grid(1).transactions().txStart(TransactionConcurrency.PESSIMISTIC,
> TransactionIsolation.REPEATABLE_READ)) {
> IgniteCache cache =
> grid(1).cache(DEFAULT_CACHE_NAME);
> cache.put(1, 1);
> spi.throwException.set(true);
> cache.put(2, 2);
> cache.put(3, 2);
> cache.put(4, 2);
> // hungs here.
> tx.commit();
> }
> for (int i=0; i < 3 ; i++) {
> assertEquals(1, grid(i).cache(DEFAULT_CACHE_NAME).get(1));
> assertEquals(2, grid(i).cache(DEFAULT_CACHE_NAME).get(2));
> }
> }
> private static class TooManyOpenFilesTcpCommunicationSpi extends
> TcpCommunicationSpi {
> private final AtomicBoolean throwException = new AtomicBoolean();
> /** {@inheritDoc} */
> @Override public void sendMessage(ClusterNode node, Message msg)
> throws IgniteSpiException {
> if (throwException.get())
> throw getException(node);
> super.sendMessage(node, msg);
> }
> /** {@inheritDoc} */
> @Override public void sendMessage(
> ClusterNode node,
> Message msg,
> IgniteInClosure ackC
> ) throws IgniteSpiException {
> if (throwException.get())
> throw getException(node);
> super.sendMessage(node, msg, ackC);
> }
> private IgniteSpiException getException(ClusterNode node) {
> String checkedExceptionMsg = "Failed to connect to node (is node
> still alive?). " +
> "Make sure that each ComputeTask and cache Transaction has a
> timeout set " +
> "in order to prevent parties from waiting forever in case of
> network issues " +
> "[nodeId=" + node.id() + ", addrs=null]";
> return new IgniteSpiException("Failed to send message to remote
> node: " + node.id(), new
[jira] [Updated] (IGNITE-12774) Transaction hangs after too many open files NIO exception
[
https://issues.apache.org/jira/browse/IGNITE-12774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-12774:
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Transaction hangs after too many open files NIO exception
> -
>
> Key: IGNITE-12774
> URL: https://issues.apache.org/jira/browse/IGNITE-12774
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Transaction hung after “Open too many files” error and never been finished.
> {code:java}
> import java.net.SocketException;
> import java.util.concurrent.atomic.AtomicBoolean;
> import org.apache.ignite.cluster.ClusterNode;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.failure.StopNodeOrHaltFailureHandler;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.lang.IgniteInClosure;
> import org.apache.ignite.plugin.extensions.communication.Message;
> import org.apache.ignite.spi.IgniteSpiException;
> import org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import org.apache.ignite.transactions.Transaction;
> import org.apache.ignite.transactions.TransactionConcurrency;
> import org.apache.ignite.transactions.TransactionIsolation;
> import static org.apache.ignite.cache.CacheAtomicityMode.TRANSACTIONAL;
> import static org.apache.ignite.cache.CacheMode.PARTITIONED;
> public class TooManyOpenFilesTest extends GridCommonAbstractTest {
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> return super.getConfiguration(igniteInstanceName)
> .setFailureHandler(new StopNodeOrHaltFailureHandler())
> .setCommunicationSpi(new TooManyOpenFilesTcpCommunicationSpi())
> .setConsistentId(igniteInstanceName);
> }
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> stopAllGrids();
> cleanPersistenceDir();
> }
> @Override protected void afterTest() throws Exception {
> stopAllGrids();
> cleanPersistenceDir();
> super.afterTest();
> }
> public void test() throws Exception {
> IgniteEx crd = startGrids(3);
> crd.cluster().active(true);
> crd.getOrCreateCache(new
> CacheConfiguration<>().setName(DEFAULT_CACHE_NAME).setAtomicityMode(TRANSACTIONAL).setBackups(1).setCacheMode(PARTITIONED));
> TooManyOpenFilesTcpCommunicationSpi spi =
> (TooManyOpenFilesTcpCommunicationSpi)grid(2).context().config().getCommunicationSpi();
> try (Transaction tx =
> grid(1).transactions().txStart(TransactionConcurrency.PESSIMISTIC,
> TransactionIsolation.REPEATABLE_READ)) {
> IgniteCache cache =
> grid(1).cache(DEFAULT_CACHE_NAME);
> cache.put(1, 1);
> spi.throwException.set(true);
> cache.put(2, 2);
> cache.put(3, 2);
> cache.put(4, 2);
> // hungs here.
> tx.commit();
> }
> for (int i=0; i < 3 ; i++) {
> assertEquals(1, grid(i).cache(DEFAULT_CACHE_NAME).get(1));
> assertEquals(2, grid(i).cache(DEFAULT_CACHE_NAME).get(2));
> }
> }
> private static class TooManyOpenFilesTcpCommunicationSpi extends
> TcpCommunicationSpi {
> private final AtomicBoolean throwException = new AtomicBoolean();
> /** {@inheritDoc} */
> @Override public void sendMessage(ClusterNode node, Message msg)
> throws IgniteSpiException {
> if (throwException.get())
> throw getException(node);
> super.sendMessage(node, msg);
> }
> /** {@inheritDoc} */
> @Override public void sendMessage(
> ClusterNode node,
> Message msg,
> IgniteInClosure ackC
> ) throws IgniteSpiException {
> if (throwException.get())
> throw getException(node);
> super.sendMessage(node, msg, ackC);
> }
> private IgniteSpiException getException(ClusterNode node) {
> String checkedExceptionMsg = "Failed to connect to node (is node
> still alive?). " +
> "Make sure that each ComputeTask and cache Transaction has a
> timeout set " +
> "in order to prevent parties from waiting forever in case of
> network issues " +
> "[nodeId=" + node.id() + ", addrs=null]";
> return new IgniteSpiException("Failed to send message to
[jira] [Updated] (IGNITE-12774) Transaction hangs after too many open files NIO exception
[
https://issues.apache.org/jira/browse/IGNITE-12774?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-12774:
Summary: Transaction hangs after too many open files NIO exception (was:
Transaction hungs after too many open files NIO exception)
> Transaction hangs after too many open files NIO exception
> -
>
> Key: IGNITE-12774
> URL: https://issues.apache.org/jira/browse/IGNITE-12774
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
>
> Transaction hung after “Open too many files” error and never been finished.
> {code:java}
> import java.net.SocketException;
> import java.util.concurrent.atomic.AtomicBoolean;
> import org.apache.ignite.cluster.ClusterNode;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.failure.StopNodeOrHaltFailureHandler;
> import org.apache.ignite.internal.IgniteEx;
> import org.apache.ignite.lang.IgniteInClosure;
> import org.apache.ignite.plugin.extensions.communication.Message;
> import org.apache.ignite.spi.IgniteSpiException;
> import org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi;
> import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
> import org.apache.ignite.transactions.Transaction;
> import org.apache.ignite.transactions.TransactionConcurrency;
> import org.apache.ignite.transactions.TransactionIsolation;
> import static org.apache.ignite.cache.CacheAtomicityMode.TRANSACTIONAL;
> import static org.apache.ignite.cache.CacheMode.PARTITIONED;
> public class TooManyOpenFilesTest extends GridCommonAbstractTest {
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> return super.getConfiguration(igniteInstanceName)
> .setFailureHandler(new StopNodeOrHaltFailureHandler())
> .setCommunicationSpi(new TooManyOpenFilesTcpCommunicationSpi())
> .setConsistentId(igniteInstanceName);
> }
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> stopAllGrids();
> cleanPersistenceDir();
> }
> @Override protected void afterTest() throws Exception {
> stopAllGrids();
> cleanPersistenceDir();
> super.afterTest();
> }
> public void test() throws Exception {
> IgniteEx crd = startGrids(3);
> crd.cluster().active(true);
> crd.getOrCreateCache(new
> CacheConfiguration<>().setName(DEFAULT_CACHE_NAME).setAtomicityMode(TRANSACTIONAL).setBackups(1).setCacheMode(PARTITIONED));
> TooManyOpenFilesTcpCommunicationSpi spi =
> (TooManyOpenFilesTcpCommunicationSpi)grid(2).context().config().getCommunicationSpi();
> try (Transaction tx =
> grid(1).transactions().txStart(TransactionConcurrency.PESSIMISTIC,
> TransactionIsolation.REPEATABLE_READ)) {
> IgniteCache cache =
> grid(1).cache(DEFAULT_CACHE_NAME);
> cache.put(1, 1);
> spi.throwException.set(true);
> cache.put(2, 2);
> cache.put(3, 2);
> cache.put(4, 2);
> // hungs here.
> tx.commit();
> }
> for (int i=0; i < 3 ; i++) {
> assertEquals(1, grid(i).cache(DEFAULT_CACHE_NAME).get(1));
> assertEquals(2, grid(i).cache(DEFAULT_CACHE_NAME).get(2));
> }
> }
> private static class TooManyOpenFilesTcpCommunicationSpi extends
> TcpCommunicationSpi {
> private final AtomicBoolean throwException = new AtomicBoolean();
> /** {@inheritDoc} */
> @Override public void sendMessage(ClusterNode node, Message msg)
> throws IgniteSpiException {
> if (throwException.get())
> throw getException(node);
> super.sendMessage(node, msg);
> }
> /** {@inheritDoc} */
> @Override public void sendMessage(
> ClusterNode node,
> Message msg,
> IgniteInClosure ackC
> ) throws IgniteSpiException {
> if (throwException.get())
> throw getException(node);
> super.sendMessage(node, msg, ackC);
> }
> private IgniteSpiException getException(ClusterNode node) {
> String checkedExceptionMsg = "Failed to connect to node (is node
> still alive?). " +
> "Make sure that each ComputeTask and cache Transaction has a
> timeout set " +
> "in order to prevent parties from waiting forever in case of
> network issues " +
> "[nodeId=" + node.id() + ", addrs=null]";
> return new IgniteSpiException("Failed to send message to
[jira] [Created] (IGNITE-12774) Transaction hungs after too many open files NIO exception
Sergey Antonov created IGNITE-12774:
---
Summary: Transaction hungs after too many open files NIO exception
Key: IGNITE-12774
URL: https://issues.apache.org/jira/browse/IGNITE-12774
Project: Ignite
Issue Type: Bug
Reporter: Sergey Antonov
Assignee: Sergey Antonov
Transaction hung after “Open too many files” error and never been finished.
{code:java}
import java.net.SocketException;
import java.util.concurrent.atomic.AtomicBoolean;
import org.apache.ignite.cluster.ClusterNode;
import org.apache.ignite.configuration.CacheConfiguration;
import org.apache.ignite.configuration.IgniteConfiguration;
import org.apache.ignite.failure.StopNodeOrHaltFailureHandler;
import org.apache.ignite.internal.IgniteEx;
import org.apache.ignite.lang.IgniteInClosure;
import org.apache.ignite.plugin.extensions.communication.Message;
import org.apache.ignite.spi.IgniteSpiException;
import org.apache.ignite.spi.communication.tcp.TcpCommunicationSpi;
import org.apache.ignite.testframework.junits.common.GridCommonAbstractTest;
import org.apache.ignite.transactions.Transaction;
import org.apache.ignite.transactions.TransactionConcurrency;
import org.apache.ignite.transactions.TransactionIsolation;
import static org.apache.ignite.cache.CacheAtomicityMode.TRANSACTIONAL;
import static org.apache.ignite.cache.CacheMode.PARTITIONED;
public class TooManyOpenFilesTest extends GridCommonAbstractTest {
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
return super.getConfiguration(igniteInstanceName)
.setFailureHandler(new StopNodeOrHaltFailureHandler())
.setCommunicationSpi(new TooManyOpenFilesTcpCommunicationSpi())
.setConsistentId(igniteInstanceName);
}
@Override protected void beforeTest() throws Exception {
super.beforeTest();
stopAllGrids();
cleanPersistenceDir();
}
@Override protected void afterTest() throws Exception {
stopAllGrids();
cleanPersistenceDir();
super.afterTest();
}
public void test() throws Exception {
IgniteEx crd = startGrids(3);
crd.cluster().active(true);
crd.getOrCreateCache(new
CacheConfiguration<>().setName(DEFAULT_CACHE_NAME).setAtomicityMode(TRANSACTIONAL).setBackups(1).setCacheMode(PARTITIONED));
TooManyOpenFilesTcpCommunicationSpi spi =
(TooManyOpenFilesTcpCommunicationSpi)grid(2).context().config().getCommunicationSpi();
try (Transaction tx =
grid(1).transactions().txStart(TransactionConcurrency.PESSIMISTIC,
TransactionIsolation.REPEATABLE_READ)) {
IgniteCache cache =
grid(1).cache(DEFAULT_CACHE_NAME);
cache.put(1, 1);
spi.throwException.set(true);
cache.put(2, 2);
cache.put(3, 2);
cache.put(4, 2);
// hungs here.
tx.commit();
}
for (int i=0; i < 3 ; i++) {
assertEquals(1, grid(i).cache(DEFAULT_CACHE_NAME).get(1));
assertEquals(2, grid(i).cache(DEFAULT_CACHE_NAME).get(2));
}
}
private static class TooManyOpenFilesTcpCommunicationSpi extends
TcpCommunicationSpi {
private final AtomicBoolean throwException = new AtomicBoolean();
/** {@inheritDoc} */
@Override public void sendMessage(ClusterNode node, Message msg) throws
IgniteSpiException {
if (throwException.get())
throw getException(node);
super.sendMessage(node, msg);
}
/** {@inheritDoc} */
@Override public void sendMessage(
ClusterNode node,
Message msg,
IgniteInClosure ackC
) throws IgniteSpiException {
if (throwException.get())
throw getException(node);
super.sendMessage(node, msg, ackC);
}
private IgniteSpiException getException(ClusterNode node) {
String checkedExceptionMsg = "Failed to connect to node (is node
still alive?). " +
"Make sure that each ComputeTask and cache Transaction has a
timeout set " +
"in order to prevent parties from waiting forever in case of
network issues " +
"[nodeId=" + node.id() + ", addrs=null]";
return new IgniteSpiException("Failed to send message to remote
node: " + node.id(), new IgniteCheckedException(checkedExceptionMsg, new
SocketException("Too many open files")));
}
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12710) Extension log in rebuild indexes to search problems
[ https://issues.apache.org/jira/browse/IGNITE-12710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-12710: Release Note: Added IGNITE_ENABLE_EXTRA_INDEX_REBUILD_LOGGING system property to enable additional logging for index creation. > Extension log in rebuild indexes to search problems > --- > > Key: IGNITE-12710 > URL: https://issues.apache.org/jira/browse/IGNITE-12710 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.9 > > > We should have the ability to get extended information about rebuild indexes: > cache, cache id, cache group, cache group id, index name, index type, index > size. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12710) Extension log in rebuild indexes to search problems
Sergey Antonov created IGNITE-12710: --- Summary: Extension log in rebuild indexes to search problems Key: IGNITE-12710 URL: https://issues.apache.org/jira/browse/IGNITE-12710 Project: Ignite Issue Type: Improvement Reporter: Sergey Antonov Assignee: Sergey Antonov Fix For: 2.9 We should have the ability to get extended information about rebuild indexes: cache, cache id, cache group, cache group id, index name, index type, index size. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12447) Modification of S#compact method
[ https://issues.apache.org/jira/browse/IGNITE-12447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-12447: Ignite Flags: (was: Docs Required,Release Notes Required) > Modification of S#compact method > > > Key: IGNITE-12447 > URL: https://issues.apache.org/jira/browse/IGNITE-12447 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > Modification of S#compact method so that it is possible to pass collection of > Numbers. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12225) Add enum for cluster state
[
https://issues.apache.org/jira/browse/IGNITE-12225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17019216#comment-17019216
]
Sergey Antonov commented on IGNITE-12225:
-
[~Pavlukhin] I created PR fix license fix
https://github.com/apache/ignite/pull/7275/
> Add enum for cluster state
> --
>
> Key: IGNITE-12225
> URL: https://issues.apache.org/jira/browse/IGNITE-12225
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> We have 3 cluster states at the moment: inactive, active, read-only.
> For getting current cluster state and changing them {{IgniteCluster}} has
> methods:
> * {{boolean active()}}, {{void active(boolean active)}} - for cluster
> activation/deactivation
> * {{boolean readOnly()}}, {{void readOnly(boolean readOnly)}} - for
> enabling/disabling read-only mode.
> Also we have control.sh commans for changing cluster state:
> * {{--activate}}
> * {{--deactivate}}
> * {{--read-only-on}}
> * {{--read-only-off}}
> For me current API looks unuseful. My proposal:
> # Create enum {{ClusterState}} with values {{ACTIVE}}, {{INACTIVE}},
> {{READ-ONLY}}.
> # Add methods to {{IgniteCluster}}:
> #* {{ClusterState state()}} returns current cluster state
> #* {{void state(ClusterState newState)}} changes cluster state to
> {{newState}} state
> # Mark as deprecated the following methods in {{IgniteCluster}}: {{boolean
> active()}}, {{void active(boolean active)}},
> # Add new command to control.sh: {{control.sh --set-state
> (ACTIVE|INACTIVE|READ-ONLY)}} [--yes]
> # Add warn message that command is depricated in control.sh. Commands:
> --activate, --deactivate,
> # Remove commands from control.sh: --read-only-on, --read-only-off (no one
> release wasn't published with this functional)
> # Add new methods to {{IgniteConfiguration}}:
> #* {{ClusterState getClusterStateOnStart()}}
> #* {{IgniteConfiguration setClusterStateOnStart(ClusterState state)}}
> # Deprecate methods in {{IgniteConfiguration}}:
> #* {{boolean isActiveOnStart()}}
> #* {{IgniteConfiguration setActiveOnStart(boolean activeOnStart)}}
> # Depracate ClusterActivationEvent and introduce new ClusterStateChangeEvent.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12554) Ignite instance couldn't be restarted if it's parent thread group has been called destroy once
[
https://issues.apache.org/jira/browse/IGNITE-12554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-12554:
Description:
I am using an inhouse platform which manage the life cycle of ignite instance
by calling ignition.start() and ignition.stop() from a web application.
it could be started without issue for the first time. however, if it stop the
ignite by calling ignition.stop() and followed by destroying the parent thread
group which starting it.
Calling ignition.start() in the 2nd time will throw the following exception
{noformat}
Exception in thread "kickOff" java.lang.IllegalThreadStateExceptionException in
thread "kickOff" java.lang.IllegalThreadStateException at
java.lang.ThreadGroup.addUnstarted(ThreadGroup.java:867) at
java.lang.Thread.init(Thread.java:405) at
java.lang.Thread.init(Thread.java:349) at
java.lang.Thread.(Thread.java:599) at
org.apache.ignite.thread.IgniteThread.(IgniteThread.java:96) at
org.apache.ignite.internal.util.StripedExecutor$Stripe.start(StripedExecutor.java:474)
at
org.apache.ignite.internal.util.StripedExecutor.(StripedExecutor.java:121)
at
org.apache.ignite.internal.util.StripedExecutor.(StripedExecutor.java:80)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1842)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158) at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589) at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:565) at
org.apache.ignite.Ignition.start(Ignition.java:305) at
com.faculty.poc.ignite.app.NodeRestartTesting.run(NodeRestartTesting.java:60)
at java.lang.Thread.run(Thread.java:748)
{noformat}
Please find my demo code for this issue.
Walk through into Ignite code, it should be caused by a static thread group
created in IgniteThread class. (private static final ThreadGroup DFLT_GRP = new
ThreadGroup("ignite")
Destroyed the parent thread group which start the ignite instance will result
in causing the DFLT_GRP go into destroyed state. Therefore, when Ignite was
start ifor the 2nd time, this static thread group has been destroyed and no
longer able to run the ignite.
was:
I am using an inhouse platform which manage the life cycle of ignite instance
by calling ignition.start() and ignition.stop() from a web application.
it could be started without issue for the first time. however, if it stop the
ignite by calling ignition.stop() and followed by destroying the parent thread
group which starting it.
Calling ignition.start() in the 2nd time will throw the following exception
Exception in thread "kickOff" java.lang.IllegalThreadStateExceptionException in
thread "kickOff" java.lang.IllegalThreadStateException at
java.lang.ThreadGroup.addUnstarted(ThreadGroup.java:867) at
java.lang.Thread.init(Thread.java:405) at
java.lang.Thread.init(Thread.java:349) at
java.lang.Thread.(Thread.java:599) at
org.apache.ignite.thread.IgniteThread.(IgniteThread.java:96) at
org.apache.ignite.internal.util.StripedExecutor$Stripe.start(StripedExecutor.java:474)
at
org.apache.ignite.internal.util.StripedExecutor.(StripedExecutor.java:121)
at
org.apache.ignite.internal.util.StripedExecutor.(StripedExecutor.java:80)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1842)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158) at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589) at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:565) at
org.apache.ignite.Ignition.start(Ignition.java:305) at
com.faculty.poc.ignite.app.NodeRestartTesting.run(NodeRestartTesting.java:60)
at java.lang.Thread.run(Thread.java:748)
Please find my demo code for this issue.
Walk through into Ignite code, it should be caused by a static thread group
created in IgniteThread class. (private static final ThreadGroup DFLT_GRP = new
ThreadGroup("ignite")
Destroyed the parent thread group which start the ignite instance will result
in causing the DFLT_GRP go into destroyed state. Therefore, when Ignite was
start ifor the 2nd time, this static thread group has been destroyed and no
longer able to run the ignite.
> Ignite instance couldn't be restarted if it's parent thread group has been
> called destroy once
> --
>
> Key: IGNITE-12554
> URL: https://issues.apache.org/jira/browse/IGNITE-12554
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7.6
>Reporter: ha faculty
>Priority: Major
>
[jira] [Updated] (IGNITE-12554) Ignite instance couldn't be restarted if it's parent thread group has been called destroy once
[
https://issues.apache.org/jira/browse/IGNITE-12554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-12554:
Description:
I am using an inhouse platform which manage the life cycle of ignite instance
by calling ignition.start() and ignition.stop() from a web application.
it could be started without issue for the first time. however, if it stop the
ignite by calling ignition.stop() and followed by destroying the parent thread
group which starting it.
Calling ignition.start() in the 2nd time will throw the following exception
Exception in thread "kickOff" java.lang.IllegalThreadStateExceptionException in
thread "kickOff" java.lang.IllegalThreadStateException at
java.lang.ThreadGroup.addUnstarted(ThreadGroup.java:867) at
java.lang.Thread.init(Thread.java:405) at
java.lang.Thread.init(Thread.java:349) at
java.lang.Thread.(Thread.java:599) at
org.apache.ignite.thread.IgniteThread.(IgniteThread.java:96) at
org.apache.ignite.internal.util.StripedExecutor$Stripe.start(StripedExecutor.java:474)
at
org.apache.ignite.internal.util.StripedExecutor.(StripedExecutor.java:121)
at
org.apache.ignite.internal.util.StripedExecutor.(StripedExecutor.java:80)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1842)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158) at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589) at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:565) at
org.apache.ignite.Ignition.start(Ignition.java:305) at
com.faculty.poc.ignite.app.NodeRestartTesting.run(NodeRestartTesting.java:60)
at java.lang.Thread.run(Thread.java:748)
Please find my demo code for this issue.
Walk through into Ignite code, it should be caused by a static thread group
created in IgniteThread class. (private static final ThreadGroup DFLT_GRP = new
ThreadGroup("ignite")
Destroyed the parent thread group which start the ignite instance will result
in causing the DFLT_GRP go into destroyed state. Therefore, when Ignite was
start ifor the 2nd time, this static thread group has been destroyed and no
longer able to run the ignite.
was:
I am using an inhouse platform which manage the life cycle of ignite instance
by calling ignition.start() and ignition.stop() from a web application.
it could be started without issue for the first time. however, if it stop the
ignite by calling ignition.stop() and followed by destroying the parent thread
group which starting it.
Calling ignition.start() in the 2nd time will throw the following exception
{noformat}
Exception in thread "kickOff" java.lang.IllegalThreadStateExceptionException in
thread "kickOff" java.lang.IllegalThreadStateException at
java.lang.ThreadGroup.addUnstarted(ThreadGroup.java:867) at
java.lang.Thread.init(Thread.java:405) at
java.lang.Thread.init(Thread.java:349) at
java.lang.Thread.(Thread.java:599) at
org.apache.ignite.thread.IgniteThread.(IgniteThread.java:96) at
org.apache.ignite.internal.util.StripedExecutor$Stripe.start(StripedExecutor.java:474)
at
org.apache.ignite.internal.util.StripedExecutor.(StripedExecutor.java:121)
at
org.apache.ignite.internal.util.StripedExecutor.(StripedExecutor.java:80)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1842)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1730)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1158) at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:589) at
org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:565) at
org.apache.ignite.Ignition.start(Ignition.java:305) at
com.faculty.poc.ignite.app.NodeRestartTesting.run(NodeRestartTesting.java:60)
at java.lang.Thread.run(Thread.java:748)
{noformat}
Please find my demo code for this issue.
Walk through into Ignite code, it should be caused by a static thread group
created in IgniteThread class. (private static final ThreadGroup DFLT_GRP = new
ThreadGroup("ignite")
Destroyed the parent thread group which start the ignite instance will result
in causing the DFLT_GRP go into destroyed state. Therefore, when Ignite was
start ifor the 2nd time, this static thread group has been destroyed and no
longer able to run the ignite.
> Ignite instance couldn't be restarted if it's parent thread group has been
> called destroy once
> --
>
> Key: IGNITE-12554
> URL: https://issues.apache.org/jira/browse/IGNITE-12554
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.7.6
>Reporter: ha faculty
>Priority: Major
>
[jira] [Updated] (IGNITE-11256) Implement read-only mode for grid
[ https://issues.apache.org/jira/browse/IGNITE-11256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-11256: Fix Version/s: (was: 2.8) 2.9 > Implement read-only mode for grid > - > > Key: IGNITE-11256 > URL: https://issues.apache.org/jira/browse/IGNITE-11256 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Scherbakov >Assignee: Sergey Antonov >Priority: Major > Labels: important > Fix For: 2.9 > > Time Spent: 4h > Remaining Estimate: 0h > > Should be triggered from control.sh utility. > Useful for maintenance work, for example checking partition consistency > (idle_verify) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12225) Add enum for cluster state
[
https://issues.apache.org/jira/browse/IGNITE-12225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17008085#comment-17008085
]
Sergey Antonov commented on IGNITE-12225:
-
Those tests are fixed under IGNITE-12520 in master branch today.
> Add enum for cluster state
> --
>
> Key: IGNITE-12225
> URL: https://issues.apache.org/jira/browse/IGNITE-12225
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have 3 cluster states at the moment: inactive, active, read-only.
> For getting current cluster state and changing them {{IgniteCluster}} has
> methods:
> * {{boolean active()}}, {{void active(boolean active)}} - for cluster
> activation/deactivation
> * {{boolean readOnly()}}, {{void readOnly(boolean readOnly)}} - for
> enabling/disabling read-only mode.
> Also we have control.sh commans for changing cluster state:
> * {{--activate}}
> * {{--deactivate}}
> * {{--read-only-on}}
> * {{--read-only-off}}
> For me current API looks unuseful. My proposal:
> # Create enum {{ClusterState}} with values {{ACTIVE}}, {{INACTIVE}},
> {{READ-ONLY}}.
> # Add methods to {{IgniteCluster}}:
> #* {{ClusterState state()}} returns current cluster state
> #* {{void state(ClusterState newState)}} changes cluster state to
> {{newState}} state
> # Mark as deprecated the following methods in {{IgniteCluster}}: {{boolean
> active()}}, {{void active(boolean active)}},
> # Add new command to control.sh: {{control.sh --set-state
> (ACTIVE|INACTIVE|READ-ONLY)}} [--yes]
> # Add warn message that command is depricated in control.sh. Commands:
> --activate, --deactivate,
> # Remove commands from control.sh: --read-only-on, --read-only-off (no one
> release wasn't published with this functional)
> # Add new methods to {{IgniteConfiguration}}:
> #* {{ClusterState getClusterStateOnStart()}}
> #* {{IgniteConfiguration setClusterStateOnStart(ClusterState state)}}
> # Deprecate methods in {{IgniteConfiguration}}:
> #* {{boolean isActiveOnStart()}}
> #* {{IgniteConfiguration setActiveOnStart(boolean activeOnStart)}}
> # Depracate ClusterActivationEvent and introduce new ClusterStateChangeEvent.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12520) Wrong year in copyright in "correct" output of control utility.
[
https://issues.apache.org/jira/browse/IGNITE-12520?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17008061#comment-17008061
]
Sergey Antonov commented on IGNITE-12520:
-
[~mmuzaf] The comparison order is correct. We are comparing "expected" utility
output from .output resource file with actual (i.e. command execution output).
https://junit.org/junit4/javadoc/4.12/org/junit/Assert.html#assertEquals(java.lang.Object,%20java.lang.Object)
I updated year in .output resource file.
> Wrong year in copyright in "correct" output of control utility.
> ---
>
> Key: IGNITE-12520
> URL: https://issues.apache.org/jira/browse/IGNITE-12520
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {noformat}
> org.junit.ComparisonFailure: line: 1 expected:<20[19] Copyright(C) > but
> was:<20[20] Copyright(C) >
> {noformat}
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5358072525606852701=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-6035521922020623279=%3Cdefault%3E=testDetails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12520) Wrong year in copyright in "correct" output of control utility.
[
https://issues.apache.org/jira/browse/IGNITE-12520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-12520:
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Wrong year in copyright in "correct" output of control utility.
> ---
>
> Key: IGNITE-12520
> URL: https://issues.apache.org/jira/browse/IGNITE-12520
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> {noformat}
> org.junit.ComparisonFailure: line: 1 expected:<20[19] Copyright(C) > but
> was:<20[20] Copyright(C) >
> {noformat}
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5358072525606852701=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-6035521922020623279=%3Cdefault%3E=testDetails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12520) Wrong year in copyright in "correct" output of control utility.
[
https://issues.apache.org/jira/browse/IGNITE-12520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-12520:
Ignite Flags: (was: Release Notes Required)
> Wrong year in copyright in "correct" output of control utility.
> ---
>
> Key: IGNITE-12520
> URL: https://issues.apache.org/jira/browse/IGNITE-12520
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> {noformat}
> org.junit.ComparisonFailure: line: 1 expected:<20[19] Copyright(C) > but
> was:<20[20] Copyright(C) >
> {noformat}
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5358072525606852701=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-6035521922020623279=%3Cdefault%3E=testDetails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12520) Wrong year in copyright in "correct" output of control utility.
[
https://issues.apache.org/jira/browse/IGNITE-12520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-12520:
Description:
{noformat}
org.junit.ComparisonFailure: line: 1 expected:<20[19] Copyright(C) > but
was:<20[20] Copyright(C) >
{noformat}
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5358072525606852701=%3Cdefault%3E=testDetails
https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-6035521922020623279=%3Cdefault%3E=testDetails
> Wrong year in copyright in "correct" output of control utility.
> ---
>
> Key: IGNITE-12520
> URL: https://issues.apache.org/jira/browse/IGNITE-12520
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.8
>
>
> {noformat}
> org.junit.ComparisonFailure: line: 1 expected:<20[19] Copyright(C) > but
> was:<20[20] Copyright(C) >
> {noformat}
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=5358072525606852701=%3Cdefault%3E=testDetails
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=-6035521922020623279=%3Cdefault%3E=testDetails
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12520) Wrong year in copyright in "correct" output of control utility.
[ https://issues.apache.org/jira/browse/IGNITE-12520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-12520: Summary: Wrong year in copyright in "correct" output of control utility. (was: Wrong year in copyright in correct output of control utility.) > Wrong year in copyright in "correct" output of control utility. > --- > > Key: IGNITE-12520 > URL: https://issues.apache.org/jira/browse/IGNITE-12520 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12520) Wrong year in copyright in correct output of control utility.
[ https://issues.apache.org/jira/browse/IGNITE-12520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-12520: Labels: MakeTeamcityGreenAgain (was: ) > Wrong year in copyright in correct output of control utility. > - > > Key: IGNITE-12520 > URL: https://issues.apache.org/jira/browse/IGNITE-12520 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Labels: MakeTeamcityGreenAgain > Fix For: 2.8 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12520) Wrong year in copyright in correct output of control utility.
Sergey Antonov created IGNITE-12520: --- Summary: Wrong year in copyright in correct output of control utility. Key: IGNITE-12520 URL: https://issues.apache.org/jira/browse/IGNITE-12520 Project: Ignite Issue Type: Bug Reporter: Sergey Antonov Assignee: Sergey Antonov -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12520) Wrong year in copyright in correct output of control utility.
[ https://issues.apache.org/jira/browse/IGNITE-12520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-12520: Fix Version/s: 2.8 > Wrong year in copyright in correct output of control utility. > - > > Key: IGNITE-12520 > URL: https://issues.apache.org/jira/browse/IGNITE-12520 > Project: Ignite > Issue Type: Bug >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.8 > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12225) Add enum for cluster state
[
https://issues.apache.org/jira/browse/IGNITE-12225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-12225:
Description:
We have 3 cluster states at the moment: inactive, active, read-only.
For getting current cluster state and changing them {{IgniteCluster}} has
methods:
* {{boolean active()}}, {{void active(boolean active)}} - for cluster
activation/deactivation
* {{boolean readOnly()}}, {{void readOnly(boolean readOnly)}} - for
enabling/disabling read-only mode.
Also we have control.sh commans for changing cluster state:
* {{--activate}}
* {{--deactivate}}
* {{--read-only-on}}
* {{--read-only-off}}
For me current API looks unuseful. My proposal:
# Create enum {{ClusterState}} with values {{ACTIVE}}, {{INACTIVE}},
{{READ-ONLY}}.
# Add methods to {{IgniteCluster}}:
#* {{ClusterState state()}} returns current cluster state
#* {{void state(ClusterState newState)}} changes cluster state to {{newState}}
state
# Mark as deprecated the following methods in {{IgniteCluster}}: {{boolean
active()}}, {{void active(boolean active)}},
# Add new command to control.sh: {{control.sh --set-state
(ACTIVE|INACTIVE|READ-ONLY)}} [--yes]
# Add warn message that command is depricated in control.sh. Commands:
--activate, --deactivate,
# Remove commands from control.sh: --read-only-on, --read-only-off (no one
release wasn't published with this functional)
# Add new methods to {{IgniteConfiguration}}:
#* {{ClusterState getClusterStateOnStart()}}
#* {{IgniteConfiguration setClusterStateOnStart(ClusterState state)}}
# Deprecate methods in {{IgniteConfiguration}}:
#* {{boolean isActiveOnStart()}}
#* {{IgniteConfiguration setActiveOnStart(boolean activeOnStart)}}
# Depracate ClusterActivationEvent and introduce new ClusterStateChangeEvent.
was:
We have 3 cluster states at the moment: inactive, active, read-only.
For getting current cluster state and changing them {{IgniteCluster}} has
methods:
* {{boolean active()}}, {{void active(boolean active)}} - for cluster
activation/deactivation
* {{boolean readOnly()}}, {{void readOnly(boolean readOnly)}} - for
enabling/disabling read-only mode.
Also we have control.sh commans for changing cluster state:
* {{--activate}}
* {{--deactivate}}
* {{--read-only-on}}
* {{--read-only-off}}
For me current API looks unuseful. My proposal:
# Create enum {{ClusterState}} with values {{ACTIVE}}, {{INACTIVE}},
{{READ-ONLY}}.
# Add methods to {{IgniteCluster}}:
#* {{ClusterState state()}} returns current cluster state
#* {{void state(ClusterState newState)}} changes cluster state to {{newState}}
state
# Mark as deprecated the following methods in {{IgniteCluster}}: {{boolean
active()}}, {{void active(boolean active)}},
# Add new command to control.sh: {{control.sh --set-state
(ACTIVE|INACTIVE|READ-ONLY)}} [--yes]
# Add warn message that command is depricated in control.sh. Commands:
--activate, --deactivate,
# Remove commands from control.sh: --read-only-on, --read-only-off (no one
release wasn't published with this functional)
# Add new methods to {{IgniteConfiguration}}:
#* {{ClusterState getClusterStateOnStart()}}
#* {{IgniteConfiguration setClusterStateOnStart(ClusterState state)}}
# Deprecate methods in {{IgniteConfiguration}}:
#* {{boolean isActiveOnStart()}}
#* {{IgniteConfiguration setActiveOnStart(boolean activeOnStart)}}
> Add enum for cluster state
> --
>
> Key: IGNITE-12225
> URL: https://issues.apache.org/jira/browse/IGNITE-12225
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have 3 cluster states at the moment: inactive, active, read-only.
> For getting current cluster state and changing them {{IgniteCluster}} has
> methods:
> * {{boolean active()}}, {{void active(boolean active)}} - for cluster
> activation/deactivation
> * {{boolean readOnly()}}, {{void readOnly(boolean readOnly)}} - for
> enabling/disabling read-only mode.
> Also we have control.sh commans for changing cluster state:
> * {{--activate}}
> * {{--deactivate}}
> * {{--read-only-on}}
> * {{--read-only-off}}
> For me current API looks unuseful. My proposal:
> # Create enum {{ClusterState}} with values {{ACTIVE}}, {{INACTIVE}},
> {{READ-ONLY}}.
> # Add methods to {{IgniteCluster}}:
> #* {{ClusterState state()}} returns current cluster state
> #* {{void state(ClusterState newState)}} changes cluster state to
> {{newState}} state
> # Mark as deprecated the following methods in {{IgniteCluster}}: {{boolean
> active()}}, {{void active(boolean active)}},
> # Add new command to control.sh: {{control.sh --set-state
> (ACTIVE|INACTIVE|READ-ONLY)}} [--yes]
> # Add warn message that command is depricated in control.sh. Commands:
> --activate, --deactivate,
[jira] [Updated] (IGNITE-12374) Too low performance ~200TPS for single ODBC client
[
https://issues.apache.org/jira/browse/IGNITE-12374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-12374:
Description:
Hi, in our test ignite performance with ODBC connection is too bad to proceed
with product integration. It is about ~200 TPS, each transaction with
select+update operation.
Please refer to attach sample program. It is just a simple test case.
Based on the profiling most of the time consumed by sql execution. Please
advice if the application did not do the right thing.
Thank you.
local ignite server, but the result same to remote container Ignite deployment
too.
{{cat /etc/apache-ignite/my-config.xml}}
{noformat}
http://www.springframework.org/schema/beans;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd;>
{noformat}
{{g++ -I/usr/include -I./ignite/binary/include -I./ignite/common/include
-I./ignite/common/os/linux/include -I./ignite/common/os/win/include
-I./ignite/core/include -I./ignite/jni/include odbcsample.cc -o odbcsample
-lodbc -L./ignite-libs/libignite.so -L./ignite-libs/libignite-odbc.so}}
was:
Hi, in our test ignite performance with ODBC connection is too bad to proceed
with product integration. It is about ~200 TPS, each transaction with
select+update operation.
Please refer to attach sample program. It is just a simple test case.
Based on the profiling most of the time consumed by sql execution. Please
advice if the application did not do the right thing.
Thank you.
local ignite server, but the result same to remote container Ignite deployment
too.
cat /etc/apache-ignite/my-config.xml
http://www.springframework.org/schema/beans;
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans.xsd;>
g++ -I/usr/include -I./ignite/binary/include -I./ignite/common/include
-I./ignite/common/os/linux/include -I./ignite/common/os/win/include
-I./ignite/core/include -I./ignite/jni/include odbcsample.cc -o odbcsample
-lodbc -L./ignite-libs/libignite.so -L./ignite-libs/libignite-odbc.so
> Too low performance ~200TPS for single ODBC client
> --
>
> Key: IGNITE-12374
> URL: https://issues.apache.org/jira/browse/IGNITE-12374
> Project: Ignite
> Issue Type: Improvement
> Components: clients, odbc
>Affects Versions: 2.7.5
> Environment: Ignite server run on top of Kubernetes, with 2 server
> nodes, persistence enabled. Both CPU and RAM at server/client server is
> sufficient according to system reports.
>Reporter: swy
>Priority: Major
> Attachments: ignite-9bb53f34.0.log,
> ignite-logs-config-source-20191128.zip,
> ignite-logs-config-source-20191129.zip, my-config-zstan.xml, odbcsample,
> odbcsample.allchar.rebind.cc, odbcsample.cc, profiling01.png,
> profiling03.png, profling02.png, screenshot-1.png,
> snapshot-1574845275597.nps, threaddump-1573207804944.tdump,
> threaddump-1574845414243.tdump, values.yaml
>
>
> Hi, in our test ignite performance with ODBC connection is too bad to proceed
> with product integration. It is about ~200 TPS, each transaction with
> select+update operation.
> Please refer to attach sample program. It is just a simple test case.
> Based on the profiling most of the time consumed by sql execution. Please
> advice if the application did not do the right thing.
> Thank you.
> local ignite server, but the result same to remote container Ignite
> deployment too.
> {{cat /etc/apache-ignite/my-config.xml}}
> {noformat}
>
> http://www.springframework.org/schema/beans;
>xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance;
>xsi:schemaLocation="http://www.springframework.org/schema/beans
> http://www.springframework.org/schema/beans/spring-beans.xsd;>
> class="org.apache.ignite.configuration.IgniteConfiguration">
>
> class="org.apache.ignite.configuration.ClientConnectorConfiguration"/>
>
>
>
>
>
> class="org.apache.ignite.binary.BinaryBasicIdMapper">
>
>
>
>
>
>
[jira] [Commented] (IGNITE-12407) Java thin client: implement API for activation/deactivation and WAL enabling/disabling
[ https://issues.apache.org/jira/browse/IGNITE-12407?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16985026#comment-16985026 ] Sergey Antonov commented on IGNITE-12407: - [~alex_pl] Please look at https://issues.apache.org/jira/browse/IGNITE-12225 > Java thin client: implement API for activation/deactivation and WAL > enabling/disabling > -- > > Key: IGNITE-12407 > URL: https://issues.apache.org/jira/browse/IGNITE-12407 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: thin > > Implement ClusterAPI methods already supported by protocol: > isActive() > setActive(active flag) > isWalEnabled(cacheName) > enableWal(cacheName) > disableWal(cacheName) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-10801) Upgrade H2 version up to 1.4.199
[ https://issues.apache.org/jira/browse/IGNITE-10801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov resolved IGNITE-10801. - Resolution: Won't Fix > Upgrade H2 version up to 1.4.199 > > > Key: IGNITE-10801 > URL: https://issues.apache.org/jira/browse/IGNITE-10801 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.7 >Reporter: Sergey Antonov >Priority: Critical > Labels: sql > Time Spent: 20m > Remaining Estimate: 0h > > After h2 1.4.199 release we should upgrade h2 version using in AI, because of > important bugs will be fixed there. For example > https://github.com/h2database/h2database/issues/1057 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-10801) Upgrade H2 version up to 1.4.199
[ https://issues.apache.org/jira/browse/IGNITE-10801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16984345#comment-16984345 ] Sergey Antonov commented on IGNITE-10801: - [~amashenkov] Ok, I closed ticket as won't fix. > Upgrade H2 version up to 1.4.199 > > > Key: IGNITE-10801 > URL: https://issues.apache.org/jira/browse/IGNITE-10801 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.7 >Reporter: Sergey Antonov >Priority: Critical > Labels: sql > Time Spent: 20m > Remaining Estimate: 0h > > After h2 1.4.199 release we should upgrade h2 version using in AI, because of > important bugs will be fixed there. For example > https://github.com/h2database/h2database/issues/1057 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (IGNITE-10801) Upgrade H2 version up to 1.4.199
[ https://issues.apache.org/jira/browse/IGNITE-10801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov closed IGNITE-10801. --- > Upgrade H2 version up to 1.4.199 > > > Key: IGNITE-10801 > URL: https://issues.apache.org/jira/browse/IGNITE-10801 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.7 >Reporter: Sergey Antonov >Priority: Critical > Labels: sql > Time Spent: 20m > Remaining Estimate: 0h > > After h2 1.4.199 release we should upgrade h2 version using in AI, because of > important bugs will be fixed there. For example > https://github.com/h2database/h2database/issues/1057 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-10801) Upgrade H2 version up to 1.4.199
[ https://issues.apache.org/jira/browse/IGNITE-10801?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-10801: Fix Version/s: (was: 2.8) > Upgrade H2 version up to 1.4.199 > > > Key: IGNITE-10801 > URL: https://issues.apache.org/jira/browse/IGNITE-10801 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.7 >Reporter: Sergey Antonov >Priority: Critical > Labels: sql > Time Spent: 20m > Remaining Estimate: 0h > > After h2 1.4.199 release we should upgrade h2 version using in AI, because of > important bugs will be fixed there. For example > https://github.com/h2database/h2database/issues/1057 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-11866) Add ability to activate cluster in read-only mode
[ https://issues.apache.org/jira/browse/IGNITE-11866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov resolved IGNITE-11866. - Assignee: Sergey Antonov Resolution: Duplicate > Add ability to activate cluster in read-only mode > - > > Key: IGNITE-11866 > URL: https://issues.apache.org/jira/browse/IGNITE-11866 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > > After IGNITE-11256 we have cluster read-only mode. We should have ability to > activate cluster and enable read-only mode like atomic operation. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12225) Add enum for cluster state
[
https://issues.apache.org/jira/browse/IGNITE-12225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Antonov updated IGNITE-12225:
Description:
We have 3 cluster states at the moment: inactive, active, read-only.
For getting current cluster state and changing them {{IgniteCluster}} has
methods:
* {{boolean active()}}, {{void active(boolean active)}} - for cluster
activation/deactivation
* {{boolean readOnly()}}, {{void readOnly(boolean readOnly)}} - for
enabling/disabling read-only mode.
Also we have control.sh commans for changing cluster state:
* {{--activate}}
* {{--deactivate}}
* {{--read-only-on}}
* {{--read-only-off}}
For me current API looks unuseful. My proposal:
# Create enum {{ClusterState}} with values {{ACTIVE}}, {{INACTIVE}},
{{READ-ONLY}}.
# Add methods to {{IgniteCluster}}:
#* {{ClusterState state()}} returns current cluster state
#* {{void state(ClusterState newState)}} changes cluster state to {{newState}}
state
# Mark as deprecated the following methods in {{IgniteCluster}}: {{boolean
active()}}, {{void active(boolean active)}},
# Add new command to control.sh: {{control.sh --set-state
(ACTIVE|INACTIVE|READ-ONLY)}} [--yes]
# Add warn message that command is depricated in control.sh. Commands:
--activate, --deactivate,
# Remove commands from control.sh: --read-only-on, --read-only-off (no one
release wasn't published with this functional)
# Add new methods to {{IgniteConfiguration}}:
#* {{ClusterState getClusterStateOnStart()}}
#* {{IgniteConfiguration setClusterStateOnStart(ClusterState state)}}
# Deprecate methods in {{IgniteConfiguration}}:
#* {{boolean isActiveOnStart()}}
#* {{IgniteConfiguration setActiveOnStart(boolean activeOnStart)}}
was:
We have 3 cluster states at the moment: inactive, active, read-only.
For getting current cluster state and changing them {{IgniteCluster}} has
methods:
* {{boolean active()}}, {{void active(boolean active)}} - for cluster
activation/deactivation
* {{boolean readOnly()}}, {{void readOnly(boolean readOnly)}} - for
enabling/disabling read-only mode.
Also we have control.sh commans for changing cluster state:
* {{--activate}}
* {{--deactivate}}
* {{--read-only-on}}
* {{--read-only-off}}
For me current API looks unuseful. My proposal:
# Create enum {{ClusterState}} with values {{ACTIVE}}, {{INACTIVE}},
{{READ-ONLY}}.
# Add methods to {{IgniteCluster}}:
#* {{ClusterState state()}} returns current cluster state
#* {{void state(ClusterState newState)}} changes cluster state to {{newState}}
state
# Mark as deprecated the following methods in {{IgniteCluster}}: {{boolean
active()}}, {{void active(boolean active)}},
# Add new command to control.sh: {{control.sh --set-state
(ACTIVE|INACTIVE|READ-ONLY)}} [--yes]
# Add warn message that command is depricated in control.sh. Commands:
--activate, --deactivate,
# Remove commands from control.sh: --read-only-on, --read-only-off (no one
release wasn't published with this functional)
> Add enum for cluster state
> --
>
> Key: IGNITE-12225
> URL: https://issues.apache.org/jira/browse/IGNITE-12225
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
>
> We have 3 cluster states at the moment: inactive, active, read-only.
> For getting current cluster state and changing them {{IgniteCluster}} has
> methods:
> * {{boolean active()}}, {{void active(boolean active)}} - for cluster
> activation/deactivation
> * {{boolean readOnly()}}, {{void readOnly(boolean readOnly)}} - for
> enabling/disabling read-only mode.
> Also we have control.sh commans for changing cluster state:
> * {{--activate}}
> * {{--deactivate}}
> * {{--read-only-on}}
> * {{--read-only-off}}
> For me current API looks unuseful. My proposal:
> # Create enum {{ClusterState}} with values {{ACTIVE}}, {{INACTIVE}},
> {{READ-ONLY}}.
> # Add methods to {{IgniteCluster}}:
> #* {{ClusterState state()}} returns current cluster state
> #* {{void state(ClusterState newState)}} changes cluster state to
> {{newState}} state
> # Mark as deprecated the following methods in {{IgniteCluster}}: {{boolean
> active()}}, {{void active(boolean active)}},
> # Add new command to control.sh: {{control.sh --set-state
> (ACTIVE|INACTIVE|READ-ONLY)}} [--yes]
> # Add warn message that command is depricated in control.sh. Commands:
> --activate, --deactivate,
> # Remove commands from control.sh: --read-only-on, --read-only-off (no one
> release wasn't published with this functional)
> # Add new methods to {{IgniteConfiguration}}:
> #* {{ClusterState getClusterStateOnStart()}}
> #* {{IgniteConfiguration setClusterStateOnStart(ClusterState state)}}
> # Deprecate methods in {{IgniteConfiguration}}:
> #* {{boolean isActiveOnStart()}}
> #* {{IgniteConfiguration
[jira] [Commented] (IGNITE-12316) Extend test coverage [IGNITE-10761] GridCacheProcessor should add info about cache in exception message, if applicable.
[
https://issues.apache.org/jira/browse/IGNITE-12316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16957835#comment-16957835
]
Sergey Antonov commented on IGNITE-12316:
-
[~ktkale...@gridgain.com] I'm okay with your changes.
> Extend test coverage [IGNITE-10761] GridCacheProcessor should add info about
> cache in exception message, if applicable.
> ---
>
> Key: IGNITE-12316
> URL: https://issues.apache.org/jira/browse/IGNITE-12316
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Test cache operations that should fail inside tx thread
> ||*Forbidden operation inside transaction*||
> |dynamic single cache start|
> |dynamic start of multiple caches|
> |dynamic cache destroy|
> |dynamic destroy of multiple caches|
> |dynamic cache close|
> |reset cache state|
> {quote}org.apache.ignite.internal.processors.cache.GridCacheProcessorActiveTxTest#testDynamicSingleCacheStart
> org.apache.ignite.internal.processors.cache.GridCacheProcessorActiveTxTest#testDynamicStartMultipleCaches
> org.apache.ignite.internal.processors.cache.GridCacheProcessorActiveTxTest#testDynamicCacheDestroy
> org.apache.ignite.internal.processors.cache.GridCacheProcessorActiveTxTest#testDynamicDestroyMultipleCaches
> org.apache.ignite.internal.processors.cache.GridCacheProcessorActiveTxTest#testDynamicCacheClose
> org.apache.ignite.internal.processors.cache.GridCacheProcessorActiveTxTest#testResetCacheState\{quote}
> # Start cluster, start active transaction in thread
> # Assert that in *Forbidden operation inside transaction* scenarios exception
> occurs with log information about cache name and reason
> # Finish running transaction, assert that there is no exception while
> evaluating *Forbidden operation inside transaction*
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12318) Extend test coverage [IGNITE-11967] control.sh validate_indexes SQL Index issue must contain information about cache group
[
https://issues.apache.org/jira/browse/IGNITE-12318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16957833#comment-16957833
]
Sergey Antonov commented on IGNITE-12318:
-
[~ktkale...@gridgain.com] I'm okay with your changes.
> Extend test coverage [IGNITE-11967] control.sh validate_indexes SQL Index
> issue must contain information about cache group
> --
>
> Key: IGNITE-12318
> URL: https://issues.apache.org/jira/browse/IGNITE-12318
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.8
>
>
> Test:
> {quote}org.apache.ignite.util.GridCommandHandlerIndexingClusterByClassTest#testBrokenCacheDataTreeShouldFailValidationWithCacheGroupInfo\{quote}
> # Put indexed data.
> # Break CacheDataTree.
> # Execute “control.sh validate_indexes”.
> # Verify that output contains cacheGroup, cacheName.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12305) Extend test coverage [IGNITE-11959] NullPointerException If transaction failed and failure handler doesn't configured explicitly
[
https://issues.apache.org/jira/browse/IGNITE-12305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16956835#comment-16956835
]
Sergey Antonov commented on IGNITE-12305:
-
[~ktkale...@gridgain.com] I'm okay with changes.
> Extend test coverage [IGNITE-11959] NullPointerException If transaction
> failed and failure handler doesn't configured explicitly
>
>
> Key: IGNITE-12305
> URL: https://issues.apache.org/jira/browse/IGNITE-12305
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Test 1. No FH and checking trace of transaction
> {quote}org.apache.ignite.internal.processors.cache.SafeLogTxFinishErrorTest#testSafeLogTxFinishErrorWithoutFailureHandler\{quote}
> # Start cluster with no FH, load data, start transaction, start and call
> \{{activeTx.logTxFinishErrorSafe}}
> # Assert that log information doesn’t contains information about FH and no
> NPE occurs
> # Assert that message starts with \{{Failed completing the transaction:
> \[commit=%s, tx=}} and tx_id is correct.
> Test 2: FH and checking trace of transaction
> {quote}org.apache.ignite.internal.processors.cache.SafeLogTxFinishErrorTest#testSafeLogTxFinishErrorWithFailureHandler\{quote}
> # Start cluster with FH, load data, start transaction, start and call
> \{{activeTx.logTxFinishErrorSafe}}
> # Assert that log information doesn’t contains information about FH and no
> NPE occurs
> # Assert that message starts with \{{Failed completing the transaction:
> \[commit=%s, tx=}} and tx_id is correct.
> Test 3: Failed String.format calling from tx
> {quote}org.apache.ignite.internal.processors.cache.SafeLogTxFinishErrorTest#testSafeLogTxFinishErrorWithFailureHandlerAndRemoveTxState\{quote}
> # Start cluster with FH, load data, start transaction with txState=null,
> start and call \{{activeTx.logTxFinishErrorSafe}}
> # Assert that log information doesn’t contains information about FH and no
> NPE occurs
> # Assert that message starts with \{{Failed completing the transaction:
> \[commit=%s, tx=}} and tx_id is correct.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12225) Add enum for cluster state
[
https://issues.apache.org/jira/browse/IGNITE-12225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16948560#comment-16948560
]
Sergey Antonov commented on IGNITE-12225:
-
[~mmuzaf], Hi!
I think, that I will keep up with this ticket till the 2.8 release code freeze.
> Add enum for cluster state
> --
>
> Key: IGNITE-12225
> URL: https://issues.apache.org/jira/browse/IGNITE-12225
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Antonov
>Assignee: Sergey Antonov
>Priority: Major
> Fix For: 2.8
>
>
> We have 3 cluster states at the moment: inactive, active, read-only.
> For getting current cluster state and changing them {{IgniteCluster}} has
> methods:
> * {{boolean active()}}, {{void active(boolean active)}} - for cluster
> activation/deactivation
> * {{boolean readOnly()}}, {{void readOnly(boolean readOnly)}} - for
> enabling/disabling read-only mode.
> Also we have control.sh commans for changing cluster state:
> * {{--activate}}
> * {{--deactivate}}
> * {{--read-only-on}}
> * {{--read-only-off}}
> For me current API looks unuseful. My proposal:
> # Create enum {{ClusterState}} with values {{ACTIVE}}, {{INACTIVE}},
> {{READ-ONLY}}.
> # Add methods to {{IgniteCluster}}:
> #* {{ClusterState state()}} returns current cluster state
> #* {{void state(ClusterState newState)}} changes cluster state to
> {{newState}} state
> # Mark as deprecated the following methods in {{IgniteCluster}}: {{boolean
> active()}}, {{void active(boolean active)}},
> # Add new command to control.sh: {{control.sh --set-state
> (ACTIVE|INACTIVE|READ-ONLY)}} [--yes]
> # Add warn message that command is depricated in control.sh. Commands:
> --activate, --deactivate,
> # Remove commands from control.sh: --read-only-on, --read-only-off (no one
> release wasn't published with this functional)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (IGNITE-10826) Control.sh add logging to file
[ https://issues.apache.org/jira/browse/IGNITE-10826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov closed IGNITE-10826. --- Ignite Flags: (was: Docs Required,Release Notes Required) > Control.sh add logging to file > -- > > Key: IGNITE-10826 > URL: https://issues.apache.org/jira/browse/IGNITE-10826 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Priority: Major > > We should print all output information to log file too. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-10826) Control.sh add logging to file
[ https://issues.apache.org/jira/browse/IGNITE-10826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov resolved IGNITE-10826. - Resolution: Duplicate > Control.sh add logging to file > -- > > Key: IGNITE-10826 > URL: https://issues.apache.org/jira/browse/IGNITE-10826 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Antonov >Priority: Major > > We should print all output information to log file too. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-10801) Upgrade H2 version up to 1.4.199
[ https://issues.apache.org/jira/browse/IGNITE-10801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942761#comment-16942761 ] Sergey Antonov edited comment on IGNITE-10801 at 10/2/19 12:20 PM: --- [~mmuzaf] Hello! I think yes. We mist upgrade h2 version in apache ignite. was (Author: antonovsergey93): [~mmuzaf] Hello! I think yes. We could upgrade h2 version in apache ignite. > Upgrade H2 version up to 1.4.199 > > > Key: IGNITE-10801 > URL: https://issues.apache.org/jira/browse/IGNITE-10801 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.7 >Reporter: Sergey Antonov >Priority: Critical > Labels: sql > Fix For: 2.8 > > > After h2 1.4.199 release we should upgrade h2 version using in AI, because of > important bugs will be fixed there. For example > https://github.com/h2database/h2database/issues/1057 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-10801) Upgrade H2 version up to 1.4.199
[ https://issues.apache.org/jira/browse/IGNITE-10801?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942761#comment-16942761 ] Sergey Antonov commented on IGNITE-10801: - [~mmuzaf] Hello! I think yes. We could upgrade h2 version in apache ignite. > Upgrade H2 version up to 1.4.199 > > > Key: IGNITE-10801 > URL: https://issues.apache.org/jira/browse/IGNITE-10801 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 2.7 >Reporter: Sergey Antonov >Priority: Critical > Labels: sql > Fix For: 2.8 > > > After h2 1.4.199 release we should upgrade h2 version using in AI, because of > important bugs will be fixed there. For example > https://github.com/h2database/h2database/issues/1057 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-8717) Move persisted cache configuration to metastore and introduce cache configuration versioning
[ https://issues.apache.org/jira/browse/IGNITE-8717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16942146#comment-16942146 ] Sergey Antonov commented on IGNITE-8717: [~mmuzaf] I don't think so. > Move persisted cache configuration to metastore and introduce cache > configuration versioning > > > Key: IGNITE-8717 > URL: https://issues.apache.org/jira/browse/IGNITE-8717 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Goncharuk >Assignee: Sergey Antonov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > Currently, we persist cache configuration to local files which resulted in > several inconsistencies when a node misses configuration update (create > index, cache destroy, etc). > I think the cache configuration should be saved to the metastore the same way > as baseline topology is saved. Same mechanics should be used for conflicting > configuration updates resolution. > Along with cache configuration, it also makes sense to move marshaller and > binary metadata to the metastore. -- This message was sent by Atlassian Jira (v8.3.4#803005)
