[jira] [Updated] (IGNITE-12946) Add description to MBeans
[ https://issues.apache.org/jira/browse/IGNITE-12946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis A. Magda updated IGNITE-12946: Labels: IEP-35 (was: ) > Add description to MBeans > - > > Key: IGNITE-12946 > URL: https://issues.apache.org/jira/browse/IGNITE-12946 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.8 >Reporter: Denis A. Magda >Priority: Major > Labels: IEP-35 > > Presently, application developers will see hundreds of metrics once connect > through JMX and it will be hard for them to sort out the valuable ones. > The documentation can do a great job outlining the right ones but we can also > add descriptions to MXBeans explaining what each metric reports. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12946) Add description to MBeans
Denis A. Magda created IGNITE-12946: --- Summary: Add description to MBeans Key: IGNITE-12946 URL: https://issues.apache.org/jira/browse/IGNITE-12946 Project: Ignite Issue Type: Improvement Affects Versions: 2.8 Reporter: Denis A. Magda Presently, application developers will see hundreds of metrics once connect through JMX and it will be hard for them to sort out the valuable ones. The documentation can do a great job outlining the right ones but we can also add descriptions to MXBeans explaining what each metric reports. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12945) Put Ignite MBeans under a proper path
[
https://issues.apache.org/jira/browse/IGNITE-12945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis A. Magda updated IGNITE-12945:
Labels: IEP-35 (was: )
> Put Ignite MBeans under a proper path
> -
>
> Key: IGNITE-12945
> URL: https://issues.apache.org/jira/browse/IGNITE-12945
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.8
>Reporter: Denis A. Magda
>Priority: Major
> Labels: IEP-35
>
> Presently, Ignite MBeans are listed under {{org.apache.{node_id}} path but
> should be rather placed under {{org.apache.ignite.{node_id}}}.
> Most likely we can do it only for Ignite 3.0 to preserve backward
> compatibility.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12945) Put Ignite MBeans under a proper path
[
https://issues.apache.org/jira/browse/IGNITE-12945?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis A. Magda updated IGNITE-12945:
Description:
Presently, Ignite MBeans are listed under {{org.apache.node_id}} path but
should be rather placed under {{org.apache.ignite.node_id}}.
Most likely we can do it only for Ignite 3.0 to preserve backward compatibility.
was:
Presently, Ignite MBeans are listed under {{org.apache.{node_id}} path but
should be rather placed under {{org.apache.ignite.{node_id}}}.
Most likely we can do it only for Ignite 3.0 to preserve backward compatibility.
> Put Ignite MBeans under a proper path
> -
>
> Key: IGNITE-12945
> URL: https://issues.apache.org/jira/browse/IGNITE-12945
> Project: Ignite
> Issue Type: Task
>Affects Versions: 2.8
>Reporter: Denis A. Magda
>Priority: Major
> Labels: IEP-35
>
> Presently, Ignite MBeans are listed under {{org.apache.node_id}} path but
> should be rather placed under {{org.apache.ignite.node_id}}.
> Most likely we can do it only for Ignite 3.0 to preserve backward
> compatibility.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12945) Put Ignite MBeans under a proper path
Denis A. Magda created IGNITE-12945:
---
Summary: Put Ignite MBeans under a proper path
Key: IGNITE-12945
URL: https://issues.apache.org/jira/browse/IGNITE-12945
Project: Ignite
Issue Type: Task
Affects Versions: 2.8
Reporter: Denis A. Magda
Presently, Ignite MBeans are listed under {{org.apache.{node_id}} path but
should be rather placed under {{org.apache.ignite.{node_id}}}.
Most likely we can do it only for Ignite 3.0 to preserve backward compatibility.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12944) Remove additional parameters required for collection of some metrics
[ https://issues.apache.org/jira/browse/IGNITE-12944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis A. Magda updated IGNITE-12944: Labels: IEP-35 (was: ) > Remove additional parameters required for collection of some metrics > > > Key: IGNITE-12944 > URL: https://issues.apache.org/jira/browse/IGNITE-12944 > Project: Ignite > Issue Type: Task >Affects Versions: 2.8 >Reporter: Denis A. Magda >Priority: Major > Labels: IEP-35 > > For some of the metrics, it won't be enough to create an exporter to enable > their collection. For instance, data region and cache APIs require to turn on > additional parameters: > * > https://apacheignite.readme.io/docs/memory-metrics#enabling-data-region-metrics > * https://apacheignite.readme.io/docs/cache-metrics#enabling-cache-metrics > We should remove such requirements after > https://issues.apache.org/jira/browse/IGNITE-11927 is completed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12944) Remove additional parameters required for collection of some metrics
Denis A. Magda created IGNITE-12944: --- Summary: Remove additional parameters required for collection of some metrics Key: IGNITE-12944 URL: https://issues.apache.org/jira/browse/IGNITE-12944 Project: Ignite Issue Type: Task Affects Versions: 2.8 Reporter: Denis A. Magda For some of the metrics, it won't be enough to create an exporter to enable their collection. For instance, data region and cache APIs require to turn on additional parameters: * https://apacheignite.readme.io/docs/memory-metrics#enabling-data-region-metrics * https://apacheignite.readme.io/docs/cache-metrics#enabling-cache-metrics We should remove such requirements after https://issues.apache.org/jira/browse/IGNITE-11927 is completed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12943) Document how to filter out metrics from registries
[
https://issues.apache.org/jira/browse/IGNITE-12943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis A. Magda updated IGNITE-12943:
Labels: IEP-35 (was: )
> Document how to filter out metrics from registries
> --
>
> Key: IGNITE-12943
> URL: https://issues.apache.org/jira/browse/IGNITE-12943
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Denis A. Magda
>Priority: Major
> Labels: IEP-35
> Fix For: 2.8.1
>
>
> As per {{MetricExporterSpi.setExportFilter}} contract, the user can filter
> out metrics for a specific exporter instance. For instance, this is how we
> can ask a JMX exporter instance to ignore the cache metrics:
> {code}
> JmxMetricExporterSpi jmxSpi = new JmxMetricExporterSpi();
> jmxSpi.setExportFilter(mreg -> !mreg.name().startsWith(«cache»));
> cfg.setMetricExporterSpi(jmxSpi);
> {code}
> We should add {{Metrics Filtering}} section to this documentation page [1]
> explaining how to use the filtering. Also, I would clarify in the
> {{MetricExporterSpi.setExportFilter}} JavaDocs that the method filters out
> certain metrics from a specific exporter.
> Also, should we possibly rename the method to
> {{MetricExporterSpi.setMetricsFilter}} to make things crystal clear?
> [1] https://apacheignite.readme.io/docs/new-metrics
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12943) Document how to filter out metrics from registries
[
https://issues.apache.org/jira/browse/IGNITE-12943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis A. Magda updated IGNITE-12943:
Description:
As per {{MetricExporterSpi.setExportFilter}} contract, the user can filter out
metrics for a specific exporter instance. For instance, this is how we can ask
a JMX exporter instance to ignore the cache metrics:
{code}
JmxMetricExporterSpi jmxSpi = new JmxMetricExporterSpi();
jmxSpi.setExportFilter(mreg -> !mreg.name().startsWith(«cache»));
cfg.setMetricExporterSpi(jmxSpi);
{code}
We should add {{Metrics Filtering}} section to this documentation page [1]
explaining how to use the filtering. Also, I would clarify in the
{{MetricExporterSpi.setExportFilter}} JavaDocs that the method filters out
certain metrics from a specific exporter.
Also, should we possibly rename the method to
{{MetricExporterSpi.setMetricsFilter}} to make things crystal clear?
[1] https://apacheignite.readme.io/docs/new-metrics
was:
As per {{MetricExporterSpi.setExportFilter}} contract, the user can filter out
metrics for a specific exporter instance. For instance, this is how we can ask
a JMX exporter instance to ignore the cache metrics:
{code}
JmxMetricExporterSpi jmxSpi = new JmxMetricExporterSpi();
jmxSpi.setExportFilter(mreg -> !mreg.name().startsWith(«cache»));
cfg.setMetricExporterSpi(jmxSpi);
{code}
We should add `Metrics Filtering section to this documentation page [1]
explaining how to use the filtering. Also, I would clarify in the
`MetricExporterSpi.setExportFilter` JavaDocs that the method filters out
certain metrics from a specific exporter.
Also, should we possibly rename the method to
`MetricExporterSpi.setMetricsFilter` to make things crystal clear?
[1] https://apacheignite.readme.io/docs/new-metrics
> Document how to filter out metrics from registries
> --
>
> Key: IGNITE-12943
> URL: https://issues.apache.org/jira/browse/IGNITE-12943
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Denis A. Magda
>Priority: Major
> Fix For: 2.8.1
>
>
> As per {{MetricExporterSpi.setExportFilter}} contract, the user can filter
> out metrics for a specific exporter instance. For instance, this is how we
> can ask a JMX exporter instance to ignore the cache metrics:
> {code}
> JmxMetricExporterSpi jmxSpi = new JmxMetricExporterSpi();
> jmxSpi.setExportFilter(mreg -> !mreg.name().startsWith(«cache»));
> cfg.setMetricExporterSpi(jmxSpi);
> {code}
> We should add {{Metrics Filtering}} section to this documentation page [1]
> explaining how to use the filtering. Also, I would clarify in the
> {{MetricExporterSpi.setExportFilter}} JavaDocs that the method filters out
> certain metrics from a specific exporter.
> Also, should we possibly rename the method to
> {{MetricExporterSpi.setMetricsFilter}} to make things crystal clear?
> [1] https://apacheignite.readme.io/docs/new-metrics
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12943) Document how to filter out metrics from registries
[
https://issues.apache.org/jira/browse/IGNITE-12943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis A. Magda updated IGNITE-12943:
Description:
As per {{MetricExporterSpi.setExportFilter}} contract, the user can filter out
metrics for a specific exporter instance. For instance, this is how we can ask
a JMX exporter instance to ignore the cache metrics:
{code}
JmxMetricExporterSpi jmxSpi = new JmxMetricExporterSpi();
jmxSpi.setExportFilter(mreg -> !mreg.name().startsWith(«cache»));
cfg.setMetricExporterSpi(jmxSpi);
{code}
We should add `Metrics Filtering section to this documentation page [1]
explaining how to use the filtering. Also, I would clarify in the
`MetricExporterSpi.setExportFilter` JavaDocs that the method filters out
certain metrics from a specific exporter.
Also, should we possibly rename the method to
`MetricExporterSpi.setMetricsFilter` to make things crystal clear?
[1] https://apacheignite.readme.io/docs/new-metrics
was:
As per {MetricExporterSpi.setExportFilter} contract, the user can filter out
metrics for a specific exporter instance. For instance, this is how we can ask
a JMX exporter instance to ignore the cache metrics:
{code}
JmxMetricExporterSpi jmxSpi = new JmxMetricExporterSpi();
jmxSpi.setExportFilter(mreg -> !mreg.name().startsWith(«cache»));
cfg.setMetricExporterSpi(jmxSpi);
{code}
We should add `Metrics Filtering section to this documentation page [1]
explaining how to use the filtering. Also, I would clarify in the
`MetricExporterSpi.setExportFilter` JavaDocs that the method filters out
certain metrics from a specific exporter.
Also, should we possibly rename the method to
`MetricExporterSpi.setMetricsFilter` to make things crystal clear?
[1] https://apacheignite.readme.io/docs/new-metrics
> Document how to filter out metrics from registries
> --
>
> Key: IGNITE-12943
> URL: https://issues.apache.org/jira/browse/IGNITE-12943
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Denis A. Magda
>Priority: Major
> Fix For: 2.8.1
>
>
> As per {{MetricExporterSpi.setExportFilter}} contract, the user can filter
> out metrics for a specific exporter instance. For instance, this is how we
> can ask a JMX exporter instance to ignore the cache metrics:
> {code}
> JmxMetricExporterSpi jmxSpi = new JmxMetricExporterSpi();
> jmxSpi.setExportFilter(mreg -> !mreg.name().startsWith(«cache»));
> cfg.setMetricExporterSpi(jmxSpi);
> {code}
> We should add `Metrics Filtering section to this documentation page [1]
> explaining how to use the filtering. Also, I would clarify in the
> `MetricExporterSpi.setExportFilter` JavaDocs that the method filters out
> certain metrics from a specific exporter.
> Also, should we possibly rename the method to
> `MetricExporterSpi.setMetricsFilter` to make things crystal clear?
> [1] https://apacheignite.readme.io/docs/new-metrics
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12943) Document how to filter out metrics from registries
[
https://issues.apache.org/jira/browse/IGNITE-12943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis A. Magda updated IGNITE-12943:
Description:
As per {MetricExporterSpi.setExportFilter} contract, the user can filter out
metrics for a specific exporter instance. For instance, this is how we can ask
a JMX exporter instance to ignore the cache metrics:
{code}
JmxMetricExporterSpi jmxSpi = new JmxMetricExporterSpi();
jmxSpi.setExportFilter(mreg -> !mreg.name().startsWith(«cache»));
cfg.setMetricExporterSpi(jmxSpi);
{code}
We should add `Metrics Filtering section to this documentation page [1]
explaining how to use the filtering. Also, I would clarify in the
`MetricExporterSpi.setExportFilter` JavaDocs that the method filters out
certain metrics from a specific exporter.
Also, should we possibly rename the method to
`MetricExporterSpi.setMetricsFilter` to make things crystal clear?
[1] https://apacheignite.readme.io/docs/new-metrics
was:
As per {code}MetricExporterSpi.setExportFilter{code} contract, the user can
filter out metrics for a specific exporter instance. For instance, this is how
we can ask a JMX exporter instance to ignore the cache metrics:
{code}
JmxMetricExporterSpi jmxSpi = new JmxMetricExporterSpi();
jmxSpi.setExportFilter(mreg -> !mreg.name().startsWith(«cache»));
cfg.setMetricExporterSpi(jmxSpi);
{code}
We should add `Metrics Filtering section to this documentation page [1]
explaining how to use the filtering. Also, I would clarify in the
`MetricExporterSpi.setExportFilter` JavaDocs that the method filters out
certain metrics from a specific exporter.
Also, should we possibly rename the method to
`MetricExporterSpi.setMetricsFilter` to make things crystal clear?
[1] https://apacheignite.readme.io/docs/new-metrics
> Document how to filter out metrics from registries
> --
>
> Key: IGNITE-12943
> URL: https://issues.apache.org/jira/browse/IGNITE-12943
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Denis A. Magda
>Priority: Major
> Fix For: 2.8.1
>
>
> As per {MetricExporterSpi.setExportFilter} contract, the user can filter out
> metrics for a specific exporter instance. For instance, this is how we can
> ask a JMX exporter instance to ignore the cache metrics:
> {code}
> JmxMetricExporterSpi jmxSpi = new JmxMetricExporterSpi();
> jmxSpi.setExportFilter(mreg -> !mreg.name().startsWith(«cache»));
> cfg.setMetricExporterSpi(jmxSpi);
> {code}
> We should add `Metrics Filtering section to this documentation page [1]
> explaining how to use the filtering. Also, I would clarify in the
> `MetricExporterSpi.setExportFilter` JavaDocs that the method filters out
> certain metrics from a specific exporter.
> Also, should we possibly rename the method to
> `MetricExporterSpi.setMetricsFilter` to make things crystal clear?
> [1] https://apacheignite.readme.io/docs/new-metrics
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12943) Document how to filter out metrics from registries
[
https://issues.apache.org/jira/browse/IGNITE-12943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis A. Magda updated IGNITE-12943:
Description:
As per {code}MetricExporterSpi.setExportFilter{code} contract, the user can
filter out metrics for a specific exporter instance. For instance, this is how
we can ask a JMX exporter instance to ignore the cache metrics:
{code}
JmxMetricExporterSpi jmxSpi = new JmxMetricExporterSpi();
jmxSpi.setExportFilter(mreg -> !mreg.name().startsWith(«cache»));
cfg.setMetricExporterSpi(jmxSpi);
{code}
We should add `Metrics Filtering section to this documentation page [1]
explaining how to use the filtering. Also, I would clarify in the
`MetricExporterSpi.setExportFilter` JavaDocs that the method filters out
certain metrics from a specific exporter.
Also, should we possibly rename the method to
`MetricExporterSpi.setMetricsFilter` to make things crystal clear?
[1] https://apacheignite.readme.io/docs/new-metrics
was:
As per `MetricExporterSpi.setExportFilter` contract, the user can filter out
metrics for a specific exporter instance. For instance, this is how we can ask
a JMX exporter instance to ignore the cache metrics:
{code}
JmxMetricExporterSpi jmxSpi = new JmxMetricExporterSpi();
jmxSpi.setExportFilter(mreg -> !mreg.name().startsWith(«cache»));
cfg.setMetricExporterSpi(jmxSpi);
{code}
We should add `Metrics Filtering` section to this documentation page [1]
explaining how to use the filtering. Also, I would clarify in the
`MetricExporterSpi.setExportFilter` JavaDocs that the method filters out
certain metrics from a specific exporter.
Also, should we possibly rename the method to
`MetricExporterSpi.setMetricsFilter` to make things crystal clear?
[1] https://apacheignite.readme.io/docs/new-metrics
> Document how to filter out metrics from registries
> --
>
> Key: IGNITE-12943
> URL: https://issues.apache.org/jira/browse/IGNITE-12943
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Denis A. Magda
>Priority: Major
> Fix For: 2.8.1
>
>
> As per {code}MetricExporterSpi.setExportFilter{code} contract, the user can
> filter out metrics for a specific exporter instance. For instance, this is
> how we can ask a JMX exporter instance to ignore the cache metrics:
> {code}
> JmxMetricExporterSpi jmxSpi = new JmxMetricExporterSpi();
> jmxSpi.setExportFilter(mreg -> !mreg.name().startsWith(«cache»));
> cfg.setMetricExporterSpi(jmxSpi);
> {code}
> We should add `Metrics Filtering section to this documentation page [1]
> explaining how to use the filtering. Also, I would clarify in the
> `MetricExporterSpi.setExportFilter` JavaDocs that the method filters out
> certain metrics from a specific exporter.
> Also, should we possibly rename the method to
> `MetricExporterSpi.setMetricsFilter` to make things crystal clear?
> [1] https://apacheignite.readme.io/docs/new-metrics
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12943) Document how to filter out metrics from registries
Denis A. Magda created IGNITE-12943:
---
Summary: Document how to filter out metrics from registries
Key: IGNITE-12943
URL: https://issues.apache.org/jira/browse/IGNITE-12943
Project: Ignite
Issue Type: Task
Reporter: Denis A. Magda
Fix For: 2.8.1
As per `MetricExporterSpi.setExportFilter` contract, the user can filter out
metrics for a specific exporter instance. For instance, this is how we can ask
a JMX exporter instance to ignore the cache metrics:
{code}
JmxMetricExporterSpi jmxSpi = new JmxMetricExporterSpi();
jmxSpi.setExportFilter(mreg -> !mreg.name().startsWith(«cache»));
cfg.setMetricExporterSpi(jmxSpi);
{code}
We should add `Metrics Filtering` section to this documentation page [1]
explaining how to use the filtering. Also, I would clarify in the
`MetricExporterSpi.setExportFilter` JavaDocs that the method filters out
certain metrics from a specific exporter.
Also, should we possibly rename the method to
`MetricExporterSpi.setMetricsFilter` to make things crystal clear?
[1] https://apacheignite.readme.io/docs/new-metrics
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12943) Document how to filter out metrics from registries
[
https://issues.apache.org/jira/browse/IGNITE-12943?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis A. Magda updated IGNITE-12943:
Component/s: documentation
> Document how to filter out metrics from registries
> --
>
> Key: IGNITE-12943
> URL: https://issues.apache.org/jira/browse/IGNITE-12943
> Project: Ignite
> Issue Type: Task
> Components: documentation
>Reporter: Denis A. Magda
>Priority: Major
> Fix For: 2.8.1
>
>
> As per `MetricExporterSpi.setExportFilter` contract, the user can filter out
> metrics for a specific exporter instance. For instance, this is how we can
> ask a JMX exporter instance to ignore the cache metrics:
> {code}
> JmxMetricExporterSpi jmxSpi = new JmxMetricExporterSpi();
> jmxSpi.setExportFilter(mreg -> !mreg.name().startsWith(«cache»));
> cfg.setMetricExporterSpi(jmxSpi);
> {code}
> We should add `Metrics Filtering` section to this documentation page [1]
> explaining how to use the filtering. Also, I would clarify in the
> `MetricExporterSpi.setExportFilter` JavaDocs that the method filters out
> certain metrics from a specific exporter.
> Also, should we possibly rename the method to
> `MetricExporterSpi.setMetricsFilter` to make things crystal clear?
> [1] https://apacheignite.readme.io/docs/new-metrics
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12942) control.sh add command for checking that inline size is same on all cluster nodes
[ https://issues.apache.org/jira/browse/IGNITE-12942?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Antonov updated IGNITE-12942: Release Note: Added "--cache check_index_inline_sizes" command to control utility. The command checks that indexes inline size the same on all cluster nodes. The command could be useful for analyzing performance problems with SQL queries. > control.sh add command for checking that inline size is same on all cluster > nodes > - > > Key: IGNITE-12942 > URL: https://issues.apache.org/jira/browse/IGNITE-12942 > Project: Ignite > Issue Type: New Feature >Reporter: Sergey Antonov >Assignee: Sergey Antonov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > We should check that the inline size is the same for the index on all nodes > in the cluster. > 1. Check inline_size of secondary indexes on node join. Warn to log if they > differ and propose a recreate problem index. > 2. Introduce a new command to control.sh (control.sh --cache > check_index_inline_sizes). The command will check inline sizes of secondary > indexes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12942) control.sh add command for checking that inline size is same on all cluster nodes
Sergey Antonov created IGNITE-12942: --- Summary: control.sh add command for checking that inline size is same on all cluster nodes Key: IGNITE-12942 URL: https://issues.apache.org/jira/browse/IGNITE-12942 Project: Ignite Issue Type: New Feature Reporter: Sergey Antonov Assignee: Sergey Antonov Fix For: 2.9 We should check that the inline size is the same for the index on all nodes in the cluster. 1. Check inline_size of secondary indexes on node join. Warn to log if they differ and propose a recreate problem index. 2. Introduce a new command to control.sh (control.sh --cache check_index_inline_sizes). The command will check inline sizes of secondary indexes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12941) .NET: Support .NET 5
Pavel Tupitsyn created IGNITE-12941:
---
Summary: .NET: Support .NET 5
Key: IGNITE-12941
URL: https://issues.apache.org/jira/browse/IGNITE-12941
Project: Ignite
Issue Type: New Feature
Components: platforms
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 2.9
.NET 5 is in preview. Ignite.NET does not seem to work there. Tested on Ubuntu:
* Install .NET 5 SDK from Snap
* Create new console app, add Apache.Ignite nuget package
* Add Ignition.Start
* dotnet run
{code}
Unhandled exception. Apache.Ignite.Core.Common.IgniteException: Failed to load
libjvm.so:
[option=/usr/bin/java,
path=/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so,
error=Unknown error]
[option=/usr/bin/java,
path=/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so,
error=/snap/core18/current/lib/x86_64-linux-gnu/libm.so.6: version `GLIBC_2.29'
not found (required by
/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so)]
at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.Load(String
configJvmDllPath, ILogger log)
at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
at Apache.Ignite.Core.Ignition.Start()
at dotnet5.Program.Main(String[] args) in
/home/pavel/w/tests/dotnet5/Program.cs:line 10
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12941) .NET: Support .NET 5
[
https://issues.apache.org/jira/browse/IGNITE-12941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-12941:
Labels: .NET newbie (was: .NET)
> .NET: Support .NET 5
>
>
> Key: IGNITE-12941
> URL: https://issues.apache.org/jira/browse/IGNITE-12941
> Project: Ignite
> Issue Type: New Feature
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, newbie
> Fix For: 2.9
>
>
> .NET 5 is in preview. Ignite.NET does not seem to work there. Tested on
> Ubuntu:
> * Install .NET 5 SDK from Snap
> * Create new console app, add Apache.Ignite nuget package
> * Add Ignition.Start
> * dotnet run
> {code}
> Unhandled exception. Apache.Ignite.Core.Common.IgniteException: Failed to
> load libjvm.so:
> [option=/usr/bin/java,
> path=/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so,
> error=Unknown error]
> [option=/usr/bin/java,
> path=/usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so,
> error=/snap/core18/current/lib/x86_64-linux-gnu/libm.so.6: version
> `GLIBC_2.29' not found (required by
> /usr/lib/jvm/java-8-openjdk-amd64/jre/lib/amd64/server/libjvm.so)]
>at Apache.Ignite.Core.Impl.Unmanaged.Jni.JvmDll.Load(String
> configJvmDllPath, ILogger log)
>at Apache.Ignite.Core.Ignition.Start(IgniteConfiguration cfg)
>at Apache.Ignite.Core.Ignition.Start()
>at dotnet5.Program.Main(String[] args) in
> /home/pavel/w/tests/dotnet5/Program.cs:line 10
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-10720) Decrease time to save metadata during checkpoint
[
https://issues.apache.org/jira/browse/IGNITE-10720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091828#comment-17091828
]
Ivan Daschinskiy edited comment on IGNITE-10720 at 4/24/20, 7:01 PM:
-
[~akalashnikov] [~agoncharuk] [~zstan] +1 For deadlock. Changed implementation
to synchronous and {{IgniteSequentialNodeCrashRecoveryTest}} doesn't hang
locally. On master this test on my laptop hangs almost in all runs.
{code}
[2020-04-24 21:49:49,383][WARN
][checkpoint-runner-#215%db.IgniteSequentialNodeCrashRecoveryTest0%][IgniteTestResources]
Possible failure suppressed accordingly to a configured handler
[hnd=NoOpFailureHandler [super=AbstractFailureHandler
[ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
[type=SYSTEM_CRITICAL_OPERATION_TIMEOUT, err=class o.a.i.IgniteException:
Checkpoint read lock acquisition has been timed out.]]
class org.apache.ignite.IgniteException: Checkpoint read lock acquisition has
been timed out.
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.failCheckpointReadLock(GridCacheDatabaseSharedManager.java:1746)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.checkpointReadLock(GridCacheDatabaseSharedManager.java:1683)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.init0(GridCacheOffheapManager.java:1696)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.fullSize(GridCacheOffheapManager.java:2069)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager$Checkpointer.lambda$fillCacheGroupState$1(GridCacheDatabaseSharedManager.java:4190)
at
org.apache.ignite.internal.util.IgniteUtils.lambda$wrapIgniteFuture$3(IgniteUtils.java:11412)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{code}
was (Author: ivandasch):
[~akalashnikov] [~agoncharuk] [~zstan] +1 For deadlock. Changed implementation
to synchronous and {{IgniteSequentialNodeCrashRecoveryTest}} doesn't hang
locally. On master this test on my laptop hangs almost in all runs.
> Decrease time to save metadata during checkpoint
>
>
> Key: IGNITE-10720
> URL: https://issues.apache.org/jira/browse/IGNITE-10720
> Project: Ignite
> Issue Type: Improvement
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Looks like it's not neccessery save all metadata(like free list) under write
> checkpoint lock because sometimes it's too long.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-10720) Decrease time to save metadata during checkpoint
[
https://issues.apache.org/jira/browse/IGNITE-10720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091828#comment-17091828
]
Ivan Daschinskiy edited comment on IGNITE-10720 at 4/24/20, 6:59 PM:
-
[~akalashnikov] [~agoncharuk] [~zstan] +1 For deadlock. Changed implementation
to synchronous and {{IgniteSequentialNodeCrashRecoveryTest}} doesn't hang
locally. On master this test on my laptop hangs almost in all runs.
was (Author: ivandasch):
[~akalashnikov][~agoncharuk][~zstan] +1 For deadlock. Changed implementation to
synchronous and {{IgniteSequentialNodeCrashRecoveryTest}} doesn't hang locally.
On master this test on my laptop hangs almost in all runs.
> Decrease time to save metadata during checkpoint
>
>
> Key: IGNITE-10720
> URL: https://issues.apache.org/jira/browse/IGNITE-10720
> Project: Ignite
> Issue Type: Improvement
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Looks like it's not neccessery save all metadata(like free list) under write
> checkpoint lock because sometimes it's too long.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-10720) Decrease time to save metadata during checkpoint
[
https://issues.apache.org/jira/browse/IGNITE-10720?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091828#comment-17091828
]
Ivan Daschinskiy commented on IGNITE-10720:
---
[~akalashnikov][~agoncharuk][~zstan] +1 For deadlock. Changed implementation to
synchronous and {{IgniteSequentialNodeCrashRecoveryTest}} doesn't hang locally.
On master this test on my laptop hangs almost in all runs.
> Decrease time to save metadata during checkpoint
>
>
> Key: IGNITE-10720
> URL: https://issues.apache.org/jira/browse/IGNITE-10720
> Project: Ignite
> Issue Type: Improvement
>Reporter: Anton Kalashnikov
>Assignee: Anton Kalashnikov
>Priority: Major
> Fix For: 2.8
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Looks like it's not neccessery save all metadata(like free list) under write
> checkpoint lock because sometimes it's too long.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12940) .NET: NuGet tests fail with compilation error
[
https://issues.apache.org/jira/browse/IGNITE-12940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-12940:
Fix Version/s: 2.9
> .NET: NuGet tests fail with compilation error
> -
>
> Key: IGNITE-12940
> URL: https://issues.apache.org/jira/browse/IGNITE-12940
> Project: Ignite
> Issue Type: New Feature
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
> Fix For: 2.9
>
>
> {code}
> :\BuildAgent\temp\buildTmp\NuGetScratch\1izrscml.xvp.nugetrestore.targets(435,34):
> error MSB4092: An unexpected token ")" was found at character position 28 in
> condition "@(PackageReference->Count()) > 0".
> [C:\BuildAgent\work\832880717e6391e9\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Apache.Ignite.Core.csproj
> {code}
> Caused by the bug in NuGet: https://github.com/NuGet/Home/issues/9458
> We use the latest version in build.ps1, so this started failing right after
> the release.
> Fix the script to use a fixed, known-to-be-good version instead of the latest.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12940) .NET: NuGet tests fail with compilation error
[
https://issues.apache.org/jira/browse/IGNITE-12940?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-12940:
Description:
{code}
:\BuildAgent\temp\buildTmp\NuGetScratch\1izrscml.xvp.nugetrestore.targets(435,34):
error MSB4092: An unexpected token ")" was found at character position 28 in
condition "@(PackageReference->Count()) > 0".
[C:\BuildAgent\work\832880717e6391e9\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Apache.Ignite.Core.csproj
{code}
Caused by the bug in NuGet: https://github.com/NuGet/Home/issues/9458
We use the latest version in build.ps1, so this started failing right after the
release.
Fix the script to use a fixed, known-to-be-good version instead of the latest.
> .NET: NuGet tests fail with compilation error
> -
>
> Key: IGNITE-12940
> URL: https://issues.apache.org/jira/browse/IGNITE-12940
> Project: Ignite
> Issue Type: New Feature
> Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET
>
> {code}
> :\BuildAgent\temp\buildTmp\NuGetScratch\1izrscml.xvp.nugetrestore.targets(435,34):
> error MSB4092: An unexpected token ")" was found at character position 28 in
> condition "@(PackageReference->Count()) > 0".
> [C:\BuildAgent\work\832880717e6391e9\incubator-ignite\modules\platforms\dotnet\Apache.Ignite.Core\Apache.Ignite.Core.csproj
> {code}
> Caused by the bug in NuGet: https://github.com/NuGet/Home/issues/9458
> We use the latest version in build.ps1, so this started failing right after
> the release.
> Fix the script to use a fixed, known-to-be-good version instead of the latest.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12940) .NET: NuGet tests fail with compilation error
Pavel Tupitsyn created IGNITE-12940: --- Summary: .NET: NuGet tests fail with compilation error Key: IGNITE-12940 URL: https://issues.apache.org/jira/browse/IGNITE-12940 Project: Ignite Issue Type: New Feature Components: platforms Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12939) Add WhitespaceAround support checkstyle rule
Maxim Muzafarov created IGNITE-12939:
Summary: Add WhitespaceAround support checkstyle rule
Key: IGNITE-12939
URL: https://issues.apache.org/jira/browse/IGNITE-12939
Project: Ignite
Issue Type: Task
Reporter: Maxim Muzafarov
Assignee: Maxim Muzafarov
Fix For: 2.9
White spaces must be checked according to java naming conventions.
Add the appropriate checkstyle rule.
{code}
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12939) Add WhitespaceAround support checkstyle rule
[
https://issues.apache.org/jira/browse/IGNITE-12939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-12939:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Add WhitespaceAround support checkstyle rule
>
>
> Key: IGNITE-12939
> URL: https://issues.apache.org/jira/browse/IGNITE-12939
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.9
>
>
> White spaces must be checked according to java naming conventions.
> Add the appropriate checkstyle rule.
> {code}
>
>
>
>
>
>
>
>
> {code}
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12938) control.sh utility commands: IdleVerify and ValidateIndexes use eventual payload check.
[ https://issues.apache.org/jira/browse/IGNITE-12938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stanilovsky Evgeny updated IGNITE-12938: Summary: control.sh utility commands: IdleVerify and ValidateIndexes use eventual payload check. (was: controls.sh utility commands: IdleVerify and ValidateIndexes use eventual payload check.) > control.sh utility commands: IdleVerify and ValidateIndexes use eventual > payload check. > --- > > Key: IGNITE-12938 > URL: https://issues.apache.org/jira/browse/IGNITE-12938 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.8 >Reporter: Stanilovsky Evgeny >Assignee: Stanilovsky Evgeny >Priority: Major > Fix For: 2.9 > > > "Checkpoint with dirty pages started! Cluster not idle" - not idle detection > command, but mechanism for check payload during commands execution. > Additionally current functional miss check on caches without persistence. > Remove old functionality from PageMemory and move it into update counters > usage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-12938) controls.sh utility commands: IdleVerify and ValidateIndexes use eventual payload check.
Stanilovsky Evgeny created IGNITE-12938: --- Summary: controls.sh utility commands: IdleVerify and ValidateIndexes use eventual payload check. Key: IGNITE-12938 URL: https://issues.apache.org/jira/browse/IGNITE-12938 Project: Ignite Issue Type: Improvement Components: general Affects Versions: 2.8 Reporter: Stanilovsky Evgeny Assignee: Stanilovsky Evgeny Fix For: 2.9 "Checkpoint with dirty pages started! Cluster not idle" - not idle detection command, but mechanism for check payload during commands execution. Additionally current functional miss check on caches without persistence. Remove old functionality from PageMemory and move it into update counters usage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-12937) Create pull-request template for the github repo
[
https://issues.apache.org/jira/browse/IGNITE-12937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-12937:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Create pull-request template for the github repo
>
>
> Key: IGNITE-12937
> URL: https://issues.apache.org/jira/browse/IGNITE-12937
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Priority: Major
>
> Create {{.github/pull_request_template.md}} to allow users to have a
> pull-request all usefull information while contributing to the Apache Ignite.
> Example:
> [ ] Coding Guidelines are followed
> [ ] TeamCity build passes
> [ ] JIRA ticked is in Patch Available state, a review has been requested in
> comments
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12937) Create pull-request template for the github repo
Maxim Muzafarov created IGNITE-12937:
Summary: Create pull-request template for the github repo
Key: IGNITE-12937
URL: https://issues.apache.org/jira/browse/IGNITE-12937
Project: Ignite
Issue Type: Task
Reporter: Maxim Muzafarov
Create {{.github/pull_request_template.md}} to allow users to have a
pull-request all usefull information while contributing to the Apache Ignite.
Example:
[ ] Coding Guidelines are followed
[ ] TeamCity build passes
[ ] JIRA ticked is in Patch Available state, a review has been requested in
comments
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12911) B+Tree Corrupted exception when using a key extracted from a BinaryObject value object --- and SQL enabled.
[
https://issues.apache.org/jira/browse/IGNITE-12911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091677#comment-17091677
]
Ilya Kasnacheev commented on IGNITE-12911:
--
This is because, for key2, detachAllowed is false, and even if it was true, we
never seem to call detach() while doing put().
This is bad, we should definitely make sure we are putting a detached object in
cache at all times. We should also set detachAllowed to true in all cases where
it is permitted.
The code sample is fixed in the following fashion:
((BinaryObjectImpl)key2).detachAllowed(true);
key2 = ((BinaryObjectImpl)key2).detach();
before problematic puts
> B+Tree Corrupted exception when using a key extracted from a BinaryObject
> value object --- and SQL enabled.
> ---
>
> Key: IGNITE-12911
> URL: https://issues.apache.org/jira/browse/IGNITE-12911
> Project: Ignite
> Issue Type: Bug
> Components: cache, sql
>Reporter: Alexander Korenshteyn
>Priority: Blocker
> Fix For: 2.9
>
> Attachments: Employee.java, EmployeeId.java, ServerNode.java,
> image-2020-04-21-17-10-55-797.png, image-2020-04-21-17-11-31-242.png,
> image-2020-04-21-17-16-10-703.png, image-2020-04-21-17-16-29-107.png,
> image-2020-04-21-17-16-46-381.png
>
>
> If a key is part of the value like so:
> class key \{ ... }
> class value
> { private Key key getKey() }
> cache = ignite.cache()*.withKeepBinary()*
> the following scenario yields a B+ Tree exception:
> 1. *Enable SQL via annotations or QueryEntities.*
> key1= new Key()
> value1 = new Value(key1)
> cache.put(key1, value1)
> BinaryObject val2 = cache.get(key1)
> BinaryObject key2 = val2.field("key")
>
> *cache2.put(key2.toBuilder().build(), emp1); // OK!*
>
> *cache.put(key2, emp1); // CRASH!!! CorruptedTreeException: B+Tree
> iscorrupted ...*
> user list:
>
> [http://apache-ignite-users.70518.x6.nabble.com/Ignite-crashes-with-CorruptedTreeException-quot-B-Tree-is-corrupted-quot-on-a-composite-BinaryObjecto-tc32032.html]
> *Reproducer – attached*
>
> his happens because:
> CacheRowAdapter.readFullRow() reads the length
> *int len = PageUtils.getInt(addr,off)*
> *it returns 0 when val2.field("key") is used*
>
> *the data is written correctly in DataPageIO.writeDataPageIO():*
> !image-2020-04-21-17-16-46-381.png!
>
> *but read incorrectly in CacheRowAdapter.readFullRow()*
> !image-2020-04-21-17-16-29-107.png!
>
>
> Exception:
> [2020-04-17 11:24:33,475][ERROR][main][root] Critical system error detected.
> Will be handled accordingly to configured handler
> [hnd=StopNodeOrHaltFailureHandler [tryStop=false, timeout=0,
> super=AbstractFailureHandler [ignoredFailureTypes=UnmodifiableSet
> [SYSTEM_WORKER_BLOCKED, SYSTEM_CRITICAL_OPERATION_TIMEOUT]]],
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
> o.a.i.i.processors.cache.persistence.tree.CorruptedTreeException: B+Tree is
> corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=1258113742,
> val2=844420635164673]], cacheId=1976096430, cacheName=EMPLOYEE,
> indexName=_key_PK, msg=Runtime failure on row: Row@2233cac0[ key:
> model.EmployeeId [idHash=1744523301, hash=674030145, employeeNumber=65348765,
> departmentNumber=123], val: model.Employee [idHash=382762227,
> hash=1627745429, firstName=John, lastName=Smith, id=model.EmployeeId
> [idHash=2021540695, hash=674030145, employeeNumber=65348765,
> departmentNumber=123]] ][ John, Smith
> class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> B+Tree is corrupted [pages(groupId, pageId)=[IgniteBiTuple [val1=1258113742,
> val2=844420635164673]], cacheId=1976096430, cacheName=EMPLOYEE,
> indexName=_key_PK, msg=Runtime failure on row: Row@2233cac0[ key:
> model.EmployeeId [idHash=1744523301, hash=674030145, employeeNumber=65348765,
> departmentNumber=123], val: model.Employee [idHash=382762227,
> hash=1627745429, firstName=John, lastName=Smith, id=model.EmployeeId
> [idHash=2021540695, hash=674030145, employeeNumber=65348765,
> departmentNumber=123]] ][ John, Smith ]]
> at
> org.apache.ignite.internal.processors.query.h2.database.H2Tree.corruptedTreeException(H2Tree.java:836)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2447)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2394)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2TreeIndex.putx(H2TreeIndex.java:437)
> at
> org.apache.ignite.internal.processors.query.h2.opt.GridH2Table.update(GridH2Table.java:756)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.store(IgniteH2Indexing.java:363)
> at
>
[jira] [Created] (IGNITE-12936) .NET inspections fail on master
Igor Sapego created IGNITE-12936: Summary: .NET inspections fail on master Key: IGNITE-12936 URL: https://issues.apache.org/jira/browse/IGNITE-12936 Project: Ignite Issue Type: Bug Components: platforms Reporter: Igor Sapego Assignee: Igor Sapego The following suites are failing: [Platform .NET (NuGet) |https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetNuGet?branch=%3Cdefault%3E] [Platform .NET (Inspections) |https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetInspections?branch=%3Cdefault%3E] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-10100) Add public Java API to call Ignite.NET services
[
https://issues.apache.org/jira/browse/IGNITE-10100?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091583#comment-17091583
]
Ivan Daschinskiy commented on IGNITE-10100:
---
[~xtern][~nizhikov] Do you mind if I assign this ticket to me?
> Add public Java API to call Ignite.NET services
> ---
>
> Key: IGNITE-10100
> URL: https://issues.apache.org/jira/browse/IGNITE-10100
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: .NET, sbcf
> Attachments: ignite-10100-vs-2.8.patch
>
>
> Ignite wraps .NET services in PlatformDotNetServiceImpl implementing
> PlatformService interface.
> PlatformService is defined in internal Ignite package
> apache.ignite.internal.processors.platform.services. It exposes
> {{ invokeMethod(methodName, Object[] params): Object}}
> to call any service method dynamically. Right now there is no Ignite public
> API to call a PlatformService using static typing.
> We need to develop a public API to call PlatformDotNetServiceImpl using
> static typing in Java.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-10100) Add public Java API to call Ignite.NET services
[
https://issues.apache.org/jira/browse/IGNITE-10100?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinskiy reassigned IGNITE-10100:
-
Assignee: Ivan Daschinskiy (was: Pavel Pereslegin)
> Add public Java API to call Ignite.NET services
> ---
>
> Key: IGNITE-10100
> URL: https://issues.apache.org/jira/browse/IGNITE-10100
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.6
>Reporter: Alexey Kukushkin
>Assignee: Ivan Daschinskiy
>Priority: Major
> Labels: .NET, sbcf
> Attachments: ignite-10100-vs-2.8.patch
>
>
> Ignite wraps .NET services in PlatformDotNetServiceImpl implementing
> PlatformService interface.
> PlatformService is defined in internal Ignite package
> apache.ignite.internal.processors.platform.services. It exposes
> {{ invokeMethod(methodName, Object[] params): Object}}
> to call any service method dynamically. Right now there is no Ignite public
> API to call a PlatformService using static typing.
> We need to develop a public API to call PlatformDotNetServiceImpl using
> static typing in Java.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12283) Access restriction to IgniteKernal
[ https://issues.apache.org/jira/browse/IGNITE-12283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Garus updated IGNITE-12283: - Description: IgniteKernal allows a user-defined code to get access to the internal features of Ignite. That behavior leads to security lack. We must encapsulate _IgniteKernal_ to restrict access to it from user-defined code. Additionally, a proxied instance of Ignite allows users to use public API of Ignite. Otherwise, using public API inside the sandbox without proxying can be the reason for access control errors. was: IgniteKernal allows a user-defined code to get access to the internal features of Ignite. That behavior leads to security lack. We must encapsulate _IgniteKernal_ to restrict access to it from user-defined code. > Access restriction to IgniteKernal > -- > > Key: IGNITE-12283 > URL: https://issues.apache.org/jira/browse/IGNITE-12283 > Project: Ignite > Issue Type: Task >Reporter: Denis Garus >Assignee: Denis Garus >Priority: Major > Labels: iep-38 > Time Spent: 10m > Remaining Estimate: 0h > > IgniteKernal allows a user-defined code to get access to the internal > features of Ignite. That behavior leads to security lack. > We must encapsulate _IgniteKernal_ to restrict access to it from > user-defined code. > Additionally, a proxied instance of Ignite allows users to use public API of > Ignite. Otherwise, using public API inside the sandbox without proxying can > be the reason for access control errors. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services
[
https://issues.apache.org/jira/browse/IGNITE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091560#comment-17091560
]
Vyacheslav Daradur edited comment on IGNITE-12894 at 4/24/20, 1:21 PM:
---
Both issues: this and IGNITE-12490 can be fixed by improvements of our
deployment guarantees, read this for details:
[dev-list-thread|http://apache-ignite-developers.2346864.n4.nabble.com/Discovery-based-services-deployment-guarantees-question-td44866.html]
The main idea is allowing
[GridServiceProxy#randomNodeForService|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L283]
to wait service deployment finished if it is registered in the cluster (but
deployment has not finished yet).
It can be achieved in the same manner as for our ["API with a timeout"
here|https://github.com/apache/ignite/blob/8dcd0f1d96dae965a0f5c479e6d0f4b4d50c6e2c/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L821http://example.com]
(mentioned as a workaround in current issue description).
Need add some conditions, something like this:
{code:java}
IgniteUuid srvcUid = lookupRegisteredServiceId(name);
if (srvcUid == null)
return null; // Service is not registerd in cluster: wasn't present in cfg
and didn't deployed througt API
Map top;
while (true) {
ServiceInfo srvcDesc = registeredServices.get(srvcUid);
if (srvcDesc == null) {
if (timeout == 0)
return null;
else
// Wait if someone sent service to deploy (as in current implementation)
}
top = srvcDesc.topologySnapshot();
if (!top.isEmpty())
return top;
// Wait using "servicesTopsUpdateMux" while service deployment finished and
the topology will not be empty
// or removed from "registeredServices" in case if deployment failure
{code}
was (Author: daradurvs):
Both issues: this and IGNITE-12490 can be fixed by improvements of our
deployment guarantees, read this for details:
[dev-list-thread|http://apache-ignite-developers.2346864.n4.nabble.com/Discovery-based-services-deployment-guarantees-question-td44866.html]
The main idea is allowing
[GridServiceProxy#randomNodeForService|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L283]
to wait service deployment finished if it is registered in the cluster (but
deployment has not finished yet).
It can be achieved in the same manner as for our ["API with a timeout"
here|https://github.com/apache/ignite/blob/8dcd0f1d96dae965a0f5c479e6d0f4b4d50c6e2c/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L821http://example.com]
(mentioned as a workaround in current issue description).
Need add some conditions, something like this:
{code:java}
IgniteUuid srvcUid = lookupRegisteredServiceId(name);
if (srvcUid == null)
return null; // Service is not registered in cluster: wasn't
present in cfg and didn't deployed through API
while (true) {
ServiceInfo srvcDesc = registeredServices.get(srvcUid);
if (srvcDesc == null) {
if (timeout == 0)
return null;
else
// Wait if someone sent service to deploy (as in current
implementation)
}
if (!srvcDesc.topologySnapshot().isEmpty()) {
return top;
}
// Wait using "servicesTopsUpdateMux" while service deployment
finished and the topology will not be empty
// or removed from "registeredServices" in case if deployment
failure
{code}
> Cannot use IgniteAtomicSequence in Ignite services
> --
>
> Key: IGNITE-12894
> URL: https://issues.apache.org/jira/browse/IGNITE-12894
> Project: Ignite
> Issue Type: Bug
> Components: compute
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: sbcf
>
> h2. Repro Steps
> Execute the below steps in default service deployment mode and in
> discovery-based service deployment mode.
> Use {{-DIGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED=true}} JVM option to
> switch to the discovery-based service deployment mode.
> * Create a service initializing an {{IgniteAtomicService}} in method
> {{Service#init()}} and using the {{IgniteAtomicService}} in a business method.
> * Start an Ignite node with the service specified in the IgniteConfiguration
> * Invoke the service's business method on the Ignite node
> h3. Actual Result
[jira] [Comment Edited] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services
[
https://issues.apache.org/jira/browse/IGNITE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091560#comment-17091560
]
Vyacheslav Daradur edited comment on IGNITE-12894 at 4/24/20, 1:16 PM:
---
Both issues: this and IGNITE-12490 can be fixed by improvements of our
deployment guarantees, read this for details:
[dev-list-thread|http://apache-ignite-developers.2346864.n4.nabble.com/Discovery-based-services-deployment-guarantees-question-td44866.html]
The main idea is allowing
[GridServiceProxy#randomNodeForService|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L283]
to wait service deployment finished if it is registered in the cluster (but
deployment has not finished yet).
It can be achieved in the same manner as for our ["API with a timeout"
here|https://github.com/apache/ignite/blob/8dcd0f1d96dae965a0f5c479e6d0f4b4d50c6e2c/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L821http://example.com]
(mentioned as a workaround in current issue description).
Need add some conditions, something like this:
{code:java}
IgniteUuid srvcUid = lookupRegisteredServiceId(name);
if (srvcUid == null)
return null; // Service is not registered in cluster: wasn't
present in cfg and didn't deployed through API
while (true) {
ServiceInfo srvcDesc = registeredServices.get(srvcUid);
if (srvcDesc == null) {
if (timeout == 0)
return null;
else
// Wait if someone sent service to deploy (as in current
implementation)
}
if (!srvcDesc.topologySnapshot().isEmpty()) {
return top;
}
// Wait using "servicesTopsUpdateMux" while service deployment
finished and the topology will not be empty
// or removed from "registeredServices" in case if deployment
failure
{code}
was (Author: daradurvs):
Both issues: this and IGNITE-12490 can be fixed by improvements of our
deployment guarantees, read this for details:
[dev-list-thread|http://apache-ignite-developers.2346864.n4.nabble.com/Discovery-based-services-deployment-guarantees-question-td44866.html]
The main idea is allowing
[GridServiceProxy#randomNodeForService|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L283]
to wait service deployment finished if it is registered in the cluster (but
deployment has not finished yet).
It can be achieved in the same manner as for our ["API with a timeout"
here|https://github.com/apache/ignite/blob/8dcd0f1d96dae965a0f5c479e6d0f4b4d50c6e2c/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L821http://example.com]
(mentioned as a workaround in current issue description).
Need add some conditions, something like this:
{code:java}
IgniteUuid srvcUid = lookupRegisteredServiceId(name);
if (srvcUid == null)
return null; // Service is not registered in cluster: wasn't
present in cfg and didn't deployed through API
Map top;
while (true) {
ServiceInfo srvcDesc = registeredServices.get(srvcUid);
if (srvcDesc == null) {
if (timeout == 0)
return null;
else
// Wait if someone sent service to deploy (as in current
implementation)
}
top = srvcDesc.topologySnapshot();
if (!top.isEmpty()) {
return top;
}
// Wait using "servicesTopsUpdateMux" while service deployment
finished and the topology will not be empty
// or removed from "registeredServices" in case if deployment
failure
{code}
> Cannot use IgniteAtomicSequence in Ignite services
> --
>
> Key: IGNITE-12894
> URL: https://issues.apache.org/jira/browse/IGNITE-12894
> Project: Ignite
> Issue Type: Bug
> Components: compute
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: sbcf
>
> h2. Repro Steps
> Execute the below steps in default service deployment mode and in
> discovery-based service deployment mode.
> Use {{-DIGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED=true}} JVM option to
> switch to the discovery-based service deployment mode.
> * Create a service initializing an {{IgniteAtomicService}} in method
> {{Service#init()}} and using the {{IgniteAtomicService}} in a business
[jira] [Issue Comment Deleted] (IGNITE-12490) Service proxy throws "Service not found" exception right after deploy
[
https://issues.apache.org/jira/browse/IGNITE-12490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Daradur updated IGNITE-12490:
Comment: was deleted
(was: Both issues: this and IGNITE-12490 can be fixed by improvements of our
deployment guarantees, read this for details:
[dev-list-thread|http://apache-ignite-developers.2346864.n4.nabble.com/Discovery-based-services-deployment-guarantees-question-td44866.html]
The main idea is allowing
[GridServiceProxy#randomNodeForService|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L283]
to wait service deployment finished if it is registered in the cluster (but
deployment has not finished yet).
It can be achieved in the same manner as for our ["API with a timeout"
here|https://github.com/apache/ignite/blob/8dcd0f1d96dae965a0f5c479e6d0f4b4d50c6e2c/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L821http://example.com]
(mentioned as a workaround in current issue description).
Need add some conditions, something like this:
{code:java}
IgniteUuid srvcUid = lookupRegisteredServiceId(name);
if (srvcUid == null)
return null; // Service is not registered in cluster: wasn't
present in cfg and didn't deployed through API
Map top;
while (true) {
ServiceInfo srvcDesc = registeredServices.get(srvcUid);
if (srvcDesc == null) {
if (timeout == 0)
return null;
else
// Wait if someone sent service to deploy (as in current
implementation)
}
top = srvcDesc.topologySnapshot();
if (!top.isEmpty()) {
return top;
}
// Wait using "servicesTopsUpdateMux" while service deployment
finished and the topology will not be empty
// or removed from "registeredServices" in case if deployment
failure
{code})
> Service proxy throws "Service not found" exception right after deploy
> -
>
> Key: IGNITE-12490
> URL: https://issues.apache.org/jira/browse/IGNITE-12490
> Project: Ignite
> Issue Type: Improvement
> Components: managed services
>Affects Versions: 2.8
>Reporter: Alexey Goncharuk
>Priority: Major
> Attachments: ServiceInvokeTest.java
>
>
> In the following scenario:
> * Start nodes A, B
> * Deploy a service on A
> * Create a service proxy on B
> * Invoke the proxy
> The proxy invocation throws a service not found exception. As per discussion
> [on the dev
> list|http://apache-ignite-developers.2346864.n4.nabble.com/Discovery-based-services-deployment-guarantees-question-td44866.html]
> this case should be handled by an automatic retry, however, it's not.
> The reproducer is attached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12894) Cannot use IgniteAtomicSequence in Ignite services
[
https://issues.apache.org/jira/browse/IGNITE-12894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091560#comment-17091560
]
Vyacheslav Daradur commented on IGNITE-12894:
-
Both issues: this and IGNITE-12490 can be fixed by improvements of our
deployment guarantees, read this for details:
[dev-list-thread|http://apache-ignite-developers.2346864.n4.nabble.com/Discovery-based-services-deployment-guarantees-question-td44866.html]
The main idea is allowing
[GridServiceProxy#randomNodeForService|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L283]
to wait service deployment finished if it is registered in the cluster (but
deployment has not finished yet).
It can be achieved in the same manner as for our ["API with a timeout"
here|https://github.com/apache/ignite/blob/8dcd0f1d96dae965a0f5c479e6d0f4b4d50c6e2c/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L821http://example.com]
(mentioned as a workaround in current issue description).
Need add some conditions, something like this:
{code:java}
IgniteUuid srvcUid = lookupRegisteredServiceId(name);
if (srvcUid == null)
return null; // Service is not registered in cluster: wasn't
present in cfg and didn't deployed through API
Map top;
while (true) {
ServiceInfo srvcDesc = registeredServices.get(srvcUid);
if (srvcDesc == null) {
if (timeout == 0)
return null;
else
// Wait if someone sent service to deploy (as in current
implementation)
}
top = srvcDesc.topologySnapshot();
if (!top.isEmpty()) {
return top;
}
// Wait using "servicesTopsUpdateMux" while service deployment
finished and the topology will not be empty
// or removed from "registeredServices" in case if deployment
failure
{code}
> Cannot use IgniteAtomicSequence in Ignite services
> --
>
> Key: IGNITE-12894
> URL: https://issues.apache.org/jira/browse/IGNITE-12894
> Project: Ignite
> Issue Type: Bug
> Components: compute
>Affects Versions: 2.8
>Reporter: Alexey Kukushkin
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: sbcf
>
> h2. Repro Steps
> Execute the below steps in default service deployment mode and in
> discovery-based service deployment mode.
> Use {{-DIGNITE_EVENT_DRIVEN_SERVICE_PROCESSOR_ENABLED=true}} JVM option to
> switch to the discovery-based service deployment mode.
> * Create a service initializing an {{IgniteAtomicService}} in method
> {{Service#init()}} and using the {{IgniteAtomicService}} in a business method.
> * Start an Ignite node with the service specified in the IgniteConfiguration
> * Invoke the service's business method on the Ignite node
> h3. Actual Result
> h4. In Default Service Deployment Mode
> Deadlock on the business method invocation
> h4. In Discovery-Based Service Deployment Mode
> The method invocation fails with {{IgniteException: Failed to find deployed
> service: IgniteTestService}}
> h2. Reproducer
> h3. Test.java
> {code:java}
> public interface Test {
> String sayHello(String name);
> }
> {code}
> h3. IgniteTestService.java
> {code:java}
> public class IgniteTestService implements Test, Service {
> private @IgniteInstanceResource Ignite ignite;
> private IgniteAtomicSequence seq;
> @Override public void cancel(ServiceContext ctx) {
> }
> @Override public void init(ServiceContext ctx) throws
> InterruptedException {
> seq = ignite.atomicSequence("TestSeq", 0, true);
> }
> @Override public void execute(ServiceContext ctx) {
> }
> @Override public String sayHello(String name) {
> return "Hello, " + name + "! #" + seq.getAndIncrement();
> }
> }
> {code}
> h3. Reproducer.java
> {code:java}
> public class Reproducer {
> public static void main(String[] args) {
> IgniteConfiguration igniteCfg = new IgniteConfiguration()
> .setServiceConfiguration(
> new ServiceConfiguration()
> .setName(IgniteTestService.class.getSimpleName())
> .setMaxPerNodeCount(1)
> .setTotalCount(0)
> .setService(new IgniteTestService())
> )
> .setDiscoverySpi(
> new TcpDiscoverySpi()
> .setIpFinder(new
> TcpDiscoveryVmIpFinder().setAddresses(Collections.singleton("127.0.0.1:47500")))
> );
> try (Ignite ignite = Ignition.start(igniteCfg)) {
>
>
[jira] [Commented] (IGNITE-12490) Service proxy throws "Service not found" exception right after deploy
[
https://issues.apache.org/jira/browse/IGNITE-12490?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091558#comment-17091558
]
Vyacheslav Daradur commented on IGNITE-12490:
-
Both issues: this and IGNITE-12490 can be fixed by improvements of our
deployment guarantees, read this for details:
[dev-list-thread|http://apache-ignite-developers.2346864.n4.nabble.com/Discovery-based-services-deployment-guarantees-question-td44866.html]
The main idea is allowing
[GridServiceProxy#randomNodeForService|https://github.com/apache/ignite/blob/8cba313c9961b16e358834216e9992310f285985/modules/core/src/main/java/org/apache/ignite/internal/processors/service/GridServiceProxy.java#L283]
to wait service deployment finished if it is registered in the cluster (but
deployment has not finished yet).
It can be achieved in the same manner as for our ["API with a timeout"
here|https://github.com/apache/ignite/blob/8dcd0f1d96dae965a0f5c479e6d0f4b4d50c6e2c/modules/core/src/main/java/org/apache/ignite/internal/processors/service/IgniteServiceProcessor.java#L821http://example.com]
(mentioned as a workaround in current issue description).
Need add some conditions, something like this:
{code:java}
IgniteUuid srvcUid = lookupRegisteredServiceId(name);
if (srvcUid == null)
return null; // Service is not registered in cluster: wasn't
present in cfg and didn't deployed through API
Map top;
while (true) {
ServiceInfo srvcDesc = registeredServices.get(srvcUid);
if (srvcDesc == null) {
if (timeout == 0)
return null;
else
// Wait if someone sent service to deploy (as in current
implementation)
}
top = srvcDesc.topologySnapshot();
if (!top.isEmpty()) {
return top;
}
// Wait using "servicesTopsUpdateMux" while service deployment
finished and the topology will not be empty
// or removed from "registeredServices" in case if deployment
failure
{code}
> Service proxy throws "Service not found" exception right after deploy
> -
>
> Key: IGNITE-12490
> URL: https://issues.apache.org/jira/browse/IGNITE-12490
> Project: Ignite
> Issue Type: Improvement
> Components: managed services
>Affects Versions: 2.8
>Reporter: Alexey Goncharuk
>Priority: Major
> Attachments: ServiceInvokeTest.java
>
>
> In the following scenario:
> * Start nodes A, B
> * Deploy a service on A
> * Create a service proxy on B
> * Invoke the proxy
> The proxy invocation throws a service not found exception. As per discussion
> [on the dev
> list|http://apache-ignite-developers.2346864.n4.nabble.com/Discovery-based-services-deployment-guarantees-question-td44866.html]
> this case should be handled by an automatic retry, however, it's not.
> The reproducer is attached.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12835) Thin client: compute support
[ https://issues.apache.org/jira/browse/IGNITE-12835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091524#comment-17091524 ] Igor Sapego commented on IGNITE-12835: -- [~alex_pl] see my minor comments in PR. Over all looks good. > Thin client: compute support > > > Key: IGNITE-12835 > URL: https://issues.apache.org/jira/browse/IGNITE-12835 > Project: Ignite > Issue Type: New Feature > Components: thin client >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: iep-42 > Time Spent: 2h 20m > Remaining Estimate: 0h > > Add compute grid functionality to thin clients. > As a first step execution of task by task name should be added. > Implement a compute facade in java thin client. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12934) Change test start|stop log format for correct TC and build.log visibility.
[ https://issues.apache.org/jira/browse/IGNITE-12934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091489#comment-17091489 ] Ilya Kasnacheev commented on IGNITE-12934: -- I don't think PDS or ZooKeeper are mine, I have re-muted OSGi, but I'll do some improvements first. > Change test start|stop log format for correct TC and build.log visibility. > -- > > Key: IGNITE-12934 > URL: https://issues.apache.org/jira/browse/IGNITE-12934 > Project: Ignite > Issue Type: Improvement > Components: build >Reporter: Ilya Kasnacheev >Assignee: Ilya Kasnacheev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > For correct TC and builds log visibility need to repeat log format, from : > ">>> Stopping test: " > as > "##teamcity[testFinished name='" > additional info: > https://www.jetbrains.com/help/teamcity/build-script-interaction-with-teamcity.html#BuildScriptInteractionwithTeamCity-ReportingTests > Also, make “Starting test”, “Stopping test” messages visible in Quiet mode! -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12934) Change test start|stop log format for correct TC and build.log visibility.
[
https://issues.apache.org/jira/browse/IGNITE-12934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091488#comment-17091488
]
Ignite TC Bot commented on IGNITE-12934:
{panel:title=Branch: [pull/7715/head] Base: [master] : Possible Blockers
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5254123]]
{color:#d04437}ZooKeeper (Discovery) 3{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5251312]]
* ZookeeperDiscoverySpiTestSuite3:
multijvm.GridCachePartitionedMultiJvmFullApiSelfTest - History for base branch
is absent.
{color:#d04437}OSGi{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5251619]]
*
org.apache.ignite.osgi.IgniteKarafFeaturesInstallationTest.testAllBundlesActiveAndFeaturesInstalled
- New test duration 180s is more that 1 minute
*
org.apache.ignite.osgi.IgniteOsgiServiceTest.testServiceExposedAndCallbacksInvoked
- New test duration 181s is more that 1 minute
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5249241buildTypeId=IgniteTests24Java8_RunAll]
> Change test start|stop log format for correct TC and build.log visibility.
> --
>
> Key: IGNITE-12934
> URL: https://issues.apache.org/jira/browse/IGNITE-12934
> Project: Ignite
> Issue Type: Improvement
> Components: build
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For correct TC and builds log visibility need to repeat log format, from :
> ">>> Stopping test: "
> as
> "##teamcity[testFinished name='"
> additional info:
> https://www.jetbrains.com/help/teamcity/build-script-interaction-with-teamcity.html#BuildScriptInteractionwithTeamCity-ReportingTests
> Also, make “Starting test”, “Stopping test” messages visible in Quiet mode!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Issue Comment Deleted] (IGNITE-12934) Change test start|stop log format for correct TC and build.log visibility.
[
https://issues.apache.org/jira/browse/IGNITE-12934?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Kasnacheev updated IGNITE-12934:
-
Comment: was deleted
(was: {panel:title=Branch: [pull/7715/head] Base: [master] : Possible Blockers
(11)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests 0 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5249205]]
{color:#d04437}ZooKeeper (Discovery) 3{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5249219]]
* ZookeeperDiscoverySpiTestSuite3:
multijvm.GridCachePartitionedMultiJvmFullApiSelfTest - History for base branch
is absent.
{color:#d04437}Cache 7{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5249196]]
* IgniteCacheTestSuite7:
TxRollbackAsyncWithPersistenceTest.testMixedAsyncRollbackTypes - Test has low
fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache 2{color} [[tests 1 TIMEOUT , Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5249191]]
* IgniteCacheTestSuite2:
IgniteCacheClientNodeChangingTopologyTest.testAtomicPrimaryPutAllMultinode -
Test has low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cassandra Store{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5249238]]
*
org.apache.ignite.tests.CassandraDirectPersistenceTest.pojoStrategyTransactionTest
- History for base branch is absent.
{color:#d04437}Basic 2{color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=5249129]]
* IgniteComputeBasicConfigVariationsFullApiTestSuite:
IgniteComputeConfigVariationsFullApiTest_17.testDeployExecuteByName - Test has
low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Cache 9{color} [[tests 1 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5249198]]
* IgniteCacheTestSuite9:
MetricsConfigurationTest.testConfigRemovedOnCacheRemove - Test has low fail
rate in base branch 0,0% and is not flaky
{color:#d04437}OSGi{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=5249203]]
*
org.apache.ignite.osgi.IgniteKarafFeaturesInstallationTest.testAllBundlesActiveAndFeaturesInstalled
- History for base branch is absent.
*
org.apache.ignite.osgi.IgniteOsgiServiceTest.testServiceExposedAndCallbacksInvoked
- History for base branch is absent.
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5249241buildTypeId=IgniteTests24Java8_RunAll])
> Change test start|stop log format for correct TC and build.log visibility.
> --
>
> Key: IGNITE-12934
> URL: https://issues.apache.org/jira/browse/IGNITE-12934
> Project: Ignite
> Issue Type: Improvement
> Components: build
>Reporter: Ilya Kasnacheev
>Assignee: Ilya Kasnacheev
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For correct TC and builds log visibility need to repeat log format, from :
> ">>> Stopping test: "
> as
> "##teamcity[testFinished name='"
> additional info:
> https://www.jetbrains.com/help/teamcity/build-script-interaction-with-teamcity.html#BuildScriptInteractionwithTeamCity-ReportingTests
> Also, make “Starting test”, “Stopping test” messages visible in Quiet mode!
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12905) QueryKeyValueIterable missing custom spliterator() implementation
[
https://issues.apache.org/jira/browse/IGNITE-12905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091425#comment-17091425
]
Dmitriy Sorokin commented on IGNITE-12905:
--
[~bleedah], so far seems no, just stay tuned.
> QueryKeyValueIterable missing custom spliterator() implementation
> -
>
> Key: IGNITE-12905
> URL: https://issues.apache.org/jira/browse/IGNITE-12905
> Project: Ignite
> Issue Type: Bug
> Components: cache, general
>Affects Versions: 2.8
> Environment: Windows 10
> JDK 1.8.0_172
> ignite-core 2.8.0
> reactor-core 3.3.3
>Reporter: Johnny Galatikitis
>Assignee: Johnny Galatikitis
>Priority: Critical
> Fix For: 2.8.1
>
> Attachments:
> IGNITE-12905_-_add_QueryKeyValueSpliterator_and_corresponding_test.patch
>
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> We are using apache ignite with reactor-core and since reactors upgrade from
> 3.2.12 to 3.3.3 {code:java}
> org.apache.ignite.internal.processors.query.QueryKeyValueIterable.iterator
> {code}
> is called multiple times. It starts with:
> 1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED),
> where iterable is instanceof QueryKeyValueIterable
> 2. calls default implementation
> Spliterators.spliteratorUnknownSize(iterator(), 0)
> 3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and
> that "uses it up" for subsequent calls, i.e. throw IgniteException "Iterator
> is already fetched or query was cancelled."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12905) QueryKeyValueIterable missing custom spliterator() implementation
[
https://issues.apache.org/jira/browse/IGNITE-12905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091409#comment-17091409
]
Johnny Galatikitis commented on IGNITE-12905:
-
[~cyberdemon] great! Is there anything else I should do? Workflow wise
> QueryKeyValueIterable missing custom spliterator() implementation
> -
>
> Key: IGNITE-12905
> URL: https://issues.apache.org/jira/browse/IGNITE-12905
> Project: Ignite
> Issue Type: Bug
> Components: cache, general
>Affects Versions: 2.8
> Environment: Windows 10
> JDK 1.8.0_172
> ignite-core 2.8.0
> reactor-core 3.3.3
>Reporter: Johnny Galatikitis
>Assignee: Johnny Galatikitis
>Priority: Critical
> Fix For: 2.8.1
>
> Attachments:
> IGNITE-12905_-_add_QueryKeyValueSpliterator_and_corresponding_test.patch
>
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> We are using apache ignite with reactor-core and since reactors upgrade from
> 3.2.12 to 3.3.3 {code:java}
> org.apache.ignite.internal.processors.query.QueryKeyValueIterable.iterator
> {code}
> is called multiple times. It starts with:
> 1. calling iterable.spliterator().hasCharacteristics(Spliterator.SIZED),
> where iterable is instanceof QueryKeyValueIterable
> 2. calls default implementation
> Spliterators.spliteratorUnknownSize(iterator(), 0)
> 3. which in turn calls ignite's QueryKeyValueIterable.iterator() call and
> that "uses it up" for subsequent calls, i.e. throw IgniteException "Iterator
> is already fetched or query was cancelled."
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12795) Partially revert changes to atomic caches introduced in IGNITE-11797
[
https://issues.apache.org/jira/browse/IGNITE-12795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091395#comment-17091395
]
Alexey Scherbakov commented on IGNITE-12795:
Merged to master #811439cf43b39e0b69889c4c79a808dc15c3cd9f and 2.8.1
#74cb70d83e4ddbc3b1e4e2a806a2c82b07e6ebdc
> Partially revert changes to atomic caches introduced in IGNITE-11797
>
>
> Key: IGNITE-12795
> URL: https://issues.apache.org/jira/browse/IGNITE-12795
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8
>Reporter: Alexey Scherbakov
>Assignee: Alexey Scherbakov
>Priority: Blocker
> Fix For: 2.8.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> These changes can trigger node failure during update on backup:
> Better fix for atomics is needed.
> {noformat}
> class org.apache.ignite.IgniteCheckedException: Failed to update the counter
> [newVal=173, curState=Counter [lwm=172, holes={173=Item [start=173,
> delta=1]}, maxApplied=174, hwm=173]]
> at
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl.update(PartitionUpdateCounterTrackingImpl.java:152)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateCounter(IgniteCacheOffheapManagerImpl.java:1578)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.updateCounter(GridCacheOffheapManager.java:2198)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition.nextUpdateCounter(GridDhtLocalPartition.java:995)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.nextPartitionCounter(GridDhtCacheEntry.java:104)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.update(GridCacheMapEntry.java:6434)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:6190)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:5881)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:3995)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.access$5700(BPlusTree.java:3889)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:2020)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1904)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1656)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1639)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:2450)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:436)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2311)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processDhtAtomicUpdateRequest(GridDhtAtomicCache.java:3362)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$600(GridDhtAtomicCache.java:139)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$7.apply(GridDhtAtomicCache.java:311)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$7.apply(GridDhtAtomicCache.java:306)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1637)
> at
>
[jira] [Commented] (IGNITE-12917) SQL: print warning log message when query's result is big
[ https://issues.apache.org/jira/browse/IGNITE-12917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091385#comment-17091385 ] Taras Ledkov commented on IGNITE-12917: --- [~amashenkov], please review the patch. > SQL: print warning log message when query's result is big > - > > Key: IGNITE-12917 > URL: https://issues.apache.org/jira/browse/IGNITE-12917 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Taras Ledkov >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.9 > > Time Spent: 10m > Remaining Estimate: 0h > > We have to track queries with big result set. > Print warning log message when query's result is bigger than threshold > specified by JMX. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-12917) SQL: print warning log message when query's result is big
[
https://issues.apache.org/jira/browse/IGNITE-12917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091383#comment-17091383
]
Ignite TC Bot commented on IGNITE-12917:
{panel:title=Branch: [pull/7697/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}PDS (Indexing){color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=5254125]]
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=5241208buildTypeId=IgniteTests24Java8_RunAll]
> SQL: print warning log message when query's result is big
> -
>
> Key: IGNITE-12917
> URL: https://issues.apache.org/jira/browse/IGNITE-12917
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.9
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We have to track queries with big result set.
> Print warning log message when query's result is bigger than threshold
> specified by JMX.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-12935) Disadvantages in log of historical rebalance
[
https://issues.apache.org/jira/browse/IGNITE-12935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov reassigned IGNITE-12935:
--
Assignee: Vladislav Pyatkov
> Disadvantages in log of historical rebalance
>
>
> Key: IGNITE-12935
> URL: https://issues.apache.org/jira/browse/IGNITE-12935
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
>
> # Mention in the log only partitions for which there are no nodes that suit
> as historical supplier
> For these partitions, print minimal counter (since which we should perform
> historical rebalancing) with corresponding node and maximum reserved counter
> (since which cluster can perform historical rebalancing) with corresponding
> node.
> This will let us know:
> ## Whether history was reserved at all
> ## How much reserved history we lack to perform a historical rebalancing
> ## I see resulting output like this:
> {noformat}
> Historical rebalancing wasn't scheduled for some partitions:
> History wasn't reserved for: [list of partitions and groups]
> History was reserved, but minimum present counter is less than maximum
> reserved: [[grp=GRP, part=ID, minCntr=cntr, minNodeId=ID, maxReserved=cntr,
> maxReservedNodeId=ID], ...]{noformat}
> ## We can also aggregate previous message by (minNodeId) to easily find the
> exact node (or nodes) which were the reason of full rebalance.
> # Log results of {{reserveHistoryForExchange()}}. They can be compactly
> represented as mappings: {{(grpId -> checkpoint (id, timestamp))}}. For every
> group, also log message about why the previous checkpoint wasn't successfully
> reserved.
> There can be three reasons:
> ## Previous checkpoint simply isn't present in the history (the oldest is
> reserved)
> ## WAL reservation failure (call below returned false)
> {code:java}
> chpEntry = entry(cpTs);
> boolean reserved = cctx.wal().reserve(chpEntry.checkpointMark());// If
> checkpoint WAL history can't be reserved, stop searching.
> if (!reserved)
> break;{code}
> ## Checkpoint was marked as inapplicable for historical rebalancing
> {code:java}
> for (Integer grpId : new HashSet<>(groupsAndPartitions.keySet()))
> if (!isCheckpointApplicableForGroup(grpId, chpEntry))
> groupsAndPartitions.remove(grpId);{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12795) Partially revert changes to atomic caches introduced in IGNITE-11797
[
https://issues.apache.org/jira/browse/IGNITE-12795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091370#comment-17091370
]
Ivan Rakov commented on IGNITE-12795:
-
[~ascherbakov] I'll take a look on what's wrong with TC bot.
LGTM, please merge.
> Partially revert changes to atomic caches introduced in IGNITE-11797
>
>
> Key: IGNITE-12795
> URL: https://issues.apache.org/jira/browse/IGNITE-12795
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8
>Reporter: Alexey Scherbakov
>Assignee: Alexey Scherbakov
>Priority: Blocker
> Fix For: 2.8.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> These changes can trigger node failure during update on backup:
> Better fix for atomics is needed.
> {noformat}
> class org.apache.ignite.IgniteCheckedException: Failed to update the counter
> [newVal=173, curState=Counter [lwm=172, holes={173=Item [start=173,
> delta=1]}, maxApplied=174, hwm=173]]
> at
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl.update(PartitionUpdateCounterTrackingImpl.java:152)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateCounter(IgniteCacheOffheapManagerImpl.java:1578)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.updateCounter(GridCacheOffheapManager.java:2198)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition.nextUpdateCounter(GridDhtLocalPartition.java:995)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.nextPartitionCounter(GridDhtCacheEntry.java:104)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.update(GridCacheMapEntry.java:6434)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:6190)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:5881)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:3995)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.access$5700(BPlusTree.java:3889)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:2020)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1904)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1656)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1639)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:2450)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:436)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2311)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processDhtAtomicUpdateRequest(GridDhtAtomicCache.java:3362)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$600(GridDhtAtomicCache.java:139)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$7.apply(GridDhtAtomicCache.java:311)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$7.apply(GridDhtAtomicCache.java:306)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1637)
> at
>
[jira] [Updated] (IGNITE-12935) Disadvantages in log of historical rebalance
[
https://issues.apache.org/jira/browse/IGNITE-12935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-12935:
---
Description:
# Mention in the log only partitions for which there are no nodes that suit as
historical supplier
For these partitions, print minimal counter (since which we should perform
historical rebalancing) with corresponding node and maximum reserved counter
(since which cluster can perform historical rebalancing) with corresponding
node.
This will let us know:
## Whether history was reserved at all
## How much reserved history we lack to perform a historical rebalancing
## I see resulting output like this:
{noformat}
Historical rebalancing wasn't scheduled for some partitions:
History wasn't reserved for: [list of partitions and groups]
History was reserved, but minimum present counter is less than maximum
reserved: [[grp=GRP, part=ID, minCntr=cntr, minNodeId=ID, maxReserved=cntr,
maxReservedNodeId=ID], ...]{noformat}
## We can also aggregate previous message by (minNodeId) to easily find the
exact node (or nodes) which were the reason of full rebalance.
# Log results of {{reserveHistoryForExchange()}}. They can be compactly
represented as mappings: {{(grpId -> checkpoint (id, timestamp))}}. For every
group, also log message about why the previous checkpoint wasn't successfully
reserved.
There can be three reasons:
## Previous checkpoint simply isn't present in the history (the oldest is
reserved)
## WAL reservation failure (call below returned false)
{code:java}
chpEntry = entry(cpTs);
boolean reserved = cctx.wal().reserve(chpEntry.checkpointMark());// If
checkpoint WAL history can't be reserved, stop searching.
if (!reserved)
break;{code}
## Checkpoint was marked as inapplicable for historical rebalancing
{code:java}
for (Integer grpId : new HashSet<>(groupsAndPartitions.keySet()))
if (!isCheckpointApplicableForGroup(grpId, chpEntry))
groupsAndPartitions.remove(grpId);{code}
was:
# Mention in the log only partitions for which there are no nodes that suit as
historical supplier
For these partitions, print minimal counter (since which we should perform
historical rebalancing) with corresponding node and maximum reserved counter
(since which cluster can perform historical rebalancing) with corresponding
node.
This will let us know:
## Whether history was reserved at all
## How much reserved history we lack to perform a historical rebalancing
## I see resulting output like this:
{noformat}
Historical rebalancing wasn't scheduled for some partitions:
History wasn't reserved for: [list of partitions and groups]
History was reserved, but minimum present counter is less than maximum
reserved: [[grp=GRP, part=ID, minCntr=cntr, minNodeId=ID, maxReserved=cntr,
maxReservedNodeId=ID], ...]{noformat}
#
## We can also aggregate previous message by (minNodeId) to easily find the
exact node (or nodes) which were the reason of full rebalance.
# Log results of {{reserveHistoryForExchange()}}. They can be compactly
represented as mappings: {{(grpId -> checkpoint (id, timestamp))}}. For every
group, also log message about why the previous checkpoint wasn't successfully
reserved.
There can be three reasons:
## Previous checkpoint simply isn't present in the history (the oldest is
reserved)
## WAL reservation failure (call below returned false)
{code:java}
chpEntry = entry(cpTs);
boolean reserved = cctx.wal().reserve(chpEntry.checkpointMark());// If
checkpoint WAL history can't be reserved, stop searching.
if (!reserved)
break;{code}
## Checkpoint was marked as inapplicable for historical rebalancing
{code:java}
for (Integer grpId : new HashSet<>(groupsAndPartitions.keySet()))
if (!isCheckpointApplicableForGroup(grpId, chpEntry))
groupsAndPartitions.remove(grpId);{code}
> Disadvantages in log of historical rebalance
>
>
> Key: IGNITE-12935
> URL: https://issues.apache.org/jira/browse/IGNITE-12935
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Priority: Major
>
> # Mention in the log only partitions for which there are no nodes that suit
> as historical supplier
> For these partitions, print minimal counter (since which we should perform
> historical rebalancing) with corresponding node and maximum reserved counter
> (since which cluster can perform historical rebalancing) with corresponding
> node.
> This will let us know:
> ## Whether history was reserved at all
> ## How much reserved history we lack to perform a historical rebalancing
> ## I see resulting output like this:
> {noformat}
> Historical rebalancing wasn't scheduled for some partitions:
> History wasn't reserved for: [list of partitions and groups]
> History was reserved, but minimum present counter is less
[jira] [Updated] (IGNITE-12935) Disadvantages in log of historical rebalance
[
https://issues.apache.org/jira/browse/IGNITE-12935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-12935:
---
Description:
# Mention in the log only partitions for which there are no nodes that suit as
historical supplier
For these partitions, print minimal counter (since which we should perform
historical rebalancing) with corresponding node and maximum reserved counter
(since which cluster can perform historical rebalancing) with corresponding
node.
This will let us know:
## Whether history was reserved at all
## How much reserved history we lack to perform a historical rebalancing
## I see resulting output like this:
{noformat}
Historical rebalancing wasn't scheduled for some partitions:
History wasn't reserved for: [list of partitions and groups]
History was reserved, but minimum present counter is less than maximum
reserved: [[grp=GRP, part=ID, minCntr=cntr, minNodeId=ID, maxReserved=cntr,
maxReservedNodeId=ID], ...]{noformat}
#
## We can also aggregate previous message by (minNodeId) to easily find the
exact node (or nodes) which were the reason of full rebalance.
# Log results of {{reserveHistoryForExchange()}}. They can be compactly
represented as mappings: {{(grpId -> checkpoint (id, timestamp))}}. For every
group, also log message about why the previous checkpoint wasn't successfully
reserved.
There can be three reasons:
## Previous checkpoint simply isn't present in the history (the oldest is
reserved)
## WAL reservation failure (call below returned false)
{code:java}
chpEntry = entry(cpTs);
boolean reserved = cctx.wal().reserve(chpEntry.checkpointMark());// If
checkpoint WAL history can't be reserved, stop searching.
if (!reserved)
break;{code}
## Checkpoint was marked as inapplicable for historical rebalancing
{code:java}
for (Integer grpId : new HashSet<>(groupsAndPartitions.keySet()))
if (!isCheckpointApplicableForGroup(grpId, chpEntry))
groupsAndPartitions.remove(grpId);{code}
was:
# Mention in the log only partitions for which there are no nodes that suit as
historical supplier
For these partitions, print minimal counter (since which we should perform
historical rebalancing) with corresponding node and maximum reserved counter
(since which cluster can perform historical rebalancing) with corresponding
node.
This will let us know:
## Whether history was reserved at all
## How much reserved history we lack to perform a historical rebalancing
## I see resulting output like this:
{noformat}
Historical rebalancing wasn't scheduled for some partitions:
History wasn't reserved for: [list of partitions and groups]
History was reserved, but minimum present counter is less than maximum
reserved: [[grp=GRP, part=ID, minCntr=cntr, minNodeId=ID, maxReserved=cntr,
maxReservedNodeId=ID], ...]{noformat}
#
## We can also aggregate previous message by (minNodeId) to easily find the
exact node (or nodes) which were the reason of full rebalance.
# Log results of {{reserveHistoryForExchange()}}. They can be compactly
represented as mappings: {{(grpId -> checkpoint (id, timestamp))}}. For every
group, also log message about why the previous checkpoint wasn't successfully
reserved.
There can be three reasons:
## Previous checkpoint simply isn't present in the history (the oldest is
reserved)
## WAL reservation failure (call below returned false)
{code:java}
chpEntry = entry(cpTs);
boolean reserved = cctx.wal().reserve(chpEntry.checkpointMark());// If
checkpoint WAL history can't be reserved, stop searching.
if (!reserved)
break;{code}
## Checkpoint was marked as inapplicable for historical rebalancing
{code}
for (Integer grpId : new HashSet<>(groupsAndPartitions.keySet()))
if (!isCheckpointApplicableForGroup(grpId, chpEntry))
groupsAndPartitions.remove(grpId);
{code:java}
> Disadvantages in log of historical rebalance
>
>
> Key: IGNITE-12935
> URL: https://issues.apache.org/jira/browse/IGNITE-12935
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Priority: Major
>
> # Mention in the log only partitions for which there are no nodes that suit
> as historical supplier
> For these partitions, print minimal counter (since which we should perform
> historical rebalancing) with corresponding node and maximum reserved counter
> (since which cluster can perform historical rebalancing) with corresponding
> node.
> This will let us know:
> ## Whether history was reserved at all
> ## How much reserved history we lack to perform a historical rebalancing
> ## I see resulting output like this:
> {noformat}
> Historical rebalancing wasn't scheduled for some partitions:
> History wasn't reserved for: [list of partitions and groups]
> History was reserved, but minimum present counter
[jira] [Updated] (IGNITE-12935) Disadvantages in log of historical rebalance
[
https://issues.apache.org/jira/browse/IGNITE-12935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-12935:
---
Description:
# Mention in the log only partitions for which there are no nodes that suit as
historical supplier
For these partitions, print minimal counter (since which we should perform
historical rebalancing) with corresponding node and maximum reserved counter
(since which cluster can perform historical rebalancing) with corresponding
node.
This will let us know:
## Whether history was reserved at all
## How much reserved history we lack to perform a historical rebalancing
## I see resulting output like this:
{noformat}
Historical rebalancing wasn't scheduled for some partitions:
History wasn't reserved for: [list of partitions and groups]
History was reserved, but minimum present counter is less than maximum
reserved: [[grp=GRP, part=ID, minCntr=cntr, minNodeId=ID, maxReserved=cntr,
maxReservedNodeId=ID], ...]{noformat}
#
## We can also aggregate previous message by (minNodeId) to easily find the
exact node (or nodes) which were the reason of full rebalance.
# Log results of {{reserveHistoryForExchange()}}. They can be compactly
represented as mappings: {{(grpId -> checkpoint (id, timestamp))}}. For every
group, also log message about why the previous checkpoint wasn't successfully
reserved.
There can be three reasons:
## Previous checkpoint simply isn't present in the history (the oldest is
reserved)
## WAL reservation failure (call below returned false)
{code:java}
chpEntry = entry(cpTs);
boolean reserved = cctx.wal().reserve(chpEntry.checkpointMark());// If
checkpoint WAL history can't be reserved, stop searching.
if (!reserved)
break;{code}
## Checkpoint was marked as inapplicable for historical rebalancing
{code}
for (Integer grpId : new HashSet<>(groupsAndPartitions.keySet()))
if (!isCheckpointApplicableForGroup(grpId, chpEntry))
groupsAndPartitions.remove(grpId);
{code:java}
was:
# Mention in the log only partitions for which there are no nodes that suit as
historical supplier
For these partitions, print minimal counter (since which we should perform
historical rebalancing) with corresponding node and maximum reserved counter
(since which cluster can perform historical rebalancing) with corresponding
node.
This will let us know:
## Whether history was reserved at all
## How much reserved history we lack to perform a historical rebalancing
## I see resulting output like this:
{noformat}
Historical rebalancing wasn't scheduled for some partitions:
History wasn't reserved for: [list of partitions and groups]
History was reserved, but minimum present counter is less than maximum
reserved: [[grp=GRP, part=ID, minCntr=cntr, minNodeId=ID, maxReserved=cntr,
maxReservedNodeId=ID], ...]{noformat}
#
## We can also aggregate previous message by (minNodeId) to easily find the
exact node (or nodes) which were the reason of full rebalance.
# Log results of {{reserveHistoryForExchange()}}. They can be compactly
represented as mappings: {{(grpId -> checkpoint (id, timestamp))}}. For every
group, also log message about why the previous checkpoint wasn't successfully
reserved.
There can be three reasons:
## Previous checkpoint simply isn't present in the history (the oldest is
reserved)
## WAL reservation failure (call below returned false)
{code:java}
chpEntry = entry(cpTs);
boolean reserved = cctx.wal().reserve(chpEntry.checkpointMark());// If
checkpoint WAL history can't be reserved, stop searching.
if (!reserved)
break;{code}
##
{code:java}
{code}
Checkpoint was marked as inapplicable for historical rebalancing
{code:java}
for (Integer grpId : new HashSet<>(groupsAndPartitions.keySet()))
if (!isCheckpointApplicableForGroup(grpId, chpEntry))
groupsAndPartitions.remove(grpId);
{code}
> Disadvantages in log of historical rebalance
>
>
> Key: IGNITE-12935
> URL: https://issues.apache.org/jira/browse/IGNITE-12935
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Priority: Major
>
> # Mention in the log only partitions for which there are no nodes that suit
> as historical supplier
> For these partitions, print minimal counter (since which we should perform
> historical rebalancing) with corresponding node and maximum reserved counter
> (since which cluster can perform historical rebalancing) with corresponding
> node.
> This will let us know:
> ## Whether history was reserved at all
> ## How much reserved history we lack to perform a historical rebalancing
> ## I see resulting output like this:
> {noformat}
> Historical rebalancing wasn't scheduled for some partitions:
> History wasn't reserved for: [list of partitions and groups]
> History was reserved, but
[jira] [Updated] (IGNITE-12935) Disadvantages in log of historical rebalance
[
https://issues.apache.org/jira/browse/IGNITE-12935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-12935:
---
Description:
# Mention in the log only partitions for which there are no nodes that suit as
historical supplier
For these partitions, print minimal counter (since which we should perform
historical rebalancing) with corresponding node and maximum reserved counter
(since which cluster can perform historical rebalancing) with corresponding
node.
This will let us know:
## Whether history was reserved at all
## How much reserved history we lack to perform a historical rebalancing
## I see resulting output like this:
{noformat}
Historical rebalancing wasn't scheduled for some partitions:
History wasn't reserved for: [list of partitions and groups]
History was reserved, but minimum present counter is less than maximum
reserved: [[grp=GRP, part=ID, minCntr=cntr, minNodeId=ID, maxReserved=cntr,
maxReservedNodeId=ID], ...]{noformat}
#
## We can also aggregate previous message by (minNodeId) to easily find the
exact node (or nodes) which were the reason of full rebalance.
# Log results of {{reserveHistoryForExchange()}}. They can be compactly
represented as mappings: {{(grpId -> checkpoint (id, timestamp))}}. For every
group, also log message about why the previous checkpoint wasn't successfully
reserved.
There can be three reasons:
## Previous checkpoint simply isn't present in the history (the oldest is
reserved)
## WAL reservation failure (call below returned false)
{code:java}
chpEntry = entry(cpTs);
boolean reserved = cctx.wal().reserve(chpEntry.checkpointMark());// If
checkpoint WAL history can't be reserved, stop searching.
if (!reserved)
break;{code}
##
{code:java}
{code}
Checkpoint was marked as inapplicable for historical rebalancing
{code:java}
for (Integer grpId : new HashSet<>(groupsAndPartitions.keySet()))
if (!isCheckpointApplicableForGroup(grpId, chpEntry))
groupsAndPartitions.remove(grpId);
{code}
was:
# Mention in the log only partitions for which there are no nodes that suit as
historical supplier
For these partitions, print minimal counter (since which we should perform
historical rebalancing) with corresponding node and maximum reserved counter
(since which cluster can perform historical rebalancing) with corresponding
node.
This will let us know:
## Whether history was reserved at all
## How much reserved history we lack to perform a historical rebalancing
## I see resulting output like this:
{noformat}
Historical rebalancing wasn't scheduled for some partitions:
History wasn't reserved for: [list of partitions and groups]
History was reserved, but minimum present counter is less than maximum
reserved: [[grp=GRP, part=ID, minCntr=cntr, minNodeId=ID, maxReserved=cntr,
maxReservedNodeId=ID], ...]{noformat}
## We can also aggregate previous message by (minNodeId) to easily find the
exact node (or nodes) which were the reason of full rebalance.
# Log results of {{reserveHistoryForExchange()}}. They can be compactly
represented as mappings: {{(grpId -> checkpoint (id, timestamp))}}. For every
group, also log message about why the previous checkpoint wasn't successfully
reserved.
There can be three reasons:
## Previous checkpoint simply isn't present in the history (the oldest is
reserved)
## WAL reservation failure (call below returned false)
{code}\{code}
{code:java}
chpEntry = entry(cpTs);
boolean reserved = cctx.wal().reserve(chpEntry.checkpointMark());// If
checkpoint WAL history can't be reserved, stop searching.
if (!reserved)
break;
{code}
3. Checkpoint was marked as inapplicable for historical
rebalancing
{code:java}
for (Integer grpId : new HashSet<>(groupsAndPartitions.keySet()))
if (!isCheckpointApplicableForGroup(grpId, chpEntry))
groupsAndPartitions.remove(grpId);
{code}
> Disadvantages in log of historical rebalance
>
>
> Key: IGNITE-12935
> URL: https://issues.apache.org/jira/browse/IGNITE-12935
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Priority: Major
>
> # Mention in the log only partitions for which there are no nodes that suit
> as historical supplier
> For these partitions, print minimal counter (since which we should perform
> historical rebalancing) with corresponding node and maximum reserved counter
> (since which cluster can perform historical rebalancing) with corresponding
> node.
> This will let us know:
> ## Whether history was reserved at all
> ## How much reserved history we lack to perform a historical rebalancing
> ## I see resulting output like this:
> {noformat}
> Historical rebalancing wasn't scheduled for some partitions:
> History wasn't reserved for: [list of partitions and groups]
>
[jira] [Updated] (IGNITE-12935) Disadvantages in log of historical rebalance
[
https://issues.apache.org/jira/browse/IGNITE-12935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-12935:
---
Description:
# Mention in the log only partitions for which there are no nodes that suit as
historical supplier
For these partitions, print minimal counter (since which we should perform
historical rebalancing) with corresponding node and maximum reserved counter
(since which cluster can perform historical rebalancing) with corresponding
node.
This will let us know:
## Whether history was reserved at all
## How much reserved history we lack to perform a historical rebalancing
## I see resulting output like this:
{noformat}
Historical rebalancing wasn't scheduled for some partitions:
History wasn't reserved for: [list of partitions and groups]
History was reserved, but minimum present counter is less than maximum
reserved: [[grp=GRP, part=ID, minCntr=cntr, minNodeId=ID, maxReserved=cntr,
maxReservedNodeId=ID], ...]{noformat}
## We can also aggregate previous message by (minNodeId) to easily find the
exact node (or nodes) which were the reason of full rebalance.
# Log results of {{reserveHistoryForExchange()}}. They can be compactly
represented as mappings: {{(grpId -> checkpoint (id, timestamp))}}. For every
group, also log message about why the previous checkpoint wasn't successfully
reserved.
There can be three reasons:
## Previous checkpoint simply isn't present in the history (the oldest is
reserved)
## WAL reservation failure (call below returned false)
{code}\{code}
{code:java}
chpEntry = entry(cpTs);
boolean reserved = cctx.wal().reserve(chpEntry.checkpointMark());// If
checkpoint WAL history can't be reserved, stop searching.
if (!reserved)
break;
{code}
3. Checkpoint was marked as inapplicable for historical
rebalancing
{code:java}
for (Integer grpId : new HashSet<>(groupsAndPartitions.keySet()))
if (!isCheckpointApplicableForGroup(grpId, chpEntry))
groupsAndPartitions.remove(grpId);
{code}
was:
# Mention in the log only partitions for which there are no nodes that suit as
historical supplier
For these partitions, print minimal counter (since which we should perform
historical rebalancing) with corresponding node and maximum reserved counter
(since which cluster can perform historical rebalancing) with corresponding
node.
This will let us know:
## Whether history was reserved at all
## How much reserved history we lack to perform a historical rebalancing
## I see resulting output like this:
{noformat}Historical rebalancing wasn't scheduled for some partitions:
History wasn't reserved for: [list of partitions and groups]
History was reserved, but minimum present counter is less than maximum
reserved: [[grp=GRP, part=ID, minCntr=cntr, minNodeId=ID, maxReserved=cntr,
maxReservedNodeId=ID], ...]\{noformat}
## We can also aggregate previous message by (minNodeId) to easily find the
exact node (or nodes) which were the reason of full rebalance.
# Log results of {{reserveHistoryForExchange()}}. They can be compactly
represented as mappings: {{(grpId -> checkpoint (id, timestamp))}}. For every
group, also log message about why the previous checkpoint wasn't successfully
reserved.
There can be three reasons:
## Previous checkpoint simply isn't present in the history (the oldest is
reserved)
## WAL reservation failure (call below returned false)
{code:java}
chpEntry = entry(cpTs);
boolean reserved = cctx.wal().reserve(chpEntry.checkpointMark());// If
checkpoint WAL history can't be reserved, stop searching.
if (!reserved)
break;
{code}
3. Checkpoint was marked as inapplicable for historical
rebalancing
{code:java}
for (Integer grpId : new HashSet<>(groupsAndPartitions.keySet()))
if (!isCheckpointApplicableForGroup(grpId, chpEntry))
groupsAndPartitions.remove(grpId);
{code}
> Disadvantages in log of historical rebalance
>
>
> Key: IGNITE-12935
> URL: https://issues.apache.org/jira/browse/IGNITE-12935
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Priority: Major
>
> # Mention in the log only partitions for which there are no nodes that suit
> as historical supplier
> For these partitions, print minimal counter (since which we should perform
> historical rebalancing) with corresponding node and maximum reserved counter
> (since which cluster can perform historical rebalancing) with corresponding
> node.
> This will let us know:
> ## Whether history was reserved at all
> ## How much reserved history we lack to perform a historical rebalancing
> ## I see resulting output like this:
> {noformat}
> Historical rebalancing wasn't scheduled for some partitions:
> History wasn't reserved for: [list of partitions and groups]
> History was
[jira] [Updated] (IGNITE-12935) Disadvantages in log of historical rebalance
[
https://issues.apache.org/jira/browse/IGNITE-12935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-12935:
---
Description:
# Mention in the log only partitions for which there are no nodes that suit as
historical supplier
For these partitions, print minimal counter (since which we should perform
historical rebalancing) with corresponding node and maximum reserved counter
(since which cluster can perform historical rebalancing) with corresponding
node.
This will let us know:
## Whether history was reserved at all
## How much reserved history we lack to perform a historical rebalancing
## I see resulting output like this:
{noformat}Historical rebalancing wasn't scheduled for some partitions:
History wasn't reserved for: [list of partitions and groups]
History was reserved, but minimum present counter is less than maximum
reserved: [[grp=GRP, part=ID, minCntr=cntr, minNodeId=ID, maxReserved=cntr,
maxReservedNodeId=ID], ...]\{noformat}
## We can also aggregate previous message by (minNodeId) to easily find the
exact node (or nodes) which were the reason of full rebalance.
# Log results of {{reserveHistoryForExchange()}}. They can be compactly
represented as mappings: {{(grpId -> checkpoint (id, timestamp))}}. For every
group, also log message about why the previous checkpoint wasn't successfully
reserved.
There can be three reasons:
## Previous checkpoint simply isn't present in the history (the oldest is
reserved)
## WAL reservation failure (call below returned false)
{code:java}
chpEntry = entry(cpTs);
boolean reserved = cctx.wal().reserve(chpEntry.checkpointMark());// If
checkpoint WAL history can't be reserved, stop searching.
if (!reserved)
break;
{code}
3. Checkpoint was marked as inapplicable for historical
rebalancing
{code:java}
for (Integer grpId : new HashSet<>(groupsAndPartitions.keySet()))
if (!isCheckpointApplicableForGroup(grpId, chpEntry))
groupsAndPartitions.remove(grpId);
{code}
was:
# Mention in the log only partitions for which there are no nodes that suit as
historical supplier
For these partitions, print minimal counter (since which we should perform
historical rebalancing) with corresponding node and maximum reserved counter
(since which cluster can perform historical rebalancing) with corresponding
node.
This will let us know:
## Whether history was reserved at all
## How much reserved history we lack to perform a historical rebalancing
## I see resulting output like this:
Historical rebalancing wasn't scheduled for some partitions:
History wasn't reserved for: [list of partitions and groups]
History was reserved, but minimum present counter is less than maximum
reserved: [[grp=GRP, part=ID, minCntr=cntr, minNodeId=ID, maxReserved=cntr,
maxReservedNodeId=ID], ...]
## We can also aggregate previous message by (minNodeId) to easily find the
exact node (or nodes) which were the reason of full rebalance.
# Log results of {{reserveHistoryForExchange()}}. They can be compactly
represented as mappings: {{(grpId -> checkpoint (id, timestamp))}}. For every
group, also log message about why the previous checkpoint wasn't successfully
reserved.
There can be three reasons:
## Previous checkpoint simply isn't present in the history (the oldest is
reserved)
## WAL reservation failure (call below returned false)
{code:java}
chpEntry = entry(cpTs);
boolean reserved = cctx.wal().reserve(chpEntry.checkpointMark());// If
checkpoint WAL history can't be reserved, stop searching.
if (!reserved)
break;
{code}
3. Checkpoint was marked as inapplicable for historical
rebalancing
{code:java}
for (Integer grpId : new HashSet<>(groupsAndPartitions.keySet()))
if (!isCheckpointApplicableForGroup(grpId, chpEntry))
groupsAndPartitions.remove(grpId);
{code}
> Disadvantages in log of historical rebalance
>
>
> Key: IGNITE-12935
> URL: https://issues.apache.org/jira/browse/IGNITE-12935
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Priority: Major
>
> # Mention in the log only partitions for which there are no nodes that suit
> as historical supplier
> For these partitions, print minimal counter (since which we should perform
> historical rebalancing) with corresponding node and maximum reserved counter
> (since which cluster can perform historical rebalancing) with corresponding
> node.
> This will let us know:
> ## Whether history was reserved at all
> ## How much reserved history we lack to perform a historical rebalancing
> ## I see resulting output like this:
> {noformat}Historical rebalancing wasn't scheduled for some partitions:
> History wasn't reserved for: [list of partitions and groups]
> History was reserved, but minimum present counter is
[jira] [Updated] (IGNITE-12935) Disadvantages in log of historical rebalance
[
https://issues.apache.org/jira/browse/IGNITE-12935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-12935:
---
Description:
# Mention in the log only partitions for which there are no nodes that suit as
historical supplier
For these partitions, print minimal counter (since which we should perform
historical rebalancing) with corresponding node and maximum reserved counter
(since which cluster can perform historical rebalancing) with corresponding
node.
This will let us know:
## Whether history was reserved at all
## How much reserved history we lack to perform a historical rebalancing
## I see resulting output like this:
Historical rebalancing wasn't scheduled for some partitions:
History wasn't reserved for: [list of partitions and groups]
History was reserved, but minimum present counter is less than maximum
reserved: [[grp=GRP, part=ID, minCntr=cntr, minNodeId=ID, maxReserved=cntr,
maxReservedNodeId=ID], ...]
## We can also aggregate previous message by (minNodeId) to easily find the
exact node (or nodes) which were the reason of full rebalance.
# Log results of {{reserveHistoryForExchange()}}. They can be compactly
represented as mappings: {{(grpId -> checkpoint (id, timestamp))}}. For every
group, also log message about why the previous checkpoint wasn't successfully
reserved.
There can be three reasons:
## Previous checkpoint simply isn't present in the history (the oldest is
reserved)
## WAL reservation failure (call below returned false)
{code:java}
chpEntry = entry(cpTs);
boolean reserved = cctx.wal().reserve(chpEntry.checkpointMark());// If
checkpoint WAL history can't be reserved, stop searching.
if (!reserved)
break;
{code}
3. Checkpoint was marked as inapplicable for historical
rebalancing
{code:java}
for (Integer grpId : new HashSet<>(groupsAndPartitions.keySet()))
if (!isCheckpointApplicableForGroup(grpId, chpEntry))
groupsAndPartitions.remove(grpId);
{code}
was:
# Mention in the log only partitions for which there are no nodes that suit as
historical supplier
For these partitions, print minimal counter (since which we should perform
historical rebalancing) with corresponding node and maximum reserved counter
(since which cluster can perform historical rebalancing) with corresponding
node.
This will let us know:
## Whether history was reserved at all
## How much reserved history we lack to perform a historical rebalancing
## I see resulting output like this:
Historical rebalancing wasn't scheduled for some partitions:
History wasn't reserved for: [list of partitions and groups]
History was reserved, but minimum present counter is less than maximum
reserved: [[grp=GRP, part=ID, minCntr=cntr, minNodeId=ID, maxReserved=cntr,
maxReservedNodeId=ID], ...]
## We can also aggregate previous message by (minNodeId) to easily find the
exact node (or nodes) which were the reason of full rebalance.
# Log results of {{reserveHistoryForExchange()}}. They can be compactly
represented as mappings: {{(grpId -> checkpoint (id, timestamp))}}. For every
group, also log message about why the previous checkpoint wasn't successfully
reserved.
There can be three reasons:
## Previous checkpoint simply isn't present in the history (the oldest is
reserved)
## WAL reservation failure (call below returned false)
{code:java}
chpEntry = entry(cpTs);boolean reserved =
cctx.wal().reserve(chpEntry.checkpointMark());// If checkpoint WAL history
can't be reserved, stop searching.
if (!reserved)
break;
{code}
3. Checkpoint was marked as inapplicable for historical
rebalancing
{code:java}
for (Integer grpId : new HashSet<>(groupsAndPartitions.keySet()))
if (!isCheckpointApplicableForGroup(grpId, chpEntry))
groupsAndPartitions.remove(grpId);
{code}
> Disadvantages in log of historical rebalance
>
>
> Key: IGNITE-12935
> URL: https://issues.apache.org/jira/browse/IGNITE-12935
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Priority: Major
>
> # Mention in the log only partitions for which there are no nodes that suit
> as historical supplier
> For these partitions, print minimal counter (since which we should perform
> historical rebalancing) with corresponding node and maximum reserved counter
> (since which cluster can perform historical rebalancing) with corresponding
> node.
> This will let us know:
> ## Whether history was reserved at all
> ## How much reserved history we lack to perform a historical rebalancing
> ## I see resulting output like this:
> Historical rebalancing wasn't scheduled for some partitions:
> History wasn't reserved for: [list of partitions and groups]
> History was reserved, but minimum present counter is less than maximum
>
[jira] [Updated] (IGNITE-12935) Disadvantages in log of historical rebalance
[
https://issues.apache.org/jira/browse/IGNITE-12935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-12935:
---
Description:
# Mention in the log only partitions for which there are no nodes that suit as
historical supplier
For these partitions, print minimal counter (since which we should perform
historical rebalancing) with corresponding node and maximum reserved counter
(since which cluster can perform historical rebalancing) with corresponding
node.
This will let us know:
## Whether history was reserved at all
## How much reserved history we lack to perform a historical rebalancing
## I see resulting output like this:
Historical rebalancing wasn't scheduled for some partitions:
History wasn't reserved for: [list of partitions and groups]
History was reserved, but minimum present counter is less than maximum
reserved: [[grp=GRP, part=ID, minCntr=cntr, minNodeId=ID, maxReserved=cntr,
maxReservedNodeId=ID], ...]
## We can also aggregate previous message by (minNodeId) to easily find the
exact node (or nodes) which were the reason of full rebalance.
# Log results of {{reserveHistoryForExchange()}}. They can be compactly
represented as mappings: {{(grpId -> checkpoint (id, timestamp))}}. For every
group, also log message about why the previous checkpoint wasn't successfully
reserved.
There can be three reasons:
## Previous checkpoint simply isn't present in the history (the oldest is
reserved)
## WAL reservation failure (call below returned false)
{code:java}
chpEntry = entry(cpTs);boolean reserved =
cctx.wal().reserve(chpEntry.checkpointMark());// If checkpoint WAL history
can't be reserved, stop searching.
if (!reserved)
break;
{code}
3. Checkpoint was marked as inapplicable for historical
rebalancing
{code:java}
for (Integer grpId : new HashSet<>(groupsAndPartitions.keySet()))
if (!isCheckpointApplicableForGroup(grpId, chpEntry))
groupsAndPartitions.remove(grpId);
{code}
was:
# Mention in the log only partitions for which there are no nodes that suit as
historical supplier
For these partitions, print minimal counter (since which we should perform
historical rebalancing) with corresponding node and maximum reserved counter
(since which cluster can perform historical rebalancing) with corresponding
node.
This will let us know:
## Whether history was reserved at all
## How much reserved history we lack to perform a historical rebalancing
## I see resulting output like this:
Historical rebalancing wasn't scheduled for some partitions:
History wasn't reserved for: [list of partitions and groups]
History was reserved, but minimum present counter is less than maximum
reserved: [[grp=GRP, part=ID, minCntr=cntr, minNodeId=ID, maxReserved=cntr,
maxReservedNodeId=ID], ...]
## We can also aggregate previous message by (minNodeId) to easily find the
exact node (or nodes) which were the reason of full rebalance.
# Log results of {{reserveHistoryForExchange()}}. They can be compactly
represented as mappings: {{(grpId -> checkpoint (id, timestamp))}}. For every
group, also log message about why the previous checkpoint wasn't successfully
reserved.
There can be three reasons:
## Previous checkpoint simply isn't present in the history (the oldest is
reserved)
## WAL reservation failure (call below returned false)
{code:java}
chpEntry = entry(cpTs);boolean reserved =
cctx.wal().reserve(chpEntry.checkpointMark());// If checkpoint WAL history
can't be reserved, stop searching.
if (!reserved)
break;
{code}
#
## Checkpoint was marked as inapplicable for historical rebalancing
{code:java}
for (Integer grpId : new HashSet<>(groupsAndPartitions.keySet()))
if (!isCheckpointApplicableForGroup(grpId, chpEntry))
groupsAndPartitions.remove(grpId);
{code}
> Disadvantages in log of historical rebalance
>
>
> Key: IGNITE-12935
> URL: https://issues.apache.org/jira/browse/IGNITE-12935
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Priority: Major
>
> # Mention in the log only partitions for which there are no nodes that suit
> as historical supplier
> For these partitions, print minimal counter (since which we should perform
> historical rebalancing) with corresponding node and maximum reserved counter
> (since which cluster can perform historical rebalancing) with corresponding
> node.
> This will let us know:
> ## Whether history was reserved at all
> ## How much reserved history we lack to perform a historical rebalancing
> ## I see resulting output like this:
> Historical rebalancing wasn't scheduled for some partitions:
> History wasn't reserved for: [list of partitions and groups]
> History was reserved, but minimum present counter is less than maximum
> reserved:
[jira] [Comment Edited] (IGNITE-12788) Cluster achieved fully rebalanced (PME-free ready) state metric
[
https://issues.apache.org/jira/browse/IGNITE-12788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091361#comment-17091361
]
Anton Vinogradov edited comment on IGNITE-12788 at 4/24/20, 9:13 AM:
-
[~PetrovMikhail]
Another problem here that fix already merged to 2.9, but issue marked as
Reopened (Not Resolved).
It will take additional time to gain what is going on here :)
A good case is just to add 2.8.1 version (with a comment) to already resolved
issue once we finish merging to 2.8.1.
was (Author: avinogradov):
[~PetrovMikhail]
Another problem here that fix already merged to 2.9, but issue marked as
Reopened (Not Resolved).
It will take additional time to gain what is going on here :)
A good case is just to add 2.8.1 version to already (with a comment) resolved
issue once we finish merging to 2.8.1.
> Cluster achieved fully rebalanced (PME-free ready) state metric
> ---
>
> Key: IGNITE-12788
> URL: https://issues.apache.org/jira/browse/IGNITE-12788
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.9, 2.8.1
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Currently, there is no metric responsible for "PME-free ready state achieved"
> delivery.
> {{GridDhtPartitionsExchangeFuture#rebalanced}} can be used to provide such
> metric.
> Seems, we should update metric on each
> {{GridDhtPartitionsExchangeFuture#onDone}}.
> P.s. Late Affinity Assignment should always set {{true}} to metric value.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12788) Cluster achieved fully rebalanced (PME-free ready) state metric
[
https://issues.apache.org/jira/browse/IGNITE-12788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091361#comment-17091361
]
Anton Vinogradov commented on IGNITE-12788:
---
[~PetrovMikhail]
Another problem here that fix already merged to 2.9, but issue marked as
Reopened (Not Resolved).
It will take additional time to gain what is going on here :)
A good case is just to add 2.8.1 version to already (with a comment) resolved
issue once we finish merging to 2.8.1.
> Cluster achieved fully rebalanced (PME-free ready) state metric
> ---
>
> Key: IGNITE-12788
> URL: https://issues.apache.org/jira/browse/IGNITE-12788
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.9, 2.8.1
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Currently, there is no metric responsible for "PME-free ready state achieved"
> delivery.
> {{GridDhtPartitionsExchangeFuture#rebalanced}} can be used to provide such
> metric.
> Seems, we should update metric on each
> {{GridDhtPartitionsExchangeFuture#onDone}}.
> P.s. Late Affinity Assignment should always set {{true}} to metric value.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-12935) Disadvantages in log of historical rebalance
Vladislav Pyatkov created IGNITE-12935:
--
Summary: Disadvantages in log of historical rebalance
Key: IGNITE-12935
URL: https://issues.apache.org/jira/browse/IGNITE-12935
Project: Ignite
Issue Type: Improvement
Reporter: Vladislav Pyatkov
# Mention in the log only partitions for which there are no nodes that suit as
historical supplier
For these partitions, print minimal counter (since which we should perform
historical rebalancing) with corresponding node and maximum reserved counter
(since which cluster can perform historical rebalancing) with corresponding
node.
This will let us know:
## Whether history was reserved at all
## How much reserved history we lack to perform a historical rebalancing
## I see resulting output like this:
Historical rebalancing wasn't scheduled for some partitions:
History wasn't reserved for: [list of partitions and groups]
History was reserved, but minimum present counter is less than maximum
reserved: [[grp=GRP, part=ID, minCntr=cntr, minNodeId=ID, maxReserved=cntr,
maxReservedNodeId=ID], ...]
## We can also aggregate previous message by (minNodeId) to easily find the
exact node (or nodes) which were the reason of full rebalance.
# Log results of reserveHistoryForExchange(). They can be compactly
represented as mappings: (grpId -> checkpoint (id, timestamp)). For every
group, also log message about why the previous checkpoint wasn't successfully
reserved.
There can be three reasons:
## Previous checkpoint simply isn't present in the history (the oldest is
reserved)
## WAL reservation failure (call below returned false)
{code:java}
chpEntry = entry(cpTs);boolean reserved =
cctx.wal().reserve(chpEntry.checkpointMark());// If checkpoint WAL history
can't be reserved, stop searching.
if (!reserved)
break;
{code}
## Checkpoint was marked as inapplicable for historical rebalancing
{code:java}
for (Integer grpId : new HashSet<>(groupsAndPartitions.keySet()))
if (!isCheckpointApplicableForGroup(grpId, chpEntry))
groupsAndPartitions.remove(grpId);
{code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12935) Disadvantages in log of historical rebalance
[
https://issues.apache.org/jira/browse/IGNITE-12935?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-12935:
---
Description:
# Mention in the log only partitions for which there are no nodes that suit as
historical supplier
For these partitions, print minimal counter (since which we should perform
historical rebalancing) with corresponding node and maximum reserved counter
(since which cluster can perform historical rebalancing) with corresponding
node.
This will let us know:
## Whether history was reserved at all
## How much reserved history we lack to perform a historical rebalancing
## I see resulting output like this:
Historical rebalancing wasn't scheduled for some partitions:
History wasn't reserved for: [list of partitions and groups]
History was reserved, but minimum present counter is less than maximum
reserved: [[grp=GRP, part=ID, minCntr=cntr, minNodeId=ID, maxReserved=cntr,
maxReservedNodeId=ID], ...]
## We can also aggregate previous message by (minNodeId) to easily find the
exact node (or nodes) which were the reason of full rebalance.
# Log results of {{reserveHistoryForExchange()}}. They can be compactly
represented as mappings: {{(grpId -> checkpoint (id, timestamp))}}. For every
group, also log message about why the previous checkpoint wasn't successfully
reserved.
There can be three reasons:
## Previous checkpoint simply isn't present in the history (the oldest is
reserved)
## WAL reservation failure (call below returned false)
{code:java}
chpEntry = entry(cpTs);boolean reserved =
cctx.wal().reserve(chpEntry.checkpointMark());// If checkpoint WAL history
can't be reserved, stop searching.
if (!reserved)
break;
{code}
#
## Checkpoint was marked as inapplicable for historical rebalancing
{code:java}
for (Integer grpId : new HashSet<>(groupsAndPartitions.keySet()))
if (!isCheckpointApplicableForGroup(grpId, chpEntry))
groupsAndPartitions.remove(grpId);
{code}
was:
# Mention in the log only partitions for which there are no nodes that suit as
historical supplier
For these partitions, print minimal counter (since which we should perform
historical rebalancing) with corresponding node and maximum reserved counter
(since which cluster can perform historical rebalancing) with corresponding
node.
This will let us know:
## Whether history was reserved at all
## How much reserved history we lack to perform a historical rebalancing
## I see resulting output like this:
Historical rebalancing wasn't scheduled for some partitions:
History wasn't reserved for: [list of partitions and groups]
History was reserved, but minimum present counter is less than maximum
reserved: [[grp=GRP, part=ID, minCntr=cntr, minNodeId=ID, maxReserved=cntr,
maxReservedNodeId=ID], ...]
## We can also aggregate previous message by (minNodeId) to easily find the
exact node (or nodes) which were the reason of full rebalance.
# Log results of reserveHistoryForExchange(). They can be compactly
represented as mappings: (grpId -> checkpoint (id, timestamp)). For every
group, also log message about why the previous checkpoint wasn't successfully
reserved.
There can be three reasons:
## Previous checkpoint simply isn't present in the history (the oldest is
reserved)
## WAL reservation failure (call below returned false)
{code:java}
chpEntry = entry(cpTs);boolean reserved =
cctx.wal().reserve(chpEntry.checkpointMark());// If checkpoint WAL history
can't be reserved, stop searching.
if (!reserved)
break;
{code}
## Checkpoint was marked as inapplicable for historical rebalancing
{code:java}
for (Integer grpId : new HashSet<>(groupsAndPartitions.keySet()))
if (!isCheckpointApplicableForGroup(grpId, chpEntry))
groupsAndPartitions.remove(grpId);
{code}
> Disadvantages in log of historical rebalance
>
>
> Key: IGNITE-12935
> URL: https://issues.apache.org/jira/browse/IGNITE-12935
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Priority: Major
>
> # Mention in the log only partitions for which there are no nodes that suit
> as historical supplier
> For these partitions, print minimal counter (since which we should perform
> historical rebalancing) with corresponding node and maximum reserved counter
> (since which cluster can perform historical rebalancing) with corresponding
> node.
> This will let us know:
> ## Whether history was reserved at all
> ## How much reserved history we lack to perform a historical rebalancing
> ## I see resulting output like this:
> Historical rebalancing wasn't scheduled for some partitions:
> History wasn't reserved for: [list of partitions and groups]
> History was reserved, but minimum present counter is less than maximum
> reserved: [[grp=GRP, part=ID, minCntr=cntr,
[jira] [Commented] (IGNITE-12795) Partially revert changes to atomic caches introduced in IGNITE-11797
[
https://issues.apache.org/jira/browse/IGNITE-12795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091358#comment-17091358
]
Vyacheslav Koptilin commented on IGNITE-12795:
--
Hello [~ascherbakov],
The fix looks good to me. Please proceed with the merge.
> Partially revert changes to atomic caches introduced in IGNITE-11797
>
>
> Key: IGNITE-12795
> URL: https://issues.apache.org/jira/browse/IGNITE-12795
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8
>Reporter: Alexey Scherbakov
>Assignee: Alexey Scherbakov
>Priority: Blocker
> Fix For: 2.8.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> These changes can trigger node failure during update on backup:
> Better fix for atomics is needed.
> {noformat}
> class org.apache.ignite.IgniteCheckedException: Failed to update the counter
> [newVal=173, curState=Counter [lwm=172, holes={173=Item [start=173,
> delta=1]}, maxApplied=174, hwm=173]]
> at
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl.update(PartitionUpdateCounterTrackingImpl.java:152)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateCounter(IgniteCacheOffheapManagerImpl.java:1578)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.updateCounter(GridCacheOffheapManager.java:2198)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition.nextUpdateCounter(GridDhtLocalPartition.java:995)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.nextPartitionCounter(GridDhtCacheEntry.java:104)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.update(GridCacheMapEntry.java:6434)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:6190)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:5881)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:3995)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.access$5700(BPlusTree.java:3889)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:2020)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1904)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1656)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1639)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:2450)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:436)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2311)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processDhtAtomicUpdateRequest(GridDhtAtomicCache.java:3362)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$600(GridDhtAtomicCache.java:139)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$7.apply(GridDhtAtomicCache.java:311)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$7.apply(GridDhtAtomicCache.java:306)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1637)
> at
>
[jira] [Updated] (IGNITE-12933) Node failed after put incorrect key class for indexed type to transactional cache
[
https://issues.apache.org/jira/browse/IGNITE-12933?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-12933:
---
Description:
Node failed after put incorrect key class for indexed type to the transactional
cache when indexing is enabled.
Reproducer:
{code:java}
public class IndexedTypesTest extends GridCommonAbstractTest {
private boolean failed;
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
return super.getConfiguration(igniteInstanceName)
.setFailureHandler((ignite, ctx) -> failed = true)
.setCacheConfiguration(new CacheConfiguration<>(DEFAULT_CACHE_NAME)
.setAtomicityMode(TRANSACTIONAL)
.setIndexedTypes(String.class, String.class));
}
@Test
public void testPutIndexedType() throws Exception {
Ignite ignite = startGrids(2);
for (int i = 0; i < 10; i++) {
try {
ignite.cache(DEFAULT_CACHE_NAME).put(i, "val" + i);
}
catch (Exception ignore) {
}
}
assertFalse(failed);
}
}
{code}
Node failed with exception:
{noformat}
[2020-04-22
17:05:34,524][ERROR][sys-stripe-11-#76%cache.IndexedTypesTest1%][IgniteTestResources]
Critical system error detected. Will be handled accordingly to configured
handler
[hnd=o.a.i.i.processors.cache.IndexedTypesTest$$Lambda$115/0x00080024d040@147237db,
failureCtx=FailureContext [type=CRITICAL_ERROR, err=class
o.a.i.i.transactions.IgniteTxHeuristicCheckedException: Committing a
transaction has produced runtime exception]]
class
org.apache.ignite.internal.transactions.IgniteTxHeuristicCheckedException:
Committing a transaction has produced runtime exception
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxAdapter.heuristicException(IgniteTxAdapter.java:800)
at
org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitIfLocked(GridDistributedTxRemoteAdapter.java:838)
at
org.apache.ignite.internal.processors.cache.distributed.GridDistributedTxRemoteAdapter.commitRemoteTx(GridDistributedTxRemoteAdapter.java:893)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.finish(IgniteTxHandler.java:1502)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler.processDhtTxPrepareRequest(IgniteTxHandler.java:1233)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$5.apply(IgniteTxHandler.java:229)
at
org.apache.ignite.internal.processors.cache.transactions.IgniteTxHandler$5.apply(IgniteTxHandler.java:227)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
at
org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
at
org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1847)
at
org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1472)
at
org.apache.ignite.internal.managers.communication.GridIoManager$9.run(GridIoManager.java:1367)
at
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:565)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:120)
at java.base/java.lang.Thread.run(Thread.java:834)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to update
index, incorrect key class [expCls=java.lang.String,
actualCls=java.lang.Integer]
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.typeByValue(GridQueryProcessor.java:2223)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:2092)
at
org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:410)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:2627)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1713)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1688)
at
org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:445)
at
[jira] [Commented] (IGNITE-12795) Partially revert changes to atomic caches introduced in IGNITE-11797
[
https://issues.apache.org/jira/browse/IGNITE-12795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091349#comment-17091349
]
Alexey Scherbakov commented on IGNITE-12795:
The core problem is related to atomic protocol - it can not guarantee all
updates are received by backups and leaves gaps in the counters potentially
forever.
It doensn't compatibe in current state with tracking counter.
> Partially revert changes to atomic caches introduced in IGNITE-11797
>
>
> Key: IGNITE-12795
> URL: https://issues.apache.org/jira/browse/IGNITE-12795
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8
>Reporter: Alexey Scherbakov
>Assignee: Alexey Scherbakov
>Priority: Blocker
> Fix For: 2.8.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> These changes can trigger node failure during update on backup:
> Better fix for atomics is needed.
> {noformat}
> class org.apache.ignite.IgniteCheckedException: Failed to update the counter
> [newVal=173, curState=Counter [lwm=172, holes={173=Item [start=173,
> delta=1]}, maxApplied=174, hwm=173]]
> at
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl.update(PartitionUpdateCounterTrackingImpl.java:152)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateCounter(IgniteCacheOffheapManagerImpl.java:1578)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.updateCounter(GridCacheOffheapManager.java:2198)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition.nextUpdateCounter(GridDhtLocalPartition.java:995)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.nextPartitionCounter(GridDhtCacheEntry.java:104)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.update(GridCacheMapEntry.java:6434)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:6190)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:5881)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:3995)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.access$5700(BPlusTree.java:3889)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:2020)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1904)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1656)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1639)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:2450)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:436)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2311)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processDhtAtomicUpdateRequest(GridDhtAtomicCache.java:3362)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$600(GridDhtAtomicCache.java:139)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$7.apply(GridDhtAtomicCache.java:311)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$7.apply(GridDhtAtomicCache.java:306)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
> at
>
[jira] [Comment Edited] (IGNITE-12795) Partially revert changes to atomic caches introduced in IGNITE-11797
[
https://issues.apache.org/jira/browse/IGNITE-12795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091349#comment-17091349
]
Alexey Scherbakov edited comment on IGNITE-12795 at 4/24/20, 9:05 AM:
--
The root cause is related to atomic protocol - it can not guarantee all updates
are received by backups and leaves gaps in the counters potentially forever.
It doensn't compatibe in current state with tracking counter.
was (Author: ascherbakov):
The core problem is related to atomic protocol - it can not guarantee all
updates are received by backups and leaves gaps in the counters potentially
forever.
It doensn't compatibe in current state with tracking counter.
> Partially revert changes to atomic caches introduced in IGNITE-11797
>
>
> Key: IGNITE-12795
> URL: https://issues.apache.org/jira/browse/IGNITE-12795
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8
>Reporter: Alexey Scherbakov
>Assignee: Alexey Scherbakov
>Priority: Blocker
> Fix For: 2.8.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> These changes can trigger node failure during update on backup:
> Better fix for atomics is needed.
> {noformat}
> class org.apache.ignite.IgniteCheckedException: Failed to update the counter
> [newVal=173, curState=Counter [lwm=172, holes={173=Item [start=173,
> delta=1]}, maxApplied=174, hwm=173]]
> at
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl.update(PartitionUpdateCounterTrackingImpl.java:152)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateCounter(IgniteCacheOffheapManagerImpl.java:1578)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.updateCounter(GridCacheOffheapManager.java:2198)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition.nextUpdateCounter(GridDhtLocalPartition.java:995)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.nextPartitionCounter(GridDhtCacheEntry.java:104)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.update(GridCacheMapEntry.java:6434)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:6190)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:5881)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:3995)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.access$5700(BPlusTree.java:3889)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:2020)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1904)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1656)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1639)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:2450)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:436)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2311)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processDhtAtomicUpdateRequest(GridDhtAtomicCache.java:3362)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$600(GridDhtAtomicCache.java:139)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$7.apply(GridDhtAtomicCache.java:311)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$7.apply(GridDhtAtomicCache.java:306)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
> at
>
[jira] [Commented] (IGNITE-12795) Partially revert changes to atomic caches introduced in IGNITE-11797
[
https://issues.apache.org/jira/browse/IGNITE-12795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091343#comment-17091343
]
Alexey Scherbakov commented on IGNITE-12795:
By some cryptic reason bot doesn't allow to post visa.
TC run results avaialble by link [1]
[1]
https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull%2F7718%2Fhead=Latest
> Partially revert changes to atomic caches introduced in IGNITE-11797
>
>
> Key: IGNITE-12795
> URL: https://issues.apache.org/jira/browse/IGNITE-12795
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8
>Reporter: Alexey Scherbakov
>Assignee: Alexey Scherbakov
>Priority: Blocker
> Fix For: 2.8.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> These changes can trigger node failure during update on backup:
> Better fix for atomics is needed.
> {noformat}
> class org.apache.ignite.IgniteCheckedException: Failed to update the counter
> [newVal=173, curState=Counter [lwm=172, holes={173=Item [start=173,
> delta=1]}, maxApplied=174, hwm=173]]
> at
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl.update(PartitionUpdateCounterTrackingImpl.java:152)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateCounter(IgniteCacheOffheapManagerImpl.java:1578)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.updateCounter(GridCacheOffheapManager.java:2198)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition.nextUpdateCounter(GridDhtLocalPartition.java:995)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.nextPartitionCounter(GridDhtCacheEntry.java:104)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.update(GridCacheMapEntry.java:6434)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:6190)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:5881)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:3995)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.access$5700(BPlusTree.java:3889)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:2020)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1904)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1656)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1639)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:2450)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:436)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2311)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processDhtAtomicUpdateRequest(GridDhtAtomicCache.java:3362)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$600(GridDhtAtomicCache.java:139)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$7.apply(GridDhtAtomicCache.java:311)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$7.apply(GridDhtAtomicCache.java:306)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:109)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:308)
> at
>
[jira] [Comment Edited] (IGNITE-12795) Partially revert changes to atomic caches introduced in IGNITE-11797
[
https://issues.apache.org/jira/browse/IGNITE-12795?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091343#comment-17091343
]
Alexey Scherbakov edited comment on IGNITE-12795 at 4/24/20, 8:50 AM:
--
By some cryptic reason TC bot doesn't allow to post visa.
TC run results avaialble by link [1]
[1]
https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull%2F7718%2Fhead=Latest
was (Author: ascherbakov):
By some cryptic reason bot doesn't allow to post visa.
TC run results avaialble by link [1]
[1]
https://mtcga.gridgain.com/pr.html?serverId=apache=IgniteTests24Java8_RunAll=pull%2F7718%2Fhead=Latest
> Partially revert changes to atomic caches introduced in IGNITE-11797
>
>
> Key: IGNITE-12795
> URL: https://issues.apache.org/jira/browse/IGNITE-12795
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Affects Versions: 2.8
>Reporter: Alexey Scherbakov
>Assignee: Alexey Scherbakov
>Priority: Blocker
> Fix For: 2.8.1
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> These changes can trigger node failure during update on backup:
> Better fix for atomics is needed.
> {noformat}
> class org.apache.ignite.IgniteCheckedException: Failed to update the counter
> [newVal=173, curState=Counter [lwm=172, holes={173=Item [start=173,
> delta=1]}, maxApplied=174, hwm=173]]
> at
> org.apache.ignite.internal.processors.cache.PartitionUpdateCounterTrackingImpl.update(PartitionUpdateCounterTrackingImpl.java:152)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.updateCounter(IgniteCacheOffheapManagerImpl.java:1578)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.updateCounter(GridCacheOffheapManager.java:2198)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtLocalPartition.nextUpdateCounter(GridDhtLocalPartition.java:995)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.nextPartitionCounter(GridDhtCacheEntry.java:104)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.update(GridCacheMapEntry.java:6434)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:6190)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:5881)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:3995)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.access$5700(BPlusTree.java:3889)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invokeDown(BPlusTree.java:2020)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:1904)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1656)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1639)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:2450)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:436)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2311)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processDhtAtomicUpdateRequest(GridDhtAtomicCache.java:3362)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$600(GridDhtAtomicCache.java:139)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$7.apply(GridDhtAtomicCache.java:311)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$7.apply(GridDhtAtomicCache.java:306)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1142)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:591)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:392)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:318)
> at
>
[jira] [Commented] (IGNITE-12788) Cluster achieved fully rebalanced (PME-free ready) state metric
[
https://issues.apache.org/jira/browse/IGNITE-12788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091332#comment-17091332
]
Mikhail Petrov commented on IGNITE-12788:
-
[~avinogradov],
I see. My mistake. Thank you for the clarification. I've specified both 2.8.1
and 2.9.
> Cluster achieved fully rebalanced (PME-free ready) state metric
> ---
>
> Key: IGNITE-12788
> URL: https://issues.apache.org/jira/browse/IGNITE-12788
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.9, 2.8.1
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Currently, there is no metric responsible for "PME-free ready state achieved"
> delivery.
> {{GridDhtPartitionsExchangeFuture#rebalanced}} can be used to provide such
> metric.
> Seems, we should update metric on each
> {{GridDhtPartitionsExchangeFuture#onDone}}.
> P.s. Late Affinity Assignment should always set {{true}} to metric value.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-12788) Cluster achieved fully rebalanced (PME-free ready) state metric
[
https://issues.apache.org/jira/browse/IGNITE-12788?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-12788:
Fix Version/s: 2.9
> Cluster achieved fully rebalanced (PME-free ready) state metric
> ---
>
> Key: IGNITE-12788
> URL: https://issues.apache.org/jira/browse/IGNITE-12788
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.9, 2.8.1
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Currently, there is no metric responsible for "PME-free ready state achieved"
> delivery.
> {{GridDhtPartitionsExchangeFuture#rebalanced}} can be used to provide such
> metric.
> Seems, we should update metric on each
> {{GridDhtPartitionsExchangeFuture#onDone}}.
> P.s. Late Affinity Assignment should always set {{true}} to metric value.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-12788) Cluster achieved fully rebalanced (PME-free ready) state metric
[
https://issues.apache.org/jira/browse/IGNITE-12788?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17091297#comment-17091297
]
Anton Vinogradov commented on IGNITE-12788:
---
[~PetrovMikhail]
"Fixed at 2.8.1" does not mean it was fixed at 2.9 since
* 2.8.1 can be released after 2.9
* 2.8.1 can be released before 2.9, but will not be merged to 2.9 because of
some reason.
And the main problem here that you will not have this issue at 2.9 Release
Notes because the Jira filter will not show it.
> Cluster achieved fully rebalanced (PME-free ready) state metric
> ---
>
> Key: IGNITE-12788
> URL: https://issues.apache.org/jira/browse/IGNITE-12788
> Project: Ignite
> Issue Type: Task
>Reporter: Anton Vinogradov
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.8.1
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> Currently, there is no metric responsible for "PME-free ready state achieved"
> delivery.
> {{GridDhtPartitionsExchangeFuture#rebalanced}} can be used to provide such
> metric.
> Seems, we should update metric on each
> {{GridDhtPartitionsExchangeFuture#onDone}}.
> P.s. Late Affinity Assignment should always set {{true}} to metric value.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
