[jira] [Assigned] (IGNITE-15155) Utils IgniteWalConverter add ability to skip reading errors
[ https://issues.apache.org/jira/browse/IGNITE-15155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexand Polyakov reassigned IGNITE-15155: - Assignee: (was: Alexand Polyakov) > Utils IgniteWalConverter add ability to skip reading errors > --- > > Key: IGNITE-15155 > URL: https://issues.apache.org/jira/browse/IGNITE-15155 > Project: Ignite > Issue Type: Improvement > Components: extensions >Affects Versions: 2.10 >Reporter: Alexand Polyakov >Priority: Major > > When reading WAL in IgniteWalConverter with error, it is useful not to stop > at the first error, but to output all the data that can be read -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-13929) Don't print sensitive information in logs by default
[ https://issues.apache.org/jira/browse/IGNITE-13929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17462155#comment-17462155 ] Alexand Polyakov commented on IGNITE-13929: --- Locally the test passes !screenshot-1.png! > Don't print sensitive information in logs by default > > > Key: IGNITE-13929 > URL: https://issues.apache.org/jira/browse/IGNITE-13929 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Assignee: Alexand Polyakov >Priority: Major > Attachments: screenshot-1.png > > > Right now, by default, node prints entries in logs of PME and long running > operations. It’s not secure, because it disclose sensitive data. However > printing of entries might help with certain issues such as deadlock. So we > can print hash of entries in log. > > *Summary of the changes:* > 1. IGNITE_TO_STRING_INCLUDE_SENSITIVE is deprecated > 2. IGNITE_SENSITIVE_DATA_LOGGING is a new system property with three > possible values: > "plain" - print as is > "hash" - print hash (primitives are printed as is) > "none" - don’t print anything > 3. "hash" is default value > 4. If a node starts with explicit IGNITE_TO_STRING_INCLUDE_SENSITIVE the > value converts to IGNITE_SENSITIVE_DATA_LOGGING: > true -> plain > false -> none -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-13929) Don't print sensitive information in logs by default
[ https://issues.apache.org/jira/browse/IGNITE-13929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexand Polyakov updated IGNITE-13929: -- Attachment: screenshot-1.png > Don't print sensitive information in logs by default > > > Key: IGNITE-13929 > URL: https://issues.apache.org/jira/browse/IGNITE-13929 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Assignee: Alexand Polyakov >Priority: Major > Attachments: screenshot-1.png > > > Right now, by default, node prints entries in logs of PME and long running > operations. It’s not secure, because it disclose sensitive data. However > printing of entries might help with certain issues such as deadlock. So we > can print hash of entries in log. > > *Summary of the changes:* > 1. IGNITE_TO_STRING_INCLUDE_SENSITIVE is deprecated > 2. IGNITE_SENSITIVE_DATA_LOGGING is a new system property with three > possible values: > "plain" - print as is > "hash" - print hash (primitives are printed as is) > "none" - don’t print anything > 3. "hash" is default value > 4. If a node starts with explicit IGNITE_TO_STRING_INCLUDE_SENSITIVE the > value converts to IGNITE_SENSITIVE_DATA_LOGGING: > true -> plain > false -> none -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-13929) Don't print sensitive information in logs by default
[ https://issues.apache.org/jira/browse/IGNITE-13929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17449348#comment-17449348 ] Alexand Polyakov edited comment on IGNITE-13929 at 11/26/21, 5:50 AM: -- Run TC https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_RunAll/6292029 was (Author: a-polyakov): Run TC https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_RunAll/6291603 > Don't print sensitive information in logs by default > > > Key: IGNITE-13929 > URL: https://issues.apache.org/jira/browse/IGNITE-13929 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Assignee: Alexand Polyakov >Priority: Major > > Right now, by default, node prints entries in logs of PME and long running > operations. It’s not secure, because it disclose sensitive data. However > printing of entries might help with certain issues such as deadlock. So we > can print hash of entries in log. > > *Summary of the changes:* > 1. IGNITE_TO_STRING_INCLUDE_SENSITIVE is deprecated > 2. IGNITE_SENSITIVE_DATA_LOGGING is a new system property with three > possible values: > "plain" - print as is > "hash" - print hash (primitives are printed as is) > "none" - don’t print anything > 3. "hash" is default value > 4. If a node starts with explicit IGNITE_TO_STRING_INCLUDE_SENSITIVE the > value converts to IGNITE_SENSITIVE_DATA_LOGGING: > true -> plain > false -> none -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-13929) Don't print sensitive information in logs by default
[ https://issues.apache.org/jira/browse/IGNITE-13929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17449348#comment-17449348 ] Alexand Polyakov commented on IGNITE-13929: --- Run TC https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_RunAll/6291603 > Don't print sensitive information in logs by default > > > Key: IGNITE-13929 > URL: https://issues.apache.org/jira/browse/IGNITE-13929 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Assignee: Alexand Polyakov >Priority: Major > > Right now, by default, node prints entries in logs of PME and long running > operations. It’s not secure, because it disclose sensitive data. However > printing of entries might help with certain issues such as deadlock. So we > can print hash of entries in log. > > *Summary of the changes:* > 1. IGNITE_TO_STRING_INCLUDE_SENSITIVE is deprecated > 2. IGNITE_SENSITIVE_DATA_LOGGING is a new system property with three > possible values: > "plain" - print as is > "hash" - print hash (primitives are printed as is) > "none" - don’t print anything > 3. "hash" is default value > 4. If a node starts with explicit IGNITE_TO_STRING_INCLUDE_SENSITIVE the > value converts to IGNITE_SENSITIVE_DATA_LOGGING: > true -> plain > false -> none -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-13929) Don't print sensitive information in logs by default
[ https://issues.apache.org/jira/browse/IGNITE-13929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17449347#comment-17449347 ] Alexand Polyakov commented on IGNITE-13929: --- Create pull request https://github.com/apache/ignite/pull/9611 > Don't print sensitive information in logs by default > > > Key: IGNITE-13929 > URL: https://issues.apache.org/jira/browse/IGNITE-13929 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Assignee: Alexand Polyakov >Priority: Major > > Right now, by default, node prints entries in logs of PME and long running > operations. It’s not secure, because it disclose sensitive data. However > printing of entries might help with certain issues such as deadlock. So we > can print hash of entries in log. > > *Summary of the changes:* > 1. IGNITE_TO_STRING_INCLUDE_SENSITIVE is deprecated > 2. IGNITE_SENSITIVE_DATA_LOGGING is a new system property with three > possible values: > "plain" - print as is > "hash" - print hash (primitives are printed as is) > "none" - don’t print anything > 3. "hash" is default value > 4. If a node starts with explicit IGNITE_TO_STRING_INCLUDE_SENSITIVE the > value converts to IGNITE_SENSITIVE_DATA_LOGGING: > true -> plain > false -> none -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-13929) Don't print sensitive information in logs by default
[ https://issues.apache.org/jira/browse/IGNITE-13929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17449346#comment-17449346 ] Alexand Polyakov commented on IGNITE-13929: --- Create branch https://github.com/gridgain/apache-ignite/tree/ignite-13929 > Don't print sensitive information in logs by default > > > Key: IGNITE-13929 > URL: https://issues.apache.org/jira/browse/IGNITE-13929 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Assignee: Alexand Polyakov >Priority: Major > > Right now, by default, node prints entries in logs of PME and long running > operations. It’s not secure, because it disclose sensitive data. However > printing of entries might help with certain issues such as deadlock. So we > can print hash of entries in log. > > *Summary of the changes:* > 1. IGNITE_TO_STRING_INCLUDE_SENSITIVE is deprecated > 2. IGNITE_SENSITIVE_DATA_LOGGING is a new system property with three > possible values: > "plain" - print as is > "hash" - print hash (primitives are printed as is) > "none" - don’t print anything > 3. "hash" is default value > 4. If a node starts with explicit IGNITE_TO_STRING_INCLUDE_SENSITIVE the > value converts to IGNITE_SENSITIVE_DATA_LOGGING: > true -> plain > false -> none -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-13929) Don't print sensitive information in logs by default
[ https://issues.apache.org/jira/browse/IGNITE-13929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexand Polyakov reassigned IGNITE-13929: - Assignee: Alexand Polyakov (was: Sergey Uttsel) > Don't print sensitive information in logs by default > > > Key: IGNITE-13929 > URL: https://issues.apache.org/jira/browse/IGNITE-13929 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Assignee: Alexand Polyakov >Priority: Major > > Right now, by default, node prints entries in logs of PME and long running > operations. It’s not secure, because it disclose sensitive data. However > printing of entries might help with certain issues such as deadlock. So we > can print hash of entries in log. > > *Summary of the changes:* > 1. IGNITE_TO_STRING_INCLUDE_SENSITIVE is deprecated > 2. IGNITE_SENSITIVE_DATA_LOGGING is a new system property with three > possible values: > "plain" - print as is > "hash" - print hash (primitives are printed as is) > "none" - don’t print anything > 3. "hash" is default value > 4. If a node starts with explicit IGNITE_TO_STRING_INCLUDE_SENSITIVE the > value converts to IGNITE_SENSITIVE_DATA_LOGGING: > true -> plain > false -> none -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-15155) Utils IgniteWalConverter add ability to skip reading errors
Alexand Polyakov created IGNITE-15155: - Summary: Utils IgniteWalConverter add ability to skip reading errors Key: IGNITE-15155 URL: https://issues.apache.org/jira/browse/IGNITE-15155 Project: Ignite Issue Type: Improvement Components: extensions Affects Versions: 2.10 Reporter: Alexand Polyakov Assignee: Alexand Polyakov When reading WAL in IgniteWalConverter with error, it is useful not to stop at the first error, but to output all the data that can be read -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-9386) control.sh --tx can produce confusing results when limit is set to small value
[ https://issues.apache.org/jira/browse/IGNITE-9386?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17330074#comment-17330074 ] Alexand Polyakov commented on IGNITE-9386: -- relevant for master (2021.04.23) > control.sh --tx can produce confusing results when limit is set to small value > -- > > Key: IGNITE-9386 > URL: https://issues.apache.org/jira/browse/IGNITE-9386 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Reporter: Alexey Scherbakov >Priority: Major > > This is happening because currently the limit is applied to primary and > backup transactions, which breaks output post-filtering (removal of primary > and backup transactions from output if near is present). > Possible solution: apply limit only to near valid transactions. If some txs > have no near part (broken tx topology), they should be always visible in > output, probably with special "broken" marking. > Best way to achieve this - implement tx paging on client side (using > continuous mapping) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13956) ManagementEnabled incomprehensible metric description
[ https://issues.apache.org/jira/browse/IGNITE-13956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17263492#comment-17263492 ] Alexand Polyakov commented on IGNITE-13956: --- Run TC https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_RunAll/5825652 > ManagementEnabled incomprehensible metric description > - > > Key: IGNITE-13956 > URL: https://issues.apache.org/jira/browse/IGNITE-13956 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > There are incomprehensible description for mben: > org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl" > ManagementEnabled -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13956) ManagementEnabled incomprehensible metric description
[ https://issues.apache.org/jira/browse/IGNITE-13956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17263490#comment-17263490 ] Alexand Polyakov commented on IGNITE-13956: --- Create pull request https://github.com/apache/ignite/pull/8658 > ManagementEnabled incomprehensible metric description > - > > Key: IGNITE-13956 > URL: https://issues.apache.org/jira/browse/IGNITE-13956 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > There are incomprehensible description for mben: > org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl" > ManagementEnabled -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13955) Thread Pools incomprehensible metric description
[ https://issues.apache.org/jira/browse/IGNITE-13955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17263486#comment-17263486 ] Alexand Polyakov commented on IGNITE-13955: --- Run TC https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_RunAll/5825551 > Thread Pools incomprehensible metric description > > > Key: IGNITE-13955 > URL: https://issues.apache.org/jira/browse/IGNITE-13955 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > There are incomprehensible description for metric > RejectedExecutionHandlerClass for each thread pool. > For example mbean org.apache:group="Thread Pools",name=GridAffinityExecutor -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13955) Thread Pools incomprehensible metric description
[ https://issues.apache.org/jira/browse/IGNITE-13955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17263485#comment-17263485 ] Alexand Polyakov commented on IGNITE-13955: --- Create pull request https://github.com/apache/ignite/pull/8657 > Thread Pools incomprehensible metric description > > > Key: IGNITE-13955 > URL: https://issues.apache.org/jira/browse/IGNITE-13955 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > There are incomprehensible description for metric > RejectedExecutionHandlerClass for each thread pool. > For example mbean org.apache:group="Thread Pools",name=GridAffinityExecutor -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13955) Thread Pools incomprehensible metric description
[ https://issues.apache.org/jira/browse/IGNITE-13955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17263484#comment-17263484 ] Alexand Polyakov commented on IGNITE-13955: --- Create branch https://github.com/gridgain/apache-ignite/tree/ignite-13955 > Thread Pools incomprehensible metric description > > > Key: IGNITE-13955 > URL: https://issues.apache.org/jira/browse/IGNITE-13955 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > > There are incomprehensible description for metric > RejectedExecutionHandlerClass for each thread pool. > For example mbean org.apache:group="Thread Pools",name=GridAffinityExecutor -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13954) TcpDiscoverySpi incomprehensible metric description
[ https://issues.apache.org/jira/browse/IGNITE-13954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17263481#comment-17263481 ] Alexand Polyakov commented on IGNITE-13954: --- Run TC https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_RunAll/5825450 > TcpDiscoverySpi incomprehensible metric description > --- > > Key: IGNITE-13954 > URL: https://issues.apache.org/jira/browse/IGNITE-13954 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > There is an incomprehensible description for metric: > org.apache:group=SPIs,name=TcpDiscoverySpi IpFinderCleanFrequency > org.apache:group=SPIs,name=TcpDiscoverySpi JoinTimeout -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13954) TcpDiscoverySpi incomprehensible metric description
[ https://issues.apache.org/jira/browse/IGNITE-13954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17263479#comment-17263479 ] Alexand Polyakov commented on IGNITE-13954: --- Create pull request https://github.com/apache/ignite/pull/8656 > TcpDiscoverySpi incomprehensible metric description > --- > > Key: IGNITE-13954 > URL: https://issues.apache.org/jira/browse/IGNITE-13954 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > There is an incomprehensible description for metric: > org.apache:group=SPIs,name=TcpDiscoverySpi IpFinderCleanFrequency > org.apache:group=SPIs,name=TcpDiscoverySpi JoinTimeout -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13954) TcpDiscoverySpi incomprehensible metric description
[ https://issues.apache.org/jira/browse/IGNITE-13954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17263478#comment-17263478 ] Alexand Polyakov commented on IGNITE-13954: --- Create branch https://github.com/gridgain/apache-ignite/tree/ignite-13954 > TcpDiscoverySpi incomprehensible metric description > --- > > Key: IGNITE-13954 > URL: https://issues.apache.org/jira/browse/IGNITE-13954 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > > There is an incomprehensible description for metric: > org.apache:group=SPIs,name=TcpDiscoverySpi IpFinderCleanFrequency > org.apache:group=SPIs,name=TcpDiscoverySpi JoinTimeout -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13953) Dataregion metrics without description
[ https://issues.apache.org/jira/browse/IGNITE-13953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17263476#comment-17263476 ] Alexand Polyakov commented on IGNITE-13953: --- Run TC https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_RunAll/5825349 > Dataregion metrics without description > -- > > Key: IGNITE-13953 > URL: https://issues.apache.org/jira/browse/IGNITE-13953 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > List of metrics: > ||mbean||attribute||description|| > |org.apache:group=DataRegionMetrics,name=default|PageSize|Attribute exposed > for management| > |org.apache:group=DataRegionMetrics,name=default|TotalAllocatedSize|Attribute > exposed for management| > |org.apache:group=DataRegionMetrics,name=default|PhysicalMemorySize|Attribute > exposed for management| > |org.apache:group=DataRegionMetrics,name=default|UsedCheckpointBufferPages|Attribute > exposed for management| > |org.apache:group=DataRegionMetrics,name=default|UsedCheckpointBufferSize|Attribute > exposed for management| > |org.apache:group=DataRegionMetrics,name=default|CheckpointBufferSize|Attribute > exposed for management| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13953) Dataregion metrics without description
[ https://issues.apache.org/jira/browse/IGNITE-13953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17263475#comment-17263475 ] Alexand Polyakov commented on IGNITE-13953: --- Create pull request https://github.com/apache/ignite/pull/8654 > Dataregion metrics without description > -- > > Key: IGNITE-13953 > URL: https://issues.apache.org/jira/browse/IGNITE-13953 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > > List of metrics: > ||mbean||attribute||description|| > |org.apache:group=DataRegionMetrics,name=default|PageSize|Attribute exposed > for management| > |org.apache:group=DataRegionMetrics,name=default|TotalAllocatedSize|Attribute > exposed for management| > |org.apache:group=DataRegionMetrics,name=default|PhysicalMemorySize|Attribute > exposed for management| > |org.apache:group=DataRegionMetrics,name=default|UsedCheckpointBufferPages|Attribute > exposed for management| > |org.apache:group=DataRegionMetrics,name=default|UsedCheckpointBufferSize|Attribute > exposed for management| > |org.apache:group=DataRegionMetrics,name=default|CheckpointBufferSize|Attribute > exposed for management| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13953) Dataregion metrics without description
[ https://issues.apache.org/jira/browse/IGNITE-13953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17263473#comment-17263473 ] Alexand Polyakov commented on IGNITE-13953: --- Create branch https://github.com/gridgain/apache-ignite/tree/ignite-13953 > Dataregion metrics without description > -- > > Key: IGNITE-13953 > URL: https://issues.apache.org/jira/browse/IGNITE-13953 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > > List of metrics: > ||mbean||attribute||description|| > |org.apache:group=DataRegionMetrics,name=default|PageSize|Attribute exposed > for management| > |org.apache:group=DataRegionMetrics,name=default|TotalAllocatedSize|Attribute > exposed for management| > |org.apache:group=DataRegionMetrics,name=default|PhysicalMemorySize|Attribute > exposed for management| > |org.apache:group=DataRegionMetrics,name=default|UsedCheckpointBufferPages|Attribute > exposed for management| > |org.apache:group=DataRegionMetrics,name=default|UsedCheckpointBufferSize|Attribute > exposed for management| > |org.apache:group=DataRegionMetrics,name=default|CheckpointBufferSize|Attribute > exposed for management| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13952) Cache metrics without description
[ https://issues.apache.org/jira/browse/IGNITE-13952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17263468#comment-17263468 ] Alexand Polyakov commented on IGNITE-13952: --- Run TC https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_RunAll/5825248 > Cache metrics without description > - > > Key: IGNITE-13952 > URL: https://issues.apache.org/jira/browse/IGNITE-13952 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > list of metrics > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|RebalancedKeys| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EstimatedRebalancingKeys| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|RebalanceClearingPartitionsLeft| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorAverageInvocationTime| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorHitPercentage| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorHits| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorInvocations| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorMaxInvocationTime| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorMinInvocationTime| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorMisses| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorMissPercentage| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorPuts| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorReadOnlyInvocations| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorRemovals| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|RebalancedKeys| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EstimatedRebalancingKeys| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|RebalanceClearingPartitionsLeft| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorAverageInvocationTime| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorHitPercentage| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorHits| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorInvocations| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorMaxInvocationTime| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorMinInvocationTime| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorMisses| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorMissPercentage| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorPuts| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorReadOnlyInvocations| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorRemovals| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13952) Cache metrics without description
[ https://issues.apache.org/jira/browse/IGNITE-13952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17263466#comment-17263466 ] Alexand Polyakov commented on IGNITE-13952: --- Create pull request https://github.com/apache/ignite/pull/8653 > Cache metrics without description > - > > Key: IGNITE-13952 > URL: https://issues.apache.org/jira/browse/IGNITE-13952 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > list of metrics > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|RebalancedKeys| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EstimatedRebalancingKeys| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|RebalanceClearingPartitionsLeft| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorAverageInvocationTime| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorHitPercentage| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorHits| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorInvocations| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorMaxInvocationTime| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorMinInvocationTime| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorMisses| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorMissPercentage| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorPuts| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorReadOnlyInvocations| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorRemovals| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|RebalancedKeys| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EstimatedRebalancingKeys| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|RebalanceClearingPartitionsLeft| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorAverageInvocationTime| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorHitPercentage| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorHits| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorInvocations| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorMaxInvocationTime| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorMinInvocationTime| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorMisses| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorMissPercentage| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorPuts| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorReadOnlyInvocations| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorRemovals| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13952) Cache metrics without description
[ https://issues.apache.org/jira/browse/IGNITE-13952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17263465#comment-17263465 ] Alexand Polyakov commented on IGNITE-13952: --- Create branch https://github.com/gridgain/apache-ignite/tree/ignite-13952 > Cache metrics without description > - > > Key: IGNITE-13952 > URL: https://issues.apache.org/jira/browse/IGNITE-13952 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > list of metrics > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|RebalancedKeys| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EstimatedRebalancingKeys| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|RebalanceClearingPartitionsLeft| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorAverageInvocationTime| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorHitPercentage| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorHits| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorInvocations| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorMaxInvocationTime| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorMinInvocationTime| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorMisses| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorMissPercentage| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorPuts| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorReadOnlyInvocations| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorRemovals| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|RebalancedKeys| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EstimatedRebalancingKeys| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|RebalanceClearingPartitionsLeft| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorAverageInvocationTime| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorHitPercentage| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorHits| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorInvocations| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorMaxInvocationTime| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorMinInvocationTime| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorMisses| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorMissPercentage| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorPuts| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorReadOnlyInvocations| > |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorRemovals| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13953) Dataregion metrics without description
[ https://issues.apache.org/jira/browse/IGNITE-13953?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexand Polyakov updated IGNITE-13953: -- Summary: Dataregion metrics without description (was: Detaregion metrics without description) > Dataregion metrics without description > -- > > Key: IGNITE-13953 > URL: https://issues.apache.org/jira/browse/IGNITE-13953 > Project: Ignite > Issue Type: Sub-task >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > > List of metrics: > ||mbean||attribute||description|| > |org.apache:group=DataRegionMetrics,name=default|PageSize|Attribute exposed > for management| > |org.apache:group=DataRegionMetrics,name=default|TotalAllocatedSize|Attribute > exposed for management| > |org.apache:group=DataRegionMetrics,name=default|PhysicalMemorySize|Attribute > exposed for management| > |org.apache:group=DataRegionMetrics,name=default|UsedCheckpointBufferPages|Attribute > exposed for management| > |org.apache:group=DataRegionMetrics,name=default|UsedCheckpointBufferSize|Attribute > exposed for management| > |org.apache:group=DataRegionMetrics,name=default|CheckpointBufferSize|Attribute > exposed for management| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13689) Extend test coverage [IGNITE-11512] Add counter left partition for index rebuild in CacheGroupMetricsMXBean
[ https://issues.apache.org/jira/browse/IGNITE-13689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17263276#comment-17263276 ] Alexand Polyakov commented on IGNITE-13689: --- Run TC https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_RunAll/5824996 > Extend test coverage [IGNITE-11512] Add counter left partition for index > rebuild in CacheGroupMetricsMXBean > --- > > Key: IGNITE-13689 > URL: https://issues.apache.org/jira/browse/IGNITE-13689 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.9 >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > Labels: test > Time Spent: 10m > Remaining Estimate: 0h > > New test: > Partial rebuild > # Start cluster, load data with indexes > # Kill single node, create new index, start node. > # Make sure that index rebuild count is in range of total new index size and > 0 and decreasing > # Wait until rebuild finished, assert that no index errors -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13955) Thread Pools incomprehensible metric description
Alexand Polyakov created IGNITE-13955: - Summary: Thread Pools incomprehensible metric description Key: IGNITE-13955 URL: https://issues.apache.org/jira/browse/IGNITE-13955 Project: Ignite Issue Type: Sub-task Reporter: Alexand Polyakov Assignee: Alexand Polyakov There are incomprehensible description for metric RejectedExecutionHandlerClass for each thread pool. For example mbean org.apache:group="Thread Pools",name=GridAffinityExecutor -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13956) ManagementEnabled incomprehensible metric description
Alexand Polyakov created IGNITE-13956: - Summary: ManagementEnabled incomprehensible metric description Key: IGNITE-13956 URL: https://issues.apache.org/jira/browse/IGNITE-13956 Project: Ignite Issue Type: Sub-task Reporter: Alexand Polyakov Assignee: Alexand Polyakov There are incomprehensible description for mben: org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl" ManagementEnabled -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13954) TcpDiscoverySpi incomprehensible metric description
Alexand Polyakov created IGNITE-13954: - Summary: TcpDiscoverySpi incomprehensible metric description Key: IGNITE-13954 URL: https://issues.apache.org/jira/browse/IGNITE-13954 Project: Ignite Issue Type: Sub-task Reporter: Alexand Polyakov Assignee: Alexand Polyakov There is an incomprehensible description for metric: org.apache:group=SPIs,name=TcpDiscoverySpi IpFinderCleanFrequency org.apache:group=SPIs,name=TcpDiscoverySpi JoinTimeout -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13953) Detaregion metrics without description
Alexand Polyakov created IGNITE-13953: - Summary: Detaregion metrics without description Key: IGNITE-13953 URL: https://issues.apache.org/jira/browse/IGNITE-13953 Project: Ignite Issue Type: Sub-task Reporter: Alexand Polyakov Assignee: Alexand Polyakov List of metrics: ||mbean||attribute||description|| |org.apache:group=DataRegionMetrics,name=default|PageSize|Attribute exposed for management| |org.apache:group=DataRegionMetrics,name=default|TotalAllocatedSize|Attribute exposed for management| |org.apache:group=DataRegionMetrics,name=default|PhysicalMemorySize|Attribute exposed for management| |org.apache:group=DataRegionMetrics,name=default|UsedCheckpointBufferPages|Attribute exposed for management| |org.apache:group=DataRegionMetrics,name=default|UsedCheckpointBufferSize|Attribute exposed for management| |org.apache:group=DataRegionMetrics,name=default|CheckpointBufferSize|Attribute exposed for management| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13952) Cache metrics without description
Alexand Polyakov created IGNITE-13952: - Summary: Cache metrics without description Key: IGNITE-13952 URL: https://issues.apache.org/jira/browse/IGNITE-13952 Project: Ignite Issue Type: Sub-task Reporter: Alexand Polyakov Assignee: Alexand Polyakov list of metrics |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|RebalancedKeys| |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EstimatedRebalancingKeys| |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|RebalanceClearingPartitionsLeft| |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorAverageInvocationTime| |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorHitPercentage| |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorHits| |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorInvocations| |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorMaxInvocationTime| |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorMinInvocationTime| |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorMisses| |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorMissPercentage| |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorPuts| |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorReadOnlyInvocations| |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheClusterMetricsMXBeanImpl"|EntryProcessorRemovals| |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|RebalancedKeys| |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EstimatedRebalancingKeys| |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|RebalanceClearingPartitionsLeft| |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorAverageInvocationTime| |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorHitPercentage| |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorHits| |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorInvocations| |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorMaxInvocationTime| |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorMinInvocationTime| |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorMisses| |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorMissPercentage| |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorPuts| |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorReadOnlyInvocations| |org.apache:group=CACHE_NAME,name="org.apache.ignite.internal.processors.cache.CacheLocalMetricsMXBeanImpl"|EntryProcessorRemovals| -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13951) Improve metric description
Alexand Polyakov created IGNITE-13951: - Summary: Improve metric description Key: IGNITE-13951 URL: https://issues.apache.org/jira/browse/IGNITE-13951 Project: Ignite Issue Type: Improvement Reporter: Alexand Polyakov Assignee: Alexand Polyakov There are a lot of metrics in jmx with useless description. There are a lot of metrics in jmx with useless description. Under this task I'll create sub-tasks to improve descriptions. * Cache metrics without description * Detaregion metrics without description * TcpDiscoverySpi incomprehensible metric description * Thread Pools incomprehensible metric description * ManagementEnabled incomprehensible metric description -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13689) Extend test coverage [IGNITE-11512] Add counter left partition for index rebuild in CacheGroupMetricsMXBean
[ https://issues.apache.org/jira/browse/IGNITE-13689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228942#comment-17228942 ] Alexand Polyakov commented on IGNITE-13689: --- Run TC https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_RunAll/5726883 > Extend test coverage [IGNITE-11512] Add counter left partition for index > rebuild in CacheGroupMetricsMXBean > --- > > Key: IGNITE-13689 > URL: https://issues.apache.org/jira/browse/IGNITE-13689 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.9 >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > Labels: test > Time Spent: 10m > Remaining Estimate: 0h > > New test: > Partial rebuild > # Start cluster, load data with indexes > # Kill single node, create new index, start node. > # Make sure that index rebuild count is in range of total new index size and > 0 and decreasing > # Wait until rebuild finished, assert that no index errors -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13689) Extend test coverage [IGNITE-11512] Add counter left partition for index rebuild in CacheGroupMetricsMXBean
[ https://issues.apache.org/jira/browse/IGNITE-13689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228940#comment-17228940 ] Alexand Polyakov commented on IGNITE-13689: --- Create branch https://github.com/gridgain/apache-ignite/tree/ignite-13689 > Extend test coverage [IGNITE-11512] Add counter left partition for index > rebuild in CacheGroupMetricsMXBean > --- > > Key: IGNITE-13689 > URL: https://issues.apache.org/jira/browse/IGNITE-13689 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.9 >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > Labels: test > Time Spent: 10m > Remaining Estimate: 0h > > New test: > Partial rebuild > # Start cluster, load data with indexes > # Kill single node, create new index, start node. > # Make sure that index rebuild count is in range of total new index size and > 0 and decreasing > # Wait until rebuild finished, assert that no index errors -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13689) Extend test coverage [IGNITE-11512] Add counter left partition for index rebuild in CacheGroupMetricsMXBean
[ https://issues.apache.org/jira/browse/IGNITE-13689?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228941#comment-17228941 ] Alexand Polyakov commented on IGNITE-13689: --- Create pull request https://github.com/apache/ignite/pull/8444 > Extend test coverage [IGNITE-11512] Add counter left partition for index > rebuild in CacheGroupMetricsMXBean > --- > > Key: IGNITE-13689 > URL: https://issues.apache.org/jira/browse/IGNITE-13689 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.9 >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > Labels: test > Time Spent: 10m > Remaining Estimate: 0h > > New test: > Partial rebuild > # Start cluster, load data with indexes > # Kill single node, create new index, start node. > # Make sure that index rebuild count is in range of total new index size and > 0 and decreasing > # Wait until rebuild finished, assert that no index errors -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13689) Extend test coverage [IGNITE-11512] Add counter left partition for index rebuild in CacheGroupMetricsMXBean
Alexand Polyakov created IGNITE-13689: - Summary: Extend test coverage [IGNITE-11512] Add counter left partition for index rebuild in CacheGroupMetricsMXBean Key: IGNITE-13689 URL: https://issues.apache.org/jira/browse/IGNITE-13689 Project: Ignite Issue Type: Improvement Components: general Affects Versions: 2.9 Reporter: Alexand Polyakov Assignee: Alexand Polyakov New test: Partial rebuild # Start cluster, load data with indexes # Kill single node, create new index, start node. # Make sure that index rebuild count is in range of total new index size and 0 and decreasing # Wait until rebuild finished, assert that no index errors -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13687) Improvement of human-readable format of WAL records (StandaloneWalRecordsIterator)
[ https://issues.apache.org/jira/browse/IGNITE-13687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228884#comment-17228884 ] Alexand Polyakov commented on IGNITE-13687: --- Link TC bot https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull/8441/head=Latest > Improvement of human-readable format of WAL records > (StandaloneWalRecordsIterator) > -- > > Key: IGNITE-13687 > URL: https://issues.apache.org/jira/browse/IGNITE-13687 > Project: Ignite > Issue Type: Improvement > Components: persistence >Affects Versions: 2.9 >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > StandaloneWalRecordsIterator is used for PageHistoryDiagnoster and wal-reader > utility for printing WAL records in human-readable format. We should add > abilities for this iterator and options for IgniteWalIteratorFactory: > to print DataRecord entries keys in hex/base64 (see UnwrapDataEntry) > to print all records existing in WAL -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-13687) Improvement of human-readable format of WAL records (StandaloneWalRecordsIterator)
[ https://issues.apache.org/jira/browse/IGNITE-13687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228883#comment-17228883 ] Alexand Polyakov edited comment on IGNITE-13687 at 11/10/20, 12:48 AM: --- Run TC https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_RunAll/5726394 was (Author: a-polyakov): Run TC Run TC https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_RunAll/5726394 > Improvement of human-readable format of WAL records > (StandaloneWalRecordsIterator) > -- > > Key: IGNITE-13687 > URL: https://issues.apache.org/jira/browse/IGNITE-13687 > Project: Ignite > Issue Type: Improvement > Components: persistence >Affects Versions: 2.9 >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > StandaloneWalRecordsIterator is used for PageHistoryDiagnoster and wal-reader > utility for printing WAL records in human-readable format. We should add > abilities for this iterator and options for IgniteWalIteratorFactory: > to print DataRecord entries keys in hex/base64 (see UnwrapDataEntry) > to print all records existing in WAL -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13687) Improvement of human-readable format of WAL records (StandaloneWalRecordsIterator)
[ https://issues.apache.org/jira/browse/IGNITE-13687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228883#comment-17228883 ] Alexand Polyakov commented on IGNITE-13687: --- Run TC Run TC https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_RunAll/5726394 > Improvement of human-readable format of WAL records > (StandaloneWalRecordsIterator) > -- > > Key: IGNITE-13687 > URL: https://issues.apache.org/jira/browse/IGNITE-13687 > Project: Ignite > Issue Type: Improvement > Components: persistence >Affects Versions: 2.9 >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > StandaloneWalRecordsIterator is used for PageHistoryDiagnoster and wal-reader > utility for printing WAL records in human-readable format. We should add > abilities for this iterator and options for IgniteWalIteratorFactory: > to print DataRecord entries keys in hex/base64 (see UnwrapDataEntry) > to print all records existing in WAL -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13687) Improvement of human-readable format of WAL records (StandaloneWalRecordsIterator)
[ https://issues.apache.org/jira/browse/IGNITE-13687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228656#comment-17228656 ] Alexand Polyakov commented on IGNITE-13687: --- Run TC https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_RunAll/5724563 > Improvement of human-readable format of WAL records > (StandaloneWalRecordsIterator) > -- > > Key: IGNITE-13687 > URL: https://issues.apache.org/jira/browse/IGNITE-13687 > Project: Ignite > Issue Type: Improvement > Components: persistence >Affects Versions: 2.9 >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > StandaloneWalRecordsIterator is used for PageHistoryDiagnoster and wal-reader > utility for printing WAL records in human-readable format. We should add > abilities for this iterator and options for IgniteWalIteratorFactory: > to print DataRecord entries keys in hex/base64 (see UnwrapDataEntry) > to print all records existing in WAL -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13687) Improvement of human-readable format of WAL records (StandaloneWalRecordsIterator)
[ https://issues.apache.org/jira/browse/IGNITE-13687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228644#comment-17228644 ] Alexand Polyakov commented on IGNITE-13687: --- Create pull request https://github.com/apache/ignite/pull/8441 > Improvement of human-readable format of WAL records > (StandaloneWalRecordsIterator) > -- > > Key: IGNITE-13687 > URL: https://issues.apache.org/jira/browse/IGNITE-13687 > Project: Ignite > Issue Type: Improvement > Components: persistence >Affects Versions: 2.9 >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > StandaloneWalRecordsIterator is used for PageHistoryDiagnoster and wal-reader > utility for printing WAL records in human-readable format. We should add > abilities for this iterator and options for IgniteWalIteratorFactory: > to print DataRecord entries keys in hex/base64 (see UnwrapDataEntry) > to print all records existing in WAL -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13687) Improvement of human-readable format of WAL records (StandaloneWalRecordsIterator)
[ https://issues.apache.org/jira/browse/IGNITE-13687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17228643#comment-17228643 ] Alexand Polyakov commented on IGNITE-13687: --- Create branch https://github.com/gridgain/apache-ignite/tree/ignite-13687 > Improvement of human-readable format of WAL records > (StandaloneWalRecordsIterator) > -- > > Key: IGNITE-13687 > URL: https://issues.apache.org/jira/browse/IGNITE-13687 > Project: Ignite > Issue Type: Improvement > Components: persistence >Affects Versions: 2.9 >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > > StandaloneWalRecordsIterator is used for PageHistoryDiagnoster and wal-reader > utility for printing WAL records in human-readable format. We should add > abilities for this iterator and options for IgniteWalIteratorFactory: > to print DataRecord entries keys in hex/base64 (see UnwrapDataEntry) > to print all records existing in WAL -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13687) Improvement of human-readable format of WAL records (StandaloneWalRecordsIterator)
Alexand Polyakov created IGNITE-13687: - Summary: Improvement of human-readable format of WAL records (StandaloneWalRecordsIterator) Key: IGNITE-13687 URL: https://issues.apache.org/jira/browse/IGNITE-13687 Project: Ignite Issue Type: Improvement Components: persistence Affects Versions: 2.9 Reporter: Alexand Polyakov Assignee: Alexand Polyakov StandaloneWalRecordsIterator is used for PageHistoryDiagnoster and wal-reader utility for printing WAL records in human-readable format. We should add abilities for this iterator and options for IgniteWalIteratorFactory: to print DataRecord entries keys in hex/base64 (see UnwrapDataEntry) to print all records existing in WAL -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13518) Change static cache configuration allowed or not and what operations: add column, drop
[ https://issues.apache.org/jira/browse/IGNITE-13518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexand Polyakov updated IGNITE-13518: -- Description: Now (version 2.5 and 2.7 and 2.8.1 and master) If cluster deactivate and new node join with a modified configuration cache, the configuration is merged and a new column is added. [^Ignite13518CaseAdd.java] If the cluster is restarted with a new cache configuration, the changes are ignored and the column is not added [^Ignite13518CaseIgnore.java] If node with a modified configuration cache join to active cluster then throw error [^Ignite13518CaseError.java] 1. need to determine whether to allow changing the static cache configuration or not to allow it 2. the behavior should be the same (restart cluster, join node to deactivate cluster, join node to active cluster) 3. the behavior is not described in the documentation 4. How static cache configuration interacts with dynamic changes from SQL? 5. Export/import database schema 6. There are no messages in the application logs about changing the cache configuration (or about a ban based on the result of point 1) 7. If the configuration can be changed, what should I do with the fields that are missing in the new version of the configuration - delete column? if they were added using SQL was: Now (version 2.5 and 2.8.1 and master) If cluster deactivate and new node join with a modified configuration cache, the configuration is merged and a new column is added. [^Ignite13518CaseAdd.java] If the cluster is restarted with a new cache configuration, the changes are ignored and the column is not added [^Ignite13518CaseIgnore.java] If node with a modified configuration cache join to active cluster then throw error [^Ignite13518CaseError.java] 1. need to determine whether to allow changing the static cache configuration or not to allow it 2. the behavior should be the same (restart cluster, join node to deactivate cluster, join node to active cluster) 3. the behavior is not described in the documentation 4. How static cache configuration interacts with dynamic changes from SQL? 5. Export/import database schema 6. There are no messages in the application logs about changing the cache configuration (or about a ban based on the result of point 1) 7. If the configuration can be changed, what should I do with the fields that are missing in the new version of the configuration - delete column? if they were added using SQL > Change static cache configuration allowed or not and what operations: add > column, drop > -- > > Key: IGNITE-13518 > URL: https://issues.apache.org/jira/browse/IGNITE-13518 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.8.1 >Reporter: Alexand Polyakov >Priority: Major > Attachments: Ignite13518CaseAdd.java, Ignite13518CaseError.java, > Ignite13518CaseIgnore.java > > > Now (version 2.5 and 2.7 and 2.8.1 and master) > If cluster deactivate and new node join with a modified configuration cache, > the configuration is merged and a new column is added. > [^Ignite13518CaseAdd.java] > If the cluster is restarted with a new cache configuration, the changes are > ignored and the column is not added [^Ignite13518CaseIgnore.java] > If node with a modified configuration cache join to active cluster then throw > error [^Ignite13518CaseError.java] > 1. need to determine whether to allow changing the static cache configuration > or not to allow it > 2. the behavior should be the same (restart cluster, join node to deactivate > cluster, join node to active cluster) > 3. the behavior is not described in the documentation > 4. How static cache configuration interacts with dynamic changes from SQL? > 5. Export/import database schema > 6. There are no messages in the application logs about changing the cache > configuration (or about a ban based on the result of point 1) > 7. If the configuration can be changed, what should I do with the fields that > are missing in the new version of the configuration - delete column? if they > were added using SQL -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13518) Change static cache configuration allowed or not and what operations: add column, drop
[ https://issues.apache.org/jira/browse/IGNITE-13518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexand Polyakov updated IGNITE-13518: -- Description: Now (version 2.5 and 2.8.1 and master) If cluster deactivate and new node join with a modified configuration cache, the configuration is merged and a new column is added. [^Ignite13518CaseAdd.java] If the cluster is restarted with a new cache configuration, the changes are ignored and the column is not added [^Ignite13518CaseIgnore.java] If node with a modified configuration cache join to active cluster then throw error [^Ignite13518CaseError.java] 1. need to determine whether to allow changing the static cache configuration or not to allow it 2. the behavior should be the same (restart cluster, join node to deactivate cluster, join node to active cluster) 3. the behavior is not described in the documentation 4. How static cache configuration interacts with dynamic changes from SQL? 5. Export/import database schema 6. There are no messages in the application logs about changing the cache configuration (or about a ban based on the result of point 1) 7. If the configuration can be changed, what should I do with the fields that are missing in the new version of the configuration - delete column? if they were added using SQL was: Now (version 2.8.1 or master) If cluster deactivate and new node join with a modified configuration cache, the configuration is merged and a new column is added. [^Ignite13518CaseAdd.java] If the cluster is restarted with a new cache configuration, the changes are ignored and the column is not added [^Ignite13518CaseIgnore.java] If node with a modified configuration cache join to active cluster then throw error [^Ignite13518CaseError.java] 1. need to determine whether to allow changing the static cache configuration or not to allow it 2. the behavior should be the same (restart cluster, join node to deactivate cluster, join node to active cluster) 3. the behavior is not described in the documentation 4. How static cache configuration interacts with dynamic changes from SQL? 5. Export/import database schema 6. There are no messages in the application logs about changing the cache configuration (or about a ban based on the result of point 1) 7. If the configuration can be changed, what should I do with the fields that are missing in the new version of the configuration - delete column? if they were added using SQL > Change static cache configuration allowed or not and what operations: add > column, drop > -- > > Key: IGNITE-13518 > URL: https://issues.apache.org/jira/browse/IGNITE-13518 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.8.1 >Reporter: Alexand Polyakov >Priority: Major > Attachments: Ignite13518CaseAdd.java, Ignite13518CaseError.java, > Ignite13518CaseIgnore.java > > > Now (version 2.5 and 2.8.1 and master) > If cluster deactivate and new node join with a modified configuration cache, > the configuration is merged and a new column is added. > [^Ignite13518CaseAdd.java] > If the cluster is restarted with a new cache configuration, the changes are > ignored and the column is not added [^Ignite13518CaseIgnore.java] > If node with a modified configuration cache join to active cluster then throw > error [^Ignite13518CaseError.java] > 1. need to determine whether to allow changing the static cache configuration > or not to allow it > 2. the behavior should be the same (restart cluster, join node to deactivate > cluster, join node to active cluster) > 3. the behavior is not described in the documentation > 4. How static cache configuration interacts with dynamic changes from SQL? > 5. Export/import database schema > 6. There are no messages in the application logs about changing the cache > configuration (or about a ban based on the result of point 1) > 7. If the configuration can be changed, what should I do with the fields that > are missing in the new version of the configuration - delete column? if they > were added using SQL -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13518) Change static cache configuration allowed or not and what operations: add column, drop
[ https://issues.apache.org/jira/browse/IGNITE-13518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexand Polyakov updated IGNITE-13518: -- Description: Now (version 2.8.1 or master) If cluster deactivate and new node join with a modified configuration cache, the configuration is merged and a new column is added. [^Ignite13518CaseAdd.java] If the cluster is restarted with a new cache configuration, the changes are ignored and the column is not added [^Ignite13518CaseIgnore.java] If node with a modified configuration cache join to active cluster then throw error [^Ignite13518CaseError.java] 1. need to determine whether to allow changing the static cache configuration or not to allow it 2. the behavior should be the same (restart cluster, join node to deactivate cluster, join node to active cluster) 3. the behavior is not described in the documentation 4. How static cache configuration interacts with dynamic changes from SQL? 5. Export/import database schema 6. There are no messages in the application logs about changing the cache configuration (or about a ban based on the result of point 1) 7. If the configuration can be changed, what should I do with the fields that are missing in the new version of the configuration - delete column? if they were added using SQL was: If cluster deactivate and new node join with a modified configuration cache, the configuration is merged and a new column is added. [^Ignite13518CaseAdd.java] If the cluster is restarted with a new cache configuration, the changes are ignored and the column is not added [^Ignite13518CaseIgnore.java] If node with a modified configuration cache join to active cluster then throw error [^Ignite13518CaseError.java] 1. need to determine whether to allow changing the static cache configuration or not to allow it 2. the behavior should be the same (restart cluster, join node to deactivate cluster, join node to active cluster) 3. the behavior is not described in the documentation 4. How static cache configuration interacts with dynamic changes from SQL? 5. Export/import database schema 6. There are no messages in the application logs about changing the cache configuration (or about a ban based on the result of point 1) 7. If the configuration can be changed, what should I do with the fields that are missing in the new version of the configuration - delete column? if they were added using SQL > Change static cache configuration allowed or not and what operations: add > column, drop > -- > > Key: IGNITE-13518 > URL: https://issues.apache.org/jira/browse/IGNITE-13518 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.8.1 >Reporter: Alexand Polyakov >Priority: Major > Attachments: Ignite13518CaseAdd.java, Ignite13518CaseError.java, > Ignite13518CaseIgnore.java > > > Now (version 2.8.1 or master) > If cluster deactivate and new node join with a modified configuration cache, > the configuration is merged and a new column is added. > [^Ignite13518CaseAdd.java] > If the cluster is restarted with a new cache configuration, the changes are > ignored and the column is not added [^Ignite13518CaseIgnore.java] > If node with a modified configuration cache join to active cluster then throw > error [^Ignite13518CaseError.java] > 1. need to determine whether to allow changing the static cache configuration > or not to allow it > 2. the behavior should be the same (restart cluster, join node to deactivate > cluster, join node to active cluster) > 3. the behavior is not described in the documentation > 4. How static cache configuration interacts with dynamic changes from SQL? > 5. Export/import database schema > 6. There are no messages in the application logs about changing the cache > configuration (or about a ban based on the result of point 1) > 7. If the configuration can be changed, what should I do with the fields that > are missing in the new version of the configuration - delete column? if they > were added using SQL -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13518) Change static cache configuration allowed or not and what operations: add column, drop
[ https://issues.apache.org/jira/browse/IGNITE-13518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexand Polyakov updated IGNITE-13518: -- Description: If cluster deactivate and new node join with a modified configuration cache, the configuration is merged and a new column is added. [^Ignite13518CaseAdd.java] If the cluster is restarted with a new cache configuration, the changes are ignored and the column is not added [^Ignite13518CaseIgnore.java] If node with a modified configuration cache join to active cluster then throw error [^Ignite13518CaseError.java] 1. need to determine whether to allow changing the static cache configuration or not to allow it 2. the behavior should be the same (restart cluster, join node to deactivate cluster, join node to active cluster) 3. the behavior is not described in the documentation 4. How static cache configuration interacts with dynamic changes from SQL? 5. Export/import database schema 6. There are no messages in the application logs about changing the cache configuration (or about a ban based on the result of point 1) 7. If the configuration can be changed, what should I do with the fields that are missing in the new version of the configuration - delete column? if they were added using SQL was: If cluster deactivate and new node join with a modified configuration cache, the configuration is merged and a new column is added. [^Ignite13518CaseAdd.java] If the cluster is restarted with a new cache configuration, the changes are ignored and the column is not added [^Ignite13518CaseIgnore.java] If node with a modified configuration cache join to active cluster then throw error [^Ignite13518CaseError.java] 1. you need to determine whether to allow changing the static cache configuration or not to allow it 2. the behavior should be the same (restart cluster, join node to deactivate cluster, join node to active cluster) 3. the behavior is not described in the documentation 4. How static cache configuration interacts with dynamic changes from SQL? 5. Export/import database schema 6. There are no messages in the application logs about changing the cache configuration (or about a ban based on the result of point 1) 7. If the configuration can be changed, what should I do with the fields that are missing in the new version of the configuration - delete column? if they were added using SQL > Change static cache configuration allowed or not and what operations: add > column, drop > -- > > Key: IGNITE-13518 > URL: https://issues.apache.org/jira/browse/IGNITE-13518 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.8.1 >Reporter: Alexand Polyakov >Priority: Major > Attachments: Ignite13518CaseAdd.java, Ignite13518CaseError.java, > Ignite13518CaseIgnore.java > > > If cluster deactivate and new node join with a modified configuration cache, > the configuration is merged and a new column is added. > [^Ignite13518CaseAdd.java] > If the cluster is restarted with a new cache configuration, the changes are > ignored and the column is not added [^Ignite13518CaseIgnore.java] > If node with a modified configuration cache join to active cluster then throw > error [^Ignite13518CaseError.java] > 1. need to determine whether to allow changing the static cache configuration > or not to allow it > 2. the behavior should be the same (restart cluster, join node to deactivate > cluster, join node to active cluster) > 3. the behavior is not described in the documentation > 4. How static cache configuration interacts with dynamic changes from SQL? > 5. Export/import database schema > 6. There are no messages in the application logs about changing the cache > configuration (or about a ban based on the result of point 1) > 7. If the configuration can be changed, what should I do with the fields that > are missing in the new version of the configuration - delete column? if they > were added using SQL -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13518) Change static cache configuration allowed or not and what operations: add column, drop
[ https://issues.apache.org/jira/browse/IGNITE-13518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexand Polyakov updated IGNITE-13518: -- Description: If cluster deactivate and new node join with a modified configuration cache, the configuration is merged and a new column is added. [^Ignite13518CaseAdd.java] If the cluster is restarted with a new cache configuration, the changes are ignored and the column is not added [^Ignite13518CaseIgnore.java] If node with a modified configuration cache join to active cluster then throw error [^Ignite13518CaseError.java] 1. you need to determine whether to allow changing the static cache configuration or not to allow it 2. the behavior should be the same (restart cluster, join node to deactivate cluster, join node to active cluster) 3. the behavior is not described in the documentation 4. How static cache configuration interacts with dynamic changes from SQL? 5. Export/import database schema 6. There are no messages in the application logs about changing the cache configuration (or about a ban based on the result of point 1) 7. If the configuration can be changed, what should I do with the fields that are missing in the new version of the configuration - delete column? if they were added using SQL was: If a new node with a modified configuration cache is connected, the configuration is merged and a new column is added. if the cluster is restarted with a new cache configuration, the changes are ignored and the column is not added 1. you need to determine whether to allow changing the static cache configuration or not to allow it 2. the behavior should be the same (restart cluster, join node) 3. the behavior is not described in the documentation 4. How static cache configuration interacts with dynamic changes from SQL? 5. Export/import database schema 6. There are no messages in the application logs about changing the cache configuration (or about a ban based on the result of point 1) 7. If the configuration can be changed, what should I do with the fields that are missing in the new version of the configuration - delete column? if they were added using SQL > Change static cache configuration allowed or not and what operations: add > column, drop > -- > > Key: IGNITE-13518 > URL: https://issues.apache.org/jira/browse/IGNITE-13518 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.8.1 >Reporter: Alexand Polyakov >Priority: Major > Attachments: Ignite13518CaseAdd.java, Ignite13518CaseError.java, > Ignite13518CaseIgnore.java > > > If cluster deactivate and new node join with a modified configuration cache, > the configuration is merged and a new column is added. > [^Ignite13518CaseAdd.java] > If the cluster is restarted with a new cache configuration, the changes are > ignored and the column is not added [^Ignite13518CaseIgnore.java] > If node with a modified configuration cache join to active cluster then throw > error [^Ignite13518CaseError.java] > 1. you need to determine whether to allow changing the static cache > configuration or not to allow it > 2. the behavior should be the same (restart cluster, join node to deactivate > cluster, join node to active cluster) > 3. the behavior is not described in the documentation > 4. How static cache configuration interacts with dynamic changes from SQL? > 5. Export/import database schema > 6. There are no messages in the application logs about changing the cache > configuration (or about a ban based on the result of point 1) > 7. If the configuration can be changed, what should I do with the fields that > are missing in the new version of the configuration - delete column? if they > were added using SQL -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13518) Change static cache configuration allowed or not and what operations: add column, drop
[ https://issues.apache.org/jira/browse/IGNITE-13518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexand Polyakov updated IGNITE-13518: -- Attachment: Ignite13518CaseError.java > Change static cache configuration allowed or not and what operations: add > column, drop > -- > > Key: IGNITE-13518 > URL: https://issues.apache.org/jira/browse/IGNITE-13518 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.8.1 >Reporter: Alexand Polyakov >Priority: Major > Attachments: Ignite13518CaseAdd.java, Ignite13518CaseError.java, > Ignite13518CaseIgnore.java > > > If a new node with a modified configuration cache is connected, the > configuration is merged and a new column is added. if the cluster is > restarted with a new cache configuration, the changes are ignored and the > column is not added > 1. you need to determine whether to allow changing the static cache > configuration or not to allow it > 2. the behavior should be the same (restart cluster, join node) > 3. the behavior is not described in the documentation > 4. How static cache configuration interacts with dynamic changes from SQL? > 5. Export/import database schema > 6. There are no messages in the application logs about changing the cache > configuration (or about a ban based on the result of point 1) > 7. If the configuration can be changed, what should I do with the fields that > are missing in the new version of the configuration - delete column? if they > were added using SQL -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13518) Change static cache configuration allowed or not and what operations: add column, drop
[ https://issues.apache.org/jira/browse/IGNITE-13518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexand Polyakov updated IGNITE-13518: -- Attachment: Ignite13518CaseIgnore.java > Change static cache configuration allowed or not and what operations: add > column, drop > -- > > Key: IGNITE-13518 > URL: https://issues.apache.org/jira/browse/IGNITE-13518 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.8.1 >Reporter: Alexand Polyakov >Priority: Major > Attachments: Ignite13518CaseAdd.java, Ignite13518CaseIgnore.java > > > If a new node with a modified configuration cache is connected, the > configuration is merged and a new column is added. if the cluster is > restarted with a new cache configuration, the changes are ignored and the > column is not added > 1. you need to determine whether to allow changing the static cache > configuration or not to allow it > 2. the behavior should be the same (restart cluster, join node) > 3. the behavior is not described in the documentation > 4. How static cache configuration interacts with dynamic changes from SQL? > 5. Export/import database schema > 6. There are no messages in the application logs about changing the cache > configuration (or about a ban based on the result of point 1) > 7. If the configuration can be changed, what should I do with the fields that > are missing in the new version of the configuration - delete column? if they > were added using SQL -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13518) Change static cache configuration allowed or not and what operations: add column, drop
[ https://issues.apache.org/jira/browse/IGNITE-13518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexand Polyakov updated IGNITE-13518: -- Attachment: Ignite13518CaseAdd.java > Change static cache configuration allowed or not and what operations: add > column, drop > -- > > Key: IGNITE-13518 > URL: https://issues.apache.org/jira/browse/IGNITE-13518 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.8.1 >Reporter: Alexand Polyakov >Priority: Major > Attachments: Ignite13518CaseAdd.java > > > If a new node with a modified configuration cache is connected, the > configuration is merged and a new column is added. if the cluster is > restarted with a new cache configuration, the changes are ignored and the > column is not added > 1. you need to determine whether to allow changing the static cache > configuration or not to allow it > 2. the behavior should be the same (restart cluster, join node) > 3. the behavior is not described in the documentation > 4. How static cache configuration interacts with dynamic changes from SQL? > 5. Export/import database schema > 6. There are no messages in the application logs about changing the cache > configuration (or about a ban based on the result of point 1) > 7. If the configuration can be changed, what should I do with the fields that > are missing in the new version of the configuration - delete column? if they > were added using SQL -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-13518) Change static cache configuration allowed or not and what operations: add column, drop
Alexand Polyakov created IGNITE-13518: - Summary: Change static cache configuration allowed or not and what operations: add column, drop Key: IGNITE-13518 URL: https://issues.apache.org/jira/browse/IGNITE-13518 Project: Ignite Issue Type: Bug Components: cache Affects Versions: 2.8.1 Reporter: Alexand Polyakov If a new node with a modified configuration cache is connected, the configuration is merged and a new column is added. if the cluster is restarted with a new cache configuration, the changes are ignored and the column is not added 1. you need to determine whether to allow changing the static cache configuration or not to allow it 2. the behavior should be the same (restart cluster, join node) 3. the behavior is not described in the documentation 4. How static cache configuration interacts with dynamic changes from SQL? 5. Export/import database schema 6. There are no messages in the application logs about changing the cache configuration (or about a ban based on the result of point 1) 7. If the configuration can be changed, what should I do with the fields that are missing in the new version of the configuration - delete column? if they were added using SQL -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-13175) NPE due to race on cache stop and transaction commit.
[
https://issues.apache.org/jira/browse/IGNITE-13175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17179314#comment-17179314
]
Alexand Polyakov commented on IGNITE-13175:
---
[^IGNITE-13175_add_test.patch] implementation test, add it to pull request
> NPE due to race on cache stop and transaction commit.
> -
>
> Key: IGNITE-13175
> URL: https://issues.apache.org/jira/browse/IGNITE-13175
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Alexand Polyakov
>Assignee: Maria Makedonskaya
>Priority: Major
> Attachments: IGNITE-13175_add_test.patch,
> IGNITE-13175_reproducer.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If don't stop load and execute stop cache, sometimes throw
> NullPointerException and nodes failed
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.finishUnmarshal(BinaryObjectImpl.java:190)
> at
> org.apache.ignite.internal.processors.cache.transactions.TxEntryValueHolder.unmarshal(TxEntryValueHolder.java:154)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxEntry.unmarshal(IgniteTxEntry.java:971)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.unmarshal(IgniteTxHandler.java:354)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:403)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:386)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:188)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.lambda$null$0(IgniteTxHandler.java:644)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:559)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> transaction use cache context race with stopCache
> {code:java}
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.cleanup(GridCacheContext.java:2058)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.cleanup(GridCacheProcessor.java:467)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCache(GridCacheProcessor.java:1020)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2539)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2518)
> {code}
> there is a reproducer who adds CountDownLatch await to
> IgniteTxEntry#unmarshal which is countDown in GridCacheContext#cleanup
> https://github.com/gridgain/gridgain/tree/sdsb-11837
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13175) NPE due to race on cache stop and transaction commit.
[
https://issues.apache.org/jira/browse/IGNITE-13175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexand Polyakov updated IGNITE-13175:
--
Attachment: IGNITE-13175_add_test.patch
> NPE due to race on cache stop and transaction commit.
> -
>
> Key: IGNITE-13175
> URL: https://issues.apache.org/jira/browse/IGNITE-13175
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7
>Reporter: Alexand Polyakov
>Assignee: Maria Makedonskaya
>Priority: Major
> Attachments: IGNITE-13175_add_test.patch,
> IGNITE-13175_reproducer.patch
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If don't stop load and execute stop cache, sometimes throw
> NullPointerException and nodes failed
> {code}
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.finishUnmarshal(BinaryObjectImpl.java:190)
> at
> org.apache.ignite.internal.processors.cache.transactions.TxEntryValueHolder.unmarshal(TxEntryValueHolder.java:154)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxEntry.unmarshal(IgniteTxEntry.java:971)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.unmarshal(IgniteTxHandler.java:354)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:403)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:386)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:188)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.lambda$null$0(IgniteTxHandler.java:644)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:559)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> transaction use cache context race with stopCache
> {code:java}
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.cleanup(GridCacheContext.java:2058)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.cleanup(GridCacheProcessor.java:467)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCache(GridCacheProcessor.java:1020)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2539)
> at
> org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2518)
> {code}
> there is a reproducer who adds CountDownLatch await to
> IgniteTxEntry#unmarshal which is countDown in GridCacheContext#cleanup
> https://github.com/gridgain/gridgain/tree/sdsb-11837
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13175) NPE due to race on cache stop and transaction commit.
Alexand Polyakov created IGNITE-13175:
-
Summary: NPE due to race on cache stop and transaction commit.
Key: IGNITE-13175
URL: https://issues.apache.org/jira/browse/IGNITE-13175
Project: Ignite
Issue Type: Bug
Affects Versions: 2.7
Reporter: Alexand Polyakov
If don't stop load and execute stop cache, sometimes throw NullPointerException
and nodes failed
{code}
java.lang.NullPointerException: null
at
org.apache.ignite.internal.binary.BinaryObjectImpl.finishUnmarshal(BinaryObjectImpl.java:190)
at
org.apache.ignite.internal.processors.cache.transactions.TxEntryValueHolder.unmarshal(TxEntryValueHolder.java:154)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxEntry.unmarshal(IgniteTxEntry.java:971)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.unmarshal(IgniteTxHandler.java:354)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:403)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.prepareNearTx(IgniteTxHandler.java:386)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processNearTxPrepareRequest0(IgniteTxHandler.java:188)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.lambda$null$0(IgniteTxHandler.java:644)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:559)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
at java.lang.Thread.run(Thread.java:748)
{code}
transaction use cache context race with stopCache
{code:java}
at
org.apache.ignite.internal.processors.cache.GridCacheContext.cleanup(GridCacheContext.java:2058)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.cleanup(GridCacheProcessor.java:467)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.stopCache(GridCacheProcessor.java:1020)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2539)
at
org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheStop(GridCacheProcessor.java:2518)
{code}
there is a reproducer who adds CountDownLatch await to IgniteTxEntry#unmarshal
which is countDown in GridCacheContext#cleanup
https://github.com/gridgain/gridgain/tree/sdsb-11837
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13165) NPE when control utility connect to cluster (VisorTxTask)
[
https://issues.apache.org/jira/browse/IGNITE-13165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexand Polyakov updated IGNITE-13165:
--
Attachment: error.txt
> NPE when control utility connect to cluster (VisorTxTask)
> -
>
> Key: IGNITE-13165
> URL: https://issues.apache.org/jira/browse/IGNITE-13165
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Alexand Polyakov
>Priority: Major
> Attachments: error.txt, screenshot-1.png
>
>
> NullPointerException when control utility connect to cluster for execute
> VisorTxTask
> {code:java}
> 2020-05-18
> 02:47:12.070[ERROR][mgmt-#305526%DPL_GRID%DplGridNodeName%][o.a.i.i.p.r.p.t.GridTcpRestProtocol]
> Failed to process client request [ses=GridSelectorNioSessionImpl
> [worker=GridWorker [name=grid-nio-worker-tcp-rest-1,
> igniteInstanceName=DPL_GRID%DplGridNodeName, finished=false,
> heartbeatTs=1589759232067, hashCode=676612820, interrupted=false,
> runner=grid-nio-worker-tcp-rest-1-#143%DPL_GRID%DplGridNodeName%]AbstractNioClientWorker
> [idx=1, bytesRcvd=0, bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=false,
> super=]ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=85
> lim=85 cap=8192], super=], writeBuf=null, readBuf=null, inRecovery=null,
> outRecovery=null, super=GridNioSessionImpl [locAddr=/10.104.6.24:11211,
> rmtAddr=10.104.6.100:57054, createTime=1589759103528,
> closeTime=1589759232067, bytesSent=10011, bytesRcvd=10203, bytesSent0=85,
> bytesRcvd0=85, sndSchedTime=1589759232057, lastSndTime=1589759232067,
> lastRcvTime=1589759230548, readsPaused=false,
> filterChain=FilterChain[filters=[, SSL filter], accepted=true,
> markedForClose=true]], msg=GridClientTaskRequest
> [taskName=o.a.i.i.v.tx.VisorTxTask, arg=VisorTaskArgument [debug=false]]]
> ...
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:293)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:204)
> ... 87 common frames omitted
> {code}
> full stack trace [^error.txt]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13165) NPE when control utility connect to cluster (VisorTxTask)
[
https://issues.apache.org/jira/browse/IGNITE-13165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexand Polyakov updated IGNITE-13165:
--
Attachment: (was: error.txt)
> NPE when control utility connect to cluster (VisorTxTask)
> -
>
> Key: IGNITE-13165
> URL: https://issues.apache.org/jira/browse/IGNITE-13165
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Alexand Polyakov
>Priority: Major
> Attachments: error.txt, screenshot-1.png
>
>
> NullPointerException when control utility connect to cluster for execute
> VisorTxTask
> {code:java}
> 2020-05-18
> 02:47:12.070[ERROR][mgmt-#305526%DPL_GRID%DplGridNodeName%][o.a.i.i.p.r.p.t.GridTcpRestProtocol]
> Failed to process client request [ses=GridSelectorNioSessionImpl
> [worker=GridWorker [name=grid-nio-worker-tcp-rest-1,
> igniteInstanceName=DPL_GRID%DplGridNodeName, finished=false,
> heartbeatTs=1589759232067, hashCode=676612820, interrupted=false,
> runner=grid-nio-worker-tcp-rest-1-#143%DPL_GRID%DplGridNodeName%]AbstractNioClientWorker
> [idx=1, bytesRcvd=0, bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=false,
> super=]ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=85
> lim=85 cap=8192], super=], writeBuf=null, readBuf=null, inRecovery=null,
> outRecovery=null, super=GridNioSessionImpl [locAddr=/10.104.6.24:11211,
> rmtAddr=10.104.6.100:57054, createTime=1589759103528,
> closeTime=1589759232067, bytesSent=10011, bytesRcvd=10203, bytesSent0=85,
> bytesRcvd0=85, sndSchedTime=1589759232057, lastSndTime=1589759232067,
> lastRcvTime=1589759230548, readsPaused=false,
> filterChain=FilterChain[filters=[, SSL filter], accepted=true,
> markedForClose=true]], msg=GridClientTaskRequest
> [taskName=o.a.i.i.v.tx.VisorTxTask, arg=VisorTaskArgument [debug=false]]]
> ...
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:293)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:204)
> ... 87 common frames omitted
> {code}
> full stack trace [^error.txt]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13165) NPE when control utility connect to cluster (VisorTxTask)
[
https://issues.apache.org/jira/browse/IGNITE-13165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexand Polyakov updated IGNITE-13165:
--
Description:
NullPointerException when control utility connect to cluster for execute
VisorTxTask
{code:java}
2020-05-18
02:47:12.070[ERROR][mgmt-#305526%DPL_GRID%DplGridNodeName%][o.a.i.i.p.r.p.t.GridTcpRestProtocol]
Failed to process client request [ses=GridSelectorNioSessionImpl
[worker=GridWorker [name=grid-nio-worker-tcp-rest-1,
igniteInstanceName=DPL_GRID%DplGridNodeName, finished=false,
heartbeatTs=1589759232067, hashCode=676612820, interrupted=false,
runner=grid-nio-worker-tcp-rest-1-#143%DPL_GRID%DplGridNodeName%]AbstractNioClientWorker
[idx=1, bytesRcvd=0, bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=false,
super=]ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=85 lim=85
cap=8192], super=], writeBuf=null, readBuf=null, inRecovery=null,
outRecovery=null, super=GridNioSessionImpl [locAddr=/10.104.6.24:11211,
rmtAddr=10.104.6.100:57054, createTime=1589759103528, closeTime=1589759232067,
bytesSent=10011, bytesRcvd=10203, bytesSent0=85, bytesRcvd0=85,
sndSchedTime=1589759232057, lastSndTime=1589759232067,
lastRcvTime=1589759230548, readsPaused=false,
filterChain=FilterChain[filters=[, SSL filter], accepted=true,
markedForClose=true]], msg=GridClientTaskRequest
[taskName=o.a.i.i.v.tx.VisorTxTask, arg=VisorTaskArgument [debug=false]]]
...
Caused by: java.lang.NullPointerException: null
at
org.apache.ignite.internal.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:293)
at
org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:204)
... 87 common frames omitted
{code}
full stack trace [^error.txt]
was:
NullPointerException when control utility connect to cluster for execute
VisorTxTask
{code:java}
2020-05-18
02:47:12.070[ERROR][mgmt-#305526%DPL_GRID%DplGridNodeName%][o.a.i.i.p.r.p.t.GridTcpRestProtocol]
Failed to process client request [ses=GridSelectorNioSessionImpl
[worker=GridWorker [name=grid-nio-worker-tcp-rest-1,
igniteInstanceName=DPL_GRID%DplGridNodeName, finished=false,
heartbeatTs=1589759232067, hashCode=676612820, interrupted=false,
runner=grid-nio-worker-tcp-rest-1-#143%DPL_GRID%DplGridNodeName%]AbstractNioClientWorker
[idx=1, bytesRcvd=0, bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=false,
super=]ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=85 lim=85
cap=8192], super=], writeBuf=null, readBuf=null, inRecovery=null,
outRecovery=null, super=GridNioSessionImpl [locAddr=/10.104.6.24:11211,
rmtAddr=10.104.6.100:57054, createTime=1589759103528, closeTime=1589759232067,
bytesSent=10011, bytesRcvd=10203, bytesSent0=85, bytesRcvd0=85,
sndSchedTime=1589759232057, lastSndTime=1589759232067,
lastRcvTime=1589759230548, readsPaused=false,
filterChain=FilterChain[filters=[, SSL filter], accepted=true,
markedForClose=true]], msg=GridClientTaskRequest
[taskName=o.a.i.i.v.tx.VisorTxTask, arg=VisorTaskArgument [debug=false]]]
...
Caused by: java.lang.NullPointerException: null
at
org.apache.ignite.internal.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:293)
at
org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:204)
... 87 common frames omitted
{code}
full stack trace [^error_kanga24.txt]
> NPE when control utility connect to cluster (VisorTxTask)
> -
>
> Key: IGNITE-13165
> URL: https://issues.apache.org/jira/browse/IGNITE-13165
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Alexand Polyakov
>Priority: Major
> Attachments: error.txt, screenshot-1.png
>
>
> NullPointerException when control utility connect to cluster for execute
> VisorTxTask
> {code:java}
> 2020-05-18
> 02:47:12.070[ERROR][mgmt-#305526%DPL_GRID%DplGridNodeName%][o.a.i.i.p.r.p.t.GridTcpRestProtocol]
> Failed to process client request [ses=GridSelectorNioSessionImpl
> [worker=GridWorker [name=grid-nio-worker-tcp-rest-1,
> igniteInstanceName=DPL_GRID%DplGridNodeName, finished=false,
> heartbeatTs=1589759232067, hashCode=676612820, interrupted=false,
> runner=grid-nio-worker-tcp-rest-1-#143%DPL_GRID%DplGridNodeName%]AbstractNioClientWorker
> [idx=1, bytesRcvd=0, bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=false,
> super=]ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=85
> lim=85 cap=8192], super=], writeBuf=null, readBuf=null, inRecovery=null,
> outRecovery=null, super=GridNioSessionImpl [locAddr=/10.104.6.24:11211,
> rmtAddr=10.104.6.100:57054, createTime=1589759103528,
>
[jira] [Updated] (IGNITE-13165) NPE when control utility connect to cluster (VisorTxTask)
[
https://issues.apache.org/jira/browse/IGNITE-13165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexand Polyakov updated IGNITE-13165:
--
Attachment: (was: error_kanga24.txt)
> NPE when control utility connect to cluster (VisorTxTask)
> -
>
> Key: IGNITE-13165
> URL: https://issues.apache.org/jira/browse/IGNITE-13165
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Alexand Polyakov
>Priority: Major
> Attachments: error.txt, screenshot-1.png
>
>
> NullPointerException when control utility connect to cluster for execute
> VisorTxTask
> {code:java}
> 2020-05-18
> 02:47:12.070[ERROR][mgmt-#305526%DPL_GRID%DplGridNodeName%][o.a.i.i.p.r.p.t.GridTcpRestProtocol]
> Failed to process client request [ses=GridSelectorNioSessionImpl
> [worker=GridWorker [name=grid-nio-worker-tcp-rest-1,
> igniteInstanceName=DPL_GRID%DplGridNodeName, finished=false,
> heartbeatTs=1589759232067, hashCode=676612820, interrupted=false,
> runner=grid-nio-worker-tcp-rest-1-#143%DPL_GRID%DplGridNodeName%]AbstractNioClientWorker
> [idx=1, bytesRcvd=0, bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=false,
> super=]ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=85
> lim=85 cap=8192], super=], writeBuf=null, readBuf=null, inRecovery=null,
> outRecovery=null, super=GridNioSessionImpl [locAddr=/10.104.6.24:11211,
> rmtAddr=10.104.6.100:57054, createTime=1589759103528,
> closeTime=1589759232067, bytesSent=10011, bytesRcvd=10203, bytesSent0=85,
> bytesRcvd0=85, sndSchedTime=1589759232057, lastSndTime=1589759232067,
> lastRcvTime=1589759230548, readsPaused=false,
> filterChain=FilterChain[filters=[, SSL filter], accepted=true,
> markedForClose=true]], msg=GridClientTaskRequest
> [taskName=o.a.i.i.v.tx.VisorTxTask, arg=VisorTaskArgument [debug=false]]]
> ...
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:293)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:204)
> ... 87 common frames omitted
> {code}
> full stack trace [^error_kanga24.txt]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13165) NPE when control utility connect to cluster (VisorTxTask)
[
https://issues.apache.org/jira/browse/IGNITE-13165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexand Polyakov updated IGNITE-13165:
--
Attachment: error.txt
> NPE when control utility connect to cluster (VisorTxTask)
> -
>
> Key: IGNITE-13165
> URL: https://issues.apache.org/jira/browse/IGNITE-13165
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Alexand Polyakov
>Priority: Major
> Attachments: error.txt, screenshot-1.png
>
>
> NullPointerException when control utility connect to cluster for execute
> VisorTxTask
> {code:java}
> 2020-05-18
> 02:47:12.070[ERROR][mgmt-#305526%DPL_GRID%DplGridNodeName%][o.a.i.i.p.r.p.t.GridTcpRestProtocol]
> Failed to process client request [ses=GridSelectorNioSessionImpl
> [worker=GridWorker [name=grid-nio-worker-tcp-rest-1,
> igniteInstanceName=DPL_GRID%DplGridNodeName, finished=false,
> heartbeatTs=1589759232067, hashCode=676612820, interrupted=false,
> runner=grid-nio-worker-tcp-rest-1-#143%DPL_GRID%DplGridNodeName%]AbstractNioClientWorker
> [idx=1, bytesRcvd=0, bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=false,
> super=]ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=85
> lim=85 cap=8192], super=], writeBuf=null, readBuf=null, inRecovery=null,
> outRecovery=null, super=GridNioSessionImpl [locAddr=/10.104.6.24:11211,
> rmtAddr=10.104.6.100:57054, createTime=1589759103528,
> closeTime=1589759232067, bytesSent=10011, bytesRcvd=10203, bytesSent0=85,
> bytesRcvd0=85, sndSchedTime=1589759232057, lastSndTime=1589759232067,
> lastRcvTime=1589759230548, readsPaused=false,
> filterChain=FilterChain[filters=[, SSL filter], accepted=true,
> markedForClose=true]], msg=GridClientTaskRequest
> [taskName=o.a.i.i.v.tx.VisorTxTask, arg=VisorTaskArgument [debug=false]]]
> ...
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:293)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:204)
> ... 87 common frames omitted
> {code}
> full stack trace [^error_kanga24.txt]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13165) NPE when control utility connect to cluster (VisorTxTask)
[
https://issues.apache.org/jira/browse/IGNITE-13165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexand Polyakov updated IGNITE-13165:
--
Description:
NullPointerException when control utility connect to cluster for execute
VisorTxTask
{code:java}
2020-05-18
02:47:12.070[ERROR][mgmt-#305526%DPL_GRID%DplGridNodeName%][o.a.i.i.p.r.p.t.GridTcpRestProtocol]
Failed to process client request [ses=GridSelectorNioSessionImpl
[worker=GridWorker [name=grid-nio-worker-tcp-rest-1,
igniteInstanceName=DPL_GRID%DplGridNodeName, finished=false,
heartbeatTs=1589759232067, hashCode=676612820, interrupted=false,
runner=grid-nio-worker-tcp-rest-1-#143%DPL_GRID%DplGridNodeName%]AbstractNioClientWorker
[idx=1, bytesRcvd=0, bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=false,
super=]ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=85 lim=85
cap=8192], super=], writeBuf=null, readBuf=null, inRecovery=null,
outRecovery=null, super=GridNioSessionImpl [locAddr=/10.104.6.24:11211,
rmtAddr=10.104.6.100:57054, createTime=1589759103528, closeTime=1589759232067,
bytesSent=10011, bytesRcvd=10203, bytesSent0=85, bytesRcvd0=85,
sndSchedTime=1589759232057, lastSndTime=1589759232067,
lastRcvTime=1589759230548, readsPaused=false,
filterChain=FilterChain[filters=[, SSL filter], accepted=true,
markedForClose=true]], msg=GridClientTaskRequest
[taskName=o.a.i.i.v.tx.VisorTxTask, arg=VisorTaskArgument [debug=false]]]
...
Caused by: java.lang.NullPointerException: null
at
org.apache.ignite.internal.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:293)
at
org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:204)
... 87 common frames omitted
{code}
full stack trace [^error_kanga24.txt]
was:
NullPointerException when control utility connect to cluster for execute
VisorTxTask
{code:java}
2020-05-18
02:47:12.070[ERROR][mgmt-#305526%DPL_GRID%DplGridNodeName%][o.a.i.i.p.r.p.t.GridTcpRestProtocol]
Failed to process client request [ses=GridSelectorNioSessionImpl
[worker=GridWorker [name=grid-nio-worker-tcp-rest-1,
igniteInstanceName=DPL_GRID%DplGridNodeName, finished=false,
heartbeatTs=1589759232067, hashCode=676612820, interrupted=false,
runner=grid-nio-worker-tcp-rest-1-#143%DPL_GRID%DplGridNodeName%]AbstractNioClientWorker
[idx=1, bytesRcvd=0, bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=false,
super=]ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=85 lim=85
cap=8192], super=], writeBuf=null, readBuf=null, inRecovery=null,
outRecovery=null, super=GridNioSessionImpl [locAddr=/10.104.6.24:11211,
rmtAddr=unuratu101.ca.sbrf.ru/10.104.6.100:57054, createTime=1589759103528,
closeTime=1589759232067, bytesSent=10011, bytesRcvd=10203, bytesSent0=85,
bytesRcvd0=85, sndSchedTime=1589759232057, lastSndTime=1589759232067,
lastRcvTime=1589759230548, readsPaused=false,
filterChain=FilterChain[filters=[, SSL filter], accepted=true,
markedForClose=true]], msg=GridClientTaskRequest
[taskName=o.a.i.i.v.tx.VisorTxTask, arg=VisorTaskArgument [debug=false]]]
...
Caused by: java.lang.NullPointerException: null
at
org.apache.ignite.internal.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:293)
at
org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:204)
... 87 common frames omitted
{code}
full stack trace [^error_kanga24.txt]
> NPE when control utility connect to cluster (VisorTxTask)
> -
>
> Key: IGNITE-13165
> URL: https://issues.apache.org/jira/browse/IGNITE-13165
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Alexand Polyakov
>Priority: Major
> Attachments: error_kanga24.txt, screenshot-1.png
>
>
> NullPointerException when control utility connect to cluster for execute
> VisorTxTask
> {code:java}
> 2020-05-18
> 02:47:12.070[ERROR][mgmt-#305526%DPL_GRID%DplGridNodeName%][o.a.i.i.p.r.p.t.GridTcpRestProtocol]
> Failed to process client request [ses=GridSelectorNioSessionImpl
> [worker=GridWorker [name=grid-nio-worker-tcp-rest-1,
> igniteInstanceName=DPL_GRID%DplGridNodeName, finished=false,
> heartbeatTs=1589759232067, hashCode=676612820, interrupted=false,
> runner=grid-nio-worker-tcp-rest-1-#143%DPL_GRID%DplGridNodeName%]AbstractNioClientWorker
> [idx=1, bytesRcvd=0, bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=false,
> super=]ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=85
> lim=85 cap=8192], super=], writeBuf=null, readBuf=null, inRecovery=null,
> outRecovery=null, super=GridNioSessionImpl [locAddr=/10.104.6.24:11211,
> rmtAddr=10.104.6.100:57054,
[jira] [Commented] (IGNITE-13165) NPE when control utility connect to cluster (VisorTxTask)
[
https://issues.apache.org/jira/browse/IGNITE-13165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17140305#comment-17140305
]
Alexand Polyakov commented on IGNITE-13165:
---
Version 2.5.8-p5 (2.5.8#20190912-sha1:67c23274)
source !screenshot-1.png!
> NPE when control utility connect to cluster (VisorTxTask)
> -
>
> Key: IGNITE-13165
> URL: https://issues.apache.org/jira/browse/IGNITE-13165
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Alexand Polyakov
>Priority: Major
> Attachments: error_kanga24.txt, screenshot-1.png
>
>
> NullPointerException when control utility connect to cluster for execute
> VisorTxTask
> {code:java}
> 2020-05-18
> 02:47:12.070[ERROR][mgmt-#305526%DPL_GRID%DplGridNodeName%][o.a.i.i.p.r.p.t.GridTcpRestProtocol]
> Failed to process client request [ses=GridSelectorNioSessionImpl
> [worker=GridWorker [name=grid-nio-worker-tcp-rest-1,
> igniteInstanceName=DPL_GRID%DplGridNodeName, finished=false,
> heartbeatTs=1589759232067, hashCode=676612820, interrupted=false,
> runner=grid-nio-worker-tcp-rest-1-#143%DPL_GRID%DplGridNodeName%]AbstractNioClientWorker
> [idx=1, bytesRcvd=0, bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=false,
> super=]ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=85
> lim=85 cap=8192], super=], writeBuf=null, readBuf=null, inRecovery=null,
> outRecovery=null, super=GridNioSessionImpl [locAddr=/10.104.6.24:11211,
> rmtAddr=unuratu101.ca.sbrf.ru/10.104.6.100:57054, createTime=1589759103528,
> closeTime=1589759232067, bytesSent=10011, bytesRcvd=10203, bytesSent0=85,
> bytesRcvd0=85, sndSchedTime=1589759232057, lastSndTime=1589759232067,
> lastRcvTime=1589759230548, readsPaused=false,
> filterChain=FilterChain[filters=[, SSL filter], accepted=true,
> markedForClose=true]], msg=GridClientTaskRequest
> [taskName=o.a.i.i.v.tx.VisorTxTask, arg=VisorTaskArgument [debug=false]]]
> ...
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:293)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:204)
> ... 87 common frames omitted
> {code}
> full stack trace [^error_kanga24.txt]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13165) NPE when control utility connect to cluster (VisorTxTask)
[
https://issues.apache.org/jira/browse/IGNITE-13165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexand Polyakov updated IGNITE-13165:
--
Attachment: screenshot-1.png
> NPE when control utility connect to cluster (VisorTxTask)
> -
>
> Key: IGNITE-13165
> URL: https://issues.apache.org/jira/browse/IGNITE-13165
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Alexand Polyakov
>Priority: Major
> Attachments: error_kanga24.txt, screenshot-1.png
>
>
> NullPointerException when control utility connect to cluster for execute
> VisorTxTask
> {code:java}
> 2020-05-18
> 02:47:12.070[ERROR][mgmt-#305526%DPL_GRID%DplGridNodeName%][o.a.i.i.p.r.p.t.GridTcpRestProtocol]
> Failed to process client request [ses=GridSelectorNioSessionImpl
> [worker=GridWorker [name=grid-nio-worker-tcp-rest-1,
> igniteInstanceName=DPL_GRID%DplGridNodeName, finished=false,
> heartbeatTs=1589759232067, hashCode=676612820, interrupted=false,
> runner=grid-nio-worker-tcp-rest-1-#143%DPL_GRID%DplGridNodeName%]AbstractNioClientWorker
> [idx=1, bytesRcvd=0, bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=false,
> super=]ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=85
> lim=85 cap=8192], super=], writeBuf=null, readBuf=null, inRecovery=null,
> outRecovery=null, super=GridNioSessionImpl [locAddr=/10.104.6.24:11211,
> rmtAddr=unuratu101.ca.sbrf.ru/10.104.6.100:57054, createTime=1589759103528,
> closeTime=1589759232067, bytesSent=10011, bytesRcvd=10203, bytesSent0=85,
> bytesRcvd0=85, sndSchedTime=1589759232057, lastSndTime=1589759232067,
> lastRcvTime=1589759230548, readsPaused=false,
> filterChain=FilterChain[filters=[, SSL filter], accepted=true,
> markedForClose=true]], msg=GridClientTaskRequest
> [taskName=o.a.i.i.v.tx.VisorTxTask, arg=VisorTaskArgument [debug=false]]]
> ...
> Caused by: java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:293)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:204)
> ... 87 common frames omitted
> {code}
> full stack trace [^error_kanga24.txt]
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-13165) NPE when control utility connect to cluster (VisorTxTask)
Alexand Polyakov created IGNITE-13165:
-
Summary: NPE when control utility connect to cluster (VisorTxTask)
Key: IGNITE-13165
URL: https://issues.apache.org/jira/browse/IGNITE-13165
Project: Ignite
Issue Type: Bug
Affects Versions: 2.5
Reporter: Alexand Polyakov
Attachments: error_kanga24.txt
NullPointerException when control utility connect to cluster for execute
VisorTxTask
{code:java}
2020-05-18
02:47:12.070[ERROR][mgmt-#305526%DPL_GRID%DplGridNodeName%][o.a.i.i.p.r.p.t.GridTcpRestProtocol]
Failed to process client request [ses=GridSelectorNioSessionImpl
[worker=GridWorker [name=grid-nio-worker-tcp-rest-1,
igniteInstanceName=DPL_GRID%DplGridNodeName, finished=false,
heartbeatTs=1589759232067, hashCode=676612820, interrupted=false,
runner=grid-nio-worker-tcp-rest-1-#143%DPL_GRID%DplGridNodeName%]AbstractNioClientWorker
[idx=1, bytesRcvd=0, bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=false,
super=]ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=85 lim=85
cap=8192], super=], writeBuf=null, readBuf=null, inRecovery=null,
outRecovery=null, super=GridNioSessionImpl [locAddr=/10.104.6.24:11211,
rmtAddr=unuratu101.ca.sbrf.ru/10.104.6.100:57054, createTime=1589759103528,
closeTime=1589759232067, bytesSent=10011, bytesRcvd=10203, bytesSent0=85,
bytesRcvd0=85, sndSchedTime=1589759232057, lastSndTime=1589759232067,
lastRcvTime=1589759230548, readsPaused=false,
filterChain=FilterChain[filters=[, SSL filter], accepted=true,
markedForClose=true]], msg=GridClientTaskRequest
[taskName=o.a.i.i.v.tx.VisorTxTask, arg=VisorTaskArgument [debug=false]]]
...
Caused by: java.lang.NullPointerException: null
at
org.apache.ignite.internal.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:293)
at
org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:204)
... 87 common frames omitted
{code}
full stack trace
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-13165) NPE when control utility connect to cluster (VisorTxTask)
[
https://issues.apache.org/jira/browse/IGNITE-13165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexand Polyakov updated IGNITE-13165:
--
Description:
NullPointerException when control utility connect to cluster for execute
VisorTxTask
{code:java}
2020-05-18
02:47:12.070[ERROR][mgmt-#305526%DPL_GRID%DplGridNodeName%][o.a.i.i.p.r.p.t.GridTcpRestProtocol]
Failed to process client request [ses=GridSelectorNioSessionImpl
[worker=GridWorker [name=grid-nio-worker-tcp-rest-1,
igniteInstanceName=DPL_GRID%DplGridNodeName, finished=false,
heartbeatTs=1589759232067, hashCode=676612820, interrupted=false,
runner=grid-nio-worker-tcp-rest-1-#143%DPL_GRID%DplGridNodeName%]AbstractNioClientWorker
[idx=1, bytesRcvd=0, bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=false,
super=]ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=85 lim=85
cap=8192], super=], writeBuf=null, readBuf=null, inRecovery=null,
outRecovery=null, super=GridNioSessionImpl [locAddr=/10.104.6.24:11211,
rmtAddr=unuratu101.ca.sbrf.ru/10.104.6.100:57054, createTime=1589759103528,
closeTime=1589759232067, bytesSent=10011, bytesRcvd=10203, bytesSent0=85,
bytesRcvd0=85, sndSchedTime=1589759232057, lastSndTime=1589759232067,
lastRcvTime=1589759230548, readsPaused=false,
filterChain=FilterChain[filters=[, SSL filter], accepted=true,
markedForClose=true]], msg=GridClientTaskRequest
[taskName=o.a.i.i.v.tx.VisorTxTask, arg=VisorTaskArgument [debug=false]]]
...
Caused by: java.lang.NullPointerException: null
at
org.apache.ignite.internal.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:293)
at
org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:204)
... 87 common frames omitted
{code}
full stack trace [^error_kanga24.txt]
was:
NullPointerException when control utility connect to cluster for execute
VisorTxTask
{code:java}
2020-05-18
02:47:12.070[ERROR][mgmt-#305526%DPL_GRID%DplGridNodeName%][o.a.i.i.p.r.p.t.GridTcpRestProtocol]
Failed to process client request [ses=GridSelectorNioSessionImpl
[worker=GridWorker [name=grid-nio-worker-tcp-rest-1,
igniteInstanceName=DPL_GRID%DplGridNodeName, finished=false,
heartbeatTs=1589759232067, hashCode=676612820, interrupted=false,
runner=grid-nio-worker-tcp-rest-1-#143%DPL_GRID%DplGridNodeName%]AbstractNioClientWorker
[idx=1, bytesRcvd=0, bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=false,
super=]ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=85 lim=85
cap=8192], super=], writeBuf=null, readBuf=null, inRecovery=null,
outRecovery=null, super=GridNioSessionImpl [locAddr=/10.104.6.24:11211,
rmtAddr=unuratu101.ca.sbrf.ru/10.104.6.100:57054, createTime=1589759103528,
closeTime=1589759232067, bytesSent=10011, bytesRcvd=10203, bytesSent0=85,
bytesRcvd0=85, sndSchedTime=1589759232057, lastSndTime=1589759232067,
lastRcvTime=1589759230548, readsPaused=false,
filterChain=FilterChain[filters=[, SSL filter], accepted=true,
markedForClose=true]], msg=GridClientTaskRequest
[taskName=o.a.i.i.v.tx.VisorTxTask, arg=VisorTaskArgument [debug=false]]]
...
Caused by: java.lang.NullPointerException: null
at
org.apache.ignite.internal.MarshallerContextImpl.registerClassName(MarshallerContextImpl.java:293)
at
org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(OptimizedMarshallerUtils.java:204)
... 87 common frames omitted
{code}
full stack trace
> NPE when control utility connect to cluster (VisorTxTask)
> -
>
> Key: IGNITE-13165
> URL: https://issues.apache.org/jira/browse/IGNITE-13165
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.5
>Reporter: Alexand Polyakov
>Priority: Major
> Attachments: error_kanga24.txt
>
>
> NullPointerException when control utility connect to cluster for execute
> VisorTxTask
> {code:java}
> 2020-05-18
> 02:47:12.070[ERROR][mgmt-#305526%DPL_GRID%DplGridNodeName%][o.a.i.i.p.r.p.t.GridTcpRestProtocol]
> Failed to process client request [ses=GridSelectorNioSessionImpl
> [worker=GridWorker [name=grid-nio-worker-tcp-rest-1,
> igniteInstanceName=DPL_GRID%DplGridNodeName, finished=false,
> heartbeatTs=1589759232067, hashCode=676612820, interrupted=false,
> runner=grid-nio-worker-tcp-rest-1-#143%DPL_GRID%DplGridNodeName%]AbstractNioClientWorker
> [idx=1, bytesRcvd=0, bytesSent=0, bytesRcvd0=0, bytesSent0=0, select=false,
> super=]ByteBufferNioClientWorker [readBuf=java.nio.HeapByteBuffer[pos=85
> lim=85 cap=8192], super=], writeBuf=null, readBuf=null, inRecovery=null,
> outRecovery=null, super=GridNioSessionImpl [locAddr=/10.104.6.24:11211,
> rmtAddr=unuratu101.ca.sbrf.ru/10.104.6.100:57054,
[jira] [Commented] (IGNITE-7883) Cluster can have inconsistent affinity configuration
[
https://issues.apache.org/jira/browse/IGNITE-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16893878#comment-16893878
]
Alexand Polyakov commented on IGNITE-7883:
--
[~agura] The code was tweaked, the tests passed.
> Cluster can have inconsistent affinity configuration
> -
>
> Key: IGNITE-7883
> URL: https://issues.apache.org/jira/browse/IGNITE-7883
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Alexand Polyakov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> A cluster can have inconsistent affinity configuration if you created two
> nodes, one with affinity key configuration and other without it(in IgniteCfg
> or CacheCfg), both nodes will work fine with no exceptions, but in the same
> time they will apply different affinity rules to keys:
>
> {code:java}
> package affinity;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheKeyConfiguration;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.affinity.Affinity;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import java.util.Arrays;
> public class Test {
> private static int id = 0;
> public static void main(String[] args) {
> Ignite ignite = Ignition.start(getConfiguration(true, false));
> Ignite ignite2 = Ignition.start(getConfiguration(false, false));
> Affinity affinity = ignite.affinity("TEST");
> Affinity affinity2 = ignite2.affinity("TEST");
> for (int i = 0; i < 1_000_000; i++) {
> AKey key = new AKey(i);
> if(affinity.partition(key) != affinity2.partition(key))
> System.out.println("FAILED for: " + key);
> }
> System.out.println("DONE");
> }
> private static IgniteConfiguration getConfiguration(boolean
> withAffinityCfg, boolean client) {
> IgniteConfiguration cfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
> finder.setAddresses(Arrays.asList("localhost:47500..47600"));
> cfg.setClientMode(client);
> cfg.setIgniteInstanceName("test" + id++);
> CacheConfiguration cacheCfg = new CacheConfiguration("TEST");
> cacheCfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cacheCfg.setCacheMode(CacheMode.PARTITIONED);
> if(withAffinityCfg) {
> cacheCfg.setKeyConfiguration(new
> CacheKeyConfiguration("affinity.AKey", "a"));
> }
> cfg.setCacheConfiguration(cacheCfg);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(finder));
> return cfg;
> }
> }
> class AKey {
> int a;
> public AKey(int a) {
> this.a = a;
> }
> @Override public String toString() {
> return "AKey{" +
> "a=" + a +
> '}';
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.14#76016)
[jira] [Comment Edited] (IGNITE-7883) Cluster can have inconsistent affinity configuration
[
https://issues.apache.org/jira/browse/IGNITE-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16880260#comment-16880260
]
Alexand Polyakov edited comment on IGNITE-7883 at 7/9/19 8:48 AM:
--
The code was tweaked, the tests passed. [~agura] please merge.
was (Author: a-polyakov):
[~agura] Fix remarks
> Cluster can have inconsistent affinity configuration
> -
>
> Key: IGNITE-7883
> URL: https://issues.apache.org/jira/browse/IGNITE-7883
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Alexand Polyakov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> A cluster can have inconsistent affinity configuration if you created two
> nodes, one with affinity key configuration and other without it(in IgniteCfg
> or CacheCfg), both nodes will work fine with no exceptions, but in the same
> time they will apply different affinity rules to keys:
>
> {code:java}
> package affinity;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheKeyConfiguration;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.affinity.Affinity;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import java.util.Arrays;
> public class Test {
> private static int id = 0;
> public static void main(String[] args) {
> Ignite ignite = Ignition.start(getConfiguration(true, false));
> Ignite ignite2 = Ignition.start(getConfiguration(false, false));
> Affinity affinity = ignite.affinity("TEST");
> Affinity affinity2 = ignite2.affinity("TEST");
> for (int i = 0; i < 1_000_000; i++) {
> AKey key = new AKey(i);
> if(affinity.partition(key) != affinity2.partition(key))
> System.out.println("FAILED for: " + key);
> }
> System.out.println("DONE");
> }
> private static IgniteConfiguration getConfiguration(boolean
> withAffinityCfg, boolean client) {
> IgniteConfiguration cfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
> finder.setAddresses(Arrays.asList("localhost:47500..47600"));
> cfg.setClientMode(client);
> cfg.setIgniteInstanceName("test" + id++);
> CacheConfiguration cacheCfg = new CacheConfiguration("TEST");
> cacheCfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cacheCfg.setCacheMode(CacheMode.PARTITIONED);
> if(withAffinityCfg) {
> cacheCfg.setKeyConfiguration(new
> CacheKeyConfiguration("affinity.AKey", "a"));
> }
> cfg.setCacheConfiguration(cacheCfg);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(finder));
> return cfg;
> }
> }
> class AKey {
> int a;
> public AKey(int a) {
> this.a = a;
> }
> @Override public String toString() {
> return "AKey{" +
> "a=" + a +
> '}';
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-7883) Cluster can have inconsistent affinity configuration
[
https://issues.apache.org/jira/browse/IGNITE-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16880260#comment-16880260
]
Alexand Polyakov commented on IGNITE-7883:
--
[~agura] Fix remarks
> Cluster can have inconsistent affinity configuration
> -
>
> Key: IGNITE-7883
> URL: https://issues.apache.org/jira/browse/IGNITE-7883
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Alexand Polyakov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> A cluster can have inconsistent affinity configuration if you created two
> nodes, one with affinity key configuration and other without it(in IgniteCfg
> or CacheCfg), both nodes will work fine with no exceptions, but in the same
> time they will apply different affinity rules to keys:
>
> {code:java}
> package affinity;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheKeyConfiguration;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.affinity.Affinity;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import java.util.Arrays;
> public class Test {
> private static int id = 0;
> public static void main(String[] args) {
> Ignite ignite = Ignition.start(getConfiguration(true, false));
> Ignite ignite2 = Ignition.start(getConfiguration(false, false));
> Affinity affinity = ignite.affinity("TEST");
> Affinity affinity2 = ignite2.affinity("TEST");
> for (int i = 0; i < 1_000_000; i++) {
> AKey key = new AKey(i);
> if(affinity.partition(key) != affinity2.partition(key))
> System.out.println("FAILED for: " + key);
> }
> System.out.println("DONE");
> }
> private static IgniteConfiguration getConfiguration(boolean
> withAffinityCfg, boolean client) {
> IgniteConfiguration cfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
> finder.setAddresses(Arrays.asList("localhost:47500..47600"));
> cfg.setClientMode(client);
> cfg.setIgniteInstanceName("test" + id++);
> CacheConfiguration cacheCfg = new CacheConfiguration("TEST");
> cacheCfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cacheCfg.setCacheMode(CacheMode.PARTITIONED);
> if(withAffinityCfg) {
> cacheCfg.setKeyConfiguration(new
> CacheKeyConfiguration("affinity.AKey", "a"));
> }
> cfg.setCacheConfiguration(cacheCfg);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(finder));
> return cfg;
> }
> }
> class AKey {
> int a;
> public AKey(int a) {
> this.a = a;
> }
> @Override public String toString() {
> return "AKey{" +
> "a=" + a +
> '}';
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-11512) Add counter left partition for index rebuild in CacheGroupMetricsMXBean
[ https://issues.apache.org/jira/browse/IGNITE-11512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexand Polyakov reassigned IGNITE-11512: - Assignee: Stanilovsky Evgeny (was: Alexand Polyakov) > Add counter left partition for index rebuild in CacheGroupMetricsMXBean > --- > > Key: IGNITE-11512 > URL: https://issues.apache.org/jira/browse/IGNITE-11512 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.7 >Reporter: Alexand Polyakov >Assignee: Stanilovsky Evgeny >Priority: Major > > Now, if ran rebuild indexes, this can determined only on load CPU and thread > dump. The presence of the "how many partitions left to index" metric will > help determine whether the rebuilding is going on and on which cache, as well > as the percentage of completion. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-7883) Cluster can have inconsistent affinity configuration
[
https://issues.apache.org/jira/browse/IGNITE-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexand Polyakov reassigned IGNITE-7883:
Assignee: Stanilovsky Evgeny (was: Alexand Polyakov)
> Cluster can have inconsistent affinity configuration
> -
>
> Key: IGNITE-7883
> URL: https://issues.apache.org/jira/browse/IGNITE-7883
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Stanilovsky Evgeny
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> A cluster can have inconsistent affinity configuration if you created two
> nodes, one with affinity key configuration and other without it(in IgniteCfg
> or CacheCfg), both nodes will work fine with no exceptions, but in the same
> time they will apply different affinity rules to keys:
>
> {code:java}
> package affinity;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheKeyConfiguration;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.affinity.Affinity;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import java.util.Arrays;
> public class Test {
> private static int id = 0;
> public static void main(String[] args) {
> Ignite ignite = Ignition.start(getConfiguration(true, false));
> Ignite ignite2 = Ignition.start(getConfiguration(false, false));
> Affinity affinity = ignite.affinity("TEST");
> Affinity affinity2 = ignite2.affinity("TEST");
> for (int i = 0; i < 1_000_000; i++) {
> AKey key = new AKey(i);
> if(affinity.partition(key) != affinity2.partition(key))
> System.out.println("FAILED for: " + key);
> }
> System.out.println("DONE");
> }
> private static IgniteConfiguration getConfiguration(boolean
> withAffinityCfg, boolean client) {
> IgniteConfiguration cfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
> finder.setAddresses(Arrays.asList("localhost:47500..47600"));
> cfg.setClientMode(client);
> cfg.setIgniteInstanceName("test" + id++);
> CacheConfiguration cacheCfg = new CacheConfiguration("TEST");
> cacheCfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cacheCfg.setCacheMode(CacheMode.PARTITIONED);
> if(withAffinityCfg) {
> cacheCfg.setKeyConfiguration(new
> CacheKeyConfiguration("affinity.AKey", "a"));
> }
> cfg.setCacheConfiguration(cacheCfg);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(finder));
> return cfg;
> }
> }
> class AKey {
> int a;
> public AKey(int a) {
> this.a = a;
> }
> @Override public String toString() {
> return "AKey{" +
> "a=" + a +
> '}';
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-11512) Add counter left partition for index rebuild in CacheGroupMetricsMXBean
[ https://issues.apache.org/jira/browse/IGNITE-11512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16844621#comment-16844621 ] Alexand Polyakov commented on IGNITE-11512: --- [~ivan.glukos], questions on comments 3. specially out from the visitor to initialize the value before creating threads 6. don't understand the comment, in fact there are 2 tests: rebuild of indexes (indexes are physically removed from disk); create index (sql CREATE INDEX) 7. Variable.apache.ignite.internal.processors.cache.CacheGroupMetricsImpl#indexBuildCountPartitionsLeft and it does not require an MXBean, or do something else mean > Add counter left partition for index rebuild in CacheGroupMetricsMXBean > --- > > Key: IGNITE-11512 > URL: https://issues.apache.org/jira/browse/IGNITE-11512 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.7 >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > > Now, if ran rebuild indexes, this can determined only on load CPU and thread > dump. The presence of the "how many partitions left to index" metric will > help determine whether the rebuilding is going on and on which cache, as well > as the percentage of completion. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-11512) Add counter left partition for index rebuild in CacheGroupMetricsMXBean
[ https://issues.apache.org/jira/browse/IGNITE-11512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexand Polyakov updated IGNITE-11512: -- Reviewer: Ivan Rakov > Add counter left partition for index rebuild in CacheGroupMetricsMXBean > --- > > Key: IGNITE-11512 > URL: https://issues.apache.org/jira/browse/IGNITE-11512 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.7 >Reporter: Alexand Polyakov >Assignee: Alexand Polyakov >Priority: Major > > Now, if ran rebuild indexes, this can determined only on load CPU and thread > dump. The presence of the "how many partitions left to index" metric will > help determine whether the rebuilding is going on and on which cache, as well > as the percentage of completion. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-11512) Add counter left partition for index rebuild in CacheGroupMetricsMXBean
Alexand Polyakov created IGNITE-11512: - Summary: Add counter left partition for index rebuild in CacheGroupMetricsMXBean Key: IGNITE-11512 URL: https://issues.apache.org/jira/browse/IGNITE-11512 Project: Ignite Issue Type: Improvement Components: general Affects Versions: 2.7 Reporter: Alexand Polyakov Assignee: Alexand Polyakov Now, if ran rebuild indexes, this can determined only on load CPU and thread dump. The presence of the "how many partitions left to index" metric will help determine whether the rebuilding is going on and on which cache, as well as the percentage of completion. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-7883) Cluster can have inconsistent affinity configuration
[
https://issues.apache.org/jira/browse/IGNITE-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexand Polyakov updated IGNITE-7883:
-
Attachment: (was: TC recheck 03.png)
> Cluster can have inconsistent affinity configuration
> -
>
> Key: IGNITE-7883
> URL: https://issues.apache.org/jira/browse/IGNITE-7883
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Alexand Polyakov
>Priority: Major
> Fix For: 2.8
>
> Attachments: TC recheck 01.png, TC recheck 02.png, TC.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> A cluster can have inconsistent affinity configuration if you created two
> nodes, one with affinity key configuration and other without it(in IgniteCfg
> or CacheCfg), both nodes will work fine with no exceptions, but in the same
> time they will apply different affinity rules to keys:
>
> {code:java}
> package affinity;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheKeyConfiguration;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.affinity.Affinity;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import java.util.Arrays;
> public class Test {
> private static int id = 0;
> public static void main(String[] args) {
> Ignite ignite = Ignition.start(getConfiguration(true, false));
> Ignite ignite2 = Ignition.start(getConfiguration(false, false));
> Affinity affinity = ignite.affinity("TEST");
> Affinity affinity2 = ignite2.affinity("TEST");
> for (int i = 0; i < 1_000_000; i++) {
> AKey key = new AKey(i);
> if(affinity.partition(key) != affinity2.partition(key))
> System.out.println("FAILED for: " + key);
> }
> System.out.println("DONE");
> }
> private static IgniteConfiguration getConfiguration(boolean
> withAffinityCfg, boolean client) {
> IgniteConfiguration cfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
> finder.setAddresses(Arrays.asList("localhost:47500..47600"));
> cfg.setClientMode(client);
> cfg.setIgniteInstanceName("test" + id++);
> CacheConfiguration cacheCfg = new CacheConfiguration("TEST");
> cacheCfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cacheCfg.setCacheMode(CacheMode.PARTITIONED);
> if(withAffinityCfg) {
> cacheCfg.setKeyConfiguration(new
> CacheKeyConfiguration("affinity.AKey", "a"));
> }
> cfg.setCacheConfiguration(cacheCfg);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(finder));
> return cfg;
> }
> }
> class AKey {
> int a;
> public AKey(int a) {
> this.a = a;
> }
> @Override public String toString() {
> return "AKey{" +
> "a=" + a +
> '}';
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7883) Cluster can have inconsistent affinity configuration
[
https://issues.apache.org/jira/browse/IGNITE-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexand Polyakov updated IGNITE-7883:
-
Attachment: (was: TC.png)
> Cluster can have inconsistent affinity configuration
> -
>
> Key: IGNITE-7883
> URL: https://issues.apache.org/jira/browse/IGNITE-7883
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Alexand Polyakov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> A cluster can have inconsistent affinity configuration if you created two
> nodes, one with affinity key configuration and other without it(in IgniteCfg
> or CacheCfg), both nodes will work fine with no exceptions, but in the same
> time they will apply different affinity rules to keys:
>
> {code:java}
> package affinity;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheKeyConfiguration;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.affinity.Affinity;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import java.util.Arrays;
> public class Test {
> private static int id = 0;
> public static void main(String[] args) {
> Ignite ignite = Ignition.start(getConfiguration(true, false));
> Ignite ignite2 = Ignition.start(getConfiguration(false, false));
> Affinity affinity = ignite.affinity("TEST");
> Affinity affinity2 = ignite2.affinity("TEST");
> for (int i = 0; i < 1_000_000; i++) {
> AKey key = new AKey(i);
> if(affinity.partition(key) != affinity2.partition(key))
> System.out.println("FAILED for: " + key);
> }
> System.out.println("DONE");
> }
> private static IgniteConfiguration getConfiguration(boolean
> withAffinityCfg, boolean client) {
> IgniteConfiguration cfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
> finder.setAddresses(Arrays.asList("localhost:47500..47600"));
> cfg.setClientMode(client);
> cfg.setIgniteInstanceName("test" + id++);
> CacheConfiguration cacheCfg = new CacheConfiguration("TEST");
> cacheCfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cacheCfg.setCacheMode(CacheMode.PARTITIONED);
> if(withAffinityCfg) {
> cacheCfg.setKeyConfiguration(new
> CacheKeyConfiguration("affinity.AKey", "a"));
> }
> cfg.setCacheConfiguration(cacheCfg);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(finder));
> return cfg;
> }
> }
> class AKey {
> int a;
> public AKey(int a) {
> this.a = a;
> }
> @Override public String toString() {
> return "AKey{" +
> "a=" + a +
> '}';
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7883) Cluster can have inconsistent affinity configuration
[
https://issues.apache.org/jira/browse/IGNITE-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexand Polyakov updated IGNITE-7883:
-
Attachment: (was: TC recheck 02.png)
> Cluster can have inconsistent affinity configuration
> -
>
> Key: IGNITE-7883
> URL: https://issues.apache.org/jira/browse/IGNITE-7883
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Alexand Polyakov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> A cluster can have inconsistent affinity configuration if you created two
> nodes, one with affinity key configuration and other without it(in IgniteCfg
> or CacheCfg), both nodes will work fine with no exceptions, but in the same
> time they will apply different affinity rules to keys:
>
> {code:java}
> package affinity;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheKeyConfiguration;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.affinity.Affinity;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import java.util.Arrays;
> public class Test {
> private static int id = 0;
> public static void main(String[] args) {
> Ignite ignite = Ignition.start(getConfiguration(true, false));
> Ignite ignite2 = Ignition.start(getConfiguration(false, false));
> Affinity affinity = ignite.affinity("TEST");
> Affinity affinity2 = ignite2.affinity("TEST");
> for (int i = 0; i < 1_000_000; i++) {
> AKey key = new AKey(i);
> if(affinity.partition(key) != affinity2.partition(key))
> System.out.println("FAILED for: " + key);
> }
> System.out.println("DONE");
> }
> private static IgniteConfiguration getConfiguration(boolean
> withAffinityCfg, boolean client) {
> IgniteConfiguration cfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
> finder.setAddresses(Arrays.asList("localhost:47500..47600"));
> cfg.setClientMode(client);
> cfg.setIgniteInstanceName("test" + id++);
> CacheConfiguration cacheCfg = new CacheConfiguration("TEST");
> cacheCfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cacheCfg.setCacheMode(CacheMode.PARTITIONED);
> if(withAffinityCfg) {
> cacheCfg.setKeyConfiguration(new
> CacheKeyConfiguration("affinity.AKey", "a"));
> }
> cfg.setCacheConfiguration(cacheCfg);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(finder));
> return cfg;
> }
> }
> class AKey {
> int a;
> public AKey(int a) {
> this.a = a;
> }
> @Override public String toString() {
> return "AKey{" +
> "a=" + a +
> '}';
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7883) Cluster can have inconsistent affinity configuration
[
https://issues.apache.org/jira/browse/IGNITE-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexand Polyakov updated IGNITE-7883:
-
Attachment: (was: TC recheck 01.png)
> Cluster can have inconsistent affinity configuration
> -
>
> Key: IGNITE-7883
> URL: https://issues.apache.org/jira/browse/IGNITE-7883
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Alexand Polyakov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> A cluster can have inconsistent affinity configuration if you created two
> nodes, one with affinity key configuration and other without it(in IgniteCfg
> or CacheCfg), both nodes will work fine with no exceptions, but in the same
> time they will apply different affinity rules to keys:
>
> {code:java}
> package affinity;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheKeyConfiguration;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.affinity.Affinity;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import java.util.Arrays;
> public class Test {
> private static int id = 0;
> public static void main(String[] args) {
> Ignite ignite = Ignition.start(getConfiguration(true, false));
> Ignite ignite2 = Ignition.start(getConfiguration(false, false));
> Affinity affinity = ignite.affinity("TEST");
> Affinity affinity2 = ignite2.affinity("TEST");
> for (int i = 0; i < 1_000_000; i++) {
> AKey key = new AKey(i);
> if(affinity.partition(key) != affinity2.partition(key))
> System.out.println("FAILED for: " + key);
> }
> System.out.println("DONE");
> }
> private static IgniteConfiguration getConfiguration(boolean
> withAffinityCfg, boolean client) {
> IgniteConfiguration cfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
> finder.setAddresses(Arrays.asList("localhost:47500..47600"));
> cfg.setClientMode(client);
> cfg.setIgniteInstanceName("test" + id++);
> CacheConfiguration cacheCfg = new CacheConfiguration("TEST");
> cacheCfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cacheCfg.setCacheMode(CacheMode.PARTITIONED);
> if(withAffinityCfg) {
> cacheCfg.setKeyConfiguration(new
> CacheKeyConfiguration("affinity.AKey", "a"));
> }
> cfg.setCacheConfiguration(cacheCfg);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(finder));
> return cfg;
> }
> }
> class AKey {
> int a;
> public AKey(int a) {
> this.a = a;
> }
> @Override public String toString() {
> return "AKey{" +
> "a=" + a +
> '}';
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-7883) Cluster can have inconsistent affinity configuration
[
https://issues.apache.org/jira/browse/IGNITE-7883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexand Polyakov updated IGNITE-7883:
-
Attachment: (was: TC recheck 04.png)
> Cluster can have inconsistent affinity configuration
> -
>
> Key: IGNITE-7883
> URL: https://issues.apache.org/jira/browse/IGNITE-7883
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.3
>Reporter: Mikhail Cherkasov
>Assignee: Alexand Polyakov
>Priority: Major
> Fix For: 2.8
>
> Attachments: TC recheck 01.png, TC recheck 02.png, TC.png
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> A cluster can have inconsistent affinity configuration if you created two
> nodes, one with affinity key configuration and other without it(in IgniteCfg
> or CacheCfg), both nodes will work fine with no exceptions, but in the same
> time they will apply different affinity rules to keys:
>
> {code:java}
> package affinity;
> import org.apache.ignite.Ignite;
> import org.apache.ignite.Ignition;
> import org.apache.ignite.cache.CacheAtomicityMode;
> import org.apache.ignite.cache.CacheKeyConfiguration;
> import org.apache.ignite.cache.CacheMode;
> import org.apache.ignite.cache.affinity.Affinity;
> import org.apache.ignite.configuration.CacheConfiguration;
> import org.apache.ignite.configuration.IgniteConfiguration;
> import org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi;
> import org.apache.ignite.spi.discovery.tcp.ipfinder.vm.TcpDiscoveryVmIpFinder;
> import java.util.Arrays;
> public class Test {
> private static int id = 0;
> public static void main(String[] args) {
> Ignite ignite = Ignition.start(getConfiguration(true, false));
> Ignite ignite2 = Ignition.start(getConfiguration(false, false));
> Affinity affinity = ignite.affinity("TEST");
> Affinity affinity2 = ignite2.affinity("TEST");
> for (int i = 0; i < 1_000_000; i++) {
> AKey key = new AKey(i);
> if(affinity.partition(key) != affinity2.partition(key))
> System.out.println("FAILED for: " + key);
> }
> System.out.println("DONE");
> }
> private static IgniteConfiguration getConfiguration(boolean
> withAffinityCfg, boolean client) {
> IgniteConfiguration cfg = new IgniteConfiguration();
> TcpDiscoveryVmIpFinder finder = new TcpDiscoveryVmIpFinder(true);
> finder.setAddresses(Arrays.asList("localhost:47500..47600"));
> cfg.setClientMode(client);
> cfg.setIgniteInstanceName("test" + id++);
> CacheConfiguration cacheCfg = new CacheConfiguration("TEST");
> cacheCfg.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL);
> cacheCfg.setCacheMode(CacheMode.PARTITIONED);
> if(withAffinityCfg) {
> cacheCfg.setKeyConfiguration(new
> CacheKeyConfiguration("affinity.AKey", "a"));
> }
> cfg.setCacheConfiguration(cacheCfg);
> cfg.setDiscoverySpi(new TcpDiscoverySpi().setIpFinder(finder));
> return cfg;
> }
> }
> class AKey {
> int a;
> public AKey(int a) {
> this.a = a;
> }
> @Override public String toString() {
> return "AKey{" +
> "a=" + a +
> '}';
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (IGNITE-6564) Incorrect calculation size and keySize for cluster cache metrics
[ https://issues.apache.org/jira/browse/IGNITE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746298#comment-16746298 ] Alexand Polyakov commented on IGNITE-6564: -- Tests wiil be broken without adding of the awaiting metrics, so these changes were included here. > Incorrect calculation size and keySize for cluster cache metrics > > > Key: IGNITE-6564 > URL: https://issues.apache.org/jira/browse/IGNITE-6564 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Ilya Kasnacheev >Assignee: Alexand Polyakov >Priority: Minor > Labels: iep-6 > Time Spent: 50m > Remaining Estimate: 0h > > They are currently not passed by ring and therefore only taken from current > node, which returns incorrect (local) value. > See CacheMetricsSnapshot class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6564) Incorrect calculation size and keySize for cluster cache metrics
[ https://issues.apache.org/jira/browse/IGNITE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746295#comment-16746295 ] Alexand Polyakov commented on IGNITE-6564: -- @[~ilyak] size return incorrect metrics, in order not to create misconceptions, zeroed, since it is impossible to delete > Incorrect calculation size and keySize for cluster cache metrics > > > Key: IGNITE-6564 > URL: https://issues.apache.org/jira/browse/IGNITE-6564 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Ilya Kasnacheev >Assignee: Alexand Polyakov >Priority: Minor > Labels: iep-6 > Time Spent: 50m > Remaining Estimate: 0h > > They are currently not passed by ring and therefore only taken from current > node, which returns incorrect (local) value. > See CacheMetricsSnapshot class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-6564) Incorrect calculation size and keySize for cluster cache metrics
[ https://issues.apache.org/jira/browse/IGNITE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16746291#comment-16746291 ] Alexand Polyakov commented on IGNITE-6564: -- [~macrergate] ok > Incorrect calculation size and keySize for cluster cache metrics > > > Key: IGNITE-6564 > URL: https://issues.apache.org/jira/browse/IGNITE-6564 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Ilya Kasnacheev >Assignee: Alexand Polyakov >Priority: Minor > Labels: iep-6 > Time Spent: 50m > Remaining Estimate: 0h > > They are currently not passed by ring and therefore only taken from current > node, which returns incorrect (local) value. > See CacheMetricsSnapshot class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10949) org.apache.ignite.internal.MarshallerContextImpl.CombinedMap generates NPE
Alexand Polyakov created IGNITE-10949: - Summary: org.apache.ignite.internal.MarshallerContextImpl.CombinedMap generates NPE Key: IGNITE-10949 URL: https://issues.apache.org/jira/browse/IGNITE-10949 Project: Ignite Issue Type: Bug Components: binary Affects Versions: 2.7 Reporter: Alexand Polyakov method entrySet return null then generates NullPointerException in method hashCode, toString and all classes that use an instance of this object. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Comment Edited] (IGNITE-6564) Incorrect calculation size and keySize for cluster cache metrics
[
https://issues.apache.org/jira/browse/IGNITE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729298#comment-16729298
]
Alexand Polyakov edited comment on IGNITE-6564 at 1/12/19 11:47 PM:
left three open questions
* are the counters correctly evaluated in CacheMetricsEntitiesCountTest
||Cache||Size||offHeapEntriesCnt||offHeapPrimaryEntriesCnt||offHeapBackupEntriesCnt||heapEntriesCnt||
|CacheMode = REPLICATED|cacheSize|cacheSize * GRID_CNT|cacheSize|cacheSize *
(GRID_CNT - 1)|0|
|CacheMode = PARTITIONED, Backups = 1|cacheSize|cacheSize *
2|cacheSize|cacheSize|0|
|CacheMode = PARTITIONED, Backups = 1, NearCache|cacheSize|cacheSize *
2|cacheSize|cacheSize|216|
|CacheMode = PARTITIONED, Backups = 1, OnheapCache|cacheSize|cacheSize *
2|cacheSize|cacheSize|cacheSize * 2|
|CacheMode = LOCAL|cacheSize|cacheSize|cacheSize|0|0|
* how to calculate heapsize for NearCache, set the value obtained empirically
216
was (Author: a-polyakov):
left three open questions
* are the counters correctly evaluated in CacheMetricsEntitiesCountTest
||Cache||Size||offHeapEntriesCnt||offHeapPrimaryEntriesCnt||offHeapBackupEntriesCnt||heapEntriesCnt||
|CacheMode = REPLICATED|cacheSize|cacheSize * GRID_CNT|cacheSize|cacheSize *
(GRID_CNT - 1)|0|
|CacheMode = PARTITIONED, Backups = 1|cacheSize|cacheSize *
2|cacheSize|cacheSize|0|
|CacheMode = PARTITIONED, Backups = 1, NearCache|cacheSize|cacheSize *
2|cacheSize|cacheSize|216|
|CacheMode = PARTITIONED, Backups = 1, OnheapCache|cacheSize|cacheSize *
2|cacheSize|cacheSize|cacheSize * 2|
|CacheMode = LOCAL|cacheSize|cacheSize|cacheSize|0|0|
* how to calculate heapsize for NearCache, set the value obtained empirically
216
* how the assessment is carried out in the checkCache method (clarification is
needed, since the calculated and actual figures differ from the theoretical
ones)
{noformat}
Checking cache, igniteIdx=0, cacheIdx=0
igniteIdx=0, cacheIdx=0 offHeapEntriesCnt offHeapEntriesCnt:300
metrics.getOffHeapEntriesCount(): 300
igniteIdx=0, cacheIdx=0 offHeapBackupEntriesCnt offHeapBackupEntriesCnt:210
metrics.getOffHeapBackupEntriesCount(): 210
igniteIdx=0, cacheIdx=0 offHeapPrimaryEntriesCnt offHeapPrimaryEntriesCnt:90
metrics.getOffHeapPrimaryEntriesCount(): 90
igniteIdx=0, cacheIdx=0 heapEntriesCnt heapEntriesCnt:0
metrics.getHeapEntriesCount(): 0
igniteIdx=0, cacheIdx=0 CacheSize cache:300 metrics.getCacheSize(): 90
Checking cache, igniteIdx=0, cacheIdx=1
igniteIdx=0, cacheIdx=1 offHeapEntriesCnt offHeapEntriesCnt:187
metrics.getOffHeapEntriesCount(): 187
igniteIdx=0, cacheIdx=1 offHeapBackupEntriesCnt offHeapBackupEntriesCnt:101
metrics.getOffHeapBackupEntriesCount(): 101
igniteIdx=0, cacheIdx=1 offHeapPrimaryEntriesCnt offHeapPrimaryEntriesCnt:86
metrics.getOffHeapPrimaryEntriesCount(): 86
igniteIdx=0, cacheIdx=1 heapEntriesCnt heapEntriesCnt:0
metrics.getHeapEntriesCount(): 0
igniteIdx=0, cacheIdx=1 CacheSize cache:187 metrics.getCacheSize(): 86
Checking cache, igniteIdx=0, cacheIdx=2
igniteIdx=0, cacheIdx=2 offHeapEntriesCnt offHeapEntriesCnt:187
metrics.getOffHeapEntriesCount(): 187
igniteIdx=0, cacheIdx=2 offHeapBackupEntriesCnt offHeapBackupEntriesCnt:101
metrics.getOffHeapBackupEntriesCount(): 101
igniteIdx=0, cacheIdx=2 offHeapPrimaryEntriesCnt offHeapPrimaryEntriesCnt:86
metrics.getOffHeapPrimaryEntriesCount(): 86
igniteIdx=0, cacheIdx=2 heapEntriesCnt heapEntriesCnt:67
metrics.getHeapEntriesCount(): 67
igniteIdx=0, cacheIdx=2 CacheSize cache:225 metrics.getCacheSize(): 86
Checking cache, igniteIdx=0, cacheIdx=3
igniteIdx=0, cacheIdx=3 offHeapEntriesCnt offHeapEntriesCnt:100
metrics.getOffHeapEntriesCount(): 100
igniteIdx=0, cacheIdx=3 offHeapBackupEntriesCnt offHeapBackupEntriesCnt:100
metrics.getOffHeapBackupEntriesCount(): 0
igniteIdx=0, cacheIdx=3 offHeapPrimaryEntriesCnt offHeapPrimaryEntriesCnt:100
metrics.getOffHeapPrimaryEntriesCount(): 100
igniteIdx=0, cacheIdx=3 heapEntriesCnt heapEntriesCnt:0
metrics.getHeapEntriesCount(): 0
igniteIdx=0, cacheIdx=3 CacheSize cache:0 metrics.getCacheSize(): 100
Checking cache, igniteIdx=1, cacheIdx=0
igniteIdx=1, cacheIdx=0 offHeapEntriesCnt offHeapEntriesCnt:300
metrics.getOffHeapEntriesCount(): 300
igniteIdx=1, cacheIdx=0 offHeapBackupEntriesCnt offHeapBackupEntriesCnt:195
metrics.getOffHeapBackupEntriesCount(): 195
igniteIdx=1, cacheIdx=0 offHeapPrimaryEntriesCnt offHeapPrimaryEntriesCnt:105
metrics.getOffHeapPrimaryEntriesCount(): 105
igniteIdx=1, cacheIdx=0 heapEntriesCnt heapEntriesCnt:0
metrics.getHeapEntriesCount(): 0
igniteIdx=1, cacheIdx=0 CacheSize cache:300 metrics.getCacheSize(): 105
Checking cache, igniteIdx=1, cacheIdx=1
igniteIdx=1, cacheIdx=1 offHeapEntriesCnt offHeapEntriesCnt:205
metrics.getOffHeapEntriesCount(): 205
igniteIdx=1, cacheIdx=1 offHeapBackupEntriesCnt offHeapBackupEntriesCnt:97
[jira] [Comment Edited] (IGNITE-6564) Incorrect calculation size and keySize for cluster cache metrics
[
https://issues.apache.org/jira/browse/IGNITE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729298#comment-16729298
]
Alexand Polyakov edited comment on IGNITE-6564 at 1/12/19 11:45 PM:
left three open questions
* are the counters correctly evaluated in CacheMetricsEntitiesCountTest
||Cache||Size||offHeapEntriesCnt||offHeapPrimaryEntriesCnt||offHeapBackupEntriesCnt||heapEntriesCnt||
|CacheMode = REPLICATED|cacheSize|cacheSize * GRID_CNT|cacheSize|cacheSize *
(GRID_CNT - 1)|0|
|CacheMode = PARTITIONED, Backups = 1|cacheSize|cacheSize *
2|cacheSize|cacheSize|0|
|CacheMode = PARTITIONED, Backups = 1, NearCache|cacheSize|cacheSize *
2|cacheSize|cacheSize|216|
|CacheMode = PARTITIONED, Backups = 1, OnheapCache|cacheSize|cacheSize *
2|cacheSize|cacheSize|cacheSize * 2|
|CacheMode = LOCAL|cacheSize|cacheSize|cacheSize|0|0|
* how to calculate heapsize for NearCache, set the value obtained empirically
216
* how the assessment is carried out in the checkCache method (clarification is
needed, since the calculated and actual figures differ from the theoretical
ones)
{noformat}
Checking cache, igniteIdx=0, cacheIdx=0
igniteIdx=0, cacheIdx=0 offHeapEntriesCnt offHeapEntriesCnt:300
metrics.getOffHeapEntriesCount(): 300
igniteIdx=0, cacheIdx=0 offHeapBackupEntriesCnt offHeapBackupEntriesCnt:210
metrics.getOffHeapBackupEntriesCount(): 210
igniteIdx=0, cacheIdx=0 offHeapPrimaryEntriesCnt offHeapPrimaryEntriesCnt:90
metrics.getOffHeapPrimaryEntriesCount(): 90
igniteIdx=0, cacheIdx=0 heapEntriesCnt heapEntriesCnt:0
metrics.getHeapEntriesCount(): 0
igniteIdx=0, cacheIdx=0 CacheSize cache:300 metrics.getCacheSize(): 90
Checking cache, igniteIdx=0, cacheIdx=1
igniteIdx=0, cacheIdx=1 offHeapEntriesCnt offHeapEntriesCnt:187
metrics.getOffHeapEntriesCount(): 187
igniteIdx=0, cacheIdx=1 offHeapBackupEntriesCnt offHeapBackupEntriesCnt:101
metrics.getOffHeapBackupEntriesCount(): 101
igniteIdx=0, cacheIdx=1 offHeapPrimaryEntriesCnt offHeapPrimaryEntriesCnt:86
metrics.getOffHeapPrimaryEntriesCount(): 86
igniteIdx=0, cacheIdx=1 heapEntriesCnt heapEntriesCnt:0
metrics.getHeapEntriesCount(): 0
igniteIdx=0, cacheIdx=1 CacheSize cache:187 metrics.getCacheSize(): 86
Checking cache, igniteIdx=0, cacheIdx=2
igniteIdx=0, cacheIdx=2 offHeapEntriesCnt offHeapEntriesCnt:187
metrics.getOffHeapEntriesCount(): 187
igniteIdx=0, cacheIdx=2 offHeapBackupEntriesCnt offHeapBackupEntriesCnt:101
metrics.getOffHeapBackupEntriesCount(): 101
igniteIdx=0, cacheIdx=2 offHeapPrimaryEntriesCnt offHeapPrimaryEntriesCnt:86
metrics.getOffHeapPrimaryEntriesCount(): 86
igniteIdx=0, cacheIdx=2 heapEntriesCnt heapEntriesCnt:67
metrics.getHeapEntriesCount(): 67
igniteIdx=0, cacheIdx=2 CacheSize cache:225 metrics.getCacheSize(): 86
Checking cache, igniteIdx=0, cacheIdx=3
igniteIdx=0, cacheIdx=3 offHeapEntriesCnt offHeapEntriesCnt:100
metrics.getOffHeapEntriesCount(): 100
igniteIdx=0, cacheIdx=3 offHeapBackupEntriesCnt offHeapBackupEntriesCnt:100
metrics.getOffHeapBackupEntriesCount(): 0
igniteIdx=0, cacheIdx=3 offHeapPrimaryEntriesCnt offHeapPrimaryEntriesCnt:100
metrics.getOffHeapPrimaryEntriesCount(): 100
igniteIdx=0, cacheIdx=3 heapEntriesCnt heapEntriesCnt:0
metrics.getHeapEntriesCount(): 0
igniteIdx=0, cacheIdx=3 CacheSize cache:0 metrics.getCacheSize(): 100
Checking cache, igniteIdx=1, cacheIdx=0
igniteIdx=1, cacheIdx=0 offHeapEntriesCnt offHeapEntriesCnt:300
metrics.getOffHeapEntriesCount(): 300
igniteIdx=1, cacheIdx=0 offHeapBackupEntriesCnt offHeapBackupEntriesCnt:195
metrics.getOffHeapBackupEntriesCount(): 195
igniteIdx=1, cacheIdx=0 offHeapPrimaryEntriesCnt offHeapPrimaryEntriesCnt:105
metrics.getOffHeapPrimaryEntriesCount(): 105
igniteIdx=1, cacheIdx=0 heapEntriesCnt heapEntriesCnt:0
metrics.getHeapEntriesCount(): 0
igniteIdx=1, cacheIdx=0 CacheSize cache:300 metrics.getCacheSize(): 105
Checking cache, igniteIdx=1, cacheIdx=1
igniteIdx=1, cacheIdx=1 offHeapEntriesCnt offHeapEntriesCnt:205
metrics.getOffHeapEntriesCount(): 205
igniteIdx=1, cacheIdx=1 offHeapBackupEntriesCnt offHeapBackupEntriesCnt:97
metrics.getOffHeapBackupEntriesCount(): 97
igniteIdx=1, cacheIdx=1 offHeapPrimaryEntriesCnt offHeapPrimaryEntriesCnt:108
metrics.getOffHeapPrimaryEntriesCount(): 108
igniteIdx=1, cacheIdx=1 heapEntriesCnt heapEntriesCnt:0
metrics.getHeapEntriesCount(): 0
igniteIdx=1, cacheIdx=1 CacheSize cache:205 metrics.getCacheSize(): 108
Checking cache, igniteIdx=1, cacheIdx=2
igniteIdx=1, cacheIdx=2 offHeapEntriesCnt offHeapEntriesCnt:205
metrics.getOffHeapEntriesCount(): 205
igniteIdx=1, cacheIdx=2 offHeapBackupEntriesCnt offHeapBackupEntriesCnt:97
metrics.getOffHeapBackupEntriesCount(): 97
igniteIdx=1, cacheIdx=2 offHeapPrimaryEntriesCnt offHeapPrimaryEntriesCnt:108
metrics.getOffHeapPrimaryEntriesCount(): 108
igniteIdx=1, cacheIdx=2 heapEntriesCnt heapEntriesCnt:76
[jira] [Comment Edited] (IGNITE-6564) Incorrect calculation size and keySize for cluster cache metrics
[
https://issues.apache.org/jira/browse/IGNITE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729298#comment-16729298
]
Alexand Polyakov edited comment on IGNITE-6564 at 12/27/18 3:47 AM:
left three open questions
* are the counters correctly evaluated in CacheMetricsEntitiesCountTest
||Cache||Size||offHeapEntriesCnt||offHeapPrimaryEntriesCnt||offHeapBackupEntriesCnt||heapEntriesCnt||
|CacheMode = REPLICATED|cacheSize|cacheSize * GRID_CNT|cacheSize|cacheSize *
(GRID_CNT - 1)|0|
|CacheMode = PARTITIONED, Backups = 1|cacheSize|cacheSize *
2|cacheSize|cacheSize|0|
|CacheMode = PARTITIONED, Backups = 1, NearCache|cacheSize|cacheSize *
2|cacheSize|cacheSize|216|
|CacheMode = LOCAL|cacheSize|cacheSize|cacheSize|0|0|
* how to calculate heapsize for NearCache, set the value obtained empirically
216
* how the assessment is carried out in the checkCache method (clarification is
needed, since the calculated and actual figures differ from the theoretical
ones)
{noformat}
Checking cache, igniteIdx=0, cacheIdx=0
igniteIdx=0, cacheIdx=0 offHeapEntriesCnt offHeapEntriesCnt:300
metrics.getOffHeapEntriesCount(): 300
igniteIdx=0, cacheIdx=0 offHeapBackupEntriesCnt offHeapBackupEntriesCnt:210
metrics.getOffHeapBackupEntriesCount(): 210
igniteIdx=0, cacheIdx=0 offHeapPrimaryEntriesCnt offHeapPrimaryEntriesCnt:90
metrics.getOffHeapPrimaryEntriesCount(): 90
igniteIdx=0, cacheIdx=0 heapEntriesCnt heapEntriesCnt:0
metrics.getHeapEntriesCount(): 0
igniteIdx=0, cacheIdx=0 CacheSize cache:300 metrics.getCacheSize(): 90
Checking cache, igniteIdx=0, cacheIdx=1
igniteIdx=0, cacheIdx=1 offHeapEntriesCnt offHeapEntriesCnt:187
metrics.getOffHeapEntriesCount(): 187
igniteIdx=0, cacheIdx=1 offHeapBackupEntriesCnt offHeapBackupEntriesCnt:101
metrics.getOffHeapBackupEntriesCount(): 101
igniteIdx=0, cacheIdx=1 offHeapPrimaryEntriesCnt offHeapPrimaryEntriesCnt:86
metrics.getOffHeapPrimaryEntriesCount(): 86
igniteIdx=0, cacheIdx=1 heapEntriesCnt heapEntriesCnt:0
metrics.getHeapEntriesCount(): 0
igniteIdx=0, cacheIdx=1 CacheSize cache:187 metrics.getCacheSize(): 86
Checking cache, igniteIdx=0, cacheIdx=2
igniteIdx=0, cacheIdx=2 offHeapEntriesCnt offHeapEntriesCnt:187
metrics.getOffHeapEntriesCount(): 187
igniteIdx=0, cacheIdx=2 offHeapBackupEntriesCnt offHeapBackupEntriesCnt:101
metrics.getOffHeapBackupEntriesCount(): 101
igniteIdx=0, cacheIdx=2 offHeapPrimaryEntriesCnt offHeapPrimaryEntriesCnt:86
metrics.getOffHeapPrimaryEntriesCount(): 86
igniteIdx=0, cacheIdx=2 heapEntriesCnt heapEntriesCnt:67
metrics.getHeapEntriesCount(): 67
igniteIdx=0, cacheIdx=2 CacheSize cache:225 metrics.getCacheSize(): 86
Checking cache, igniteIdx=0, cacheIdx=3
igniteIdx=0, cacheIdx=3 offHeapEntriesCnt offHeapEntriesCnt:100
metrics.getOffHeapEntriesCount(): 100
igniteIdx=0, cacheIdx=3 offHeapBackupEntriesCnt offHeapBackupEntriesCnt:100
metrics.getOffHeapBackupEntriesCount(): 0
igniteIdx=0, cacheIdx=3 offHeapPrimaryEntriesCnt offHeapPrimaryEntriesCnt:100
metrics.getOffHeapPrimaryEntriesCount(): 100
igniteIdx=0, cacheIdx=3 heapEntriesCnt heapEntriesCnt:0
metrics.getHeapEntriesCount(): 0
igniteIdx=0, cacheIdx=3 CacheSize cache:0 metrics.getCacheSize(): 100
Checking cache, igniteIdx=1, cacheIdx=0
igniteIdx=1, cacheIdx=0 offHeapEntriesCnt offHeapEntriesCnt:300
metrics.getOffHeapEntriesCount(): 300
igniteIdx=1, cacheIdx=0 offHeapBackupEntriesCnt offHeapBackupEntriesCnt:195
metrics.getOffHeapBackupEntriesCount(): 195
igniteIdx=1, cacheIdx=0 offHeapPrimaryEntriesCnt offHeapPrimaryEntriesCnt:105
metrics.getOffHeapPrimaryEntriesCount(): 105
igniteIdx=1, cacheIdx=0 heapEntriesCnt heapEntriesCnt:0
metrics.getHeapEntriesCount(): 0
igniteIdx=1, cacheIdx=0 CacheSize cache:300 metrics.getCacheSize(): 105
Checking cache, igniteIdx=1, cacheIdx=1
igniteIdx=1, cacheIdx=1 offHeapEntriesCnt offHeapEntriesCnt:205
metrics.getOffHeapEntriesCount(): 205
igniteIdx=1, cacheIdx=1 offHeapBackupEntriesCnt offHeapBackupEntriesCnt:97
metrics.getOffHeapBackupEntriesCount(): 97
igniteIdx=1, cacheIdx=1 offHeapPrimaryEntriesCnt offHeapPrimaryEntriesCnt:108
metrics.getOffHeapPrimaryEntriesCount(): 108
igniteIdx=1, cacheIdx=1 heapEntriesCnt heapEntriesCnt:0
metrics.getHeapEntriesCount(): 0
igniteIdx=1, cacheIdx=1 CacheSize cache:205 metrics.getCacheSize(): 108
Checking cache, igniteIdx=1, cacheIdx=2
igniteIdx=1, cacheIdx=2 offHeapEntriesCnt offHeapEntriesCnt:205
metrics.getOffHeapEntriesCount(): 205
igniteIdx=1, cacheIdx=2 offHeapBackupEntriesCnt offHeapBackupEntriesCnt:97
metrics.getOffHeapBackupEntriesCount(): 97
igniteIdx=1, cacheIdx=2 offHeapPrimaryEntriesCnt offHeapPrimaryEntriesCnt:108
metrics.getOffHeapPrimaryEntriesCount(): 108
igniteIdx=1, cacheIdx=2 heapEntriesCnt heapEntriesCnt:76
metrics.getHeapEntriesCount(): 76
igniteIdx=1, cacheIdx=2 CacheSize cache:238 metrics.getCacheSize(): 108
Checking cache,
[jira] [Commented] (IGNITE-6564) Incorrect calculation size and keySize for cluster cache metrics
[ https://issues.apache.org/jira/browse/IGNITE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16729298#comment-16729298 ] Alexand Polyakov commented on IGNITE-6564: -- left three open questions * are the counters correctly evaluated in CacheMetricsEntitiesCountTest ||Cache||Size||offHeapEntriesCnt||offHeapPrimaryEntriesCnt||offHeapBackupEntriesCnt||heapEntriesCnt|| |CacheMode = REPLICATED|cacheSize|cacheSize * GRID_CNT|cacheSize|cacheSize * (GRID_CNT - 1)|0| |CacheMode = PARTITIONED, Backups = 1|cacheSize|cacheSize * 2|cacheSize|cacheSize|0| |CacheMode = PARTITIONED, Backups = 1, NearCache|cacheSize|cacheSize * 2|cacheSize|cacheSize|216| |CacheMode = LOCAL|cacheSize|cacheSize|cacheSize|0|0| * how to calculate heapsize for NearCache, set the value obtained empirically 216 * how the assessment is carried out in the checkCache method (clarification is needed, since the calculated and actual figures differ from the theoretical ones) > Incorrect calculation size and keySize for cluster cache metrics > > > Key: IGNITE-6564 > URL: https://issues.apache.org/jira/browse/IGNITE-6564 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Ilya Kasnacheev >Assignee: Alexand Polyakov >Priority: Minor > Labels: iep-6 > > They are currently not passed by ring and therefore only taken from current > node, which returns incorrect (local) value. > See CacheMetricsSnapshot class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-6564) Incorrect calculation size and keySize for cluster cache metrics
[ https://issues.apache.org/jira/browse/IGNITE-6564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexand Polyakov reassigned IGNITE-6564: Assignee: Alexand Polyakov > Incorrect calculation size and keySize for cluster cache metrics > > > Key: IGNITE-6564 > URL: https://issues.apache.org/jira/browse/IGNITE-6564 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.2 >Reporter: Ilya Kasnacheev >Assignee: Alexand Polyakov >Priority: Minor > Labels: iep-6 > > They are currently not passed by ring and therefore only taken from current > node, which returns incorrect (local) value. > See CacheMetricsSnapshot class. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (IGNITE-9120) Metadata writer does not propagate error to failure handler
[
https://issues.apache.org/jira/browse/IGNITE-9120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexand Polyakov reassigned IGNITE-9120:
Assignee: Alexand Polyakov
> Metadata writer does not propagate error to failure handler
> ---
>
> Key: IGNITE-9120
> URL: https://issues.apache.org/jira/browse/IGNITE-9120
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexand Polyakov
>Assignee: Alexand Polyakov
>Priority: Major
>
> In logs
> {code:java}
> [WARN] [tcp-disco-msg-worker- # 2% DPL_GRID% DplGridNodeName%]
> [o.a.i.i.p.c.b.CacheObjectBinaryProcessorImpl] Failed to save metadata for
> typeId: 978611101; The exception was selected: there was no space left on the
> device{code}
> Node does not shut down
> The number of stalled transactions begins to grow.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Assigned] (IGNITE-10324) Disallow fallback to Scanner in control.sh when asking password
[ https://issues.apache.org/jira/browse/IGNITE-10324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexand Polyakov reassigned IGNITE-10324: - Assignee: Alexand Polyakov > Disallow fallback to Scanner in control.sh when asking password > --- > > Key: IGNITE-10324 > URL: https://issues.apache.org/jira/browse/IGNITE-10324 > Project: Ignite > Issue Type: Bug >Reporter: Pavel Voronkin >Assignee: Alexand Polyakov >Priority: Major > > After implementing IGNITE-9990 we still can fallback to Scanner in case of > Console is not allowed, user can easily fallback to non-secure mode by using > some java agent. We should not allow this, cause otherwise all efforts in > IGNITE-9990 are useless. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10557) Control.sh validate index work long and broke down
Alexand Polyakov created IGNITE-10557:
-
Summary: Control.sh validate index work long and broke down
Key: IGNITE-10557
URL: https://issues.apache.org/jira/browse/IGNITE-10557
Project: Ignite
Issue Type: Bug
Components: visor
Affects Versions: 2.6
Reporter: Alexand Polyakov
cluster in the amount of 27Gb
performing validate_indexes took more than 1 hour
and execution failed
{code}
control.sh --cache validate_indexes
Control utility [ver. 2.6]
2018 Copyright(C) Apache Software Foundation
User: pprbusr
Connection to cluster failed.
Error: Failed to perform request (connection failed): /10.117.102.207:11211
You have mail in /var/spool/mail/busr
{code}
analysis of the thread for 40 minutes showed that out of 32 nodes only on 3
nodes were flows ValidateIndexesClosure
at the same time, some threads are blocked
{code}
"pool-55-thread-53" #9255 prio=5 os_prio=0 tid=0x7eb5a0073800 nid=0xb408
waiting for monitor entry [0x7eb6554f3000]
java.lang.Thread.State: BLOCKED (on object monitor)
at
org.apache.ignite.internal.pagemem.PageUtils.getBytes(PageUtils.java:63)
at
org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.readFullRow(CacheDataRowAdapter.java:296)
at
org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:159)
at
org.apache.ignite.internal.processors.cache.persistence.CacheDataRowAdapter.initFromLink(CacheDataRowAdapter.java:102)
at
org.apache.ignite.internal.processors.query.h2.database.H2RowFactory.getRow(H2RowFactory.java:61)
at
org.apache.ignite.internal.processors.query.h2.database.H2Tree.createRowFromLink(H2Tree.java:152)
at
org.apache.ignite.internal.processors.query.h2.database.io.H2InnerIO.getLookupRow(H2InnerIO.java:60)
at
org.apache.ignite.internal.processors.query.h2.database.io.H2InnerIO.getLookupRow(H2InnerIO.java:33)
at
org.apache.ignite.internal.processors.query.h2.database.H2Tree.getRow(H2Tree.java:170)
at
org.apache.ignite.internal.processors.query.h2.database.H2Tree.getRow(H2Tree.java:47)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.getRow(BPlusTree.java:4524)
at
org.apache.ignite.internal.processors.query.h2.database.H2Tree.compare(H2Tree.java:212)
at
org.apache.ignite.internal.processors.query.h2.database.H2Tree.compare(H2Tree.java:47)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.compare(BPlusTree.java:4511)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findInsertionPoint(BPlusTree.java:4431)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.access$1300(BPlusTree.java:90)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Search.run0(BPlusTree.java:291)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:4858)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Search.run(BPlusTree.java:271)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$GetPageHandler.run(BPlusTree.java:4843)
at
org.apache.ignite.internal.processors.cache.persistence.tree.util.PageHandler.readPage(PageHandler.java:161)
at
org.apache.ignite.internal.processors.cache.persistence.DataStructure.read(DataStructure.java:332)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findDown(BPlusTree.java:1157)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doFind(BPlusTree.java:1124)
at
org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.findOne(BPlusTree.java:1091)
at
org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.find(H2TreeIndex.java:201)
at
org.apache.ignite.internal.visor.verify.ValidateIndexesClosure.processPartition(ValidateIndexesClosure.java:524)
at
org.apache.ignite.internal.visor.verify.ValidateIndexesClosure.access$100(ValidateIndexesClosure.java:86)
at
org.apache.ignite.internal.visor.verify.ValidateIndexesClosure$2.call(ValidateIndexesClosure.java:394)
at
org.apache.ignite.internal.visor.verify.ValidateIndexesClosure$2.call(ValidateIndexesClosure.java:392)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Closed] (IGNITE-9698) Add tests to control.sh with ssl authentication
[ https://issues.apache.org/jira/browse/IGNITE-9698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexand Polyakov closed IGNITE-9698. Ignite Flags: (was: Docs Required) > Add tests to control.sh with ssl authentication > > > Key: IGNITE-9698 > URL: https://issues.apache.org/jira/browse/IGNITE-9698 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Kosarev >Assignee: Alexand Polyakov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9698) Add tests to control.sh with ssl authentication
[ https://issues.apache.org/jira/browse/IGNITE-9698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16706455#comment-16706455 ] Alexand Polyakov commented on IGNITE-9698: -- test added under https://issues.apache.org/jira/browse/IGNITE-9298 > Add tests to control.sh with ssl authentication > > > Key: IGNITE-9698 > URL: https://issues.apache.org/jira/browse/IGNITE-9698 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Kosarev >Assignee: Alexand Polyakov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-9698) Add tests to control.sh with ssl authentication
[ https://issues.apache.org/jira/browse/IGNITE-9698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexand Polyakov resolved IGNITE-9698. -- Resolution: Won't Fix > Add tests to control.sh with ssl authentication > > > Key: IGNITE-9698 > URL: https://issues.apache.org/jira/browse/IGNITE-9698 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Kosarev >Assignee: Alexand Polyakov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (IGNITE-9698) Add tests to control.sh with ssl authentication
[ https://issues.apache.org/jira/browse/IGNITE-9698?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16668462#comment-16668462 ] Alexand Polyakov commented on IGNITE-9698: -- https://issues.apache.org/jira/browse/IGNITE-9298 has 2 implementations community planed to take implementation of Paul Anderson and this ticket add test from my implementation > Add tests to control.sh with ssl authentication > > > Key: IGNITE-9698 > URL: https://issues.apache.org/jira/browse/IGNITE-9698 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Kosarev >Assignee: Alexand Polyakov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (IGNITE-10060) Optimize test use seconds instead of minutes
[ https://issues.apache.org/jira/browse/IGNITE-10060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexand Polyakov resolved IGNITE-10060. --- Resolution: Invalid > Optimize test use seconds instead of minutes > > > Key: IGNITE-10060 > URL: https://issues.apache.org/jira/browse/IGNITE-10060 > Project: Ignite > Issue Type: Test >Reporter: Alexand Polyakov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (IGNITE-10060) Optimize test use seconds instead of minutes
[ https://issues.apache.org/jira/browse/IGNITE-10060?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexand Polyakov updated IGNITE-10060: -- Summary: Optimize test use seconds instead of minutes (was: Optimize IncSnapshotNearbyFullSnapshotTest#test use seconds instead of minutes) > Optimize test use seconds instead of minutes > > > Key: IGNITE-10060 > URL: https://issues.apache.org/jira/browse/IGNITE-10060 > Project: Ignite > Issue Type: Test >Reporter: Alexand Polyakov >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10060) Optimize IncSnapshotNearbyFullSnapshotTest#test use seconds instead of minutes
Alexand Polyakov created IGNITE-10060: - Summary: Optimize IncSnapshotNearbyFullSnapshotTest#test use seconds instead of minutes Key: IGNITE-10060 URL: https://issues.apache.org/jira/browse/IGNITE-10060 Project: Ignite Issue Type: Test Reporter: Alexand Polyakov -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-10020) control.sh error: Comparison method violates its general contract!
Alexand Polyakov created IGNITE-10020: - Summary: control.sh error: Comparison method violates its general contract! Key: IGNITE-10020 URL: https://issues.apache.org/jira/browse/IGNITE-10020 Project: Ignite Issue Type: Bug Reporter: Alexand Polyakov Assignee: Alexand Polyakov ./control.sh --host 192.168.1.1 --cache distribution null Control utility [ver. 2.5#20181002-sha1:3d28432b] 2018 Copyright(C) Apache Software Foundation User: test Check arguments. Error: Comparison method violates its general contract! -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (IGNITE-9990) Control.sh utility should request a password if necessary.
Alexand Polyakov created IGNITE-9990:
Summary: Control.sh utility should request a password if necessary.
Key: IGNITE-9990
URL: https://issues.apache.org/jira/browse/IGNITE-9990
Project: Ignite
Issue Type: New Feature
Affects Versions: 2.5
Reporter: Alexand Polyakov
Assignee: Alexand Polyakov
Since password in line parameters may not be safe (stored in console history in
open form).
Use hidden input
{code:java}
Console console = System.console();
char passwordArray[] = console.readPassword("password: ");
{code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (IGNITE-9954) An error in rollback the transaction caused the cluster to hang
[
https://issues.apache.org/jira/browse/IGNITE-9954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexand Polyakov updated IGNITE-9954:
-
Summary: An error in rollback the transaction caused the cluster to hang
(was: An error in rolling back the transaction caused the cluster to hang)
> An error in rollback the transaction caused the cluster to hang
> ---
>
> Key: IGNITE-9954
> URL: https://issues.apache.org/jira/browse/IGNITE-9954
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Kalinin
>Priority: Major
>
> Starts a transaction with a small timeout
> on one node, we observe the rollback of the transaction by timeout:
> {code:java}
> 2018-10-18 02:14:13.339
> [ERROR][sys-stripe-48-#49%GRID%GridNodeName%][o.a.i.i.p.c.t.IgniteTxHandler]
> Failed to process prepare request: GridDhtTxPrepareRequest
> [nearNodeId=ab0c3e9f-1642-4779-a6a0-dd10a6efd387,
> futId=54208048661-53dd6648-cc70-4076-a608-f6072645e609, miniId=1,
> topVer=AffinityTopologyVersion [topVer=338, minorTopVer=0],
> invalidateNearEntries={}, nearWrites=null, owned=null,
> nearXidVer=GridCacheVersion [topVer=151260338, order=1543126364337,
> nodeOrder=172], subjId=ab0c3e9f-1642-4779-a6a0-dd10a6efd387, taskNameHash=0,
> preloadKeys=null, skipCompletedVers=false,
> super=GridDistributedTxPrepareRequest [threadId=732, concurrency=PESSIMISTIC,
> isolation=REPEATABLE_READ, writeVer=GridCacheVersion [topVer=151260338,
> order=1543126439977, nodeOrder=81], timeout=9, reads=null, writes=ArrayList
> [IgniteTxEntry [key=KeyCacheObjectImpl [part=12715, val=ids_name,
> hasValBytes=true], cacheId=-1934881220, txKey=IgniteTxKey
> [key=KeyCacheObjectImpl [part=12715, val=ids_name, hasValBytes=true],
> cacheId=-1934881220], val=CacheObjectImpl [val=null,
> hasValBytes=true][op=UPDATE, val=], prevVal=[op=NOOP, val=null],
> oldVal=CacheObjectImpl [val=null, hasValBytes=true][op=UPDATE, val=],
> entryProcessorsCol=null, ttl=-1, conflictExpireTime=-1, conflictVer=null,
> explicitVer=null, dhtVer=null, filters=CacheEntryPredicate[] [],
> filtersPassed=false, filtersSet=false, entry=GridCacheMapEntry
> [key=KeyCacheObjectImpl [part=12715, val=ids_name, hasValBytes=true],
> val=null, startVer=1543128775655, ver=GridCacheVersion [topVer=151260338,
> order=1543126364674, nodeOrder=81], hash=-864500235,
> extras=GridCacheObsoleteEntryExtras [obsoleteVer=GridCacheVersion
> [topVer=2147483647, order=0, nodeOrder=0]], flags=2]GridDistributedCacheEntry
> [super=]GridDhtCacheEntry [rdrs=ReaderId[] [], part=12715, super=],
> prepared=0, locked=false, nodeId=null, locMapped=false, expiryPlc=null,
> transferExpiryPlc=false, flags=2, partUpdateCntr=0, serReadVer=null,
> xidVer=null]], dhtVers=null, txSize=0, plc=2, txState=null,
> flags=onePhase|last, super=GridDistributedBaseMessage [ver=GridCacheVersion
> [topVer=151260338, order=1543126439864, nodeOrder=81], committedVers=null,
> rolledbackVers=null, cnt=0, super=GridCacheIdMessage [cacheId=0
> org.apache.ignite.internal.transactions.IgniteTxTimeoutCheckedException:
> Transaction timed out: GridCacheSharedManagerAdapter [starting=true,
> stop=false]
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxManager.prepareTx(IgniteTxManager.java:868)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.prepareRemoteTx(GridDistributedTxRemoteAdapter.java:406)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.startRemoteTx(IgniteTxHandler.java:1754)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxPrepareRequest(IgniteTxHandler.java:1121)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.access$400(IgniteTxHandler.java:101)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$5.apply(IgniteTxHandler.java:205)
> at
> org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$5.apply(IgniteTxHandler.java:203)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1058)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:583)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:382)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:308)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:101)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1$2$1.run(GridCacheIoManager.java:277)
>
