[jira] [Assigned] (IGNITE-22883) Send all cluster IDs to thin client on connection
[ https://issues.apache.org/jira/browse/IGNITE-22883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy reassigned IGNITE-22883: -- Assignee: Roman Puchkovskiy > Send all cluster IDs to thin client on connection > - > > Key: IGNITE-22883 > URL: https://issues.apache.org/jira/browse/IGNITE-22883 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: iep-128, ignite-3 > > After IGNITE-22807 and IGNITE-22882 are implemented, we should start sending > all cluster IDs (all previous ones and the current one) to a thin client when > it connects a server node. > Also, a test has to be added for the following scenario: > # A cluster is initialized > # A thin client is connected to the cluster (and does something like making > a put) > # CMG is reset on the cluster > # The thin client should still work (a get should succeed) without a restart -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22741) DB API Driver 3: Implement simple data fetching
[
https://issues.apache.org/jira/browse/IGNITE-22741?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878748#comment-17878748
]
Pavel Tupitsyn commented on IGNITE-22741:
-
[~isapego] looks good to me.
> DB API Driver 3: Implement simple data fetching
> ---
>
> Key: IGNITE-22741
> URL: https://issues.apache.org/jira/browse/IGNITE-22741
> Project: Ignite
> Issue Type: Improvement
> Components: platforms, python, thin client
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Let's add an ability to fetch queried data from cursor.
> At least the following methods should be implemented:
> {code:python}
> pyignite3.Cursor.fetchone()
> {code}
> The following methods can be implemented as the part of this ticket, or a
> separate ticket for them should be created:
> {code:python}
> pyignite3.Cursor.fetchmany()
> pyignite3.Cursor.fetchall()
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23129) .NET: Thin 3.0: TestJobExecutionCancel is flaky
[
https://issues.apache.org/jira/browse/IGNITE-23129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-23129:
Description:
{code}
System.ArgumentException : Cannot compare to a null reference. (Parameter
'actual')
at NUnit.Framework.Guard.ArgumentValid(Boolean condition, String message,
String paramName)
at NUnit.Framework.Constraints.ComparisonConstraint.ApplyTo[TActual](TActual
actual)
at NUnit.Framework.Assert.That[TActual](TActual actual, IResolveConstraint
expression, String message, Object[] args)
at NUnit.Framework.Assert.Greater(IComparable arg1, IComparable arg2)
at
Apache.Ignite.Tests.Compute.ComputeTests.AssertJobStatus[T](IJobExecution`1
jobExecution, JobStatus status, Instant beforeStart) in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Compute/ComputeTests.cs:line
891
at Apache.Ignite.Tests.Compute.ComputeTests.TestJobExecutionCancel() in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Compute/ComputeTests.cs:line
645
{code}
https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunNetTests/8445947?expandBuildDeploymentsSection=false&hideTestsFromDependencies=false&hideProblemsFromDependencies=false&expandBuildTestsSection=true&expandBuildChangesSection=true
was:
{code}
System.ArgumentException : Cannot compare to a null reference. (Parameter
'actual')
at NUnit.Framework.Guard.ArgumentValid(Boolean condition, String message,
String paramName)
at NUnit.Framework.Constraints.ComparisonConstraint.ApplyTo[TActual](TActual
actual)
at NUnit.Framework.Assert.That[TActual](TActual actual, IResolveConstraint
expression, String message, Object[] args)
at NUnit.Framework.Assert.Greater(IComparable arg1, IComparable arg2)
at
Apache.Ignite.Tests.Compute.ComputeTests.AssertJobStatus[T](IJobExecution`1
jobExecution, JobStatus status, Instant beforeStart) in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Compute/ComputeTests.cs:line
891
at Apache.Ignite.Tests.Compute.ComputeTests.TestJobExecutionCancel() in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Compute/ComputeTests.cs:line
645
{code}
> .NET: Thin 3.0: TestJobExecutionCancel is flaky
> ---
>
> Key: IGNITE-23129
> URL: https://issues.apache.org/jira/browse/IGNITE-23129
> Project: Ignite
> Issue Type: Bug
> Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>
> {code}
> System.ArgumentException : Cannot compare to a null reference. (Parameter
> 'actual')
>at NUnit.Framework.Guard.ArgumentValid(Boolean condition, String message,
> String paramName)
>at
> NUnit.Framework.Constraints.ComparisonConstraint.ApplyTo[TActual](TActual
> actual)
>at NUnit.Framework.Assert.That[TActual](TActual actual, IResolveConstraint
> expression, String message, Object[] args)
>at NUnit.Framework.Assert.Greater(IComparable arg1, IComparable arg2)
>at
> Apache.Ignite.Tests.Compute.ComputeTests.AssertJobStatus[T](IJobExecution`1
> jobExecution, JobStatus status, Instant beforeStart) in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Compute/ComputeTests.cs:line
> 891
>at Apache.Ignite.Tests.Compute.ComputeTests.TestJobExecutionCancel() in
> /opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Compute/ComputeTests.cs:line
> 645
> {code}
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunNetTests/8445947?expandBuildDeploymentsSection=false&hideTestsFromDependencies=false&hideProblemsFromDependencies=false&expandBuildTestsSection=true&expandBuildChangesSection=true
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-23129) .NET: Thin 3.0: TestJobExecutionCancel is flaky
Pavel Tupitsyn created IGNITE-23129:
---
Summary: .NET: Thin 3.0: TestJobExecutionCancel is flaky
Key: IGNITE-23129
URL: https://issues.apache.org/jira/browse/IGNITE-23129
Project: Ignite
Issue Type: Bug
Components: platforms, thin client
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 3.0.0-beta2
{code}
System.ArgumentException : Cannot compare to a null reference. (Parameter
'actual')
at NUnit.Framework.Guard.ArgumentValid(Boolean condition, String message,
String paramName)
at NUnit.Framework.Constraints.ComparisonConstraint.ApplyTo[TActual](TActual
actual)
at NUnit.Framework.Assert.That[TActual](TActual actual, IResolveConstraint
expression, String message, Object[] args)
at NUnit.Framework.Assert.Greater(IComparable arg1, IComparable arg2)
at
Apache.Ignite.Tests.Compute.ComputeTests.AssertJobStatus[T](IJobExecution`1
jobExecution, JobStatus status, Instant beforeStart) in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Compute/ComputeTests.cs:line
891
at Apache.Ignite.Tests.Compute.ComputeTests.TestJobExecutionCancel() in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Compute/ComputeTests.cs:line
645
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22942) NodeFinder should be able to resolve multiple IP addresses under the same host name
[ https://issues.apache.org/jira/browse/IGNITE-22942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878760#comment-17878760 ] Roman Puchkovskiy commented on IGNITE-22942: Now, if a name (not an address) is provided in the original list, it's being resolved to addresses. If it resolves to none, it just contributes nothing to the output. If it resolves to more than one address, all of them are included in the result. This will allow `StaticNodeFinder` to be more useful in Kubernetes environments. > NodeFinder should be able to resolve multiple IP addresses under the same > host name > --- > > Key: IGNITE-22942 > URL: https://issues.apache.org/jira/browse/IGNITE-22942 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtsev >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > It would be useful to have a NodeFinder that will be able to resolve multiple > IP addresses that are hidden behind a single host name. This is required to > better target Kubernetes with its [Headless > Services|https://kubernetes.io/docs/concepts/services-networking/service/#headless-services]. > As a solution we may provide either a new NodeFinder implementation that will > resolve such addresses, or augment the StaticNodeFinder's behavior. The > latter is preferable from the UX POV. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-22942) NodeFinder should be able to resolve multiple IP addresses under the same host name
[ https://issues.apache.org/jira/browse/IGNITE-22942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878760#comment-17878760 ] Roman Puchkovskiy edited comment on IGNITE-22942 at 9/3/24 7:52 AM: Now, if a name (not an address) is provided in the original list, it's being resolved to addresses. If it resolves to none, it just contributes nothing to the output. If it resolves to more than one address, all of them are included in the result. This will allow StaticNodeFinder to be more useful in Kubernetes environments. was (Author: rpuch): Now, if a name (not an address) is provided in the original list, it's being resolved to addresses. If it resolves to none, it just contributes nothing to the output. If it resolves to more than one address, all of them are included in the result. This will allow `StaticNodeFinder` to be more useful in Kubernetes environments. > NodeFinder should be able to resolve multiple IP addresses under the same > host name > --- > > Key: IGNITE-22942 > URL: https://issues.apache.org/jira/browse/IGNITE-22942 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtsev >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > It would be useful to have a NodeFinder that will be able to resolve multiple > IP addresses that are hidden behind a single host name. This is required to > better target Kubernetes with its [Headless > Services|https://kubernetes.io/docs/concepts/services-networking/service/#headless-services]. > As a solution we may provide either a new NodeFinder implementation that will > resolve such addresses, or augment the StaticNodeFinder's behavior. The > latter is preferable from the UX POV. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19882) Sql. Queries that access columns of type DECIMAL do not pick index, when compared with INT/BIGINT.
[
https://issues.apache.org/jira/browse/IGNITE-19882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky reassigned IGNITE-19882:
---
Assignee: Evgeny Stanilovsky
> Sql. Queries that access columns of type DECIMAL do not pick index, when
> compared with INT/BIGINT.
> --
>
> Key: IGNITE-19882
> URL: https://issues.apache.org/jira/browse/IGNITE-19882
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Maksim Zhuravkov
>Assignee: Evgeny Stanilovsky
>Priority: Minor
> Labels: ignite-3
>
> When decimal column is compared with literal/dynamic parameter of integral
> numeric type, index is not picked:
> {code:java}
> sql("CREATE TABLE t_dec (ID INTEGER PRIMARY KEY, VAL DECIMAL(5,3))");
> sql("CREATE INDEX t_dec_idx ON t_dec(VAL)");
> sql("INSERT INTO t_dec VALUES (1, 42)");
> // 1 passes
> assertQuery("SELECT id FROM t_dec WHERE val = 42.000")
> .matches(containsIndexScan("PUBLIC", "T_DEC", "T_DEC_IDX"))
> .returns(1)
> .check();
> // 2 passes
> assertQuery("SELECT id FROM t_dec WHERE val = 42::DECIMAL(5,3)")
>.matches(containsIndexScan("PUBLIC", "T_DEC", "T_DEC_IDX"))
>.returns(1)
>.check();
> // 3 fails
> assertQuery("SELECT id FROM t_dec WHERE val = 42")
> .matches(containsIndexScan("PUBLIC", "T_DEC", "T_DEC_IDX"))
> .returns(1)
> .check();
> // 4 fails
> assertQuery("SELECT id FROM t_dec WHERE val = ?")
> .withParams(42)
> .matches(containsIndexScan("PUBLIC", "T_DEC", "T_DEC_IDX"))
> .returns(1)
> .check();
> // 5 fails
> assertQuery("SELECT id FROM t_dec WHERE val = ?")
> .withParams(42L)
> .matches(containsIndexScan("PUBLIC", "T_DEC", "T_DEC_IDX"))
> .returns(1)
> .check();
> {code}
> Expected behaviour: Queries 3, 4, 5 should use an index.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23125) AssertionError: Unexpected primary replica state STOPPED in ItRestartPartitionsCommandTest.testRestartAllPartitions
[ https://issues.apache.org/jira/browse/IGNITE-23125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-23125: -- Description: This assertion happens when ReplicaStateManager gets an event notification about primary replica elected, and replica is already stopped. Usually, replica is reserved as primary at the moment when this notification is gotten (and there is clear HB), and cannot be stopped because of assignments change if it is reserved as primary. But it can be stopped because of replica restart (which happens in this test) and this assertion doesn't take into account this reason. It seems that this assertion is invalid and can be removed. Other solution may be adding special "restarting" flag to know that the primary is being restarted while asserting. See ReplicaManager.ReplicaStateManager#onPrimaryElected. was: This assertion happens when ReplicaStateManager gets an event notification about primary replica elected, and replica is already stopped. Usually, replica is reserved as primary at the moment when this notification is gotten (and there is clear HB), and cannot be stopped because of assignments change if it is reserved as primary. But it can be stopped because of replica restart (which happens in this test) and this assertion doesn't take into account this reason. It seems that this assertion is invalid and can be removed. See ReplicaManager.ReplicaStateManager#onPrimaryElected. > AssertionError: Unexpected primary replica state STOPPED in > ItRestartPartitionsCommandTest.testRestartAllPartitions > --- > > Key: IGNITE-23125 > URL: https://issues.apache.org/jira/browse/IGNITE-23125 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > This assertion happens when ReplicaStateManager gets an event notification > about primary replica elected, and replica is already stopped. Usually, > replica is reserved as primary at the moment when this notification is gotten > (and there is clear HB), and cannot be stopped because of assignments change > if it is reserved as primary. But it can be stopped because of replica > restart (which happens in this test) and this assertion doesn't take into > account this reason. > It seems that this assertion is invalid and can be removed. > Other solution may be adding special "restarting" flag to know that the > primary is being restarted while asserting. > See ReplicaManager.ReplicaStateManager#onPrimaryElected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-23130) Sql. Typeof for TIMESTAMP return not well formed name
Iurii Gerzhedovich created IGNITE-23130: --- Summary: Sql. Typeof for TIMESTAMP return not well formed name Key: IGNITE-23130 URL: https://issues.apache.org/jira/browse/IGNITE-23130 Project: Ignite Issue Type: Improvement Components: sql Reporter: Iurii Gerzhedovich SELECT typeof(?) with a TIMESTAMP dynamic parameter returns TIMESTAMP_WITH_LOCAL_TIME_ZONE(6) instead of TIMESTAMP WITH LOCAL TIME ZONE (6) Points of interest are: org.apache.ignite.internal.sql.engine.exec.exp.RexImpTable.Builder.IgniteSystemFunctionImplementor#createTypeOfImplementor org.apache.ignite.internal.sql.engine.ItDynamicParameterTest#testMetadataTypesForDynamicParameters Let's fix it -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23130) Sql. Typeof for TIMESTAMP return not well formed name
[ https://issues.apache.org/jira/browse/IGNITE-23130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich updated IGNITE-23130: Description: SELECT typeof( ? ) with a TIMESTAMP dynamic parameter returns TIMESTAMP_WITH_LOCAL_TIME_ZONE(6) instead of TIMESTAMP WITH LOCAL TIME ZONE (6) Points of interest are: org.apache.ignite.internal.sql.engine.exec.exp.RexImpTable.Builder.IgniteSystemFunctionImplementor#createTypeOfImplementor org.apache.ignite.internal.sql.engine.ItDynamicParameterTest#testMetadataTypesForDynamicParameters Let's fix it was: SELECT typeof(?) with a TIMESTAMP dynamic parameter returns TIMESTAMP_WITH_LOCAL_TIME_ZONE(6) instead of TIMESTAMP WITH LOCAL TIME ZONE (6) Points of interest are: org.apache.ignite.internal.sql.engine.exec.exp.RexImpTable.Builder.IgniteSystemFunctionImplementor#createTypeOfImplementor org.apache.ignite.internal.sql.engine.ItDynamicParameterTest#testMetadataTypesForDynamicParameters Let's fix it > Sql. Typeof for TIMESTAMP return not well formed name > - > > Key: IGNITE-23130 > URL: https://issues.apache.org/jira/browse/IGNITE-23130 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Iurii Gerzhedovich >Priority: Major > Labels: ignite-3 > > SELECT typeof( ? ) with a TIMESTAMP dynamic parameter returns > TIMESTAMP_WITH_LOCAL_TIME_ZONE(6) instead of TIMESTAMP WITH LOCAL TIME ZONE > (6) > Points of interest are: > org.apache.ignite.internal.sql.engine.exec.exp.RexImpTable.Builder.IgniteSystemFunctionImplementor#createTypeOfImplementor > org.apache.ignite.internal.sql.engine.ItDynamicParameterTest#testMetadataTypesForDynamicParameters > > Let's fix it -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-23073) Sql. Constant default value is not implemented for UUID data type
[
https://issues.apache.org/jira/browse/IGNITE-23073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878772#comment-17878772
]
Maksim Zhuravkov commented on IGNITE-23073:
---
Looks like an optimization in IGNITE-22765 has caused this issue.
{noformat}
Caused by: java.lang.IllegalArgumentException
at
com.google.common.base.Preconditions.checkArgument(Preconditions.java:129)
at org.apache.calcite.rex.RexLiteral.(RexLiteral.java:234)
at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:1098)
at
org.apache.ignite.internal.sql.engine.rex.IgniteRexBuilder.makeLiteral(IgniteRexBuilder.java:55)
at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:1664)
at
org.apache.ignite.internal.sql.engine.schema.TableDescriptorImpl.newColumnDefaultValue(TableDescriptorImpl.java:135)
at
org.apache.ignite.internal.sql.engine.prepare.PlannerHelper.tryOptimizeInsert(PlannerHelper.java:269)
at
org.apache.ignite.internal.sql.engine.prepare.PlannerHelper.tryOptimizeFast(PlannerHelper.java:208)
at
org.apache.ignite.internal.sql.engine.prepare.PlannerHelper.optimize(PlannerHelper.java:113)
at
org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.doOptimize(PrepareServiceImpl.java:675)
{noformat}
> Sql. Constant default value is not implemented for UUID data type
> -
>
> Key: IGNITE-23073
> URL: https://issues.apache.org/jira/browse/IGNITE-23073
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: ignite-3
>
> In SQL, it's possible to define default values for some columns. These values
> would be used on insertion when explicit values are omitted. For example:
> {code:sql}
> sql-cli> create table def_time(key INTEGER not null, val TIME not null
> default '12:12:12', primary key (key));
> sql-cli> insert into def_time (key) values (1);
> sql-cli> select * from def_time;
> ╔═╤══╗
> ║ KEY │ VAL ║
> ╠═╪══╣
> ║ 1 │ 12:12:12 ║
> ╚═╧══╝
> {code}
> But it's not true for *UUID* data type. It's possible to "define" default
> value for this type, but it's not actually applied as default:
> {code:sql}
> sql-cli> create table def_uuid(key INTEGER not null, val UUID not null
> default '4a2f1859-c73b-4eec-a29c-629ec68d8735', primary key (key));
> sql-cli> insert into def_uuid(key) values (1);
> Unknown error
> null
> {code}
> Only explicit UUID values are currently supported:
> {code:sql}
> sql-cli> insert into def_uuid values (2,
> '46e438c5-4722-4806-8614-e5aa15b9ded8');
> Updated 1 rows.
> sql-cli> select * from def_uuid;
> ╔═╤══╗
> ║ KEY │ VAL ║
> ╠═╪══╣
> ║ 2 │ 46e438c5-4722-4806-8614-e5aa15b9ded8 ║
> ╚═╧══╝
> {code}
> Found on `06f62ebd7abb76f9c24d171cf03bad26f21436ca`.
> Probably, it's simply a non-implemented-yet feature (as UUID-related epic is
> not completely finished yet). In that case, feel free to trasnform this
> ticket from bug into a feature request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-23073) Sql. Constant default value is not implemented for UUID data type
[
https://issues.apache.org/jira/browse/IGNITE-23073?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878772#comment-17878772
]
Maksim Zhuravkov edited comment on IGNITE-23073 at 9/3/24 8:54 AM:
---
Looks like an optimization in IGNITE-22765 has caused this issue.
{noformat}
Caused by: java.lang.IllegalArgumentException
at
com.google.common.base.Preconditions.checkArgument(Preconditions.java:129)
at org.apache.calcite.rex.RexLiteral.(RexLiteral.java:234)
at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:1098)
at
org.apache.ignite.internal.sql.engine.rex.IgniteRexBuilder.makeLiteral(IgniteRexBuilder.java:55)
at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:1664)
at
org.apache.ignite.internal.sql.engine.schema.TableDescriptorImpl.newColumnDefaultValue(TableDescriptorImpl.java:135)
at
org.apache.ignite.internal.sql.engine.prepare.PlannerHelper.tryOptimizeInsert(PlannerHelper.java:269)
at
org.apache.ignite.internal.sql.engine.prepare.PlannerHelper.tryOptimizeFast(PlannerHelper.java:208)
at
org.apache.ignite.internal.sql.engine.prepare.PlannerHelper.optimize(PlannerHelper.java:113)
at
org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.doOptimize(PrepareServiceImpl.java:675)
{noformat}
We can update TableDescriptor to return a cast from a UUID string (because
there is no UUID literal) to fix this.
was (Author: JIRAUSER298618):
Looks like an optimization in IGNITE-22765 has caused this issue.
{noformat}
Caused by: java.lang.IllegalArgumentException
at
com.google.common.base.Preconditions.checkArgument(Preconditions.java:129)
at org.apache.calcite.rex.RexLiteral.(RexLiteral.java:234)
at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:1098)
at
org.apache.ignite.internal.sql.engine.rex.IgniteRexBuilder.makeLiteral(IgniteRexBuilder.java:55)
at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:1664)
at
org.apache.ignite.internal.sql.engine.schema.TableDescriptorImpl.newColumnDefaultValue(TableDescriptorImpl.java:135)
at
org.apache.ignite.internal.sql.engine.prepare.PlannerHelper.tryOptimizeInsert(PlannerHelper.java:269)
at
org.apache.ignite.internal.sql.engine.prepare.PlannerHelper.tryOptimizeFast(PlannerHelper.java:208)
at
org.apache.ignite.internal.sql.engine.prepare.PlannerHelper.optimize(PlannerHelper.java:113)
at
org.apache.ignite.internal.sql.engine.prepare.PrepareServiceImpl.doOptimize(PrepareServiceImpl.java:675)
{noformat}
> Sql. Constant default value is not implemented for UUID data type
> -
>
> Key: IGNITE-23073
> URL: https://issues.apache.org/jira/browse/IGNITE-23073
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: ignite-3
>
> In SQL, it's possible to define default values for some columns. These values
> would be used on insertion when explicit values are omitted. For example:
> {code:sql}
> sql-cli> create table def_time(key INTEGER not null, val TIME not null
> default '12:12:12', primary key (key));
> sql-cli> insert into def_time (key) values (1);
> sql-cli> select * from def_time;
> ╔═╤══╗
> ║ KEY │ VAL ║
> ╠═╪══╣
> ║ 1 │ 12:12:12 ║
> ╚═╧══╝
> {code}
> But it's not true for *UUID* data type. It's possible to "define" default
> value for this type, but it's not actually applied as default:
> {code:sql}
> sql-cli> create table def_uuid(key INTEGER not null, val UUID not null
> default '4a2f1859-c73b-4eec-a29c-629ec68d8735', primary key (key));
> sql-cli> insert into def_uuid(key) values (1);
> Unknown error
> null
> {code}
> Only explicit UUID values are currently supported:
> {code:sql}
> sql-cli> insert into def_uuid values (2,
> '46e438c5-4722-4806-8614-e5aa15b9ded8');
> Updated 1 rows.
> sql-cli> select * from def_uuid;
> ╔═╤══╗
> ║ KEY │ VAL ║
> ╠═╪══╣
> ║ 2 │ 46e438c5-4722-4806-8614-e5aa15b9ded8 ║
> ╚═╧══╝
> {code}
> Found on `06f62ebd7abb76f9c24d171cf03bad26f21436ca`.
> Probably, it's simply a non-implemented-yet feature (as UUID-related epic is
> not completely finished yet). In that case, feel free to trasnform this
> ticket from bug into a feature request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-23131) java.lang.AssertionError: The local node is outside of the replication group
Mirza Aliev created IGNITE-23131:
Summary: java.lang.AssertionError: The local node is outside of
the replication group
Key: IGNITE-23131
URL: https://issues.apache.org/jira/browse/IGNITE-23131
Project: Ignite
Issue Type: Bug
Reporter: Mirza Aliev
Attachments: _Integration_Tests_Run_All_Other_27436.log.zip
We've started to receive a lot of {{AssertionError}} during TC builds on main.
These exceptions do not lead to failed tests, but must be investigated.
{noformat}
[2024-09-02T12:09:05,392][WARN
][%irlt_trisons_20002%tableManager-io-19][PartitionReplicaLifecycleManager]
Unable to process pending assignments event
java.lang.AssertionError: The local node is outside of the replication group [,
stable=Assignments [nodes=HashSet [Assignment [consistentId=irlt_trisons_2,
isPeer=true]], force=false, timestamp=113067880806875136], pending=Assignments
[nodes=HashSet [Assignment [consistentId=irlt_trisons_20002, isPeer=true]],
force=false, timestamp=113067880806875136], reduce=null,
localName=irlt_trisons_20002].
at
org.apache.ignite.internal.partition.replicator.PartitionReplicaLifecycleManager.isNodeInReducedStableOrPendingAssignments(PartitionReplicaLifecycleManager.java:1175)
~[ignite-partition-replicator-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.partition.replicator.PartitionReplicaLifecycleManager.lambda$handleChangePendingAssignmentEvent$48(PartitionReplicaLifecycleManager.java:1015)
~[ignite-partition-replicator-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.util.IgniteUtils.inBusyLock(IgniteUtils.java:872)
~[ignite-core-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.partition.replicator.PartitionReplicaLifecycleManager.lambda$handleChangePendingAssignmentEvent$49(PartitionReplicaLifecycleManager.java:1014)
~[ignite-partition-replicator-3.0.0-SNAPSHOT.jar:?]
at
java.base/java.util.concurrent.CompletableFuture$UniAccept.tryFire(CompletableFuture.java:714)
[?:?]
at
java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?]
at java.base/java.lang.Thread.run(Thread.java:834) [?:?]
{noformat}
https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8444342?expandBuildDeploymentsSection=false&hideTestsFromDependencies=false&hideProblemsFromDependencies=false&expandBuildProblemsSection=true&expandCode+Inspection=true&expandBuildChangesSection=true&logFilter=debug&logView=flowAware
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-23132) java.lang.NullPointerException: null in LogId.compareTo when handle vote request
Mirza Aliev created IGNITE-23132:
Summary: java.lang.NullPointerException: null in LogId.compareTo
when handle vote request
Key: IGNITE-23132
URL: https://issues.apache.org/jira/browse/IGNITE-23132
Project: Ignite
Issue Type: Bug
Reporter: Mirza Aliev
Attachments: _Integration_Tests_Module_Table_27645.log.zip
TC main has started to detect NullPointerException in builds logs. This happens
in {{ItEstimatedSizeTest#testEstimatedSize}}, seems like it happens when node
has already been stopped, but still handle vote request with already cleared
states. We need to figure out and fix NPE.
{noformat}
[2024-08-30T13:58:43,614][ERROR][%iest_tes_1%JRaft-Request-Processor-13][RpcRequestProcessor]
handleRequest RequestVoteRequestImpl [groupId=12_part_10, lastLogIndex=193,
lastLogTerm=1, peerId=iest_tes_1, preVote=false, serverId=iest_tes_2, term=2]
failed
java.lang.NullPointerException: null
at org.apache.ignite.raft.jraft.entity.LogId.compareTo(LogId.java:91)
~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.raft.jraft.core.NodeImpl.handleRequestVoteRequest(NodeImpl.java:2071)
~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.raft.jraft.rpc.impl.core.RequestVoteRequestProcessor.processRequest0(RequestVoteRequestProcessor.java:52)
~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.raft.jraft.rpc.impl.core.RequestVoteRequestProcessor.processRequest0(RequestVoteRequestProcessor.java:29)
~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.raft.jraft.rpc.impl.core.NodeRequestProcessor.processRequest(NodeRequestProcessor.java:55)
~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.raft.jraft.rpc.RpcRequestProcessor.handleRequest(RpcRequestProcessor.java:49)
~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.raft.jraft.rpc.RpcRequestProcessor.handleRequest(RpcRequestProcessor.java:29)
~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcServer$RpcMessageHandler.lambda$onReceived$0(IgniteRpcServer.java:181)
~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?]
at java.base/java.lang.Thread.run(Thread.java:834) [?:?]
{noformat}
https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8439410?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildChangesSection=true&expandBuildDeploymentsSection=false&expandBuildProblemsSection=true&logFilter=debug&logView=flowAware
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23132) java.lang.NullPointerException: null in LogId.compareTo when handle vote request
[
https://issues.apache.org/jira/browse/IGNITE-23132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-23132:
-
Epic Link: IGNITE-21389
> java.lang.NullPointerException: null in LogId.compareTo when handle vote
> request
>
>
> Key: IGNITE-23132
> URL: https://issues.apache.org/jira/browse/IGNITE-23132
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Attachments: _Integration_Tests_Module_Table_27645.log.zip
>
>
> TC main has started to detect NullPointerException in builds logs. This
> happens in {{ItEstimatedSizeTest#testEstimatedSize}}, seems like it happens
> when node has already been stopped, but still handle vote request with
> already cleared states. We need to figure out and fix NPE.
> {noformat}
> [2024-08-30T13:58:43,614][ERROR][%iest_tes_1%JRaft-Request-Processor-13][RpcRequestProcessor]
> handleRequest RequestVoteRequestImpl [groupId=12_part_10, lastLogIndex=193,
> lastLogTerm=1, peerId=iest_tes_1, preVote=false, serverId=iest_tes_2, term=2]
> failed
> java.lang.NullPointerException: null
> at org.apache.ignite.raft.jraft.entity.LogId.compareTo(LogId.java:91)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.core.NodeImpl.handleRequestVoteRequest(NodeImpl.java:2071)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.rpc.impl.core.RequestVoteRequestProcessor.processRequest0(RequestVoteRequestProcessor.java:52)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.rpc.impl.core.RequestVoteRequestProcessor.processRequest0(RequestVoteRequestProcessor.java:29)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.rpc.impl.core.NodeRequestProcessor.processRequest(NodeRequestProcessor.java:55)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.rpc.RpcRequestProcessor.handleRequest(RpcRequestProcessor.java:49)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.rpc.RpcRequestProcessor.handleRequest(RpcRequestProcessor.java:29)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcServer$RpcMessageHandler.lambda$onReceived$0(IgniteRpcServer.java:181)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.base/java.lang.Thread.run(Thread.java:834) [?:?]
> {noformat}
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8439410?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildChangesSection=true&expandBuildDeploymentsSection=false&expandBuildProblemsSection=true&logFilter=debug&logView=flowAware
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23133) Java thin 3.0: Flaky NPE in TcpClientChannel.handshakeRes
[
https://issues.apache.org/jira/browse/IGNITE-23133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-23133:
Description:
{code}
[2024-09-03T09:13:45,181][ERROR][ForkJoinPool.commonPool-worker-3][TcpClientChannel]
Failed to deserialize server response [remoteAddress=127.0.0.1:10801]: null
java.lang.NullPointerException: null
at
org.apache.ignite.internal.client.TcpClientChannel.handshakeRes(TcpClientChannel.java:663)
~[ignite-client-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.client.TcpClientChannel.lambda$handshakeAsync$5(TcpClientChannel.java:585)
~[ignite-client-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.client.TcpClientChannel.complete(TcpClientChannel.java:407)
~[ignite-client-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.client.TcpClientChannel.processNextMessage(TcpClientChannel.java:424)
~[ignite-client-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.client.TcpClientChannel.lambda$onMessage$3(TcpClientChannel.java:276)
~[ignite-client-3.0.0-SNAPSHOT.jar:?]
at
java.base/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1426)
[?:?]
at
java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290) [?:?]
at
java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
[?:?]
at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
[?:?]
at
java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
[?:?]
at
java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
[?:?]
{code}
> Java thin 3.0: Flaky NPE in TcpClientChannel.handshakeRes
> -
>
> Key: IGNITE-23133
> URL: https://issues.apache.org/jira/browse/IGNITE-23133
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> {code}
>
> [2024-09-03T09:13:45,181][ERROR][ForkJoinPool.commonPool-worker-3][TcpClientChannel]
> Failed to deserialize server response [remoteAddress=127.0.0.1:10801]: null
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.client.TcpClientChannel.handshakeRes(TcpClientChannel.java:663)
> ~[ignite-client-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.TcpClientChannel.lambda$handshakeAsync$5(TcpClientChannel.java:585)
> ~[ignite-client-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.TcpClientChannel.complete(TcpClientChannel.java:407)
> ~[ignite-client-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.TcpClientChannel.processNextMessage(TcpClientChannel.java:424)
> ~[ignite-client-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.TcpClientChannel.lambda$onMessage$3(TcpClientChannel.java:276)
> ~[ignite-client-3.0.0-SNAPSHOT.jar:?]
> at
> java.base/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1426)
> [?:?]
> at
> java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
> [?:?]
> at
> java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
> [?:?]
> at
> java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656) [?:?]
> at
> java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
> [?:?]
> at
> java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
> [?:?]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-23133) Java thin 3.0: Flaky NPE in TcpClientChannel.handshakeRes
Pavel Tupitsyn created IGNITE-23133: --- Summary: Java thin 3.0: Flaky NPE in TcpClientChannel.handshakeRes Key: IGNITE-23133 URL: https://issues.apache.org/jira/browse/IGNITE-23133 Project: Ignite Issue Type: Bug Components: thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23133) Java thin 3.0: Flaky NPE in TcpClientChannel.handshakeRes
[
https://issues.apache.org/jira/browse/IGNITE-23133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-23133:
Description:
{code}
[2024-09-03T09:13:45,181][ERROR][ForkJoinPool.commonPool-worker-3][TcpClientChannel]
Failed to deserialize server response [remoteAddress=127.0.0.1:10801]: null
java.lang.NullPointerException: null
at
org.apache.ignite.internal.client.TcpClientChannel.handshakeRes(TcpClientChannel.java:663)
~[ignite-client-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.client.TcpClientChannel.lambda$handshakeAsync$5(TcpClientChannel.java:585)
~[ignite-client-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.client.TcpClientChannel.complete(TcpClientChannel.java:407)
~[ignite-client-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.client.TcpClientChannel.processNextMessage(TcpClientChannel.java:424)
~[ignite-client-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.client.TcpClientChannel.lambda$onMessage$3(TcpClientChannel.java:276)
~[ignite-client-3.0.0-SNAPSHOT.jar:?]
at
java.base/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1426)
[?:?]
at
java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290) [?:?]
at
java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
[?:?]
at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
[?:?]
at
java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
[?:?]
at
java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
[?:?]
{code}
https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_IntegrationTests_ModuleRunner/8446381?hideTestsFromDependencies=false&hideProblemsFromDependencies=false&expandBuildDeploymentsSection=false&expandBuildProblemsSection=true&expandBuildChangesSection=true
Looks like *sock.remoteAddress()* can return null.
was:
{code}
[2024-09-03T09:13:45,181][ERROR][ForkJoinPool.commonPool-worker-3][TcpClientChannel]
Failed to deserialize server response [remoteAddress=127.0.0.1:10801]: null
java.lang.NullPointerException: null
at
org.apache.ignite.internal.client.TcpClientChannel.handshakeRes(TcpClientChannel.java:663)
~[ignite-client-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.client.TcpClientChannel.lambda$handshakeAsync$5(TcpClientChannel.java:585)
~[ignite-client-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.client.TcpClientChannel.complete(TcpClientChannel.java:407)
~[ignite-client-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.client.TcpClientChannel.processNextMessage(TcpClientChannel.java:424)
~[ignite-client-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.client.TcpClientChannel.lambda$onMessage$3(TcpClientChannel.java:276)
~[ignite-client-3.0.0-SNAPSHOT.jar:?]
at
java.base/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1426)
[?:?]
at
java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290) [?:?]
at
java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
[?:?]
at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
[?:?]
at
java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
[?:?]
at
java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
[?:?]
{code}
https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_IntegrationTests_ModuleRunner/8446381?hideTestsFromDependencies=false&hideProblemsFromDependencies=false&expandBuildDeploymentsSection=false&expandBuildProblemsSection=true&expandBuildChangesSection=true
> Java thin 3.0: Flaky NPE in TcpClientChannel.handshakeRes
> -
>
> Key: IGNITE-23133
> URL: https://issues.apache.org/jira/browse/IGNITE-23133
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> {code}
>
> [2024-09-03T09:13:45,181][ERROR][ForkJoinPool.commonPool-worker-3][TcpClientChannel]
> Failed to deserialize server response [remoteAddress=127.0.0.1:10801]: null
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.client.TcpClientChannel.handshakeRes(TcpClientChannel.java:663)
> ~[ignite-client-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.TcpClientChannel.lambda$handshakeAsync$5(TcpClientChannel.java:585)
> ~[ignite-client-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.TcpClientChannel.complete(TcpClientChannel.java:407)
> ~[ignite-cl
[jira] [Updated] (IGNITE-23133) Java thin 3.0: Flaky NPE in TcpClientChannel.handshakeRes
[
https://issues.apache.org/jira/browse/IGNITE-23133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-23133:
Description:
{code}
[2024-09-03T09:13:45,181][ERROR][ForkJoinPool.commonPool-worker-3][TcpClientChannel]
Failed to deserialize server response [remoteAddress=127.0.0.1:10801]: null
java.lang.NullPointerException: null
at
org.apache.ignite.internal.client.TcpClientChannel.handshakeRes(TcpClientChannel.java:663)
~[ignite-client-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.client.TcpClientChannel.lambda$handshakeAsync$5(TcpClientChannel.java:585)
~[ignite-client-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.client.TcpClientChannel.complete(TcpClientChannel.java:407)
~[ignite-client-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.client.TcpClientChannel.processNextMessage(TcpClientChannel.java:424)
~[ignite-client-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.client.TcpClientChannel.lambda$onMessage$3(TcpClientChannel.java:276)
~[ignite-client-3.0.0-SNAPSHOT.jar:?]
at
java.base/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1426)
[?:?]
at
java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290) [?:?]
at
java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
[?:?]
at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
[?:?]
at
java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
[?:?]
at
java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
[?:?]
{code}
https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_IntegrationTests_ModuleRunner/8446381?hideTestsFromDependencies=false&hideProblemsFromDependencies=false&expandBuildDeploymentsSection=false&expandBuildProblemsSection=true&expandBuildChangesSection=true
was:
{code}
[2024-09-03T09:13:45,181][ERROR][ForkJoinPool.commonPool-worker-3][TcpClientChannel]
Failed to deserialize server response [remoteAddress=127.0.0.1:10801]: null
java.lang.NullPointerException: null
at
org.apache.ignite.internal.client.TcpClientChannel.handshakeRes(TcpClientChannel.java:663)
~[ignite-client-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.client.TcpClientChannel.lambda$handshakeAsync$5(TcpClientChannel.java:585)
~[ignite-client-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.client.TcpClientChannel.complete(TcpClientChannel.java:407)
~[ignite-client-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.client.TcpClientChannel.processNextMessage(TcpClientChannel.java:424)
~[ignite-client-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.client.TcpClientChannel.lambda$onMessage$3(TcpClientChannel.java:276)
~[ignite-client-3.0.0-SNAPSHOT.jar:?]
at
java.base/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1426)
[?:?]
at
java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290) [?:?]
at
java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
[?:?]
at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
[?:?]
at
java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
[?:?]
at
java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
[?:?]
{code}
> Java thin 3.0: Flaky NPE in TcpClientChannel.handshakeRes
> -
>
> Key: IGNITE-23133
> URL: https://issues.apache.org/jira/browse/IGNITE-23133
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> {code}
>
> [2024-09-03T09:13:45,181][ERROR][ForkJoinPool.commonPool-worker-3][TcpClientChannel]
> Failed to deserialize server response [remoteAddress=127.0.0.1:10801]: null
> java.lang.NullPointerException: null
> at
> org.apache.ignite.internal.client.TcpClientChannel.handshakeRes(TcpClientChannel.java:663)
> ~[ignite-client-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.TcpClientChannel.lambda$handshakeAsync$5(TcpClientChannel.java:585)
> ~[ignite-client-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.TcpClientChannel.complete(TcpClientChannel.java:407)
> ~[ignite-client-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.TcpClientChannel.processNextMessage(TcpClientChannel.java:424)
> ~[ignite-client-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.TcpClientChannel.lambda$onMessage$3(TcpClientChannel.java:276)
> ~[ignite-client-3.0.0-SNAPSHOT.jar:?]
>
[jira] [Updated] (IGNITE-23108) Improve HOCON highlighting in CLI
[ https://issues.apache.org/jira/browse/IGNITE-23108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vadim Pakhnushev updated IGNITE-23108: -- Ignite Flags: Docs Required > Improve HOCON highlighting in CLI > - > > Key: IGNITE-23108 > URL: https://issues.apache.org/jira/browse/IGNITE-23108 > Project: Ignite > Issue Type: Improvement > Components: cli >Reporter: Vadim Pakhnushev >Assignee: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > Attachments: image-2024-08-29-13-53-15-535.png > > Time Spent: 10m > Remaining Estimate: 0h > > When [https://github.com/bonede/tree-sitter-ng/issues/44] is fixed, the HOCON > parser should be used to properly highlight config output in CLI. The only > visible issue now is the wrong highlighting of the enums: > !image-2024-08-29-13-53-15-535.png! -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-23108) Improve HOCON highlighting in CLI
[
https://issues.apache.org/jira/browse/IGNITE-23108?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878796#comment-17878796
]
Vadim Pakhnushev commented on IGNITE-23108:
---
New {{--format}} option was added to control the output format of the
{{node/cluster config show}} commands:
{code:java}
--format= Output format. Valid values - JSON, HOCON
Default: HOCON
{code}
> Improve HOCON highlighting in CLI
> -
>
> Key: IGNITE-23108
> URL: https://issues.apache.org/jira/browse/IGNITE-23108
> Project: Ignite
> Issue Type: Improvement
> Components: cli
>Reporter: Vadim Pakhnushev
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
> Attachments: image-2024-08-29-13-53-15-535.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When [https://github.com/bonede/tree-sitter-ng/issues/44] is fixed, the HOCON
> parser should be used to properly highlight config output in CLI. The only
> visible issue now is the wrong highlighting of the enums:
> !image-2024-08-29-13-53-15-535.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21563) Update developer docs according to the storage profiles feature
[ https://issues.apache.org/jira/browse/IGNITE-21563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-21563: Assignee: Kirill Gusakov (was: Alexander Lapin) > Update developer docs according to the storage profiles feature > --- > > Key: IGNITE-21563 > URL: https://issues.apache.org/jira/browse/IGNITE-21563 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > > Motivation > At the moment we have the several documentation artifacts, which is still use > the datastorage abstraction instead of storage profile one. Also, we need to > update the docs, which desribe the new storage engine creation in the > codebase. > Definition of done > All documents in the github repo, where datastorage approach still exists, > should be rewrited according to the storage profile one. Some known places: > - modules/storage-api/README.md must be reworked (actually it should be > reworked earlier, it is still based on the configuration changes approach) > - docs/_docs/sql-reference/distribution-zones.adoc -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22322) Removal of MVCC WAL record types
[
https://issues.apache.org/jira/browse/IGNITE-22322?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Davydov reassigned IGNITE-22322:
---
Assignee: Maksim Davydov
> Removal of MVCC WAL record types
>
>
> Key: IGNITE-22322
> URL: https://issues.apache.org/jira/browse/IGNITE-22322
> Project: Ignite
> Issue Type: Sub-task
> Components: mvcc
>Reporter: Ilya Shishkov
>Assignee: Maksim Davydov
>Priority: Minor
> Labels: ise
>
> Records type to remove:
> * {{RecordType.MVCC_DATA_PAGE_MARK_UPDATED_RECORD}}
> * {{RecordType.MVCC_DATA_PAGE_NEW_TX_STATE_HINT_UPDATED_RECORD}}
> * {{RecordType.MVCC_DATA_PAGE_TX_STATE_HINT_UPDATED_RECORD}}
> * {{RecordType.MVCC_DATA_RECORD}}
> * {{RecordType.MVCC_TX_RECORD}}
> + test on possible compatibility issues.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-23131) java.lang.AssertionError: The local node is outside of the replication group
[
https://issues.apache.org/jira/browse/IGNITE-23131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev reassigned IGNITE-23131:
Assignee: Mikhail Efremov
> java.lang.AssertionError: The local node is outside of the replication group
>
>
> Key: IGNITE-23131
> URL: https://issues.apache.org/jira/browse/IGNITE-23131
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mikhail Efremov
>Priority: Major
> Labels: ignite-3
> Attachments: _Integration_Tests_Run_All_Other_27436.log.zip
>
>
> We've started to receive a lot of {{AssertionError}} during TC builds on
> main. These exceptions do not lead to failed tests, but must be investigated.
> {noformat}
> [2024-09-02T12:09:05,392][WARN
> ][%irlt_trisons_20002%tableManager-io-19][PartitionReplicaLifecycleManager]
> Unable to process pending assignments event
> java.lang.AssertionError: The local node is outside of the replication group
> [, stable=Assignments [nodes=HashSet [Assignment
> [consistentId=irlt_trisons_2, isPeer=true]], force=false,
> timestamp=113067880806875136], pending=Assignments [nodes=HashSet [Assignment
> [consistentId=irlt_trisons_20002, isPeer=true]], force=false,
> timestamp=113067880806875136], reduce=null, localName=irlt_trisons_20002].
> at
> org.apache.ignite.internal.partition.replicator.PartitionReplicaLifecycleManager.isNodeInReducedStableOrPendingAssignments(PartitionReplicaLifecycleManager.java:1175)
> ~[ignite-partition-replicator-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.partition.replicator.PartitionReplicaLifecycleManager.lambda$handleChangePendingAssignmentEvent$48(PartitionReplicaLifecycleManager.java:1015)
> ~[ignite-partition-replicator-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.util.IgniteUtils.inBusyLock(IgniteUtils.java:872)
> ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.partition.replicator.PartitionReplicaLifecycleManager.lambda$handleChangePendingAssignmentEvent$49(PartitionReplicaLifecycleManager.java:1014)
> ~[ignite-partition-replicator-3.0.0-SNAPSHOT.jar:?]
> at
> java.base/java.util.concurrent.CompletableFuture$UniAccept.tryFire(CompletableFuture.java:714)
> [?:?]
> at
> java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.base/java.lang.Thread.run(Thread.java:834) [?:?]
> {noformat}
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8444342?expandBuildDeploymentsSection=false&hideTestsFromDependencies=false&hideProblemsFromDependencies=false&expandBuildProblemsSection=true&expandCode+Inspection=true&expandBuildChangesSection=true&logFilter=debug&logView=flowAware
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-23132) java.lang.NullPointerException: null in LogId.compareTo when handle vote request
[
https://issues.apache.org/jira/browse/IGNITE-23132?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev reassigned IGNITE-23132:
Assignee: Mirza Aliev
> java.lang.NullPointerException: null in LogId.compareTo when handle vote
> request
>
>
> Key: IGNITE-23132
> URL: https://issues.apache.org/jira/browse/IGNITE-23132
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Attachments: _Integration_Tests_Module_Table_27645.log.zip
>
>
> TC main has started to detect NullPointerException in builds logs. This
> happens in {{ItEstimatedSizeTest#testEstimatedSize}}, seems like it happens
> when node has already been stopped, but still handle vote request with
> already cleared states. We need to figure out and fix NPE.
> {noformat}
> [2024-08-30T13:58:43,614][ERROR][%iest_tes_1%JRaft-Request-Processor-13][RpcRequestProcessor]
> handleRequest RequestVoteRequestImpl [groupId=12_part_10, lastLogIndex=193,
> lastLogTerm=1, peerId=iest_tes_1, preVote=false, serverId=iest_tes_2, term=2]
> failed
> java.lang.NullPointerException: null
> at org.apache.ignite.raft.jraft.entity.LogId.compareTo(LogId.java:91)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.core.NodeImpl.handleRequestVoteRequest(NodeImpl.java:2071)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.rpc.impl.core.RequestVoteRequestProcessor.processRequest0(RequestVoteRequestProcessor.java:52)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.rpc.impl.core.RequestVoteRequestProcessor.processRequest0(RequestVoteRequestProcessor.java:29)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.rpc.impl.core.NodeRequestProcessor.processRequest(NodeRequestProcessor.java:55)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.rpc.RpcRequestProcessor.handleRequest(RpcRequestProcessor.java:49)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.rpc.RpcRequestProcessor.handleRequest(RpcRequestProcessor.java:29)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.raft.jraft.rpc.impl.IgniteRpcServer$RpcMessageHandler.lambda$onReceived$0(IgniteRpcServer.java:181)
> ~[ignite-raft-3.0.0-SNAPSHOT.jar:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.base/java.lang.Thread.run(Thread.java:834) [?:?]
> {noformat}
> https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/8439410?hideProblemsFromDependencies=false&hideTestsFromDependencies=false&expandCode+Inspection=true&expandBuildChangesSection=true&expandBuildDeploymentsSection=false&expandBuildProblemsSection=true&logFilter=debug&logView=flowAware
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22833) Test DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation is flaky
[
https://issues.apache.org/jira/browse/IGNITE-22833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-22833:
-
Epic Link: IGNITE-21389
> Test
> DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation
> is flaky
> -
>
> Key: IGNITE-22833
> URL: https://issues.apache.org/jira/browse/IGNITE-22833
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Attachments:
> _Run_Unit_Tests_auto-generated_Run_Unit_Tests_3_30973.log.zip
>
>
> {noformat}
> [10:10:14] : [:ignite-distribution-zones:test]
> DistributionZoneCausalityDataNodesTest >
> testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation(int,
> int) > [1] 1, 1 STANDARD_ERROR
> [10:10:14] : [:ignite-distribution-zones:test]
> [2024-07-23T10:10:14,100][WARN
> ][%test%metastorage-watch-executor-2][UpdateLogImpl] Unable to process
> catalog event
> [10:10:14] : [:ignite-distribution-zones:test]
> java.lang.NullPointerException: null
> [10:10:14] : [:ignite-distribution-zones:test] at
> org.apache.ignite.internal.distributionzones.DistributionZoneManager.initDataNodesAndTriggerKeysInMetaStorage(DistributionZoneManager.java:527)
> ~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> org.apache.ignite.internal.distributionzones.DistributionZoneManager.onCreateZone(DistributionZoneManager.java:456)
> ~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> org.apache.ignite.internal.distributionzones.DistributionZoneManager.lambda$registerCatalogEventListenersOnStartManagerBusy$37(DistributionZoneManager.java:1396)
> ~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> org.apache.ignite.internal.util.IgniteUtils.inBusyLock(IgniteUtils.java:832)
> ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> org.apache.ignite.internal.distributionzones.DistributionZoneManager.lambda$registerCatalogEventListenersOnStartManagerBusy$38(DistributionZoneManager.java:1395)
> ~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> org.apache.ignite.internal.event.AbstractEventProducer.fireEvent(AbstractEventProducer.java:88)
> ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> org.apache.ignite.internal.catalog.CatalogManagerImpl.access$000(CatalogManagerImpl.java:81)
> ~[ignite-catalog-3.0.0-SNAPSHOT.jar:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:577)
> ~[ignite-catalog-3.0.0-SNAPSHOT.jar:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:544)
> ~[ignite-catalog-3.0.0-SNAPSHOT.jar:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> org.apache.ignite.internal.catalog.storage.UpdateLogImpl$UpdateListener.onUpdate(UpdateLogImpl.java:320)
> ~[ignite-catalog-3.0.0-SNAPSHOT.jar:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> org.apache.ignite.internal.metastorage.server.Watch.onUpdate(Watch.java:67)
> ~[ignite-metastorage-3.0.0-SNAPSHOT.jar:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> org.apache.ignite.internal.metastorage.server.WatchProcessor.notifyWatches(WatchProcessor.java:245)
> ~[ignite-metastorage-3.0.0-SNAPSHOT.jar:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$notifyWatches$4(WatchProcessor.java:193)
> ~[ignite-metastorage-3.0.0-SNAPSHOT.jar:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
> [?:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
> [?:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> java.base/java.u
[jira] [Assigned] (IGNITE-23125) AssertionError: Unexpected primary replica state STOPPED in ItRestartPartitionsCommandTest.testRestartAllPartitions
[ https://issues.apache.org/jira/browse/IGNITE-23125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-23125: Assignee: Denis Chudov > AssertionError: Unexpected primary replica state STOPPED in > ItRestartPartitionsCommandTest.testRestartAllPartitions > --- > > Key: IGNITE-23125 > URL: https://issues.apache.org/jira/browse/IGNITE-23125 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > > This assertion happens when ReplicaStateManager gets an event notification > about primary replica elected, and replica is already stopped. Usually, > replica is reserved as primary at the moment when this notification is gotten > (and there is clear HB), and cannot be stopped because of assignments change > if it is reserved as primary. But it can be stopped because of replica > restart (which happens in this test) and this assertion doesn't take into > account this reason. > It seems that this assertion is invalid and can be removed. > Other solution may be adding special "restarting" flag to know that the > primary is being restarted while asserting. > See ReplicaManager.ReplicaStateManager#onPrimaryElected. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-23081) Lease configuration
[
https://issues.apache.org/jira/browse/IGNITE-23081?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-23081:
Assignee: Kirill Sizov
> Lease configuration
> ---
>
> Key: IGNITE-23081
> URL: https://issues.apache.org/jira/browse/IGNITE-23081
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Kirill Sizov
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> Lease is a valid interval for the primary replica. Leases are distributed by
> a placement driver for a particular period. This period is hardcoded in the
> lease updater and cannot be configurable.
> Another interval is an interval that is given by the placement driver to a
> replica to apply a lease.
> {code:java}
> LeaseUpdater#LEASE_INTERVAL
> LeaseUpdater#longLeaseInterval
> {code}
> h3. Definition of done
> Both intervals have to be configurable through cluster configuration.
> *Implementation notes*
> Need to create a configuration extension that is a subclass of
> ClusterConfigurationSchema where this configuration will be added to. Also
> need better names for the provided properties.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-23075) Call failure processor during a timeout worker crash
[
https://issues.apache.org/jira/browse/IGNITE-23075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-23075:
Assignee: Denis Chudov
> Call failure processor during a timeout worker crash
>
>
> Key: IGNITE-23075
> URL: https://issues.apache.org/jira/browse/IGNITE-23075
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> For the majority of the cluster transaction operation, we use a Timeout
> worker. It is a single thread that completes futures with a timeout
> exception. But if the thread stops (due to an unhandled exception) no more
> operations can time out.
> h3. Definition of done
> The falure processor has to be called on the catch block of the timeout
> worker.
> {code:java}
> } catch (Throwable t) {
> failureProcessor.process(new FailureContext(SYSTEM_WORKER_TERMINATION,
> t));
>
> throw new IgniteInternalException(t);
> }{code}
> *Implementation notes*
> It would be also nice to add tests for timeout worker.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-23034) Issuses with concurrent inserts that depend on cluster size and zone settings
[
https://issues.apache.org/jira/browse/IGNITE-23034?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-23034:
Assignee: Kirill Sizov
> Issuses with concurrent inserts that depend on cluster size and zone settings
> -
>
> Key: IGNITE-23034
> URL: https://issues.apache.org/jira/browse/IGNITE-23034
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0
>Reporter: Andrey Khitrin
>Assignee: Kirill Sizov
>Priority: Major
> Labels: ignite-3, index, transaction
>
> {*}Steps to reproduce{*}:
> 1. Start AI3 cluster with *3 or more* nodes
> 2. Create a simple table with an index:
> {code:sql}
> CREATE TABLE indexed_kids(id INTEGER, name VARCHAR(100), primary key (id))
> CREATE INDEX indexed_kids_index on indexed_kids using SORTED (name)
> INSERT INTO indexed_kids (id, name) VALUES (1, 'Europe')
> {code}
> 3. Run 2 parallel transactions that try to insert values with the same value
> for the *indexed column* (not PK!). For example:
> {code:sql}
> -- First transaction
> INSERT INTO indexed_kids (id, name) VALUES (9, 'Kolobok')
> -- Second transaction
> INSERT INTO indexed_kids (id, name) VALUES (12, 'Kolobok')
> {code}
> {*}Expected behavior{*}:
> We expect both transactions to pass, in general.
> {*}Actual behavior{*}:
> Looks like it depends on 3 metrics: cluster size, amount of table partitions
> and amount of table replicas. In some cases, one transaction may fail with
> *SQLException* ("Failed to acquire a lock due to a possible deadlock")
> For example, in a cluster of 1 or 2 nodes, the second transaction always
> fail. In a cluster of 3 nodes, it may pass on default zone settings, but
> fails again when we increase amount of table partitions and/or replicas.
> *Implementation notes*
> We should fix the behaviour according to Transactional IEP (section Sorted
> non-unique index) [1] and the paper describing locking model [2]
> [1]
> [https://cwiki.apache.org/confluence/display/IGNITE/IEP-91%3A+Transaction+protocol#IEP91:Transactionprotocol-Non-uniqueindex]
> [2] https://www.vldb.org/conf/1990/P392.PDF
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22833) Test DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation is flaky
[
https://issues.apache.org/jira/browse/IGNITE-22833?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-22833:
Assignee: Vladislav Pyatkov
> Test
> DistributionZoneCausalityDataNodesTest.testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation
> is flaky
> -
>
> Key: IGNITE-22833
> URL: https://issues.apache.org/jira/browse/IGNITE-22833
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Attachments:
> _Run_Unit_Tests_auto-generated_Run_Unit_Tests_3_30973.log.zip
>
>
> {noformat}
> [10:10:14] : [:ignite-distribution-zones:test]
> DistributionZoneCausalityDataNodesTest >
> testEmptyDataNodesOnZoneCreationBeforeTopologyEventAndZoneInitialisation(int,
> int) > [1] 1, 1 STANDARD_ERROR
> [10:10:14] : [:ignite-distribution-zones:test]
> [2024-07-23T10:10:14,100][WARN
> ][%test%metastorage-watch-executor-2][UpdateLogImpl] Unable to process
> catalog event
> [10:10:14] : [:ignite-distribution-zones:test]
> java.lang.NullPointerException: null
> [10:10:14] : [:ignite-distribution-zones:test] at
> org.apache.ignite.internal.distributionzones.DistributionZoneManager.initDataNodesAndTriggerKeysInMetaStorage(DistributionZoneManager.java:527)
> ~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> org.apache.ignite.internal.distributionzones.DistributionZoneManager.onCreateZone(DistributionZoneManager.java:456)
> ~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> org.apache.ignite.internal.distributionzones.DistributionZoneManager.lambda$registerCatalogEventListenersOnStartManagerBusy$37(DistributionZoneManager.java:1396)
> ~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> org.apache.ignite.internal.util.IgniteUtils.inBusyLock(IgniteUtils.java:832)
> ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> org.apache.ignite.internal.distributionzones.DistributionZoneManager.lambda$registerCatalogEventListenersOnStartManagerBusy$38(DistributionZoneManager.java:1395)
> ~[ignite-distribution-zones-3.0.0-SNAPSHOT.jar:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> org.apache.ignite.internal.event.AbstractEventProducer.fireEvent(AbstractEventProducer.java:88)
> ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> org.apache.ignite.internal.catalog.CatalogManagerImpl.access$000(CatalogManagerImpl.java:81)
> ~[ignite-catalog-3.0.0-SNAPSHOT.jar:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:577)
> ~[ignite-catalog-3.0.0-SNAPSHOT.jar:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:544)
> ~[ignite-catalog-3.0.0-SNAPSHOT.jar:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> org.apache.ignite.internal.catalog.storage.UpdateLogImpl$UpdateListener.onUpdate(UpdateLogImpl.java:320)
> ~[ignite-catalog-3.0.0-SNAPSHOT.jar:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> org.apache.ignite.internal.metastorage.server.Watch.onUpdate(Watch.java:67)
> ~[ignite-metastorage-3.0.0-SNAPSHOT.jar:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> org.apache.ignite.internal.metastorage.server.WatchProcessor.notifyWatches(WatchProcessor.java:245)
> ~[ignite-metastorage-3.0.0-SNAPSHOT.jar:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$notifyWatches$4(WatchProcessor.java:193)
> ~[ignite-metastorage-3.0.0-SNAPSHOT.jar:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
> [?:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
> [?:?]
> [10:10:14] : [:ignite-distribution-zones:test] at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> [10:10:14] : [:ignite-
[jira] [Updated] (IGNITE-23113) [ducktests] Support Thin JDBC driver in ducktests
[ https://issues.apache.org/jira/browse/IGNITE-23113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov updated IGNITE-23113: - Labels: ise (was: ducktests ise) > [ducktests] Support Thin JDBC driver in ducktests > - > > Key: IGNITE-23113 > URL: https://issues.apache.org/jira/browse/IGNITE-23113 > Project: Ignite > Issue Type: Task >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Major > Labels: ise > > Ducktests do not aloow to test JDBC driver currently. It need to be fixed. > In particular it's needed for the IGNITE-6141 and related tasks testing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23113) [ducktests] Support Thin JDBC driver in ducktests
[ https://issues.apache.org/jira/browse/IGNITE-23113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Korotkov updated IGNITE-23113: - Labels: ducktests ise (was: ise) > [ducktests] Support Thin JDBC driver in ducktests > - > > Key: IGNITE-23113 > URL: https://issues.apache.org/jira/browse/IGNITE-23113 > Project: Ignite > Issue Type: Task >Reporter: Sergey Korotkov >Assignee: Sergey Korotkov >Priority: Major > Labels: ducktests, ise > > Ducktests do not aloow to test JDBC driver currently. It need to be fixed. > In particular it's needed for the IGNITE-6141 and related tasks testing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-6141) JDBC thin: support BLOB and CLOB types
[
https://issues.apache.org/jira/browse/IGNITE-6141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878822#comment-17878822
]
Ignite TC Bot commented on IGNITE-6141:
---
{panel:title=Branch: [pull/11492/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11492/head] Base: [master] : New Tests
(22)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}JDBC Driver{color} [[tests
22|https://ci2.ignite.apache.org/viewLog.html?buildId=8054426]]
* {color:#013220}IgniteJdbcDriverTestSuite: JdbcClobTest.testSetAsciiStream -
PASSED{color}
* {color:#013220}IgniteJdbcDriverTestSuite: JdbcResultSetSelfTest.testClob -
PASSED{color}
* {color:#013220}IgniteJdbcDriverTestSuite: JdbcResultSetSelfTest.testBlob -
PASSED{color}
* {color:#013220}IgniteJdbcDriverTestSuite:
JdbcPreparedStatementSelfTest.testClob - PASSED{color}
* {color:#013220}IgniteJdbcDriverTestSuite:
JdbcClobTest.testPositionWithClobPattern - PASSED{color}
* {color:#013220}IgniteJdbcDriverTestSuite: JdbcClobTest.testFree -
PASSED{color}
* {color:#013220}IgniteJdbcDriverTestSuite: JdbcClobTest.testTruncate -
PASSED{color}
* {color:#013220}IgniteJdbcDriverTestSuite: JdbcClobTest.testGetSubString -
PASSED{color}
* {color:#013220}IgniteJdbcDriverTestSuite:
JdbcClobTest.testGetCharacterStreamWithParams - PASSED{color}
* {color:#013220}IgniteJdbcDriverTestSuite: JdbcClobTest.testGetCharacterStream
- PASSED{color}
* {color:#013220}IgniteJdbcDriverTestSuite: JdbcClobTest.testGetAsciiStream -
PASSED{color}
... and 11 new tests
{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=8053121&buildTypeId=IgniteTests24Java8_RunAll]
> JDBC thin: support BLOB and CLOB types
> --
>
> Key: IGNITE-6141
> URL: https://issues.apache.org/jira/browse/IGNITE-6141
> Project: Ignite
> Issue Type: Task
> Components: jdbc
>Affects Versions: 2.1
>Reporter: Taras Ledkov
>Assignee: Sergey Korotkov
>Priority: Major
> Labels: ise
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Support BLOB and CLOB types by JDBC thin driver.
> It is very useful types. jdbc2 driver has supported one already (IGNITE-5203).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-22286) Remove waitTimeout in deadlock prevention policy
[
https://issues.apache.org/jira/browse/IGNITE-22286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878622#comment-17878622
]
Denis Chudov edited comment on IGNITE-22286 at 9/3/24 11:54 AM:
I did a benchmark: explicit tx with one upsert, high contention on keys. Tx is
rolled back if upsert fails. Upsert duration measured from upsert() call to
returning control to user. Time is in millis.
Benchmark results:
{code:java}
++-+--+-+
| Configuration | total txns | rolled back txns | average
upsert duration |
++-+--+-+
| Timeout wait, 1 node, 2 cores|1611 | 166|
7.583306 |
| Timeout wait, 3 nodes, 2 cores|1705 | 120|
17.575059|
| Timeout wait, 1 node, 8 cores|3445 | 394|
3.911635 |
| Timeout wait, 3 nodes, 8 cores|3055 | 371|
4.813581 |
| WaitDie + retries, 1 node, 2 cores|8160 | 169|
12.158225|
| WaitDie + retries, 3 nodes, 2 cores|3853 | 213|
10.584286|
| WaitDie + retries, 1 node, 8 cores| 22797 | 2477|
8.767905 |
| WaitDie + retries, 3 nodes, 8 cores| 13092 | 1285|
12.519806|
++-+--+-+
{code}
was (Author: denis chudov):
Benchmark results:
{code:java}
++-+--+-+
| Configuration | total txns | rolled back txns | average
upsert duration |
++-+--+-+
| Timeout wait, 1 node, 2 cores|1611 | 166|
7.583306 |
| Timeout wait, 3 nodes, 2 cores|1705 | 120|
17.575059|
| Timeout wait, 1 node, 8 cores|3445 | 394|
3.911635 |
| Timeout wait, 3 nodes, 8 cores|3055 | 371|
4.813581 |
| WaitDie + retries, 1 node, 2 cores|8160 | 169|
12.158225|
| WaitDie + retries, 3 nodes, 2 cores|3853 | 213|
10.584286|
| WaitDie + retries, 1 node, 8 cores| 22797 | 2477|
8.767905 |
| WaitDie + retries, 3 nodes, 8 cores| 13092 | 1285|
12.519806|
++-+--+-+
{code}
> Remove waitTimeout in deadlock prevention policy
>
>
> Key: IGNITE-22286
> URL: https://issues.apache.org/jira/browse/IGNITE-22286
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-beta1
>Reporter: Alexey Scherbakov
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0
>
>
> After IGNITE-21540 and IGNITE-20127 we now have proper retries on client side.
> This means we no longer need
> org.apache.ignite.internal.tx.DeadlockPreventionPolicy#waitTimeout as a part
> of deadock prevention policy.
> Moreover, client side retries has benefit in the following scenario (having
> in mind WAIT_DIE prevention):
> # tx1 takes lock at timestamp 10
> # tx2 tries to take lock at timestamp 20 and goes for retry (without holding
> lock)
> # tx1 lock is released
> # tx3 takes lock at timestamp 30
> # tx3 lock is released
> # tx2 attemps to lock after retry and succeeds
> Without retry (without holding locks) on step 2 tx3 would retry too on step 4.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22286) Remove waitTimeout in deadlock prevention policy
[
https://issues.apache.org/jira/browse/IGNITE-22286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878850#comment-17878850
]
Denis Chudov commented on IGNITE-22286:
---
On this scenario results are different and retries show better throughput and
latency.
100 accounts, money is transferred from one account to another randomly in each
transaction (2 gets, 2 upserts per transaction):
{code:java}
++-+--++--+-+
| Configuration | total txns | rolled back txns | rolled
back, % | average get duration | average upsert duration |
++-+--++--+-+
| Timeout wait, 1 node, 2 cores | 2776 | 99 |
3.6% | 3.779460 | 11.848301 |
| Timeout wait, 3 nodes, 2 cores| 2206 | 72 |
3.3% | 3.876897 | 13.024651 |
| Timeout wait, 1 node, 8 cores | 3374 | 260 |
7.7% | 11.460481 | 18.459695 |
| Timeout wait, 3 nodes, 8 cores| 3144 | 252 |
8.0% | 10.896002 | 19.587510 |
| WaitDie + retries, 1 node, 2 cores | 5882 | 109 |
1.9% | 1.210868 | 7.957916 |
| WaitDie + retries, 3 nodes, 2 cores| 3717 | 126 |
3.4% | 2.403865 | 6.673273 |
| WaitDie + retries, 1 node, 8 cores | 18970 | 1123 |
5.9% | 1.431751 | 5.046949 |
| WaitDie + retries, 3 nodes, 8 cores| 10845 | 797 |
7.4% | 2.040012 | 8.359724 |
++-+--++--+-+
{code}
> Remove waitTimeout in deadlock prevention policy
>
>
> Key: IGNITE-22286
> URL: https://issues.apache.org/jira/browse/IGNITE-22286
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-beta1
>Reporter: Alexey Scherbakov
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0
>
>
> After IGNITE-21540 and IGNITE-20127 we now have proper retries on client side.
> This means we no longer need
> org.apache.ignite.internal.tx.DeadlockPreventionPolicy#waitTimeout as a part
> of deadock prevention policy.
> Moreover, client side retries has benefit in the following scenario (having
> in mind WAIT_DIE prevention):
> # tx1 takes lock at timestamp 10
> # tx2 tries to take lock at timestamp 20 and goes for retry (without holding
> lock)
> # tx1 lock is released
> # tx3 takes lock at timestamp 30
> # tx3 lock is released
> # tx2 attemps to lock after retry and succeeds
> Without retry (without holding locks) on step 2 tx3 would retry too on step 4.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-23134) Adapt transactional benchmarks for JMH
Denis Chudov created IGNITE-23134: - Summary: Adapt transactional benchmarks for JMH Key: IGNITE-23134 URL: https://issues.apache.org/jira/browse/IGNITE-23134 Project: Ignite Issue Type: Bug Reporter: Denis Chudov Adapt benchmark from IGNITE-22286 for JMH and commit it to main. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22286) Remove waitTimeout in deadlock prevention policy
[ https://issues.apache.org/jira/browse/IGNITE-22286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878851#comment-17878851 ] Denis Chudov commented on IGNITE-22286: --- Created the tickets: IGNITE-23065 for configurable retries and deadlock prevention policies IGNITE-23134 to adapt the benchmarks for JMH. the code is here: https://github.com/gridgain/apache-ignite-3/tree/ignite-22286 > Remove waitTimeout in deadlock prevention policy > > > Key: IGNITE-22286 > URL: https://issues.apache.org/jira/browse/IGNITE-22286 > Project: Ignite > Issue Type: Improvement >Affects Versions: 3.0.0-beta1 >Reporter: Alexey Scherbakov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > > After IGNITE-21540 and IGNITE-20127 we now have proper retries on client side. > This means we no longer need > org.apache.ignite.internal.tx.DeadlockPreventionPolicy#waitTimeout as a part > of deadock prevention policy. > Moreover, client side retries has benefit in the following scenario (having > in mind WAIT_DIE prevention): > # tx1 takes lock at timestamp 10 > # tx2 tries to take lock at timestamp 20 and goes for retry (without holding > lock) > # tx1 lock is released > # tx3 takes lock at timestamp 30 > # tx3 lock is released > # tx2 attemps to lock after retry and succeeds > Without retry (without holding locks) on step 2 tx3 would retry too on step 4. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22286) Remove waitTimeout in deadlock prevention policy
[ https://issues.apache.org/jira/browse/IGNITE-22286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-22286: -- Fix Version/s: (was: 3.0) > Remove waitTimeout in deadlock prevention policy > > > Key: IGNITE-22286 > URL: https://issues.apache.org/jira/browse/IGNITE-22286 > Project: Ignite > Issue Type: Improvement >Affects Versions: 3.0.0-beta1 >Reporter: Alexey Scherbakov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > > After IGNITE-21540 and IGNITE-20127 we now have proper retries on client side. > This means we no longer need > org.apache.ignite.internal.tx.DeadlockPreventionPolicy#waitTimeout as a part > of deadock prevention policy. > Moreover, client side retries has benefit in the following scenario (having > in mind WAIT_DIE prevention): > # tx1 takes lock at timestamp 10 > # tx2 tries to take lock at timestamp 20 and goes for retry (without holding > lock) > # tx1 lock is released > # tx3 takes lock at timestamp 30 > # tx3 lock is released > # tx2 attemps to lock after retry and succeeds > Without retry (without holding locks) on step 2 tx3 would retry too on step 4. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23134) Adapt transactional benchmarks for JMH
[ https://issues.apache.org/jira/browse/IGNITE-23134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov updated IGNITE-23134: -- Description: Adapt benchmark from IGNITE-22286 for JMH and commit it to main. Raw benchmarks are here [https://github.com/gridgain/apache-ignite-3/tree/ignite-22286] was:Adapt benchmark from IGNITE-22286 for JMH and commit it to main. > Adapt transactional benchmarks for JMH > -- > > Key: IGNITE-23134 > URL: https://issues.apache.org/jira/browse/IGNITE-23134 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > Adapt benchmark from IGNITE-22286 for JMH and commit it to main. > Raw benchmarks are here > [https://github.com/gridgain/apache-ignite-3/tree/ignite-22286] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23038) Can't update node configuration via CLI using our Docker image
[
https://issues.apache.org/jira/browse/IGNITE-23038?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-23038:
-
Labels: ignite-3 (was: )
> Can't update node configuration via CLI using our Docker image
> --
>
> Key: IGNITE-23038
> URL: https://issues.apache.org/jira/browse/IGNITE-23038
> Project: Ignite
> Issue Type: Bug
> Components: build
>Affects Versions: 3.0.0-beta1
> Environment: Ignite 3 docker image
>Reporter: Ivan Zlenko
>Priority: Major
> Labels: ignite-3
>
> If you try to execute command in CLI
> {code}
> node config update …
> {code}
> it will fail with following error:
> {code}
> [node1]> node config update --url http://172.18.0.3:10300 raft.fsync=true
> IGN-CMN--1 Trace ID: 1d2b44de-10e3-4bf2-9de9-273d2945d125
> Failed to write values to config file.
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23066) Update DEVNOTES.md with correct Ignite set up instruction
[ https://issues.apache.org/jira/browse/IGNITE-23066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-23066: - Labels: ignite-3 (was: ) > Update DEVNOTES.md with correct Ignite set up instruction > - > > Key: IGNITE-23066 > URL: https://issues.apache.org/jira/browse/IGNITE-23066 > Project: Ignite > Issue Type: Task >Reporter: Kirill Sizov >Priority: Major > Labels: ignite-3 > > The step by step guide in DEVNOTES.md is no longer up to date. > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23102) Usernames in basic authentication should be case insitive
[ https://issues.apache.org/jira/browse/IGNITE-23102?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-23102: - Labels: ignite-3 (was: ) > Usernames in basic authentication should be case insitive > - > > Key: IGNITE-23102 > URL: https://issues.apache.org/jira/browse/IGNITE-23102 > Project: Ignite > Issue Type: Bug > Components: security >Affects Versions: 3.0.0-beta1 >Reporter: Dmitry Baranov >Assignee: Dmitry Baranov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Right now we can create 'Admin' and 'admin' users, it should be prohibited -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-23127) Old documentation for storage engine usage
[
https://issues.apache.org/jira/browse/IGNITE-23127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-23127:
-
Labels: ignite-3 (was: )
> Old documentation for storage engine usage
> --
>
> Key: IGNITE-23127
> URL: https://issues.apache.org/jira/browse/IGNITE-23127
> Project: Ignite
> Issue Type: Bug
> Components: documentation
>Reporter: Ivan Zlenko
>Priority: Major
> Labels: ignite-3
>
> In some places of Ignite documentation of help we still have remnants of an
> old syntax for setting a storage engine to a table.
> For example in IgniteSqlCommand.java we have following help:
> {code:java}
> CREATE_TABLE("CREATE TABLE",
> "CREATE TABLE [IF NOT EXISTS] tableName (tableColumn [,
> tableColumn]...)\n"
> + "[COLOCATE [BY] (columnName [, columnName]...)]\n"
> + "[ENGINE engineName]\n"
> + "[WITH paramName=paramValue
> [,paramName=paramValue]...]\n"
> + "tableColumn = columnName columnType [[NOT] NULL]
> [DEFAULT defaultValue] [PRIMARY KEY]"),
> {code}
> We need to check our documentation and help and make it up to date with how
> it should actually work.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-23128) NullPointerException if non-existent profile passed into zone and table
[
https://issues.apache.org/jira/browse/IGNITE-23128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-23128:
-
Labels: ignite-3 (was: )
> NullPointerException if non-existent profile passed into zone and table
>
>
> Key: IGNITE-23128
> URL: https://issues.apache.org/jira/browse/IGNITE-23128
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Zlenko
>Priority: Major
> Labels: ignite-3
>
> If we try to create a table with a zone containing a profile that not
> described in the node configuration we will get NullPointerException trying
> to create such table.
> To reproduce you need to do following:
> 1. Execute command
> {code:sql}
> create zone test with storage_profiles='IAmAPhantomProfile'
> {code}
> Where IAmAPhantomProfile is not described in storage.profiles section of node
> configuration.
> 2. Execute command
> {code:sql}
> create table test (I int) with storage_profile='IAmAPhantomProfile'
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22360) Sql. SUBSTRING function should not accept REAL/DOUBLE values in its numeric arguments.
[
https://issues.apache.org/jira/browse/IGNITE-22360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878866#comment-17878866
]
Evgeny Stanilovsky commented on IGNITE-22360:
-
fixed in : IGNITE-21243 Bump calcite version to 1.37
> Sql. SUBSTRING function should not accept REAL/DOUBLE values in its numeric
> arguments.
> --
>
> Key: IGNITE-22360
> URL: https://issues.apache.org/jira/browse/IGNITE-22360
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> The following queries should be rejected by the validator, because numeric
> arguments other than INTs do not make any sense for this function:
> {noformat}
> SELECT SUBSTRING('aaa', 1.0);
> SELECT SUBSTRING('aaa', 1.0, 2.3)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22530) CDC: Add regex filters for cache names
[
https://issues.apache.org/jira/browse/IGNITE-22530?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878872#comment-17878872
]
Ignite TC Bot commented on IGNITE-22530:
{panel:title=Branch: [pull/11503/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11503/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=8048925&buildTypeId=IgniteTests24Java8_RunAll]
> CDC: Add regex filters for cache names
> --
>
> Key: IGNITE-22530
> URL: https://issues.apache.org/jira/browse/IGNITE-22530
> Project: Ignite
> Issue Type: New Feature
> Components: extensions
>Reporter: Ilya Shishkov
>Assignee: Andrei Nadyktov
>Priority: Major
> Labels: IEP-59, ise
> Fix For: 2.17
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Motivation:*
> Currently, we can specify cache names _only explicitly as list_ in
> configuration files. But, if we create new cache, it will not be processed by
> CDC, until cluster and CDC applications are not restarted with updated
> configuration.
> For example, if we need all caches to be replicated, it seems that most
> convenient way to do so, is to specify some kind of asterisk or regex filter.
> *Proposed solution:*
> # Add regex filters to all CDC classes with configured cache names:
> CdcConsumer implementations, ConflictResolver implementations and
> KafkaToIgnite streamers.
> # Current way to specify caches list must remain available in order to
> preserve compatibility.
> # Optional exclude filter also should be implemented.
> # Multiple include and exclude filters should be supported.
> # It should be compatible with realtime CDC.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-23135) Do not use ByteUtils.toBytes() to store persistent data
Roman Puchkovskiy created IGNITE-23135: -- Summary: Do not use ByteUtils.toBytes() to store persistent data Key: IGNITE-23135 URL: https://issues.apache.org/jira/browse/IGNITE-23135 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-23115) Checkpoint single partition from a single thread
[ https://issues.apache.org/jira/browse/IGNITE-23115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Pligin reassigned IGNITE-23115: Assignee: Kirill Tkalenko > Checkpoint single partition from a single thread > > > Key: IGNITE-23115 > URL: https://issues.apache.org/jira/browse/IGNITE-23115 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > As far as I know, writing multiple files from multiple threads is more > efficient that writing a single file from multiple threads. But that's > exactly what we do. > We should make an alternative implementation that would distribute partitions > between threads and check if it performs better than current implementation. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-23105) Data race in aipersist partition destruction
[
https://issues.apache.org/jira/browse/IGNITE-23105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Pligin reassigned IGNITE-23105:
Assignee: Kirill Tkalenko
> Data race in aipersist partition destruction
>
>
> Key: IGNITE-23105
> URL: https://issues.apache.org/jira/browse/IGNITE-23105
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
>
> {{CheckpointProgressImpl#onStartPartitionProcessing}} and
> {{CheckpointProgressImpl#onFinishPartitionProcessing}} don't work as intended
> for several reasons:
> * There's a race, we could call {{onFinish}} before {{onStart}} is called in
> a concurrent thread. This might happen if there's only a handful of dirty
> pages in each partition and there are more than one checkpoint threads.
> Basically, this protection doesn't work.
> * Even if that particular race wouldn't exits, this code still doesn't work,
> because some of pages could be added to {{pageIdsToRetry}} map. That map will
> be processed later, when
> {{writePages}} is finished, manning that we mark unfinished partitions as
> finished.
> * Due to aforementioned bugs, I didn't bother including these methods to
> {{{}drainCheckpointBuffers{}}}. As a result, this method requires a fix too
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-23103) RandomLruPageReplacementPolicy is not fully ported
[
https://issues.apache.org/jira/browse/IGNITE-23103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Pligin reassigned IGNITE-23103:
Assignee: Aleksandr Polovtsev
> RandomLruPageReplacementPolicy is not fully ported
> --
>
> Key: IGNITE-23103
> URL: https://issues.apache.org/jira/browse/IGNITE-23103
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Assignee: Aleksandr Polovtsev
>Priority: Major
> Labels: ignite-3
>
> There should be a line
> {code:java}
> if (relRmvAddr == rndAddr || pinned || skip || (dirty && (checkpointPages ==
> null || !checkpointPages.contains(fullId {{code}
> instead of
> {code:java}
> if (relRmvAddr == rndAddr || pinned || skip || dirty) { {code}
> Due to this mistake we have several conditions, that are always evaluated to
> constants, namely
> *
> {{!dirty}} - always true
> *
> {{pageTs < dirtyTs && dirty && !storMeta}} - always false
> Ideally, we should add tests that would cover this situation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-23056) Verbose logging of delta-files compaction
[ https://issues.apache.org/jira/browse/IGNITE-23056?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Pligin reassigned IGNITE-23056: Assignee: Ivan Bessonov > Verbose logging of delta-files compaction > - > > Key: IGNITE-23056 > URL: https://issues.apache.org/jira/browse/IGNITE-23056 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > > For checkpoints we have a very extensive log message, that shows the duration > of each checkpoint's phase. We don't have that for compactor. > In this Jira we need to implement that. The list of phases and statistics is > at developers discretion. > As a bonus, we might want to print some values in microseconds instead of > milliseconds, and not use fast timestamp (they don't have enough > granularity). While we're doing that for compactor logs, we might as well > update checkpoint's logs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-23136) Duplicate commands in sql help
Vadim Pakhnushev created IGNITE-23136:
-
Summary: Duplicate commands in sql help
Key: IGNITE-23136
URL: https://issues.apache.org/jira/browse/IGNITE-23136
Project: Ignite
Issue Type: Bug
Components: cli
Reporter: Vadim Pakhnushev
Assignee: Vadim Pakhnushev
After entering sql REPL mode and running {{help}} the following help message
contains both upper-case and lower-case version of each command:
{noformat}
SQL commands:
SELECT
select
INSERT
insert
...{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21663) Cluster load balancing when 1 node is killed doesn't work
[
https://issues.apache.org/jira/browse/IGNITE-21663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-21663:
Fix Version/s: 3.0
(was: 3.0.0-beta1)
> Cluster load balancing when 1 node is killed doesn't work
> -
>
> Key: IGNITE-21663
> URL: https://issues.apache.org/jira/browse/IGNITE-21663
> Project: Ignite
> Issue Type: Bug
> Components: persistence, sql
>Affects Versions: 3.0.0-beta1
>Reporter: Igor
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0
>
>
> *Steps to reproduce:*
> # Start cluster with 2 nodes running locally.
> # Make connection like this:
> {code:java}
> try (IgniteClient igniteClient = IgniteClient.builder().retryPolicy(new
> RetryLimitPolicy()).addresses(thinClientEndpoints.toArray(new
> String[]{"localhost:10800","localhost:10801"})).build()) {
> try (Session session = igniteClient.sql().createSession()) {
> //code here
> }
> } {code}
> 3. Create table with replication 2
> 4. Execute insert 1 row and select from the table.
> 5. Kill first node (in list of connection)
> 6. Execute select from the table.
> *Expected:*
> Cluster works with one node.
> *Actual:*
> The exception on select after first node is killed, the select is not
> executed.
> {code:java}
> org.apache.ignite.sql.SqlException: IGN-CMN-65535
> TraceId:92e48867-2e6e-4730-9781-527a4e204b32 Unable to send fragment
> [targetNode=ConnectionTest_cluster_0, fragmentId=1,
> cause=io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection
> refused: no further information: /192.168.100.5:3344]
> at
> java.base/java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
> at
> org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:765)
> at
> org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:699)
> at
> org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:525)
> at
> org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCauseInternal(ExceptionUtils.java:634)
> at
> org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:476)
> at
> org.apache.ignite.internal.sql.AbstractSession.execute(AbstractSession.java:63)
> at
> org.gridgain.ai3tests.tests.teststeps.ThinClientSteps.lambda$executeQuery$0(ThinClientSteps.java:61)
> at io.qameta.allure.Allure.lambda$step$1(Allure.java:127)
> at io.qameta.allure.Allure.step(Allure.java:181)
> at io.qameta.allure.Allure.step(Allure.java:125)
> at
> org.gridgain.ai3tests.tests.teststeps.ThinClientSteps.executeQuery(ThinClientSteps.java:61)
> at
> org.gridgain.ai3tests.tests.ConnectionTest.testThinClientConnectionToMultipleHost(ConnectionTest.java:93)
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1540)
> Caused by: java.util.concurrent.CompletionException:
> org.apache.ignite.sql.SqlException: IGN-CMN-65535
> TraceId:92e48867-2e6e-4730-9781-527a4e204b32 Unable to send fragment
> [targetNode=ConnectionTest_cluster_0, fragmentId=1,
> cause=io.netty.channel.AbstractChannel$AnnotatedConnectException: Connection
> refused: no further information: /192.168.100.5:3344]
> at
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
> at
> java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:346)
> at
> java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:870)
> at
> java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.internal.client.TcpClientChannel.processNextMessage(TcpClientChannel.java:419)
> at
> org.apache.ignite.internal.client.TcpClientChannel.lambda$onMessage$3(TcpClientChannel.java:238)
> at
> java.base/java.util.concurrent.ForkJoinTask$RunnableExecuteAction.exec(ForkJoinTask.java:1426)
> at
> java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
> at
> java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
> at
> java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
> at
> java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
> at
> java.base/java.util.conc
[jira] [Commented] (IGNITE-22883) Send all cluster IDs to thin client on connection
[ https://issues.apache.org/jira/browse/IGNITE-22883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878893#comment-17878893 ] Pavel Tupitsyn commented on IGNITE-22883: - [~rpuch] looks good to me. > Send all cluster IDs to thin client on connection > - > > Key: IGNITE-22883 > URL: https://issues.apache.org/jira/browse/IGNITE-22883 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: iep-128, ignite-3 > Time Spent: 0.5h > Remaining Estimate: 0h > > After IGNITE-22807 and IGNITE-22882 are implemented, we should start sending > all cluster IDs (all previous ones and the current one) to a thin client when > it connects a server node. > Also, a test has to be added for the following scenario: > # A cluster is initialized > # A thin client is connected to the cluster (and does something like making > a put) > # CMG is reset on the cluster > # The thin client should still work (a get should succeed) without a restart -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-22424) Insert and read errors under high cluster load
[
https://issues.apache.org/jira/browse/IGNITE-22424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Sivkov resolved IGNITE-22424.
Resolution: Cannot Reproduce
> Insert and read errors under high cluster load
> --
>
> Key: IGNITE-22424
> URL: https://issues.apache.org/jira/browse/IGNITE-22424
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikita Sivkov
>Priority: Major
> Labels: ignite-3, ignite3_performance
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h2. Setup
> * 1 or 3 server nodes cluster
> * 3 client nodes
> * 64+ threads per client performing KV put/get
> * Each node (server or client) is an AWS instance of {{c5d.4xlarge}}
> h2. Steps
> * Client nodes do put 15m records
> * Client nodes do get 15m records
> h2. Expected result
> No errors occurred, all records inserted and read after successfully.
> h2. Actual result
> On some point, cluster degrades and throws errors on inserting/reading.
> Error examples:
> * The primary replica has changed
> {code:java}
> org.apache.ignite.lang.IgniteException: The primary replica has changed
> [expectedLeaseholderName=poc-tester-SERVER-192.168.1.58-id-0,
> currentLeaseholderName=null,
> expectedLeaseholderId=b4425409-2d71-482d-a5d6-468522569cd0,
> currentLeaseholderId=null,
> expectedEnlistmentConsistencyToken=112569527664115719,
> currentEnlistmentConsistencyToken=null]
> at
> java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
> ~[?:?]
> at
> org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:789)
> ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:723)
> ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:525)
> ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.ClientUtils.copyExceptionWithCauseIfPossible(ClientUtils.java:73)
> ~[ignite-client-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.ClientUtils.ensurePublicException(ClientUtils.java:54)
> ~[ignite-client-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.ClientUtils.sync(ClientUtils.java:97)
> ~[ignite-client-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.table.ClientKeyValueBinaryView.get(ClientKeyValueBinaryView.java:78)
> ~[ignite-client-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.table.ClientKeyValueBinaryView.get(ClientKeyValueBinaryView.java:59)
> ~[ignite-client-3.0.0-SNAPSHOT.jar:?]
> at site.ycsb.db.ignite3.IgniteClient.read(IgniteClient.java:90)
> [ignite3-binding-2024.11.jar:?]
> at site.ycsb.DBWrapper.read(DBWrapper.java:157) [core-2024.11.jar:?]
> at
> site.ycsb.workloads.CoreWorkload.doTransactionRead(CoreWorkload.java:803)
> [core-2024.11.jar:?]
> at
> site.ycsb.workloads.CoreWorkload.doTransaction(CoreWorkload.java:722)
> [core-2024.11.jar:?]
> at site.ycsb.ClientThread.run(ClientThread.java:145)
> [core-2024.11.jar:?]
> at java.lang.Thread.run(Thread.java:829) [?:?] {code}
>
> * Replication is timed out
> {code:java}
> org.apache.ignite.tx.TransactionException: Replication is timed out
> [replicaGrpId=10_part_4]
> at
> java.lang.invoke.MethodHandle.invokeWithArguments(MethodHandle.java:710)
> ~[?:?]
> at
> org.apache.ignite.internal.util.ExceptionUtils$1.copy(ExceptionUtils.java:789)
> ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.util.ExceptionUtils$ExceptionFactory.createCopy(ExceptionUtils.java:723)
> ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.util.ExceptionUtils.copyExceptionWithCause(ExceptionUtils.java:525)
> ~[ignite-core-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.ClientUtils.copyExceptionWithCauseIfPossible(ClientUtils.java:73)
> ~[ignite-client-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.ClientUtils.ensurePublicException(ClientUtils.java:54)
> ~[ignite-client-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.ClientUtils.sync(ClientUtils.java:97)
> ~[ignite-client-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.table.ClientKeyValueBinaryView.get(ClientKeyValueBinaryView.java:78)
> ~[ignite-client-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.client.table.ClientKeyValueBinaryView.get(ClientKeyValueBinaryView.java:59)
> ~[ignite-client-3.0.0-SNAPSHOT.jar:?]
> at site.ycsb.db.ignite3.IgniteClient.read(IgniteClient.java:90)
> [ignite3-binding-2024.11.jar:?]
> at site.ycsb.DBWrapper.read(DBWrapper.java:157) [core-2024.11.jar:?]
[jira] [Commented] (IGNITE-22883) Send all cluster IDs to thin client on connection
[ https://issues.apache.org/jira/browse/IGNITE-22883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17878897#comment-17878897 ] Roman Puchkovskiy commented on IGNITE-22883: Thanks! > Send all cluster IDs to thin client on connection > - > > Key: IGNITE-22883 > URL: https://issues.apache.org/jira/browse/IGNITE-22883 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: iep-128, ignite-3 > Time Spent: 40m > Remaining Estimate: 0h > > After IGNITE-22807 and IGNITE-22882 are implemented, we should start sending > all cluster IDs (all previous ones and the current one) to a thin client when > it connects a server node. > Also, a test has to be added for the following scenario: > # A cluster is initialized > # A thin client is connected to the cluster (and does something like making > a put) > # CMG is reset on the cluster > # The thin client should still work (a get should succeed) without a restart -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20902) Fix IgniteWalRebalanceTest flakiness
[
https://issues.apache.org/jira/browse/IGNITE-20902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrei Nadyktov reassigned IGNITE-20902:
Assignee: Andrei Nadyktov
> Fix IgniteWalRebalanceTest flakiness
>
>
> Key: IGNITE-20902
> URL: https://issues.apache.org/jira/browse/IGNITE-20902
> Project: Ignite
> Issue Type: Test
>Reporter: Ilya Shishkov
>Assignee: Andrei Nadyktov
>Priority: Trivial
> Labels: ise
>
> Some of {{IgniteWalRebalanceTest}} methods are flaky:
> # {{#testRebalanceCancelOnSupplyError}} - fails often.
> # {{#testWithLocalWalChange}} - fails rarely.
> Tests fails with a foolowing error:
> {code}
> java.lang.AssertionError: WAL rebalance hasn't been invoked.
> at
> org.apache.ignite.internal.processors.cache.persistence.db.wal.IgniteWalRebalanceTest.afterTest(IgniteWalRebalanceTest.java:197)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runAfterTest(GridAbstractTest.java:760)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.cleanUpTestEnviroment(GridAbstractTest.java:737)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.runTest(GridAbstractTest.java:2550)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$1.evaluate(GridAbstractTest.java:235)
> ...
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-23137) vars.bat is different from vars.env
Igor created IGNITE-23137:
-
Summary: vars.bat is different from vars.env
Key: IGNITE-23137
URL: https://issues.apache.org/jira/browse/IGNITE-23137
Project: Ignite
Issue Type: Bug
Components: general, platforms
Affects Versions: 3.0.0-beta2
Reporter: Igor
Linux environment setup (vars.env) contains the next string:
{code:java}
JVM_GC_LOG_NAME="gc.log.$(date -u +%Y%m%d_%H%M%S)"
{code}
While Windows environment setup (vars.bat) has the next:
{code:java}
set JVM_GC_LOG_NAME=gc.log
{code}
As result the *`gc.log` has different names in different platforms.*
I would suggest to use something like this instead:
{code:java}
for /f %%a in ('powershell -Command "Get-Date -format MMdd__HHmmss"') do
set datetime=%%a
set JVM_GC_LOG_NAME="gc.log.%datetime%"
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-23040) Fix GridNioSslSelfTest (Basic 1 group)
[ https://issues.apache.org/jira/browse/IGNITE-23040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879067#comment-17879067 ] Semyon Zikunov commented on IGNITE-23040: - Cannot be reproduced locally on MacOs x 14.5 aarch64. There is an assertion error only in teamcity builds without message on lines like: assert latch.await(30, SECONDS); Adding the line Thread.sleep(50) to the sendMessage() method solves the problem of test crashes. I came to the conclusion that due to the simple implementation of the test client, messages are sent too quickly, while the client does not have time to close the socket from the messages of the previous test. > Fix GridNioSslSelfTest (Basic 1 group) > -- > > Key: IGNITE-23040 > URL: https://issues.apache.org/jira/browse/IGNITE-23040 > Project: Ignite > Issue Type: Test >Reporter: Semyon Zikunov >Assignee: Semyon Zikunov >Priority: Trivial > Labels: ise > Time Spent: 1h > Remaining Estimate: 0h > > 3 tests constantly failed with java.lang.AssertionError. > Tests: > testDeliveryDuration > testMultiThreadedSendReceive > testSendReceive -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-23040) Fix GridNioSslSelfTest (Basic 1 group)
[ https://issues.apache.org/jira/browse/IGNITE-23040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17879067#comment-17879067 ] Semyon Zikunov edited comment on IGNITE-23040 at 9/4/24 12:39 AM: -- Cannot be reproduced locally on MacOs x 14.5 aarch64. There is an assertion error only in teamcity builds on lines like: assert latch.await(30, SECONDS); Adding the line Thread.sleep(50) to the sendMessage() method solves the problem of test crashes. I came to the conclusion that due to the simple implementation of the test client, messages are sent too quickly, while the client does not have time to close the socket from the messages of the previous test. was (Author: JIRAUSER303459): Cannot be reproduced locally on MacOs x 14.5 aarch64. There is an assertion error only in teamcity builds without message on lines like: assert latch.await(30, SECONDS); Adding the line Thread.sleep(50) to the sendMessage() method solves the problem of test crashes. I came to the conclusion that due to the simple implementation of the test client, messages are sent too quickly, while the client does not have time to close the socket from the messages of the previous test. > Fix GridNioSslSelfTest (Basic 1 group) > -- > > Key: IGNITE-23040 > URL: https://issues.apache.org/jira/browse/IGNITE-23040 > Project: Ignite > Issue Type: Test >Reporter: Semyon Zikunov >Assignee: Semyon Zikunov >Priority: Trivial > Labels: ise > Time Spent: 1h > Remaining Estimate: 0h > > 3 tests constantly failed with java.lang.AssertionError. > Tests: > testDeliveryDuration > testMultiThreadedSendReceive > testSendReceive -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-23138) Fix TxWithKeyContentionSelfTest (Cache 12 group)
Semyon Zikunov created IGNITE-23138: --- Summary: Fix TxWithKeyContentionSelfTest (Cache 12 group) Key: IGNITE-23138 URL: https://issues.apache.org/jira/browse/IGNITE-23138 Project: Ignite Issue Type: Test Reporter: Semyon Zikunov Assignee: Semyon Zikunov 6 tests constantly fail with java.lang.AssertionError. All marked as flaky. High fail rate - more than 80%. Tests: testOptimisticReadCommittedCheckContentionTxMetricNear testOptimisticRepeatableReadCheckContentionTxMetric testOptimisticReadCommittedCheckContentionTxMetric testOptimisticRepeatableReadCheckContentionTxMetricNear testPessimisticRepeatableReadCheckContentionTxMetric testPessimisticRepeatableReadCheckContentionTxMetricNear -- This message was sent by Atlassian Jira (v8.20.10#820010)
