[jira] [Commented] (IGNITE-20145) Update maven surefire version
[
https://issues.apache.org/jira/browse/IGNITE-20145?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753325#comment-17753325
]
Nikita Amelchev commented on IGNITE-20145:
--
The {{-DforkMode=always}} property was removed in surefire plugin. For TC it is
replaced to {{-DFORK_COUNT_SET_TO_1}}.
> Update maven surefire version
> -
>
> Key: IGNITE-20145
> URL: https://issues.apache.org/jira/browse/IGNITE-20145
> Project: Ignite
> Issue Type: Task
>Reporter: Nikita Amelchev
>Assignee: Nikita Amelchev
>Priority: Major
> Labels: ise
> Fix For: 2.16
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> There are many useful updates in new versions, such as
> [SUREFIRE-1426|https://issues.apache.org/jira/browse/SUREFIRE-1426]. This
> fixes the exit code in case of a fork failure and is needed for proper
> failure handling in CI tools.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20201) Node failure when incorrect names are used for hitrate and histogram metrics configuration
[
https://issues.apache.org/jira/browse/IGNITE-20201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-20201:
---
Description:
There are no metric name validation when we perform hitrate and historgam
metrics configuration by means of control script. It can lead to impossibility
to restart persistent cluster.
*How to reproduce:*
# Start persistent cluster
# Just repeat commands from instructions:
[https://ignite.apache.org/docs/latest/tools/control-script#metric-configure-command]
{noformat}
control.sh —metric —configure-histogram histogram-metric-name 1,2,3
control.sh —metric —configure-hitrate hitrate-metric-name 1000
{noformat}
# Deactivate and restart cluster.
# Start and activate cluster and nodes will fail with following error:
{noformat}
[19:47:26,981][SEVERE][main][IgniteKernal] Got exception while starting (will
rollback startup routine).
java.lang.StringIndexOutOfBoundsException: String index out of range: -1
at java.lang.String.substring(String.java:1967)
at
org.apache.ignite.internal.processors.metric.impl.MetricUtils.fromFullName(MetricUtils.java:72)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.find(GridMetricManager.java:502)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.onHistogramConfigChanged(GridMetricManager.java:480)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.access$300(GridMetricManager.java:73)
at
org.apache.ignite.internal.processors.metric.GridMetricManager$1.lambda$onReadyForRead$1(GridMetricManager.java:272)
at
org.apache.ignite.internal.processors.metastorage.persistence.InMemoryCachedDistributedMetaStorageBridge.iterate(InMemoryCachedDistributedMetaStorageBridge.java:87)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.iterate(DistributedMetaStorageImpl.java:542)
at
org.apache.ignite.internal.processors.metric.GridMetricManager$1.onReadyForRead(GridMetricManager.java:272)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.notifyReadyForRead(DistributedMetaStorageImpl.java:355)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.onMetaStorageReadyForRead(DistributedMetaStorageImpl.java:434)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.access$200(DistributedMetaStorageImpl.java:116)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl$2.onReadyForRead(DistributedMetaStorageImpl.java:259)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:430)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:877)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:3094)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1120)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1725)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1089)
at
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:983)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:889)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:808)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:678)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:647)
at org.apache.ignite.Ignition.start(Ignition.java:325)
at
org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:365)
{noformat}
Failure occurs when {{GridMetricManager}} tries to parse entries with incorrect
metric names from metastorage:
{noformat}
metrics.histogram.histogram-metric-name [1, 2, 3]
metrics.hitrate.hitrate-metric-name 1000
{noformat}
*Workaround:*
Clean metastorage.
was:
There are no metric name validation when we perform hitrate and historgam
metrics configuration by means of control script. It can lead to impossibility
to restart persistent cluster without clearing of metastorage.
*How to reproduce:*
# Start persistent cluster
# Just repeat commands from instructions:
[https://ignite.apache.org/docs/latest/tools/control-script#metric-configure-command
[jira] [Updated] (IGNITE-20201) Node failure when incorrect names are used for hitrate and histogram metrics configuration
[
https://issues.apache.org/jira/browse/IGNITE-20201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-20201:
---
Description:
There are no metric name validation when we perform hitrate and historgam
metrics configuration by means of control script. It can lead to impossibility
to restart persistent cluster without clearing of metastorage.
*How to reproduce:*
# Start persistent cluster
# Just repeat commands from instructions:
[https://ignite.apache.org/docs/latest/tools/control-script#metric-configure-command]
{noformat}
control.sh —metric —configure-histogram histogram-metric-name 1,2,3
control.sh —metric —configure-hitrate hitrate-metric-name 1000
{noformat}
# Deactivate and restart cluster.
# Start and activate cluster and nodes will fail with following error:
{noformat}
[12:44:18,713][SEVERE][main][IgniteKernal%myGrid1] Exception during start
processors, node will be stopped and close connections
java.lang.StringIndexOutOfBoundsException: begin 0, end -1, length 19
at java.base/java.lang.String.checkBoundsBeginEnd(String.java:4606)
at java.base/java.lang.String.substring(String.java:2709)
at
org.apache.ignite.internal.processors.metric.impl.MetricUtils.fromFullName(MetricUtils.java:72)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.find(GridMetricManager.java:502)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.onHitRateConfigChanged(GridMetricManager.java:462)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.access$400(GridMetricManager.java:73)
at
org.apache.ignite.internal.processors.metric.GridMetricManager$1.lambda$onReadyForRead$0(GridMetricManager.java:269)
at
org.apache.ignite.internal.processors.metastorage.persistence.InMemoryCachedDistributedMetaStorageBridge.iterate(InMemoryCachedDistributedMetaStorageBridge.java:87)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.iterate(DistributedMetaStorageImpl.java:542)
at
org.apache.ignite.internal.processors.metric.GridMetricManager$1.onReadyForRead(GridMetricManager.java:269)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.notifyReadyForRead(DistributedMetaStorageImpl.java:355)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.onMetaStorageReadyForRead(DistributedMetaStorageImpl.java:434)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.access$200(DistributedMetaStorageImpl.java:116)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl$2.onReadyForRead(DistributedMetaStorageImpl.java:259)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:430)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:877)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:3094)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1120)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1725)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1089)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:599)
at
org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
at
org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:74)
{noformat}
Failure occurs when {{GridMetricManager}} tries to parse entries with incorrect
metric names from metastorage:
{noformat}
metrics.histogram.histogram-metric-name [1, 2, 3]
metrics.hitrate.hitrate-metric-name 1000
{noformat}
*Workaround:*
Clean metastorage.
was:
There are no metric name validation when we perform hitrate and historgam
metrics configuration by means of control script. It can lead to impossibility
to restart persistent cluster.
*How to reproduce:*
# Start persistent cluster
# Just repeat commands from instructions:
[https://ignite.apache.org/docs/latest/tools/control-script#metric-configure-command]
{noformat}
control.sh —metric —configure-histogram histogram-metric-name 1,2,3
control.sh —metric —configure-hitrate hitrate-metric-name 1000
{noformat}
# Deactivate and restart cluster.
# Start and activate cluster and nodes will fail with following error:
{noformat}
[12:44:18,713
[jira] [Updated] (IGNITE-20201) Node failure when incorrect names are used for hitrate and histogram metrics configuration
[
https://issues.apache.org/jira/browse/IGNITE-20201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-20201:
---
Description:
There are no metric name validation when we perform hitrate and historgam
metrics configuration by means of control script. It can lead to impossibility
to restart persistent cluster.
*How to reproduce:*
# Start persistent cluster
# Just repeat commands from instructions:
[https://ignite.apache.org/docs/latest/tools/control-script#metric-configure-command]
{noformat}
control.sh —metric —configure-histogram histogram-metric-name 1,2,3
control.sh —metric —configure-hitrate hitrate-metric-name 1000
{noformat}
# Deactivate and restart cluster.
# Start and activate cluster and nodes will fail with following error:
{noformat}
[12:44:18,713][SEVERE][main][IgniteKernal%myGrid1] Exception during start
processors, node will be stopped and close connections
java.lang.StringIndexOutOfBoundsException: begin 0, end -1, length 19
at java.base/java.lang.String.checkBoundsBeginEnd(String.java:4606)
at java.base/java.lang.String.substring(String.java:2709)
at
org.apache.ignite.internal.processors.metric.impl.MetricUtils.fromFullName(MetricUtils.java:72)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.find(GridMetricManager.java:502)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.onHitRateConfigChanged(GridMetricManager.java:462)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.access$400(GridMetricManager.java:73)
at
org.apache.ignite.internal.processors.metric.GridMetricManager$1.lambda$onReadyForRead$0(GridMetricManager.java:269)
at
org.apache.ignite.internal.processors.metastorage.persistence.InMemoryCachedDistributedMetaStorageBridge.iterate(InMemoryCachedDistributedMetaStorageBridge.java:87)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.iterate(DistributedMetaStorageImpl.java:542)
at
org.apache.ignite.internal.processors.metric.GridMetricManager$1.onReadyForRead(GridMetricManager.java:269)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.notifyReadyForRead(DistributedMetaStorageImpl.java:355)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.onMetaStorageReadyForRead(DistributedMetaStorageImpl.java:434)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.access$200(DistributedMetaStorageImpl.java:116)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl$2.onReadyForRead(DistributedMetaStorageImpl.java:259)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:430)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:877)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:3094)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1120)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1725)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1089)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:599)
at
org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
at
org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:74)
{noformat}
Failure occurs when {{GridMetricManager}} tries to parse entries with incorrect
metric names from metastorage:
{noformat}
metrics.histogram.histogram-metric-name [1, 2, 3]
metrics.hitrate.hitrate-metric-name 1000
{noformat}
*Workaround:*
Clean metastorage.
was:
There are no metric name validation when we perform hitrate and historgam
metrics configuration by means of control script. It can lead to impossibility
to restart persistent cluster.
*How to reproduce:*
# Start persistent cluster
# Just repeat commands from instructions:
[https://ignite.apache.org/docs/latest/tools/control-script#metric-configure-command]
{noformat}
control.sh —metric —configure-histogram histogram-metric-name 1,2,3
control.sh —metric —configure-hitrate hitrate-metric-name 1000
{noformat}
# Deactivate and restart cluster.
# Start and activate cluster and nodes will fail with following error:
{noformat}
[12:44:18,713][SEVERE][main][IgniteKernal%myG
[jira] [Updated] (IGNITE-20201) Node failure when incorrect names are used for hitrate and histogram metrics configuration
[
https://issues.apache.org/jira/browse/IGNITE-20201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-20201:
---
Description:
There are no metric name validation when we perform hitrate and historgam
metrics configuration by means of control script. It can lead to impossibility
to restart persistent cluster.
*How to reproduce:*
# Start persistent cluster
# Just repeat commands from instructions:
[https://ignite.apache.org/docs/latest/tools/control-script#metric-configure-command]
{noformat}
control.sh —metric —configure-histogram histogram-metric-name 1,2,3
control.sh —metric —configure-hitrate hitrate-metric-name 1000
{noformat}
# Deactivate and restart cluster.
# Start and activate cluster and nodes will fail with following error:
{noformat}
[12:44:18,713][SEVERE][main][IgniteKernal%myGrid1] Exception during start
processors, node will be stopped and close connections
java.lang.StringIndexOutOfBoundsException: begin 0, end -1, length 19
at java.base/java.lang.String.checkBoundsBeginEnd(String.java:4606)
at java.base/java.lang.String.substring(String.java:2709)
at
org.apache.ignite.internal.processors.metric.impl.MetricUtils.fromFullName(MetricUtils.java:72)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.find(GridMetricManager.java:502)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.onHitRateConfigChanged(GridMetricManager.java:462)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.access$400(GridMetricManager.java:73)
at
org.apache.ignite.internal.processors.metric.GridMetricManager$1.lambda$onReadyForRead$0(GridMetricManager.java:269)
at
org.apache.ignite.internal.processors.metastorage.persistence.InMemoryCachedDistributedMetaStorageBridge.iterate(InMemoryCachedDistributedMetaStorageBridge.java:87)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.iterate(DistributedMetaStorageImpl.java:542)
at
org.apache.ignite.internal.processors.metric.GridMetricManager$1.onReadyForRead(GridMetricManager.java:269)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.notifyReadyForRead(DistributedMetaStorageImpl.java:355)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.onMetaStorageReadyForRead(DistributedMetaStorageImpl.java:434)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.access$200(DistributedMetaStorageImpl.java:116)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl$2.onReadyForRead(DistributedMetaStorageImpl.java:259)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:430)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:877)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:3094)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1120)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1725)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1089)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:599)
at
org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
at
org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:74)
{noformat}
Failure occurs when {{GridMetricManager}} tries to parse incorrect entries from
metastorage:
{noformat}
metrics.histogram.histogram-metric-name [1, 2, 3]
metrics.hitrate.hitrate-metric-name 1000
{noformat}
*Workaround:*
Clean metastorage.
was:
There are no metric name validation when we perform hitrate and historgam
metrics configuration by means of control script. It can lead to impossibility
to restart persistent cluster.
*How to reproduce:*
# Start persistent cluster
# Just repeat commands from instructions:
https://ignite.apache.org/docs/latest/tools/control-script#metric-configure-command
{noformat}
control.sh —metric —configure-histogram histogram-metric-name 1,2,3
control.sh —metric —configure-hitrate hitrate-metric-name 1000
{noformat}
# Deactivate and restart cluster.
# Start and activate cluster and nodes will fail with following error:
{noformat}
[12:44:18,713][SEVERE][main][IgniteKernal%myGrid1] Exception during s
[jira] [Updated] (IGNITE-20201) Node failure when incorrect names are used for hitrate and histogram metrics configuration
[
https://issues.apache.org/jira/browse/IGNITE-20201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-20201:
---
Description:
There are no metric name validation when we perform hitrate and historgam
metrics configuration by means of control script. It can lead to impossibility
to restart persistent cluster.
*How to reproduce:*
# Start persistent cluster
# Just repeat commands from instructions:
https://ignite.apache.org/docs/latest/tools/control-script#metric-configure-command
{noformat}
control.sh —metric —configure-histogram histogram-metric-name 1,2,3
control.sh —metric —configure-hitrate hitrate-metric-name 1000
{noformat}
# Deactivate and restart cluster.
# Start and activate cluster and nodes will fail with following error:
{noformat}
[12:44:18,713][SEVERE][main][IgniteKernal%myGrid1] Exception during start
processors, node will be stopped and close connections
java.lang.StringIndexOutOfBoundsException: begin 0, end -1, length 19
at java.base/java.lang.String.checkBoundsBeginEnd(String.java:4606)
at java.base/java.lang.String.substring(String.java:2709)
at
org.apache.ignite.internal.processors.metric.impl.MetricUtils.fromFullName(MetricUtils.java:72)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.find(GridMetricManager.java:502)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.onHitRateConfigChanged(GridMetricManager.java:462)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.access$400(GridMetricManager.java:73)
at
org.apache.ignite.internal.processors.metric.GridMetricManager$1.lambda$onReadyForRead$0(GridMetricManager.java:269)
at
org.apache.ignite.internal.processors.metastorage.persistence.InMemoryCachedDistributedMetaStorageBridge.iterate(InMemoryCachedDistributedMetaStorageBridge.java:87)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.iterate(DistributedMetaStorageImpl.java:542)
at
org.apache.ignite.internal.processors.metric.GridMetricManager$1.onReadyForRead(GridMetricManager.java:269)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.notifyReadyForRead(DistributedMetaStorageImpl.java:355)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.onMetaStorageReadyForRead(DistributedMetaStorageImpl.java:434)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.access$200(DistributedMetaStorageImpl.java:116)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl$2.onReadyForRead(DistributedMetaStorageImpl.java:259)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:430)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:877)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:3094)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1120)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1725)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1089)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:599)
at
org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
at
org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:74)
{noformat}
*Workaround:*
Clean metastorage.
was:
There are no metric name validation when we perform hitrate and historgam
metrics configuration by means of control script. It can lead to impossibility
to restart persistent cluster.
How to reproduce:
# Start persistent cluster
# Just repeat commands from instructions:
https://ignite.apache.org/docs/latest/tools/control-script#metric-configure-command
{noformat}
control.sh —metric —configure-histogram histogram-metric-name 1,2,3
control.sh —metric —configure-hitrate hitrate-metric-name 1000
{noformat}
# Deactivate and restart cluster.
# Start and activate cluster and nodes will fail with following error:
{noformat}
[12:44:18,713][SEVERE][main][IgniteKernal%myGrid1] Exception during start
processors, node will be stopped and close connections
java.lang.StringIndexOutOfBoundsException: begin 0, end -1, length 19
at java.base/java.lang.String.checkBoundsBeginEnd(String.java:4606)
at java.base/java.lang.String.substring(String.java:2709)
at
org.apache.ignite.internal.processors.metric.impl.MetricUtils.fromFullName(MetricUtils.java:72)
at
org
[jira] [Updated] (IGNITE-20201) Node failure when incorrect names are used for hitrate and histogram metrics configuration
[
https://issues.apache.org/jira/browse/IGNITE-20201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-20201:
---
Description:
There are no metric name validation when we perform hitrate and historgam
metrics configuration by means of control script. It can lead to impossibility
to restart persistent cluster.
How to reproduce:
# Start persistent cluster
# Just repeat commands from instructions:
https://ignite.apache.org/docs/latest/tools/control-script#metric-configure-command
{noformat}
control.sh —metric —configure-histogram histogram-metric-name 1,2,3
control.sh —metric —configure-hitrate hitrate-metric-name 1000
{noformat}
# Deactivate and restart cluster.
# Start and activate cluster and nodes will fail with following error:
{noformat}
[12:44:18,713][SEVERE][main][IgniteKernal%myGrid1] Exception during start
processors, node will be stopped and close connections
java.lang.StringIndexOutOfBoundsException: begin 0, end -1, length 19
at java.base/java.lang.String.checkBoundsBeginEnd(String.java:4606)
at java.base/java.lang.String.substring(String.java:2709)
at
org.apache.ignite.internal.processors.metric.impl.MetricUtils.fromFullName(MetricUtils.java:72)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.find(GridMetricManager.java:502)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.onHitRateConfigChanged(GridMetricManager.java:462)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.access$400(GridMetricManager.java:73)
at
org.apache.ignite.internal.processors.metric.GridMetricManager$1.lambda$onReadyForRead$0(GridMetricManager.java:269)
at
org.apache.ignite.internal.processors.metastorage.persistence.InMemoryCachedDistributedMetaStorageBridge.iterate(InMemoryCachedDistributedMetaStorageBridge.java:87)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.iterate(DistributedMetaStorageImpl.java:542)
at
org.apache.ignite.internal.processors.metric.GridMetricManager$1.onReadyForRead(GridMetricManager.java:269)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.notifyReadyForRead(DistributedMetaStorageImpl.java:355)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.onMetaStorageReadyForRead(DistributedMetaStorageImpl.java:434)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.access$200(DistributedMetaStorageImpl.java:116)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl$2.onReadyForRead(DistributedMetaStorageImpl.java:259)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:430)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:877)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:3094)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1120)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1725)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1089)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:599)
at
org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
at
org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:74)
{noformat}
was:
There are no metric name validation when we perform hitrate and historgam
metrics configuration by means of control script, which can lead to
impossibility to restart persistent cluster.
How to reproduce:
# Start persistent cluster
# Just repeat commands from instructions:
https://ignite.apache.org/docs/latest/tools/control-script#metric-configure-command
{noformat}
control.sh —metric —configure-histogram histogram-metric-name 1,2,3
control.sh —metric —configure-hitrate hitrate-metric-name 1000
{noformat}
# Deactivate and restart cluster.
# Start and activate cluster and nodes will fail with following error:
{noformat}
[12:44:18,713][SEVERE][main][IgniteKernal%myGrid1] Exception during start
processors, node will be stopped and close connections
java.lang.StringIndexOutOfBoundsException: begin 0, end -1, length 19
at java.base/java.lang.String.checkBoundsBeginEnd(String.java:4606)
at java.base/java.lang.String.substring(String.java:2709)
at
org.apache.ignite.internal.processors.metric.impl.MetricUtils.fromFullName(MetricUtils.java:72)
at
org.apache.ignite.internal.processor
[jira] [Updated] (IGNITE-20201) Node failure when incorrect names are used for hitrate and histogram metrics configuration
[
https://issues.apache.org/jira/browse/IGNITE-20201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-20201:
---
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Node failure when incorrect names are used for hitrate and histogram metrics
> configuration
> --
>
> Key: IGNITE-20201
> URL: https://issues.apache.org/jira/browse/IGNITE-20201
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.15
>Reporter: Ilya Shishkov
>Priority: Critical
>
> There are no metric name validation when we perform hitrate and historgam
> metrics configuration by means of control script, which can lead to
> impossibility to restart persistent cluster.
> How to reproduce:
> # Start persistent cluster
> # Just repeat commands from instructions:
> https://ignite.apache.org/docs/latest/tools/control-script#metric-configure-command
> {noformat}
> control.sh —metric —configure-histogram histogram-metric-name 1,2,3
> control.sh —metric —configure-hitrate hitrate-metric-name 1000
> {noformat}
> # Deactivate and restart cluster.
> # Start and activate cluster and nodes will fail with following error:
> {noformat}
> [12:44:18,713][SEVERE][main][IgniteKernal%myGrid1] Exception during start
> processors, node will be stopped and close connections
> java.lang.StringIndexOutOfBoundsException: begin 0, end -1, length 19
> at java.base/java.lang.String.checkBoundsBeginEnd(String.java:4606)
> at java.base/java.lang.String.substring(String.java:2709)
> at
> org.apache.ignite.internal.processors.metric.impl.MetricUtils.fromFullName(MetricUtils.java:72)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager.find(GridMetricManager.java:502)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager.onHitRateConfigChanged(GridMetricManager.java:462)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager.access$400(GridMetricManager.java:73)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager$1.lambda$onReadyForRead$0(GridMetricManager.java:269)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.InMemoryCachedDistributedMetaStorageBridge.iterate(InMemoryCachedDistributedMetaStorageBridge.java:87)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.iterate(DistributedMetaStorageImpl.java:542)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager$1.onReadyForRead(GridMetricManager.java:269)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.notifyReadyForRead(DistributedMetaStorageImpl.java:355)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.onMetaStorageReadyForRead(DistributedMetaStorageImpl.java:434)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.access$200(DistributedMetaStorageImpl.java:116)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl$2.onReadyForRead(DistributedMetaStorageImpl.java:259)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:430)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:877)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:3094)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1120)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1725)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1089)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:599)
> at
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
> at
> org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:74)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20201) Node failure when incorrect names are used for hitrate and histogram metrics configuration
[
https://issues.apache.org/jira/browse/IGNITE-20201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-20201:
---
Description:
There are no metric name validation when we perform hitrate and historgam
metrics configuration by means of control script, which can lead to
impossibility to restart persistent cluster.
How to reproduce:
# Start persistent cluster
# Just repeat commands from instructions:
https://ignite.apache.org/docs/latest/tools/control-script#metric-configure-command
{noformat}
control.sh —metric —configure-histogram histogram-metric-name 1,2,3
control.sh —metric —configure-hitrate hitrate-metric-name 1000
{noformat}
# Deactivate and restart cluster.
# Start and activate cluster and nodes will fail with following error:
{noformat}
[12:44:18,713][SEVERE][main][IgniteKernal%myGrid1] Exception during start
processors, node will be stopped and close connections
java.lang.StringIndexOutOfBoundsException: begin 0, end -1, length 19
at java.base/java.lang.String.checkBoundsBeginEnd(String.java:4606)
at java.base/java.lang.String.substring(String.java:2709)
at
org.apache.ignite.internal.processors.metric.impl.MetricUtils.fromFullName(MetricUtils.java:72)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.find(GridMetricManager.java:502)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.onHitRateConfigChanged(GridMetricManager.java:462)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.access$400(GridMetricManager.java:73)
at
org.apache.ignite.internal.processors.metric.GridMetricManager$1.lambda$onReadyForRead$0(GridMetricManager.java:269)
at
org.apache.ignite.internal.processors.metastorage.persistence.InMemoryCachedDistributedMetaStorageBridge.iterate(InMemoryCachedDistributedMetaStorageBridge.java:87)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.iterate(DistributedMetaStorageImpl.java:542)
at
org.apache.ignite.internal.processors.metric.GridMetricManager$1.onReadyForRead(GridMetricManager.java:269)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.notifyReadyForRead(DistributedMetaStorageImpl.java:355)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.onMetaStorageReadyForRead(DistributedMetaStorageImpl.java:434)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.access$200(DistributedMetaStorageImpl.java:116)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl$2.onReadyForRead(DistributedMetaStorageImpl.java:259)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:430)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:877)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:3094)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1120)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1725)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1089)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:599)
at
org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
at
org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:74)
{noformat}
was:
There are no metric name validation when we perform hitrate and historgam
metrics configuration by means of control script, which can lead to
impossibility to restart persistent cluster.
How to reproduce:
# Start persistent cluster
# Just repeat commands from instructions:
https://ignite.apache.org/docs/latest/tools/control-script#metric-configure-command
{noformat}
control.sh —metric —configure-histogram histogram-metric-name 1,2,3
control.sh —metric —configure-hitrate hitrate-metric-name 1000
{noformat}
# Deactivate and restart cluster.
# Start cluster and nodes will fail with following error:
{noformat}
[12:44:18,713][SEVERE][main][IgniteKernal%myGrid1] Exception during start
processors, node will be stopped and close connections
java.lang.StringIndexOutOfBoundsException: begin 0, end -1, length 19
at java.base/java.lang.String.checkBoundsBeginEnd(String.java:4606)
at java.base/java.lang.String.substring(String.java:2709)
at
org.apache.ignite.internal.processors.metric.impl.MetricUtils.fromFullName(MetricUtils.java:72)
at
org.apache.ignite.internal.processors.metric.G
[jira] [Updated] (IGNITE-20201) Node failure when incorrect names are used for hitrate and histogram metrics configuration
[
https://issues.apache.org/jira/browse/IGNITE-20201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-20201:
---
Priority: Critical (was: Major)
> Node failure when incorrect names are used for hitrate and histogram metrics
> configuration
> --
>
> Key: IGNITE-20201
> URL: https://issues.apache.org/jira/browse/IGNITE-20201
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.15
>Reporter: Ilya Shishkov
>Priority: Critical
>
> There are no metric name validation when we perform hitrate and historgam
> metrics configuration by means of control script, which can lead to
> impossibility to restart persistent cluster.
> How to reproduce:
> # Start persistent cluster
> # Just repeat commands from instructions:
> https://ignite.apache.org/docs/latest/tools/control-script#metric-configure-command
> {noformat}
> control.sh —metric —configure-histogram histogram-metric-name 1,2,3
> control.sh —metric —configure-hitrate hitrate-metric-name 1000
> {noformat}
> # Deactivate and restart cluster.
> # Start cluster and nodes will fail with following error:
> {noformat}
> [12:44:18,713][SEVERE][main][IgniteKernal%myGrid1] Exception during start
> processors, node will be stopped and close connections
> java.lang.StringIndexOutOfBoundsException: begin 0, end -1, length 19
> at java.base/java.lang.String.checkBoundsBeginEnd(String.java:4606)
> at java.base/java.lang.String.substring(String.java:2709)
> at
> org.apache.ignite.internal.processors.metric.impl.MetricUtils.fromFullName(MetricUtils.java:72)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager.find(GridMetricManager.java:502)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager.onHitRateConfigChanged(GridMetricManager.java:462)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager.access$400(GridMetricManager.java:73)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager$1.lambda$onReadyForRead$0(GridMetricManager.java:269)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.InMemoryCachedDistributedMetaStorageBridge.iterate(InMemoryCachedDistributedMetaStorageBridge.java:87)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.iterate(DistributedMetaStorageImpl.java:542)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager$1.onReadyForRead(GridMetricManager.java:269)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.notifyReadyForRead(DistributedMetaStorageImpl.java:355)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.onMetaStorageReadyForRead(DistributedMetaStorageImpl.java:434)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.access$200(DistributedMetaStorageImpl.java:116)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl$2.onReadyForRead(DistributedMetaStorageImpl.java:259)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:430)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:877)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:3094)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1120)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1725)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1089)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:599)
> at
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
> at
> org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:74)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20201) Node failure when incorrect names are used for hitrate and histogram metrics configuration
[
https://issues.apache.org/jira/browse/IGNITE-20201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-20201:
---
Description:
There are no metric name validation when we perform hitrate and historgam
metrics configuration by means of control script, which can lead to
impossibility to restart persistent cluster.
How to reproduce:
# Start persistent cluster
# Just repeat commands from instructions:
https://ignite.apache.org/docs/latest/tools/control-script#metric-configure-command
{noformat}
control.sh —metric —configure-histogram histogram-metric-name 1,2,3
control.sh —metric —configure-hitrate hitrate-metric-name 1000
{noformat}
# Deactivate and restart cluster
# Start cluster and nodes will fail with following error:
{noformat}
[12:44:18,713][SEVERE][main][IgniteKernal%myGrid1] Exception during start
processors, node will be stopped and close connections
java.lang.StringIndexOutOfBoundsException: begin 0, end -1, length 19
at java.base/java.lang.String.checkBoundsBeginEnd(String.java:4606)
at java.base/java.lang.String.substring(String.java:2709)
at
org.apache.ignite.internal.processors.metric.impl.MetricUtils.fromFullName(MetricUtils.java:72)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.find(GridMetricManager.java:502)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.onHitRateConfigChanged(GridMetricManager.java:462)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.access$400(GridMetricManager.java:73)
at
org.apache.ignite.internal.processors.metric.GridMetricManager$1.lambda$onReadyForRead$0(GridMetricManager.java:269)
at
org.apache.ignite.internal.processors.metastorage.persistence.InMemoryCachedDistributedMetaStorageBridge.iterate(InMemoryCachedDistributedMetaStorageBridge.java:87)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.iterate(DistributedMetaStorageImpl.java:542)
at
org.apache.ignite.internal.processors.metric.GridMetricManager$1.onReadyForRead(GridMetricManager.java:269)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.notifyReadyForRead(DistributedMetaStorageImpl.java:355)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.onMetaStorageReadyForRead(DistributedMetaStorageImpl.java:434)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.access$200(DistributedMetaStorageImpl.java:116)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl$2.onReadyForRead(DistributedMetaStorageImpl.java:259)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:430)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:877)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:3094)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1120)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1725)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1089)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:599)
at
org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
at
org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:74)
{noformat}
was:
There are no metric name validation when we perform hitrate and historgam
metrics configuration by means of control script, which can lead to
impossibility to restart persistent cluster.
How to reproduce:
# Start persistent cluster
# Just repeat commands from instructions:
https://ignite.apache.org/docs/latest/tools/control-script#metric-configure-command
{noformat}
control.sh —metric —configure-histogram histogram-metric-name 1,2,3
control.sh —metric —configure-hitrate hitrate-metric-name 1000
{noformat}
# Deactivate and restart cluster
# Start cluster and nodes will fail with following error:
{nofromat}
[12:44:18,713][SEVERE][main][IgniteKernal%myGrid1] Exception during start
processors, node will be stopped and close connections
java.lang.StringIndexOutOfBoundsException: begin 0, end -1, length 19
at java.base/java.lang.String.checkBoundsBeginEnd(String.java:4606)
at java.base/java.lang.String.substring(String.java:2709)
at
org.apache.ignite.internal.processors.metric.impl.MetricUtils.fromFullName(MetricUtils.java:72)
at
org.apache.ignite.internal.processors.metric.GridMetricManage
[jira] [Created] (IGNITE-20201) Node failure when incorrect names are used for hitrate and histogram metrics configuration
Ilya Shishkov created IGNITE-20201:
--
Summary: Node failure when incorrect names are used for hitrate
and histogram metrics configuration
Key: IGNITE-20201
URL: https://issues.apache.org/jira/browse/IGNITE-20201
Project: Ignite
Issue Type: Improvement
Affects Versions: 2.15
Reporter: Ilya Shishkov
There are no metric name validation when we perform hitrate and historgam
metrics configuration by means of control script, which can lead to
impossibility to restart persistent cluster.
How to reproduce:
# Start persistent cluster
# Just repeat commands from instructions:
https://ignite.apache.org/docs/latest/tools/control-script#metric-configure-command
{noformat}
control.sh —metric —configure-histogram histogram-metric-name 1,2,3
control.sh —metric —configure-hitrate hitrate-metric-name 1000
{noformat}
# Deactivate and restart cluster
# Start cluster and nodes will fail with following error:
{nofromat}
[12:44:18,713][SEVERE][main][IgniteKernal%myGrid1] Exception during start
processors, node will be stopped and close connections
java.lang.StringIndexOutOfBoundsException: begin 0, end -1, length 19
at java.base/java.lang.String.checkBoundsBeginEnd(String.java:4606)
at java.base/java.lang.String.substring(String.java:2709)
at
org.apache.ignite.internal.processors.metric.impl.MetricUtils.fromFullName(MetricUtils.java:72)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.find(GridMetricManager.java:502)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.onHitRateConfigChanged(GridMetricManager.java:462)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.access$400(GridMetricManager.java:73)
at
org.apache.ignite.internal.processors.metric.GridMetricManager$1.lambda$onReadyForRead$0(GridMetricManager.java:269)
at
org.apache.ignite.internal.processors.metastorage.persistence.InMemoryCachedDistributedMetaStorageBridge.iterate(InMemoryCachedDistributedMetaStorageBridge.java:87)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.iterate(DistributedMetaStorageImpl.java:542)
at
org.apache.ignite.internal.processors.metric.GridMetricManager$1.onReadyForRead(GridMetricManager.java:269)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.notifyReadyForRead(DistributedMetaStorageImpl.java:355)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.onMetaStorageReadyForRead(DistributedMetaStorageImpl.java:434)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.access$200(DistributedMetaStorageImpl.java:116)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl$2.onReadyForRead(DistributedMetaStorageImpl.java:259)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:430)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:877)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:3094)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1120)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1725)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1089)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:599)
at
org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
at
org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:74)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20201) Node failure when incorrect names are used for hitrate and histogram metrics configuration
[
https://issues.apache.org/jira/browse/IGNITE-20201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-20201:
---
Description:
There are no metric name validation when we perform hitrate and historgam
metrics configuration by means of control script, which can lead to
impossibility to restart persistent cluster.
How to reproduce:
# Start persistent cluster
# Just repeat commands from instructions:
https://ignite.apache.org/docs/latest/tools/control-script#metric-configure-command
{noformat}
control.sh —metric —configure-histogram histogram-metric-name 1,2,3
control.sh —metric —configure-hitrate hitrate-metric-name 1000
{noformat}
# Deactivate and restart cluster.
# Start cluster and nodes will fail with following error:
{noformat}
[12:44:18,713][SEVERE][main][IgniteKernal%myGrid1] Exception during start
processors, node will be stopped and close connections
java.lang.StringIndexOutOfBoundsException: begin 0, end -1, length 19
at java.base/java.lang.String.checkBoundsBeginEnd(String.java:4606)
at java.base/java.lang.String.substring(String.java:2709)
at
org.apache.ignite.internal.processors.metric.impl.MetricUtils.fromFullName(MetricUtils.java:72)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.find(GridMetricManager.java:502)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.onHitRateConfigChanged(GridMetricManager.java:462)
at
org.apache.ignite.internal.processors.metric.GridMetricManager.access$400(GridMetricManager.java:73)
at
org.apache.ignite.internal.processors.metric.GridMetricManager$1.lambda$onReadyForRead$0(GridMetricManager.java:269)
at
org.apache.ignite.internal.processors.metastorage.persistence.InMemoryCachedDistributedMetaStorageBridge.iterate(InMemoryCachedDistributedMetaStorageBridge.java:87)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.iterate(DistributedMetaStorageImpl.java:542)
at
org.apache.ignite.internal.processors.metric.GridMetricManager$1.onReadyForRead(GridMetricManager.java:269)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.notifyReadyForRead(DistributedMetaStorageImpl.java:355)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.onMetaStorageReadyForRead(DistributedMetaStorageImpl.java:434)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.access$200(DistributedMetaStorageImpl.java:116)
at
org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl$2.onReadyForRead(DistributedMetaStorageImpl.java:259)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:430)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:877)
at
org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:3094)
at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1120)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1725)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1089)
at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:599)
at
org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
at
org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:74)
{noformat}
was:
There are no metric name validation when we perform hitrate and historgam
metrics configuration by means of control script, which can lead to
impossibility to restart persistent cluster.
How to reproduce:
# Start persistent cluster
# Just repeat commands from instructions:
https://ignite.apache.org/docs/latest/tools/control-script#metric-configure-command
{noformat}
control.sh —metric —configure-histogram histogram-metric-name 1,2,3
control.sh —metric —configure-hitrate hitrate-metric-name 1000
{noformat}
# Deactivate and restart cluster
# Start cluster and nodes will fail with following error:
{noformat}
[12:44:18,713][SEVERE][main][IgniteKernal%myGrid1] Exception during start
processors, node will be stopped and close connections
java.lang.StringIndexOutOfBoundsException: begin 0, end -1, length 19
at java.base/java.lang.String.checkBoundsBeginEnd(String.java:4606)
at java.base/java.lang.String.substring(String.java:2709)
at
org.apache.ignite.internal.processors.metric.impl.MetricUtils.fromFullName(MetricUtils.java:72)
at
org.apache.ignite.internal.processors.metric.GridMetricManag
[jira] [Updated] (IGNITE-20201) Node failure when incorrect names are used for hitrate and histogram metrics configuration
[
https://issues.apache.org/jira/browse/IGNITE-20201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-20201:
---
Issue Type: Bug (was: Improvement)
> Node failure when incorrect names are used for hitrate and histogram metrics
> configuration
> --
>
> Key: IGNITE-20201
> URL: https://issues.apache.org/jira/browse/IGNITE-20201
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.15
>Reporter: Ilya Shishkov
>Priority: Major
>
> There are no metric name validation when we perform hitrate and historgam
> metrics configuration by means of control script, which can lead to
> impossibility to restart persistent cluster.
> How to reproduce:
> # Start persistent cluster
> # Just repeat commands from instructions:
> https://ignite.apache.org/docs/latest/tools/control-script#metric-configure-command
> {noformat}
> control.sh —metric —configure-histogram histogram-metric-name 1,2,3
> control.sh —metric —configure-hitrate hitrate-metric-name 1000
> {noformat}
> # Deactivate and restart cluster
> # Start cluster and nodes will fail with following error:
> {nofromat}
> [12:44:18,713][SEVERE][main][IgniteKernal%myGrid1] Exception during start
> processors, node will be stopped and close connections
> java.lang.StringIndexOutOfBoundsException: begin 0, end -1, length 19
> at java.base/java.lang.String.checkBoundsBeginEnd(String.java:4606)
> at java.base/java.lang.String.substring(String.java:2709)
> at
> org.apache.ignite.internal.processors.metric.impl.MetricUtils.fromFullName(MetricUtils.java:72)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager.find(GridMetricManager.java:502)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager.onHitRateConfigChanged(GridMetricManager.java:462)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager.access$400(GridMetricManager.java:73)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager$1.lambda$onReadyForRead$0(GridMetricManager.java:269)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.InMemoryCachedDistributedMetaStorageBridge.iterate(InMemoryCachedDistributedMetaStorageBridge.java:87)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.iterate(DistributedMetaStorageImpl.java:542)
> at
> org.apache.ignite.internal.processors.metric.GridMetricManager$1.onReadyForRead(GridMetricManager.java:269)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.notifyReadyForRead(DistributedMetaStorageImpl.java:355)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.onMetaStorageReadyForRead(DistributedMetaStorageImpl.java:434)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl.access$200(DistributedMetaStorageImpl.java:116)
> at
> org.apache.ignite.internal.processors.metastorage.persistence.DistributedMetaStorageImpl$2.onReadyForRead(DistributedMetaStorageImpl.java:259)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetastorageReadyForRead(GridCacheDatabaseSharedManager.java:430)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.readMetastore(GridCacheDatabaseSharedManager.java:877)
> at
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.notifyMetaStorageSubscribersOnReadyForRead(GridCacheDatabaseSharedManager.java:3094)
> at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1120)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1725)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1647)
> at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1089)
> at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:599)
> at
> org.apache.ignite.internal.processors.platform.PlatformAbstractBootstrap.start(PlatformAbstractBootstrap.java:43)
> at
> org.apache.ignite.internal.processors.platform.PlatformIgnition.start(PlatformIgnition.java:74)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20200) Muted tests on TC lead to failed builds
[ https://issues.apache.org/jira/browse/IGNITE-20200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753255#comment-17753255 ] Pavel Tupitsyn commented on IGNITE-20200: - Merged to main: 027bdd16819ff8a6d811b6cba836652b28592e0b > Muted tests on TC lead to failed builds > --- > > Key: IGNITE-20200 > URL: https://issues.apache.org/jira/browse/IGNITE-20200 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > When a faulty unit test is muted on TC, it still gets executed by Gradle and > is interpreted as failed, which fails the whole unit tests build even though > TC treats this failure as muted. It is proposed to make Gradle ignore unit > test failures, which are instead going to be handled by TC. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20200) Muted tests on TC lead to failed builds
[ https://issues.apache.org/jira/browse/IGNITE-20200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20200: Fix Version/s: 3.0.0-beta2 > Muted tests on TC lead to failed builds > --- > > Key: IGNITE-20200 > URL: https://issues.apache.org/jira/browse/IGNITE-20200 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > When a faulty unit test is muted on TC, it still gets executed by Gradle and > is interpreted as failed, which fails the whole unit tests build even though > TC treats this failure as muted. It is proposed to make Gradle ignore unit > test failures, which are instead going to be handled by TC. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-20165) Revisit the configuration of thread pools used by JRaft
[ https://issues.apache.org/jira/browse/IGNITE-20165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753233#comment-17753233 ] Mirza Aliev edited comment on IGNITE-20165 at 8/11/23 2:51 PM: --- By default, all executors are shared among the instance of Loza, meaning that all raft groups share executors. Below I've represented all JRaft executors with short description and the number of threads ||Pool name||Description||Number of Threads|| |JRaft-Common-Executor|A pool for processing short-lived asynchronous tasks. Should never be blocked.|Utils.cpus() (core == max)| |JRaft-Node-Scheduler|A scheduled executor for running delayed or repeating tasks.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |JRaft-Request-Processor|A default pool for handling RAFT requests. Should never be blocked.|Utils.cpus() * 6 (core == max)| |JRaft-Response-Processor|A default pool for handling RAFT responses. Should never be blocked.|80 (core == max/3, workQueue == 1)| |JRaft-AppendEntries-Processor|A pool of single thread executors. Used only if a replication pipelining is enabled. Handles append entries requests and responses (used by the replication flow). Threads are started on demand. Each replication pair (leader-follower) uses dedicated single thread executor from the pool, so all messages between replication peer pairs are processed sequentially.|SystemPropertyUtil.getInt( "jraft.append.entries.threads.send", Math.max(16, Ints.findNextPositivePowerOfTwo(cpus() * 2)));| |NodeImpl-Disruptor|A striped disruptor for batching FSM (finite state machine) user tasks.|DEFAULT_STRIPES = Utils.cpus() * 2| |ReadOnlyService-Disruptor|A striped disruptor for batching read requests before doing read index request.|DEFAULT_STRIPES = Utils.cpus() * 2| |LogManager-Disruptor|A striped disruptor for delivering log entries to a storage.|DEFAULT_STRIPES = Utils.cpus() * 2| |FSMCaller-Disruptor|A striped disruptor for FSM callbacks.|DEFAULT_STRIPES = Utils.cpus() * 2| |SnapshotTimer|A timer for periodic snapshot creation.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |ElectionTimer|A timer to handle election timeout on followers.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |VoteTimer|A timer to handle vote timeout when a leader was not confirmed by majority.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |StepDownTimer|A timer to process leader step down condition.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| was (Author: maliev): By default, all executors are shared among the instance of Loza, meaning that all groups share executors ||Pool name||Description||Number of Threads|| |JRaft-Common-Executor|A pool for processing short-lived asynchronous tasks. Should never be blocked.|Utils.cpus() (core == max)| |JRaft-Node-Scheduler|A scheduled executor for running delayed or repeating tasks.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |JRaft-Request-Processor|A default pool for handling RAFT requests. Should never be blocked.|Utils.cpus() * 6 (core == max)| |JRaft-Response-Processor|A default pool for handling RAFT responses. Should never be blocked.|80 (core == max/3, workQueue == 1)| |JRaft-AppendEntries-Processor|A pool of single thread executors. Used only if a replication pipelining is enabled. Handles append entries requests and responses (used by the replication flow). Threads are started on demand. Each replication pair (leader-follower) uses dedicated single thread executor from the pool, so all messages between replication peer pairs are processed sequentially.|SystemPropertyUtil.getInt( "jraft.append.entries.threads.send", Math.max(16, Ints.findNextPositivePowerOfTwo(cpus() * 2)));| |NodeImpl-Disruptor|A striped disruptor for batching FSM (finite state machine) user tasks.|DEFAULT_STRIPES = Utils.cpus() * 2| |ReadOnlyService-Disruptor|A striped disruptor for batching read requests before doing read index request.|DEFAULT_STRIPES = Utils.cpus() * 2| |LogManager-Disruptor|A striped disruptor for delivering log entries to a storage.|DEFAULT_STRIPES = Utils.cpus() * 2| |FSMCaller-Disruptor|A striped disruptor for FSM callbacks.|DEFAULT_STRIPES = Utils.cpus() * 2| |SnapshotTimer|A timer for periodic snapshot creation.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |ElectionTimer|A timer to handle election timeout on followers.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |VoteTimer|A timer to handle vote timeout when a leader was not confirmed by majority.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |StepDownTimer|A timer to process leader step down condition.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| > Revisit the configuration of thread pools used by JRaft > --
[jira] [Created] (IGNITE-20200) Muted tests on TC lead to failed builds
Aleksandr Polovtcev created IGNITE-20200: Summary: Muted tests on TC lead to failed builds Key: IGNITE-20200 URL: https://issues.apache.org/jira/browse/IGNITE-20200 Project: Ignite Issue Type: Task Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev When a faulty unit test is muted on TC, it still gets executed by Gradle and is interpreted as failed, which fails the whole unit tests build even though TC treats this failure as muted. It is proposed to make Gradle ignore unit test failures, which are instead going to be handled by TC. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20200) Muted tests on TC lead to failed builds
[ https://issues.apache.org/jira/browse/IGNITE-20200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-20200: - Ignite Flags: (was: Docs Required,Release Notes Required) > Muted tests on TC lead to failed builds > --- > > Key: IGNITE-20200 > URL: https://issues.apache.org/jira/browse/IGNITE-20200 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > > When a faulty unit test is muted on TC, it still gets executed by Gradle and > is interpreted as failed, which fails the whole unit tests build even though > TC treats this failure as muted. It is proposed to make Gradle ignore unit > test failures, which are instead going to be handled by TC. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20200) Muted tests on TC lead to failed builds
[ https://issues.apache.org/jira/browse/IGNITE-20200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-20200: - Labels: ignite-3 (was: ) > Muted tests on TC lead to failed builds > --- > > Key: IGNITE-20200 > URL: https://issues.apache.org/jira/browse/IGNITE-20200 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > > When a faulty unit test is muted on TC, it still gets executed by Gradle and > is interpreted as failed, which fails the whole unit tests build even though > TC treats this failure as muted. It is proposed to make Gradle ignore unit > test failures, which are instead going to be handled by TC. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-20165) Revisit the configuration of thread pools used by JRaft
[ https://issues.apache.org/jira/browse/IGNITE-20165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753233#comment-17753233 ] Mirza Aliev edited comment on IGNITE-20165 at 8/11/23 2:35 PM: --- By default, all executors are shared among the instance of Loza, meaning that all groups share executors ||Pool name||Description||Number of Threads|| |JRaft-Common-Executor|A pool for processing short-lived asynchronous tasks. Should never be blocked.|Utils.cpus() (core == max)| |JRaft-Node-Scheduler|A scheduled executor for running delayed or repeating tasks.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |JRaft-Request-Processor|A default pool for handling RAFT requests. Should never be blocked.|Utils.cpus() * 6 (core == max)| |JRaft-Response-Processor|A default pool for handling RAFT responses. Should never be blocked.|80 (core == max/3, workQueue == 1)| |JRaft-AppendEntries-Processor|A pool of single thread executors. Used only if a replication pipelining is enabled. Handles append entries requests and responses (used by the replication flow). Threads are started on demand. Each replication pair (leader-follower) uses dedicated single thread executor from the pool, so all messages between replication peer pairs are processed sequentially.|SystemPropertyUtil.getInt( "jraft.append.entries.threads.send", Math.max(16, Ints.findNextPositivePowerOfTwo(cpus() * 2)));| |NodeImpl-Disruptor|A striped disruptor for batching FSM (finite state machine) user tasks.|DEFAULT_STRIPES = Utils.cpus() * 2| |ReadOnlyService-Disruptor|A striped disruptor for batching read requests before doing read index request.|DEFAULT_STRIPES = Utils.cpus() * 2| |LogManager-Disruptor|A striped disruptor for delivering log entries to a storage.|DEFAULT_STRIPES = Utils.cpus() * 2| |FSMCaller-Disruptor|A striped disruptor for FSM callbacks.|DEFAULT_STRIPES = Utils.cpus() * 2| |SnapshotTimer|A timer for periodic snapshot creation.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |ElectionTimer|A timer to handle election timeout on followers.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |VoteTimer|A timer to handle vote timeout when a leader was not confirmed by majority.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |StepDownTimer|A timer to process leader step down condition.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| was (Author: maliev): By default, all executors are shared among the instance of Loza, meaning that all groups share executors ||Pool name||Description||Number of Threads|| |JRaft-Common-Executor|A pool for processing short-lived asynchronous tasks. Should never be blocked.|Utils.cpus() (core == max)| |JRaft-Node-Scheduler|A scheduled executor for running delayed or repeating tasks.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |JRaft-Request-Processor|A default pool for handling RAFT requests. Should never be blocked.|Utils.cpus() * 6 (core == max)| |JRaft-Response-Processor|A default pool for handling RAFT responses. Should never be blocked.|80 (core == max/3)| |JRaft-AppendEntries-Processor|A pool of single thread executors. Used only if a replication pipelining is enabled. Handles append entries requests and responses (used by the replication flow). Threads are started on demand. Each replication pair (leader-follower) uses dedicated single thread executor from the pool, so all messages between replication peer pairs are processed sequentially.|SystemPropertyUtil.getInt( "jraft.append.entries.threads.send", Math.max(16, Ints.findNextPositivePowerOfTwo(cpus() * 2)));| |NodeImpl-Disruptor|A striped disruptor for batching FSM (finite state machine) user tasks.|DEFAULT_STRIPES = Utils.cpus() * 2| |ReadOnlyService-Disruptor|A striped disruptor for batching read requests before doing read index request.|DEFAULT_STRIPES = Utils.cpus() * 2| |LogManager-Disruptor|A striped disruptor for delivering log entries to a storage.|DEFAULT_STRIPES = Utils.cpus() * 2| |FSMCaller-Disruptor|A striped disruptor for FSM callbacks.|DEFAULT_STRIPES = Utils.cpus() * 2| |SnapshotTimer|A timer for periodic snapshot creation.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |ElectionTimer|A timer to handle election timeout on followers.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |VoteTimer|A timer to handle vote timeout when a leader was not confirmed by majority.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |StepDownTimer|A timer to process leader step down condition.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| > Revisit the configuration of thread pools used by JRaft > --- > > Key: IGNITE-20165 > URL: https://issues.apache.org/jira/
[jira] [Updated] (IGNITE-20199) Do not return updating rebalance assignments futures in DistributionZoneRebalanceEngine#onUpdateReplicas
[
https://issues.apache.org/jira/browse/IGNITE-20199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-20199:
-
Summary: Do not return updating rebalance assignments futures in
DistributionZoneRebalanceEngine#onUpdateReplicas (was: Do not return updating
rebalance assignments future in
DistributionZoneRebalanceEngine#onUpdateReplicas )
> Do not return updating rebalance assignments futures in
> DistributionZoneRebalanceEngine#onUpdateReplicas
> -
>
> Key: IGNITE-20199
> URL: https://issues.apache.org/jira/browse/IGNITE-20199
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> Seems that the current logic in
> {{DistributionZoneRebalanceEngine#onUpdateReplicas}} is not correct in terms
> of futures chaining. Currently we block configuration notification thread
> until all partitions would updates theirs rebalance assignments keys in
> metastorage.
>
> {code:java}
> private CompletableFuture
> onUpdateReplicas(ConfigurationNotificationEvent replicasCtx) {
> ...
> ...
> return
> distributionZoneManager.dataNodes(replicasCtx.storageRevision(),
> zoneCfg.zoneId())
> .thenCompose(dataNodes -> {
> ...
> for (TableView tableCfg : tableViews) {
>...
> CompletableFuture[] partitionFutures =
> RebalanceUtil.triggerAllTablePartitionsRebalance(...);
> tableFutures.add(allOf(partitionFutures));
> }
> return
> allOf(tableFutures.toArray(CompletableFuture[]::new));
> });
> ...
> } {code}
> As a solution, we could just return completed future in the
> {{DistributionZoneRebalanceEngine#onUpdateReplicas}} after we started
> asynchronous logic of updating rebalance assignmnets.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20199) Do not return updating rebalance assignments future in DistributionZoneRebalanceEngine#onUpdateReplicas
[
https://issues.apache.org/jira/browse/IGNITE-20199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-20199:
-
Summary: Do not return updating rebalance assignments future in
DistributionZoneRebalanceEngine#onUpdateReplicas (was: Do not chain updating
rebalance assignments future in
DistributionZoneRebalanceEngine#onUpdateReplicas )
> Do not return updating rebalance assignments future in
> DistributionZoneRebalanceEngine#onUpdateReplicas
>
>
> Key: IGNITE-20199
> URL: https://issues.apache.org/jira/browse/IGNITE-20199
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> Seems that the current logic in
> {{DistributionZoneRebalanceEngine#onUpdateReplicas}} is not correct in terms
> of futures chaining. Currently we block configuration notification thread
> until all partitions would updates theirs rebalance assignments keys in
> metastorage.
>
> {code:java}
> private CompletableFuture
> onUpdateReplicas(ConfigurationNotificationEvent replicasCtx) {
> ...
> ...
> return
> distributionZoneManager.dataNodes(replicasCtx.storageRevision(),
> zoneCfg.zoneId())
> .thenCompose(dataNodes -> {
> ...
> for (TableView tableCfg : tableViews) {
>...
> CompletableFuture[] partitionFutures =
> RebalanceUtil.triggerAllTablePartitionsRebalance(...);
> tableFutures.add(allOf(partitionFutures));
> }
> return
> allOf(tableFutures.toArray(CompletableFuture[]::new));
> });
> ...
> } {code}
> As a solution, we could just return completed future in the
> {{DistributionZoneRebalanceEngine#onUpdateReplicas}} after we started
> asynchronous logic of updating rebalance assignmnets.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20199) Do not chain updating rebalance assignments future in DistributionZoneRebalanceEngine#onUpdateReplicas
[
https://issues.apache.org/jira/browse/IGNITE-20199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-20199:
-
Description:
Seems that the current logic in
{{DistributionZoneRebalanceEngine#onUpdateReplicas}} is not correct in terms of
futures chaining. Currently we block configuration notification thread until
all partitions would updates theirs rebalance assignments keys in metastorage.
{code:java}
private CompletableFuture
onUpdateReplicas(ConfigurationNotificationEvent replicasCtx) {
...
...
return distributionZoneManager.dataNodes(replicasCtx.storageRevision(),
zoneCfg.zoneId())
.thenCompose(dataNodes -> {
...
for (TableView tableCfg : tableViews) {
...
CompletableFuture[] partitionFutures =
RebalanceUtil.triggerAllTablePartitionsRebalance(...);
tableFutures.add(allOf(partitionFutures));
}
return
allOf(tableFutures.toArray(CompletableFuture[]::new));
});
...
} {code}
As a solution, we could just return completed future in the
{{DistributionZoneRebalanceEngine#onUpdateReplicas}} after we started
asynchronous logic of updating rebalance assignmnets.
was:
After IGNITE-19506 was merged, it added the regression.
Previously we haven't returned future, that updates rebalance pending keys, in
{{{}DistributionZoneRebalanceEngine#onUpdateReplicas{}}}. It was done because
otherwise we would block configuration notification thread until all partitions
would updates theirs rebalance assignments keys in metastorage.
Unfortunately, IGNITE-19506 has brought this blockage
{code:java}
private CompletableFuture
onUpdateReplicas(ConfigurationNotificationEvent replicasCtx) {
...
...
return distributionZoneManager.dataNodes(replicasCtx.storageRevision(),
zoneCfg.zoneId())
.thenCompose(dataNodes -> {
...
for (TableView tableCfg : tableViews) {
...
CompletableFuture[] partitionFutures =
RebalanceUtil.triggerAllTablePartitionsRebalance(...);
tableFutures.add(allOf(partitionFutures));
}
return
allOf(tableFutures.toArray(CompletableFuture[]::new));
});
...
} {code}
> Do not chain updating rebalance assignments future in
> DistributionZoneRebalanceEngine#onUpdateReplicas
> ---
>
> Key: IGNITE-20199
> URL: https://issues.apache.org/jira/browse/IGNITE-20199
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> Seems that the current logic in
> {{DistributionZoneRebalanceEngine#onUpdateReplicas}} is not correct in terms
> of futures chaining. Currently we block configuration notification thread
> until all partitions would updates theirs rebalance assignments keys in
> metastorage.
>
> {code:java}
> private CompletableFuture
> onUpdateReplicas(ConfigurationNotificationEvent replicasCtx) {
> ...
> ...
> return
> distributionZoneManager.dataNodes(replicasCtx.storageRevision(),
> zoneCfg.zoneId())
> .thenCompose(dataNodes -> {
> ...
> for (TableView tableCfg : tableViews) {
>...
> CompletableFuture[] partitionFutures =
> RebalanceUtil.triggerAllTablePartitionsRebalance(...);
> tableFutures.add(allOf(partitionFutures));
> }
> return
> allOf(tableFutures.toArray(CompletableFuture[]::new));
> });
> ...
> } {code}
> As a solution, we could just return completed future in the
> {{DistributionZoneRebalanceEngine#onUpdateReplicas}} after we started
> asynchronous logic of updating rebalance assignmnets.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20053) Empty data nodes are returned by data nodes engine
[
https://issues.apache.org/jira/browse/IGNITE-20053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753243#comment-17753243
]
Kirill Gusakov commented on IGNITE-20053:
-
LGTM
> Empty data nodes are returned by data nodes engine
> --
>
> Key: IGNITE-20053
> URL: https://issues.apache.org/jira/browse/IGNITE-20053
> Project: Ignite
> Issue Type: Bug
>Reporter: Denis Chudov
>Assignee: Alexander Lapin
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There is a meta storage key called DISTRIBUTION_ZONES_LOGICAL_TOPOLOGY_KEY
> and it is refreshed by topology listener on topology events and stores
> logical topology. If the value stored by this key is null, then empty data
> nodes are returned from data nodes engine on data nodes calculation for a
> distribution zone. As a result, empty assignments are calculated for
> partitions, which leads to exception described in IGNITE-19466.
> Some integration tests, for example, ItRebalanceDistributedTest are flaky
> because of possible problems with value of
> DISTRIBUTION_ZONES_LOGICAL_TOPOLOGY_KEY and empty data nodes calculated by
> data nodes engine.
> Actually, the empty data nodes collection is a wrong result for this case
> because the current logical topology is not empty.
> h3. UPD #1
> *1.* The reason for empty data nodes assertion is race between join
> completion and thus firing logical topology updates and DZM start. Literally,
> it's required to put
> {code:java}
> nodes.stream().forEach(Node::waitWatches); {code}
> before
> {code:java}
> assertThat(
> allOf(nodes.get(0).cmgManager.onJoinReady(),
> nodes.get(1).cmgManager.onJoinReady(), nodes.get(2).cmgManager.onJoinReady()),
> willCompleteSuccessfully()
> ); {code}
> in
> org.apache.ignite.internal.configuration.storage.ItRebalanceDistributedTest#before.
>
> *2.* However, that's not the whole story. We also faced
> {code:java}
> Unable to initialize the cluster: null{code}
> because cmg init failed with TimeoutException because we start CMGManager
> asynchronously, which is incorrect. So if we move cmgManager to
> firstComponents that will solve the issue.
> {code:java}
> List firstComponents = List.of(
> vaultManager,
> nodeCfgMgr,
> clusterService,
> raftManager,
> cmgManager
> ); {code}
>
> *3.* Still it's not the whole story. testTwoQueuedRebalances failed because
> we didn't retrieved an expected stable assignments after table creation
> {code:java}
> await(nodes.get(0).tableManager.createTableAsync(
> "TBL1",
> ZONE_1_NAME,
> tblChanger -> SchemaConfigurationConverter.convert(schTbl1,
> tblChanger)
> ));
> assertEquals(1, getPartitionClusterNodes(0, 0).size());{code}
> The reason for that is that assignments calculation is an async process, so
> there are no guarantees that we will retrieve proper assignments right after
> table creation completes. So we might substitute
> {code:java}
> assertEquals(1, getPartitionClusterNodes(0, 0).size());{code}
> with
> {code:java}
> assertTrue(waitForCondition(() -> getPartitionClusterNodes(0, 0).size() == 1,
> 10_000));{code}
> Please pay attention that there are multiple places where we retrieve
> assignments and expect them to be ready.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20199) Do not chain updating rebalance assignments future in DistributionZoneRebalanceEngine#onUpdateReplicas
[
https://issues.apache.org/jira/browse/IGNITE-20199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-20199:
-
Description:
After IGNITE-19506 was merged, it added the regression.
Previously we haven't returned future, that updates rebalance pending keys, in
{{{}DistributionZoneRebalanceEngine#onUpdateReplicas{}}}. It was done because
otherwise we would block configuration notification thread until all partitions
would updates theirs rebalance assignments keys in metastorage.
Unfortunately, IGNITE-19506 has brought this blockage
{code:java}
private CompletableFuture
onUpdateReplicas(ConfigurationNotificationEvent replicasCtx) {
...
...
return distributionZoneManager.dataNodes(replicasCtx.storageRevision(),
zoneCfg.zoneId())
.thenCompose(dataNodes -> {
...
for (TableView tableCfg : tableViews) {
...
CompletableFuture[] partitionFutures =
RebalanceUtil.triggerAllTablePartitionsRebalance(...);
tableFutures.add(allOf(partitionFutures));
}
return
allOf(tableFutures.toArray(CompletableFuture[]::new));
});
...
} {code}
was:
After IGNITE-19506 was merged, it added the regression.
Previously we haven't returned future, that updates rebalance pending keys, in
{{{}DistributionZoneRebalanceEngine#onUpdateReplicas{}}}. It was done because
otherwise we would block configuration notification thread until all partitions
would updates theirs rebalance assignments keys in metastorage.
Unfortunately, IGNITE-19506 has brought this blockage
{code:java}
private CompletableFuture
onUpdateReplicas(ConfigurationNotificationEvent replicasCtx) {
...
...
return distributionZoneManager.dataNodes(replicasCtx.storageRevision(),
zoneCfg.zoneId())
.thenCompose(dataNodes -> {
...
for (TableView tableCfg : tableViews) {
...
CompletableFuture[] partitionFutures =
RebalanceUtil.triggerAllTablePartitionsRebalance(...);
tableFutures.add(allOf(partitionFutures));
}
return
allOf(tableFutures.toArray(CompletableFuture[]::new));
});
} finally {
busyLock.leaveBusy();
}
} {code}
> Do not chain updating rebalance assignments future in
> DistributionZoneRebalanceEngine#onUpdateReplicas
> ---
>
> Key: IGNITE-20199
> URL: https://issues.apache.org/jira/browse/IGNITE-20199
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> After IGNITE-19506 was merged, it added the regression.
> Previously we haven't returned future, that updates rebalance pending keys,
> in {{{}DistributionZoneRebalanceEngine#onUpdateReplicas{}}}. It was done
> because otherwise we would block configuration notification thread until all
> partitions would updates theirs rebalance assignments keys in metastorage.
>
> Unfortunately, IGNITE-19506 has brought this blockage
>
> {code:java}
> private CompletableFuture
> onUpdateReplicas(ConfigurationNotificationEvent replicasCtx) {
> ...
> ...
> return
> distributionZoneManager.dataNodes(replicasCtx.storageRevision(),
> zoneCfg.zoneId())
> .thenCompose(dataNodes -> {
> ...
> for (TableView tableCfg : tableViews) {
>...
> CompletableFuture[] partitionFutures =
> RebalanceUtil.triggerAllTablePartitionsRebalance(...);
> tableFutures.add(allOf(partitionFutures));
> }
> return
> allOf(tableFutures.toArray(CompletableFuture[]::new));
> });
> ...
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20199) Do not chain updating rebalance assignments future in DistributionZoneRebalanceEngine#onUpdateReplicas
Mirza Aliev created IGNITE-20199:
Summary: Do not chain updating rebalance assignments future in
DistributionZoneRebalanceEngine#onUpdateReplicas
Key: IGNITE-20199
URL: https://issues.apache.org/jira/browse/IGNITE-20199
Project: Ignite
Issue Type: Bug
Reporter: Mirza Aliev
After IGNITE-19506 was merged, it added the regression.
Previously we haven't returned future, that updates rebalance pending keys, in
\{{DistributionZoneRebalanceEngine#onUpdateReplicas}}. It was done because
otherwise we would block configuration notification thread until all partitions
would updates theirs rebalance assignments keys in metastorage.
Unfortunately, IGNITE-19506 has brought this blockage
{code:java}
private CompletableFuture
onUpdateReplicas(ConfigurationNotificationEvent replicasCtx) {
...
...
return distributionZoneManager.dataNodes(replicasCtx.storageRevision(),
zoneCfg.zoneId())
.thenCompose(dataNodes -> {
...
for (TableView tableCfg : tableViews) {
...
CompletableFuture[] partitionFutures =
RebalanceUtil.triggerAllTablePartitionsRebalance(
tableDescriptor,
zoneDescriptor,
dataNodes,
replicasCtx.storageRevision(),
metaStorageManager
);
tableFutures.add(allOf(partitionFutures));
}
return
allOf(tableFutures.toArray(CompletableFuture[]::new));
});
} finally {
busyLock.leaveBusy();
}
} {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20199) Do not chain updating rebalance assignments future in DistributionZoneRebalanceEngine#onUpdateReplicas
[
https://issues.apache.org/jira/browse/IGNITE-20199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-20199:
-
Description:
After IGNITE-19506 was merged, it added the regression.
Previously we haven't returned future, that updates rebalance pending keys, in
{{{}DistributionZoneRebalanceEngine#onUpdateReplicas{}}}. It was done because
otherwise we would block configuration notification thread until all partitions
would updates theirs rebalance assignments keys in metastorage.
Unfortunately, IGNITE-19506 has brought this blockage
{code:java}
private CompletableFuture
onUpdateReplicas(ConfigurationNotificationEvent replicasCtx) {
...
...
return distributionZoneManager.dataNodes(replicasCtx.storageRevision(),
zoneCfg.zoneId())
.thenCompose(dataNodes -> {
...
for (TableView tableCfg : tableViews) {
...
CompletableFuture[] partitionFutures =
RebalanceUtil.triggerAllTablePartitionsRebalance(...);
tableFutures.add(allOf(partitionFutures));
}
return
allOf(tableFutures.toArray(CompletableFuture[]::new));
});
} finally {
busyLock.leaveBusy();
}
} {code}
was:
After IGNITE-19506 was merged, it added the regression.
Previously we haven't returned future, that updates rebalance pending keys, in
\{{DistributionZoneRebalanceEngine#onUpdateReplicas}}. It was done because
otherwise we would block configuration notification thread until all partitions
would updates theirs rebalance assignments keys in metastorage.
Unfortunately, IGNITE-19506 has brought this blockage
{code:java}
private CompletableFuture
onUpdateReplicas(ConfigurationNotificationEvent replicasCtx) {
...
...
return distributionZoneManager.dataNodes(replicasCtx.storageRevision(),
zoneCfg.zoneId())
.thenCompose(dataNodes -> {
...
for (TableView tableCfg : tableViews) {
...
CompletableFuture[] partitionFutures =
RebalanceUtil.triggerAllTablePartitionsRebalance(
tableDescriptor,
zoneDescriptor,
dataNodes,
replicasCtx.storageRevision(),
metaStorageManager
);
tableFutures.add(allOf(partitionFutures));
}
return
allOf(tableFutures.toArray(CompletableFuture[]::new));
});
} finally {
busyLock.leaveBusy();
}
} {code}
> Do not chain updating rebalance assignments future in
> DistributionZoneRebalanceEngine#onUpdateReplicas
> ---
>
> Key: IGNITE-20199
> URL: https://issues.apache.org/jira/browse/IGNITE-20199
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> After IGNITE-19506 was merged, it added the regression.
> Previously we haven't returned future, that updates rebalance pending keys,
> in {{{}DistributionZoneRebalanceEngine#onUpdateReplicas{}}}. It was done
> because otherwise we would block configuration notification thread until all
> partitions would updates theirs rebalance assignments keys in metastorage.
>
> Unfortunately, IGNITE-19506 has brought this blockage
>
> {code:java}
> private CompletableFuture
> onUpdateReplicas(ConfigurationNotificationEvent replicasCtx) {
> ...
> ...
> return
> distributionZoneManager.dataNodes(replicasCtx.storageRevision(),
> zoneCfg.zoneId())
> .thenCompose(dataNodes -> {
> ...
> for (TableView tableCfg : tableViews) {
>...
> CompletableFuture[] partitionFutures =
> RebalanceUtil.triggerAllTablePartitionsRebalance(...);
> tableFutures.add(allOf(partitionFutures));
> }
> return
> allOf(tableFutures.toArray(CompletableFuture[]::new));
> });
> } finally {
> busyLock.leaveBusy();
> }
> } {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-20165) Revisit the configuration of thread pools used by JRaft
[ https://issues.apache.org/jira/browse/IGNITE-20165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753233#comment-17753233 ] Mirza Aliev edited comment on IGNITE-20165 at 8/11/23 2:00 PM: --- By default, all executors are shared among the instance of Loza, meaning that all groups share executors ||Pool name||Description||Number of Threads|| |JRaft-Common-Executor|A pool for processing short-lived asynchronous tasks. Should never be blocked.|Utils.cpus() (core == max)| |JRaft-Node-Scheduler|A scheduled executor for running delayed or repeating tasks.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |JRaft-Request-Processor|A default pool for handling RAFT requests. Should never be blocked.|Utils.cpus() * 6 (core == max)| |JRaft-Response-Processor|A default pool for handling RAFT responses. Should never be blocked.|80 (core == max/3)| |JRaft-AppendEntries-Processor|A pool of single thread executors. Used only if a replication pipelining is enabled. Handles append entries requests and responses (used by the replication flow). Threads are started on demand. Each replication pair (leader-follower) uses dedicated single thread executor from the pool, so all messages between replication peer pairs are processed sequentially.|SystemPropertyUtil.getInt( "jraft.append.entries.threads.send", Math.max(16, Ints.findNextPositivePowerOfTwo(cpus() * 2)));| |NodeImpl-Disruptor|A striped disruptor for batching FSM (finite state machine) user tasks.|DEFAULT_STRIPES = Utils.cpus() * 2| |ReadOnlyService-Disruptor|A striped disruptor for batching read requests before doing read index request.|DEFAULT_STRIPES = Utils.cpus() * 2| |LogManager-Disruptor|A striped disruptor for delivering log entries to a storage.|DEFAULT_STRIPES = Utils.cpus() * 2| |FSMCaller-Disruptor|A striped disruptor for FSM callbacks.|DEFAULT_STRIPES = Utils.cpus() * 2| |SnapshotTimer|A timer for periodic snapshot creation.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |ElectionTimer|A timer to handle election timeout on followers.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |VoteTimer|A timer to handle vote timeout when a leader was not confirmed by majority.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |StepDownTimer|A timer to process leader step down condition.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| was (Author: maliev): ||Pool name||Description||Number of Threads|| |JRaft-Common-Executor|A pool for processing short-lived asynchronous tasks. Should never be blocked.|Utils.cpus() (core == max)| |JRaft-Node-Scheduler|A scheduled executor for running delayed or repeating tasks.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |JRaft-Request-Processor|A default pool for handling RAFT requests. Should never be blocked.|Utils.cpus() * 6 (core == max)| |JRaft-Response-Processor|A default pool for handling RAFT responses. Should never be blocked.|80 (core == max/3)| |JRaft-AppendEntries-Processor|A pool of single thread executors. Used only if a replication pipelining is enabled. Handles append entries requests and responses (used by the replication flow). Threads are started on demand. Each replication pair (leader-follower) uses dedicated single thread executor from the pool, so all messages between replication peer pairs are processed sequentially.|SystemPropertyUtil.getInt( "jraft.append.entries.threads.send", Math.max(16, Ints.findNextPositivePowerOfTwo(cpus() * 2)));| |NodeImpl-Disruptor|A striped disruptor for batching FSM (finite state machine) user tasks.|DEFAULT_STRIPES = Utils.cpus() * 2| |ReadOnlyService-Disruptor|A striped disruptor for batching read requests before doing read index request.|DEFAULT_STRIPES = Utils.cpus() * 2| |LogManager-Disruptor|A striped disruptor for delivering log entries to a storage.|DEFAULT_STRIPES = Utils.cpus() * 2| |FSMCaller-Disruptor|A striped disruptor for FSM callbacks.|DEFAULT_STRIPES = Utils.cpus() * 2| |SnapshotTimer|A timer for periodic snapshot creation.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |ElectionTimer|A timer to handle election timeout on followers.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |VoteTimer|A timer to handle vote timeout when a leader was not confirmed by majority.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |StepDownTimer|A timer to process leader step down condition.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| > Revisit the configuration of thread pools used by JRaft > --- > > Key: IGNITE-20165 > URL: https://issues.apache.org/jira/browse/IGNITE-20165 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtce
[jira] [Comment Edited] (IGNITE-20165) Revisit the configuration of thread pools used by JRaft
[ https://issues.apache.org/jira/browse/IGNITE-20165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753233#comment-17753233 ] Mirza Aliev edited comment on IGNITE-20165 at 8/11/23 1:59 PM: --- ||Pool name||Description||Number of Threads|| |JRaft-Common-Executor|A pool for processing short-lived asynchronous tasks. Should never be blocked.|Utils.cpus() (core == max)| |JRaft-Node-Scheduler|A scheduled executor for running delayed or repeating tasks.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |JRaft-Request-Processor|A default pool for handling RAFT requests. Should never be blocked.|Utils.cpus() * 6 (core == max)| |JRaft-Response-Processor|A default pool for handling RAFT responses. Should never be blocked.|80 (core == max/3)| |JRaft-AppendEntries-Processor|A pool of single thread executors. Used only if a replication pipelining is enabled. Handles append entries requests and responses (used by the replication flow). Threads are started on demand. Each replication pair (leader-follower) uses dedicated single thread executor from the pool, so all messages between replication peer pairs are processed sequentially.|SystemPropertyUtil.getInt( "jraft.append.entries.threads.send", Math.max(16, Ints.findNextPositivePowerOfTwo(cpus() * 2)));| |NodeImpl-Disruptor|A striped disruptor for batching FSM (finite state machine) user tasks.|DEFAULT_STRIPES = Utils.cpus() * 2| |ReadOnlyService-Disruptor|A striped disruptor for batching read requests before doing read index request.|DEFAULT_STRIPES = Utils.cpus() * 2| |LogManager-Disruptor|A striped disruptor for delivering log entries to a storage.|DEFAULT_STRIPES = Utils.cpus() * 2| |FSMCaller-Disruptor|A striped disruptor for FSM callbacks.|DEFAULT_STRIPES = Utils.cpus() * 2| |SnapshotTimer|A timer for periodic snapshot creation.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |ElectionTimer|A timer to handle election timeout on followers.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |VoteTimer|A timer to handle vote timeout when a leader was not confirmed by majority.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |StepDownTimer|A timer to process leader step down condition.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| was (Author: maliev): ||Pool name||Description||Number of Threads|| |JRaft-Common-Executor|A pool for processing short-lived asynchronous tasks. Should never be blocked.|Utils.cpus() (core == max)| |JRaft-Node-Scheduler|A scheduled executor for running delayed or repeating tasks.|Math.min(Utils.cpus() * 3, 20)| |JRaft-Request-Processor|A default pool for handling RAFT requests. Should never be blocked.|Utils.cpus() * 6 (core == max)| |JRaft-Response-Processor|A default pool for handling RAFT responses. Should never be blocked.|80 (core == max/3)| |JRaft-AppendEntries-Processor|A pool of single thread executors. Used only if a replication pipelining is enabled. Handles append entries requests and responses (used by the replication flow). Threads are started on demand. Each replication pair (leader-follower) uses dedicated single thread executor from the pool, so all messages between replication peer pairs are processed sequentially.|SystemPropertyUtil.getInt( "jraft.append.entries.threads.send", Math.max(16, Ints.findNextPositivePowerOfTwo(cpus() * 2)));| |NodeImpl-Disruptor|A striped disruptor for batching FSM (finite state machine) user tasks.|DEFAULT_STRIPES = Utils.cpus() * 2| |ReadOnlyService-Disruptor|A striped disruptor for batching read requests before doing read index request.|DEFAULT_STRIPES = Utils.cpus() * 2| |LogManager-Disruptor|A striped disruptor for delivering log entries to a storage.|DEFAULT_STRIPES = Utils.cpus() * 2| |FSMCaller-Disruptor|A striped disruptor for FSM callbacks.|DEFAULT_STRIPES = Utils.cpus() * 2| |SnapshotTimer|A timer for periodic snapshot creation.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |ElectionTimer|A timer to handle election timeout on followers.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |VoteTimer|A timer to handle vote timeout when a leader was not confirmed by majority.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |StepDownTimer|A timer to process leader step down condition.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| > Revisit the configuration of thread pools used by JRaft > --- > > Key: IGNITE-20165 > URL: https://issues.apache.org/jira/browse/IGNITE-20165 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > > JRaft uses a bunch of thread
[jira] [Comment Edited] (IGNITE-20165) Revisit the configuration of thread pools used by JRaft
[ https://issues.apache.org/jira/browse/IGNITE-20165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753233#comment-17753233 ] Mirza Aliev edited comment on IGNITE-20165 at 8/11/23 1:58 PM: --- ||Pool name||Description||Number of Threads|| |JRaft-Common-Executor|A pool for processing short-lived asynchronous tasks. Should never be blocked.|Utils.cpus() (core == max)| |JRaft-Node-Scheduler|A scheduled executor for running delayed or repeating tasks.|Math.min(Utils.cpus() * 3, 20)| |JRaft-Request-Processor|A default pool for handling RAFT requests. Should never be blocked.|Utils.cpus() * 6 (core == max)| |JRaft-Response-Processor|A default pool for handling RAFT responses. Should never be blocked.|80 (core == max/3)| |JRaft-AppendEntries-Processor|A pool of single thread executors. Used only if a replication pipelining is enabled. Handles append entries requests and responses (used by the replication flow). Threads are started on demand. Each replication pair (leader-follower) uses dedicated single thread executor from the pool, so all messages between replication peer pairs are processed sequentially.|SystemPropertyUtil.getInt( "jraft.append.entries.threads.send", Math.max(16, Ints.findNextPositivePowerOfTwo(cpus() * 2)));| |NodeImpl-Disruptor|A striped disruptor for batching FSM (finite state machine) user tasks.|DEFAULT_STRIPES = Utils.cpus() * 2| |ReadOnlyService-Disruptor|A striped disruptor for batching read requests before doing read index request.|DEFAULT_STRIPES = Utils.cpus() * 2| |LogManager-Disruptor|A striped disruptor for delivering log entries to a storage.|DEFAULT_STRIPES = Utils.cpus() * 2| |FSMCaller-Disruptor|A striped disruptor for FSM callbacks.|DEFAULT_STRIPES = Utils.cpus() * 2| |SnapshotTimer|A timer for periodic snapshot creation.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |ElectionTimer|A timer to handle election timeout on followers.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |VoteTimer|A timer to handle vote timeout when a leader was not confirmed by majority.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| |StepDownTimer|A timer to process leader step down condition.|Math.min(Utils.cpus() * 3, 20) (core, max == Integer.MAX_VALUE)| was (Author: maliev): ||Pool name||Description||Number of Threads|| |JRaft-Common-Executor|A pool for processing short-lived asynchronous tasks. Should never be blocked.|Utils.cpus()| |JRaft-Node-Scheduler|A scheduled executor for running delayed or repeating tasks.|Math.min(Utils.cpus() * 3, 20)| |JRaft-Request-Processor|A default pool for handling RAFT requests. Should never be blocked.|Utils.cpus() * 6| |JRaft-Response-Processor|A default pool for handling RAFT responses. Should never be blocked.|80| |JRaft-AppendEntries-Processor|A pool of single thread executors. Used only if a replication pipelining is enabled. Handles append entries requests and responses (used by the replication flow). Threads are started on demand. Each replication pair (leader-follower) uses dedicated single thread executor from the pool, so all messages between replication peer pairs are processed sequentially.|SystemPropertyUtil.getInt( "jraft.append.entries.threads.send", Math.max(16, Ints.findNextPositivePowerOfTwo(cpus() * 2)));| |NodeImpl-Disruptor|A striped disruptor for batching FSM (finite state machine) user tasks.|DEFAULT_STRIPES = Utils.cpus() * 2| |ReadOnlyService-Disruptor|A striped disruptor for batching read requests before doing read index request.|DEFAULT_STRIPES = Utils.cpus() * 2| |LogManager-Disruptor|A striped disruptor for delivering log entries to a storage.|DEFAULT_STRIPES = Utils.cpus() * 2| |FSMCaller-Disruptor|A striped disruptor for FSM callbacks.|DEFAULT_STRIPES = Utils.cpus() * 2| |SnapshotTimer|A timer for periodic snapshot creation.|Math.min(Utils.cpus() * 3, 20)| |ElectionTimer|A timer to handle election timeout on followers.|Math.min(Utils.cpus() * 3, 20)| |VoteTimer|A timer to handle vote timeout when a leader was not confirmed by majority.|Math.min(Utils.cpus() * 3, 20)| |StepDownTimer|A timer to process leader step down condition.|Math.min(Utils.cpus() * 3, 20)| > Revisit the configuration of thread pools used by JRaft > --- > > Key: IGNITE-20165 > URL: https://issues.apache.org/jira/browse/IGNITE-20165 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > > JRaft uses a bunch of thread pools to execute its operations. Most of these > thread pools use the number of CPUs to determine the amount of threads they > can use. For example, as described in IGNITE-20080, having 64 cores led to > JR
[jira] [Updated] (IGNITE-19919) org.apache.ignite.sql.ResultSet#close should close implicit transaction if any
[
https://issues.apache.org/jira/browse/IGNITE-19919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-19919:
--
Fix Version/s: 3.0.0-beta2
> org.apache.ignite.sql.ResultSet#close should close implicit transaction if any
> --
>
> Key: IGNITE-19919
> URL: https://issues.apache.org/jira/browse/IGNITE-19919
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Alexander Lapin
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> At the current moment, the transaction will be closed only if the cursor has
> read all the data:
> {code:java}
> org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl#requestNextAsync{code}
> in the case of an explicit ResultSet.close() call, the transaction will not
> be closed.
>
> Repoducerers within org.apache.ignite.internal.sql.api.ItSqlSynchronousApiTest
> {code:java}
> @Test
> public void resultSetCloseShouldFinishImplicitTransacion() throws
> InterruptedException {
> sql("CREATE TABLE TEST(ID INT PRIMARY KEY, VAL0 INT)");
> for (int i = 0; i < ROW_COUNT; ++i) {
> sql("INSERT INTO TEST VALUES (?, ?)", i, i);
> }
> IgniteSql sql = igniteSql();
> Session ses = sql.sessionBuilder().defaultPageSize(2).build();
> ResultSet rs = ses.execute(null, "SELECT * FROM TEST");
> assertEquals(1, ((IgniteImpl)
> CLUSTER_NODES.get(0)).txManager().pending());
> rs.close();
> assertEquals(0, ((IgniteImpl)
> CLUSTER_NODES.get(0)).txManager().pending());
> }{code}
> and
> {code:java}
> @Test
> public void
> resultSetCloseShouldFinishImplicitTransacionWithCursorTouchAfterClose()
> throws InterruptedException {
> sql("CREATE TABLE TEST(ID INT PRIMARY KEY, VAL0 INT)");
> for (int i = 0; i < ROW_COUNT; ++i) {
> sql("INSERT INTO TEST VALUES (?, ?)", i, i);
> }
> IgniteSql sql = igniteSql();
> Session ses = sql.sessionBuilder().defaultPageSize(2).build();
> ResultSet rs = ses.execute(null, "SELECT * FROM TEST");
> assertEquals(1, ((IgniteImpl)
> CLUSTER_NODES.get(0)).txManager().pending());
> Thread.sleep(300); // ResultSetImpl fetches next page in background, wait
> to it to complete to avoid flakiness.
> rs.close();
> assertThrowsWithCause(() -> rs.forEachRemaining(Object::hashCode),
> CursorClosedException.class);
> assertEquals(0, ((IgniteImpl)
> CLUSTER_NODES.get(0)).txManager().pending());
> }{code}
> Please, pay attention, that
> resultSetCloseShouldFinishImplicitTransacionWithCursorTouchAfterClose faisl
> only if client is used as entry point, meaning within
> ItSqlClientSynchronousApiTest only, but
> resultSetCloseShouldFinishImplicitTransacion fails both for client and
> server, meaning both for ItSqlClientSynchronousApiTest and
> ItSqlSynchronousApiTest.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20035) IndexOutOfBoundsException when statement.SetMaxRows is set
[
https://issues.apache.org/jira/browse/IGNITE-20035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753236#comment-17753236
]
Pavel Pereslegin commented on IGNITE-20035:
---
[~mzhuravkov], [~amashenkov],
please take a look at the proposed changes.
> IndexOutOfBoundsException when statement.SetMaxRows is set
> --
>
> Key: IGNITE-20035
> URL: https://issues.apache.org/jira/browse/IGNITE-20035
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0
>Reporter: Alexander Belyak
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If setMaxRows > count(*) - query fail with IndexOutOfBound exception.
> Reproducer:
>
> {noformat}
> try (Connection connection = connect(); Statement statement =
> connection.createStatement()) {
> JdbcSteps steps = new JdbcSteps(statement);
> steps.executeUpdateQuery("CREATE TABLE Person (id INT PRIMARY KEY, name
> VARCHAR)", "Creating a table with two columns.");
> steps.executeUpdateQuery("INSERT INTO Person (id, name) VALUES (1,
> 'John')", "Inserting a single record");
> statement.setMaxRows(25);
> ResultSet res = steps.executeQuery("SELECT * FROM Person", "Selecting all
> the records from the table");
> while (res.next()) {
> log.info("{}, {}", res.getInt(1), res.getString(2));
> assertEquals(1, res.getInt(1));
> assertEquals("John", res.getString(2));
> }
> }{noformat}
> Returns:
>
>
> {noformat}
> Exception while executing query [query=SELECT * FROM Person]. Error
> message:toIndex = 25
> java.sql.SQLException: Exception while executing query [query=SELECT * FROM
> Person]. Error message:toIndex = 25
> at
> org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:149)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:108)
> at
> org.gridgain.ai3tests.tests.teststeps.JdbcSteps.executeQuery(JdbcSteps.java:50)
> at
> org.gridgain.ai3tests.tests.BasicOperationsTest.testSaveAndGetFromCache(BasicOperationsTest.java:41)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at
> org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> org.junit.jupiter.api.extension.InvocationInterceptor.interceptTestMethod(InvocationInterceptor.java:118)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
> at
> org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableIn
[jira] [Commented] (IGNITE-20165) Revisit the configuration of thread pools used by JRaft
[ https://issues.apache.org/jira/browse/IGNITE-20165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753233#comment-17753233 ] Mirza Aliev commented on IGNITE-20165: -- ||Pool name||Description||Number of Threads|| |JRaft-Common-Executor|A pool for processing short-lived asynchronous tasks. Should never be blocked.|Utils.cpus()| |JRaft-Node-Scheduler|A scheduled executor for running delayed or repeating tasks.|Math.min(Utils.cpus() * 3, 20)| |JRaft-Request-Processor|A default pool for handling RAFT requests. Should never be blocked.|Utils.cpus() * 6| |JRaft-Response-Processor|A default pool for handling RAFT responses. Should never be blocked.|80| |JRaft-AppendEntries-Processor|A pool of single thread executors. Used only if a replication pipelining is enabled. Handles append entries requests and responses (used by the replication flow). Threads are started on demand. Each replication pair (leader-follower) uses dedicated single thread executor from the pool, so all messages between replication peer pairs are processed sequentially.|SystemPropertyUtil.getInt( "jraft.append.entries.threads.send", Math.max(16, Ints.findNextPositivePowerOfTwo(cpus() * 2)));| |NodeImpl-Disruptor|A striped disruptor for batching FSM (finite state machine) user tasks.|DEFAULT_STRIPES = Utils.cpus() * 2| |ReadOnlyService-Disruptor|A striped disruptor for batching read requests before doing read index request.|DEFAULT_STRIPES = Utils.cpus() * 2| |LogManager-Disruptor|A striped disruptor for delivering log entries to a storage.|DEFAULT_STRIPES = Utils.cpus() * 2| |FSMCaller-Disruptor|A striped disruptor for FSM callbacks.|DEFAULT_STRIPES = Utils.cpus() * 2| |SnapshotTimer|A timer for periodic snapshot creation.|Math.min(Utils.cpus() * 3, 20)| |ElectionTimer|A timer to handle election timeout on followers.|Math.min(Utils.cpus() * 3, 20)| |VoteTimer|A timer to handle vote timeout when a leader was not confirmed by majority.|Math.min(Utils.cpus() * 3, 20)| |StepDownTimer|A timer to process leader step down condition.|Math.min(Utils.cpus() * 3, 20)| > Revisit the configuration of thread pools used by JRaft > --- > > Key: IGNITE-20165 > URL: https://issues.apache.org/jira/browse/IGNITE-20165 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > > JRaft uses a bunch of thread pools to execute its operations. Most of these > thread pools use the number of CPUs to determine the amount of threads they > can use. For example, as described in IGNITE-20080, having 64 cores led to > JRaft allocating around 600 threads. Even though these thread pools are > shared between all Raft nodes, this approach is clearly sub-optimal, because > it should take into account both the amount of nodes as well as the number of > processors. It may also be beneficial to revise the amount of thread pools > used and why they are needed and reduce their number, if possible. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-19919) org.apache.ignite.sql.ResultSet#close should close implicit transaction if any
[
https://issues.apache.org/jira/browse/IGNITE-19919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753230#comment-17753230
]
Pavel Pereslegin edited comment on IGNITE-19919 at 8/11/23 1:45 PM:
[~mzhuravkov], thanks for the contribution!
Merged to the main branch
([3efece824520e4345cdd89014ebe6b867c18442d|https://github.com/apache/ignite-3/commit/3efece824520e4345cdd89014ebe6b867c18442d]).
was (Author: xtern):
[~mzhuravkov], thanks for the contribution!
Merged to the main branch
([3efece824520e4345cdd89014ebe6b867c18442d|https://github.com/apache/ignite-3/commit/3efece824520e4345cdd89014ebe6b867c18442d].
> org.apache.ignite.sql.ResultSet#close should close implicit transaction if any
> --
>
> Key: IGNITE-19919
> URL: https://issues.apache.org/jira/browse/IGNITE-19919
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Alexander Lapin
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 1h
> Remaining Estimate: 0h
>
> At the current moment, the transaction will be closed only if the cursor has
> read all the data:
> {code:java}
> org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl#requestNextAsync{code}
> in the case of an explicit ResultSet.close() call, the transaction will not
> be closed.
>
> Repoducerers within org.apache.ignite.internal.sql.api.ItSqlSynchronousApiTest
> {code:java}
> @Test
> public void resultSetCloseShouldFinishImplicitTransacion() throws
> InterruptedException {
> sql("CREATE TABLE TEST(ID INT PRIMARY KEY, VAL0 INT)");
> for (int i = 0; i < ROW_COUNT; ++i) {
> sql("INSERT INTO TEST VALUES (?, ?)", i, i);
> }
> IgniteSql sql = igniteSql();
> Session ses = sql.sessionBuilder().defaultPageSize(2).build();
> ResultSet rs = ses.execute(null, "SELECT * FROM TEST");
> assertEquals(1, ((IgniteImpl)
> CLUSTER_NODES.get(0)).txManager().pending());
> rs.close();
> assertEquals(0, ((IgniteImpl)
> CLUSTER_NODES.get(0)).txManager().pending());
> }{code}
> and
> {code:java}
> @Test
> public void
> resultSetCloseShouldFinishImplicitTransacionWithCursorTouchAfterClose()
> throws InterruptedException {
> sql("CREATE TABLE TEST(ID INT PRIMARY KEY, VAL0 INT)");
> for (int i = 0; i < ROW_COUNT; ++i) {
> sql("INSERT INTO TEST VALUES (?, ?)", i, i);
> }
> IgniteSql sql = igniteSql();
> Session ses = sql.sessionBuilder().defaultPageSize(2).build();
> ResultSet rs = ses.execute(null, "SELECT * FROM TEST");
> assertEquals(1, ((IgniteImpl)
> CLUSTER_NODES.get(0)).txManager().pending());
> Thread.sleep(300); // ResultSetImpl fetches next page in background, wait
> to it to complete to avoid flakiness.
> rs.close();
> assertThrowsWithCause(() -> rs.forEachRemaining(Object::hashCode),
> CursorClosedException.class);
> assertEquals(0, ((IgniteImpl)
> CLUSTER_NODES.get(0)).txManager().pending());
> }{code}
> Please, pay attention, that
> resultSetCloseShouldFinishImplicitTransacionWithCursorTouchAfterClose faisl
> only if client is used as entry point, meaning within
> ItSqlClientSynchronousApiTest only, but
> resultSetCloseShouldFinishImplicitTransacion fails both for client and
> server, meaning both for ItSqlClientSynchronousApiTest and
> ItSqlSynchronousApiTest.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20194) Calcite engine. Dependency common-codec required for some functions
[
https://issues.apache.org/jira/browse/IGNITE-20194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753227#comment-17753227
]
Ignite TC Bot commented on IGNITE-20194:
{panel:title=Branch: [pull/10889/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10889/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7295200&buildTypeId=IgniteTests24Java8_RunAll]
> Calcite engine. Dependency common-codec required for some functions
> ---
>
> Key: IGNITE-20194
> URL: https://issues.apache.org/jira/browse/IGNITE-20194
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, ise
> Fix For: 2.16
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Some functions (md5, soundex) require common-codec dependency, but this
> dependency is not included explicitly to dependencies list and doesn't added
> to calcite library folder on build. Tests run with transitive dependencies
> and don't trigger the problem. Queries fail only when run on Ignite started
> from binary release package.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20015) Sql. Introduce new distribution function
[
https://issues.apache.org/jira/browse/IGNITE-20015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov reassigned IGNITE-20015:
-
Assignee: Andrey Mashenkov
> Sql. Introduce new distribution function
>
>
> Key: IGNITE-20015
> URL: https://issues.apache.org/jira/browse/IGNITE-20015
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
>
> To realize the full potential of sql engine in queries over node specific
> views, we need to support new type of distribution function
> ({{org.apache.ignite.internal.sql.engine.trait.DistributionFunction}}). The
> semantic of this new function should be pretty strait forward: the column
> this function refers to is actually an identity of the node containing the
> data.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19789) Sql. Introduce RowSchema for RowFactory
[
https://issues.apache.org/jira/browse/IGNITE-19789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-19789:
--
Fix Version/s: 3.0.0-beta2
> Sql. Introduce RowSchema for RowFactory
> ---
>
> Key: IGNITE-19789
> URL: https://issues.apache.org/jira/browse/IGNITE-19789
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Konstantin Orlov
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 2h 10m
> Remaining Estimate: 0h
>
> There are three way to create
> {{{}org.apache.ignite.internal.sql.engine.exec.RowHandler.RowFactory{}}}:
> {code:java}
> RowFactory factory(IgniteTypeFactory typeFactory, RelDataType rowType);
> RowFactory factory(IgniteTypeFactory typeFactory, List
> fieldTypes);
> RowFactory factory(Type... types);
> {code}
> The first two create unnecessary dependency on {{calcite}} library, the last
> one doesn't provide required type's parameters, like decimal scale, for
> instance.
> Let's replace all three methods with a single {{{}RowFactory
> factory(RowSchema schema){}}}, where {{RowSchema}} is a class that should be
> introduced.
> h4. Implementation Notes
> Although {{org.apache.ignite.internal.schema.BinaryTupleSchemas}} might seem
> like a good candidate on the role of RowSchema, it doesn't have exhaustive
> type's support. Besides, introducing new type to binary tuple is much complex
> procedure since it will affect every module. Thus, it's better to implement
> distinct schema optimised for RowHandler|RowFactory use case.
> RowSchema should support complex/nested objects
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20198) .NET: Frequent failures in Plaform .NET (Core Linux) TC Project
[ https://issues.apache.org/jira/browse/IGNITE-20198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-20198: --- Assignee: Pavel Tupitsyn > .NET: Frequent failures in Plaform .NET (Core Linux) TC Project > --- > > Key: IGNITE-20198 > URL: https://issues.apache.org/jira/browse/IGNITE-20198 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.15 >Reporter: Andrey Khitrin >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET > Fix For: 2.16 > > > * Out of memory: Java heap space > * Execution timeout > * Flaky tests -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20198) .NET: Frequent failures in Plaform .NET (Core Linux) TC Project
[ https://issues.apache.org/jira/browse/IGNITE-20198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20198: Component/s: platforms (was: .NET) > .NET: Frequent failures in Plaform .NET (Core Linux) TC Project > --- > > Key: IGNITE-20198 > URL: https://issues.apache.org/jira/browse/IGNITE-20198 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.15 >Reporter: Andrey Khitrin >Priority: Major > Labels: .NET > > * Out of memory: Java heap space > * Execution timeout > * Flaky tests -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20198) .NET: Frequent failures in Plaform .NET (Core Linux) TC Project
[ https://issues.apache.org/jira/browse/IGNITE-20198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20198: Labels: .NET (was: ) > .NET: Frequent failures in Plaform .NET (Core Linux) TC Project > --- > > Key: IGNITE-20198 > URL: https://issues.apache.org/jira/browse/IGNITE-20198 > Project: Ignite > Issue Type: Bug > Components: .NET >Affects Versions: 2.15 >Reporter: Andrey Khitrin >Priority: Major > Labels: .NET > > * Out of memory: Java heap space > * Execution timeout > * Flaky tests -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20198) .NET: Frequent failures in Plaform .NET (Core Linux) TC Project
[ https://issues.apache.org/jira/browse/IGNITE-20198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20198: Fix Version/s: 2.16 > .NET: Frequent failures in Plaform .NET (Core Linux) TC Project > --- > > Key: IGNITE-20198 > URL: https://issues.apache.org/jira/browse/IGNITE-20198 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.15 >Reporter: Andrey Khitrin >Priority: Major > Labels: .NET > Fix For: 2.16 > > > * Out of memory: Java heap space > * Execution timeout > * Flaky tests -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20198) .NET: Frequent failures in Plaform .NET (Core Linux) TC Project
[ https://issues.apache.org/jira/browse/IGNITE-20198?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20198: Summary: .NET: Frequent failures in Plaform .NET (Core Linux) TC Project (was: .NET Frequent failures in Plaform .NET (Core Linux) TC Project) > .NET: Frequent failures in Plaform .NET (Core Linux) TC Project > --- > > Key: IGNITE-20198 > URL: https://issues.apache.org/jira/browse/IGNITE-20198 > Project: Ignite > Issue Type: Bug > Components: .NET >Affects Versions: 2.15 >Reporter: Andrey Khitrin >Priority: Major > > * Out of memory: Java heap space > * Execution timeout > * Flaky tests -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20197) .NET: Thin 3.0: Perf: Excessive dictionary lookups by GetFieldByColumnName usages
[ https://issues.apache.org/jira/browse/IGNITE-20197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20197: Summary: .NET: Thin 3.0: Perf: Excessive dictionary lookups by GetFieldByColumnName usages (was: .NET: Thin 3.0: Excessive dictionary lookups by GetFieldByColumnName usages) > .NET: Thin 3.0: Perf: Excessive dictionary lookups by GetFieldByColumnName > usages > - > > Key: IGNITE-20197 > URL: https://issues.apache.org/jira/browse/IGNITE-20197 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Trivial > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > All usages of > [ReflectionUtils.GetFieldByColumnName|https://github.com/apache/ignite-3/blob/64f8248fe52a50e09eace2eea7b7308a7c8f6eaf/modules/platforms/dotnet/Apache.Ignite/Internal/Table/Serialization/ReflectionUtils.cs#L53] > are within loops. > As a result, *GetFieldsByColumnName(type)* is called for the same type > multiple times. > We should remove *ReflectionUtils.GetFieldByColumnName* to avoid this pitfall > and perform the first lookup outside of the loop. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20197) .NET: Thin 3.0: Excessive dictionary lookups by GetFieldByColumnName usages
[ https://issues.apache.org/jira/browse/IGNITE-20197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20197: Description: All usages of [ReflectionUtils.GetFieldByColumnName|https://github.com/apache/ignite-3/blob/64f8248fe52a50e09eace2eea7b7308a7c8f6eaf/modules/platforms/dotnet/Apache.Ignite/Internal/Table/Serialization/ReflectionUtils.cs#L53] are within loops. As a result, *GetFieldsByColumnName(type)* is called for the same type multiple times. We should remove *ReflectionUtils.GetFieldByColumnName* to avoid this pitfall and perform the first lookup outside of the loop. was:All callers of > .NET: Thin 3.0: Excessive dictionary lookups by GetFieldByColumnName usages > --- > > Key: IGNITE-20197 > URL: https://issues.apache.org/jira/browse/IGNITE-20197 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Trivial > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > All usages of > [ReflectionUtils.GetFieldByColumnName|https://github.com/apache/ignite-3/blob/64f8248fe52a50e09eace2eea7b7308a7c8f6eaf/modules/platforms/dotnet/Apache.Ignite/Internal/Table/Serialization/ReflectionUtils.cs#L53] > are within loops. > As a result, *GetFieldsByColumnName(type)* is called for the same type > multiple times. > We should remove *ReflectionUtils.GetFieldByColumnName* to avoid this pitfall > and perform the first lookup outside of the loop. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20198) .NET Frequent failures in Plaform .NET (Core Linux) TC Project
Andrey Khitrin created IGNITE-20198: --- Summary: .NET Frequent failures in Plaform .NET (Core Linux) TC Project Key: IGNITE-20198 URL: https://issues.apache.org/jira/browse/IGNITE-20198 Project: Ignite Issue Type: Bug Components: .NET Affects Versions: 2.15 Reporter: Andrey Khitrin * Out of memory: Java heap space * Execution timeout * Flaky tests -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20197) .NET: Thin 3.0: Excessive dictionary lookups by GetFieldByColumnName usages
[ https://issues.apache.org/jira/browse/IGNITE-20197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-20197: Description: All callers of > .NET: Thin 3.0: Excessive dictionary lookups by GetFieldByColumnName usages > --- > > Key: IGNITE-20197 > URL: https://issues.apache.org/jira/browse/IGNITE-20197 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Trivial > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > All callers of -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20197) .NET: Thin 3.0: Excessive dictionary lookups by GetFieldByColumnName usages
Pavel Tupitsyn created IGNITE-20197: --- Summary: .NET: Thin 3.0: Excessive dictionary lookups by GetFieldByColumnName usages Key: IGNITE-20197 URL: https://issues.apache.org/jira/browse/IGNITE-20197 Project: Ignite Issue Type: Improvement Components: platforms, thin client Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-20196) Sql. Review list of reserver keywords
Konstantin Orlov created IGNITE-20196: - Summary: Sql. Review list of reserver keywords Key: IGNITE-20196 URL: https://issues.apache.org/jira/browse/IGNITE-20196 Project: Ignite Issue Type: Improvement Components: sql Reporter: Konstantin Orlov Assignee: Konstantin Orlov IGNITE-19759 introduces some refactoring to the parser configuration: reserved keywords are revised and parser is configured with defaults defined in default_configuration, which makes config.fmpp a bit cleaner. Let's port all these changes to Ignite-3. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-18989) Design table management flow (part 2)
[ https://issues.apache.org/jira/browse/IGNITE-18989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin resolved IGNITE-18989. -- Resolution: Won't Do > Design table management flow (part 2) > - > > Key: IGNITE-18989 > URL: https://issues.apache.org/jira/browse/IGNITE-18989 > Project: Ignite > Issue Type: Task >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > After making the diagram of current flow, we should design the new flow and a > plan for descomposition of TableManager by different components having more > narrow responsibility. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20189) Prepare existing tests for the distributed zone to switch to the catalog #2
[ https://issues.apache.org/jira/browse/IGNITE-20189?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753135#comment-17753135 ] Roman Puchkovskiy commented on IGNITE-20189: The patch looks good to me > Prepare existing tests for the distributed zone to switch to the catalog #2 > --- > > Key: IGNITE-20189 > URL: https://issues.apache.org/jira/browse/IGNITE-20189 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > During IGNITE-20114, it was discovered that the tests used zone IDs as > constants, which is not the right solution, and also complicates the switch > of these tests to the catalog. > We need to take the zone ID from the configuration. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-20168) MultiActorPlacementDriverTest#testLeaseProlong is flaky
[
https://issues.apache.org/jira/browse/IGNITE-20168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin resolved IGNITE-20168.
--
Resolution: Cannot Reproduce
> MultiActorPlacementDriverTest#testLeaseProlong is flaky
> ---
>
> Key: IGNITE-20168
> URL: https://issues.apache.org/jira/browse/IGNITE-20168
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
> Attachments: _Integration_Tests_Run_All_Other_13189.log.zip, test.log
>
>
> TC run:
> [https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7412161?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildProblemsSection=true&expandBuildChangesSection=true&expandBuildTestsSection=true]
> For some reason, lease was not created within timeout:
>
> {code:java}
> [07:38:49]F:
> [org.apache.ignite.internal.placementdriver.MultiActorPlacementDriverTest.testLeaseProlong()]
> org.opentest4j.AssertionFailedError: expected: but was:
>
> [07:38:49]F:
> [org.apache.ignite.internal.placementdriver.MultiActorPlacementDriverTest.testLeaseProlong()]
> org.opentest4j.AssertionFailedError: expected: but was:
>
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at
> app//org.junit.jupiter.api.AssertTrue.failNotTrue(AssertTrue.java:63)
> at
> app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:36)
> at
> app//org.junit.jupiter.api.AssertTrue.assertTrue(AssertTrue.java:31)
> at
> app//org.junit.jupiter.api.Assertions.assertTrue(Assertions.java:180)
> at
> app//org.apache.ignite.internal.placementdriver.MultiActorPlacementDriverTest.checkLeaseCreated(MultiActorPlacementDriverTest.java:571)
> at
> app//org.apache.ignite.internal.placementdriver.MultiActorPlacementDriverTest.testLeaseProlong(MultiActorPlacementDriverTest.java:368)
> at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base@11.0.17/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at
> java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566)
> at
> app//org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:727)
> at
> app//org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
> at
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
> at
> app//org.junit.jupiter.engine.extension.SameThreadTimeoutInvocation.proceed(SameThreadTimeoutInvocation.java:45)
> at
> app//org.junit.jupiter.engine.extension.TimeoutExtension.intercept(TimeoutExtension.java:156)
> at
> app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestableMethod(TimeoutExtension.java:147)
> at
> app//org.junit.jupiter.engine.extension.TimeoutExtension.interceptTestMethod(TimeoutExtension.java:86)
> at
> app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
> at
> app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
> at
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain$InterceptedInvocation.proceed(InvocationInterceptorChain.java:106)
> at
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.proceed(InvocationInterceptorChain.java:64)
> at
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.chainAndInvoke(InvocationInterceptorChain.java:45)
> at
> app//org.junit.jupiter.engine.execution.InvocationInterceptorChain.invoke(InvocationInterceptorChain.java:37)
> at
> app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:92)
> at
> app//org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.invoke(InterceptingExecutableInvoker.java:86)
> at
> app//org.junit.jupiter.engine.descriptor.TestMethodTestDescriptor.lambda$invokeTestMethod$7(TestMethodTestDescriptor.java:217)
> at
> app//org.junit.platform.engine.support.hierarchical.ThrowableCollector.execute(ThrowableCollector.java:73)
> at
> app//org.junit.jupiter.engine.descriptor.TestMethodTestDescript
[jira] [Assigned] (IGNITE-19227) Wait for schema awailability out of JRaft threads
[
https://issues.apache.org/jira/browse/IGNITE-19227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy reassigned IGNITE-19227:
--
Assignee: Roman Puchkovskiy
> Wait for schema awailability out of JRaft threads
> -
>
> Key: IGNITE-19227
> URL: https://issues.apache.org/jira/browse/IGNITE-19227
> Project: Ignite
> Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: iep-98, ignite-3
>
> According to
> [https://cwiki.apache.org/confluence/display/IGNITE/IEP-98%3A+Schema+Synchronization#IEP98:SchemaSynchronization-Waitingforsafetimeinthepast]
> , we might need to wait for schema availability when fetching a schema. If
> such waits happen inside a PartitionListener, JRaft threads might be blocked
> for a noticeable amount of time (maybe even seconds). We should avoid this.
> h3. In RW transactions
> When a primary node is going to process a request, it waits till it has all
> the schema versions for the corresponding timestamp (beginTs or commitTs) Top
> (i.e. that MS SafeTime >= Top). {*}The wait happens outside of JRaft
> threads{*}. Then it obtains the global schema revision SR of the latest
> schema update that is not later than the corresponding timestamp. It then
> builds a command (putting that SR inside) and submits it to RAFT.
> When an AppendEntriesRequest is built, Replicator inspects all the entries it
> includes in it, extracts SRs from each of them, takes max of them (as MSR,
> for ‘max schema revision’) and puts it in the AppendEntriesRequest.
> When the request is processed by a follower/learner, it compares the MSR from
> the request with its locally known MSR (in the Catalog). If the request’s MSR
> > local MSR, then the request is rejected (with reason EBUSY). It will be
> retried by the leader after some time. As an optimization, we might wait for
> some time in hope that the local MSR catches up with the request’s MSR.
> As we need an additional field in AppendEntriesRequest that will only be used
> by partition groups, we could add a generic container for properties to this
> interface, like Map extras().
> To extract the SR from a command, we might just deserialize it completely,
> but this requires a lot of work that is not necessary. We might serialize
> commands having SR in a special way (putting SR in the very first bytes of
> the message) to make its retrieval effective.
> As the primary has already made sure that it has the schema versions needed
> to execute the command, no waits will be needed on the primary node while
> executing the RAFT command.
> As secondaries/learners refuse AppendEntries which they cannot execute
> waitless, they will not have to wait at all in JRaft threads.
> A case when the RAFT leader is not collocated with the primary is possible.
> We can add the same validation for ActionRequests: pass the required SR
> inside an ActionRequest, validate it in ActionRequestProcessor and reject
> requests having SR above the local MSR.
> h3. In RO transactions
> When processing an RO transaction, we just wait for MS SafeTime. This is made
> out of RAFT, so no special measures are needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20178) Introduce param-free IgniteInternalFuture.listen(() -> {}) in addition to .listen((fut) -> {}) to avoid ignored params
[
https://issues.apache.org/jira/browse/IGNITE-20178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17753107#comment-17753107
]
Ignite TC Bot commented on IGNITE-20178:
{panel:title=Branch: [pull/10885/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10885/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7295033&buildTypeId=IgniteTests24Java8_RunAll]
> Introduce param-free IgniteInternalFuture.listen(() -> {}) in addition to
> .listen((fut) -> {}) to avoid ignored params
> --
>
> Key: IGNITE-20178
> URL: https://issues.apache.org/jira/browse/IGNITE-20178
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Fix For: 2.16
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-20195) Long fsync of Raft log storage
Denis Chudov created IGNITE-20195: - Summary: Long fsync of Raft log storage Key: IGNITE-20195 URL: https://issues.apache.org/jira/browse/IGNITE-20195 Project: Ignite Issue Type: Bug Reporter: Denis Chudov Under intensive transactional load (see test [1]) the duration of fsync of Raft log storage [2] can exceed 1 second on local test runs. [1] ItTxDistributedTestThreeNodesThreeReplicas#testBalance [2] RocksDbSharedLogStorage#commitWriteBatch -- This message was sent by Atlassian Jira (v8.20.10#820010)
