[jira] [Commented] (IGNITE-21131) Calcite engine. OR operator with dynamic parameters can't be used for index scans
[
https://issues.apache.org/jira/browse/IGNITE-21131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800703#comment-17800703
]
Ignite TC Bot commented on IGNITE-21131:
{panel:title=Branch: [pull/11126/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11126/head] Base: [master] : New Tests
(14)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Calcite SQL{color} [[tests
14|https://ci2.ignite.apache.org/viewLog.html?buildId=7674125]]
* {color:#013220}IgniteCalciteTestSuite:
IndexMultiRangeScanIntegrationTest.testRangeIntersection[dynamicParams=true] -
PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
IndexMultiRangeScanIntegrationTest.testOrdering[dynamicParams=true] -
PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
IndexMultiRangeScanIntegrationTest.testInvalidRange[dynamicParams=true] -
PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
IndexMultiRangeScanIntegrationTest.testNot[dynamicParams=false] - PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
IndexMultiRangeScanIntegrationTest.testRangeIntersection[dynamicParams=false] -
PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
IndexMultiRangeScanIntegrationTest.testNulls[dynamicParams=true] - PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
IndexMultiRangeScanIntegrationTest.testNot[dynamicParams=true] - PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
IndexMultiRangeScanIntegrationTest.testIn[dynamicParams=true] - PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
IndexMultiRangeScanIntegrationTest.testRange[dynamicParams=true] - PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
IndexMultiRangeScanIntegrationTest.testOrdering[dynamicParams=false] -
PASSED{color}
* {color:#013220}IgniteCalciteTestSuite:
IndexMultiRangeScanIntegrationTest.testRange[dynamicParams=false] -
PASSED{color}
... and 3 new tests
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7668130buildTypeId=IgniteTests24Java8_RunAll]
> Calcite engine. OR operator with dynamic parameters can't be used for index
> scans
> -
>
> Key: IGNITE-21131
> URL: https://issues.apache.org/jira/browse/IGNITE-21131
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Calcite can compose OR operator with literals to SEARCH/SARG, and SEARCH/SARG
> can be used for index scans. But we can't do this for OR operator with
> dynamic parameters.
> For example expression {{a IN (1, 2, 3)}} can be converted to {{a = 1 OR a =
> 2 OR a = 3}} and after that can be converted to {{SEARCH(a, SARG(1, 2, 3))}},
> but expression {{a IN (?, ?, ?)}} can be converted only to {{a = ? OR a = ?
> OR a = ?}} and can't be used for index scan.
> To fix this issue we can create ranges from dynamic parameters during
> planning, sort and remove intersections from these ranges in runtime.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21093) MvccMessage removal
[
https://issues.apache.org/jira/browse/IGNITE-21093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800701#comment-17800701
]
Ignite TC Bot commented on IGNITE-21093:
{panel:title=Branch: [pull/11144/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11144/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=7676302buildTypeId=IgniteTests24Java8_RunAll]
> MvccMessage removal
> ---
>
> Key: IGNITE-21093
> URL: https://issues.apache.org/jira/browse/IGNITE-21093
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Julia Bakulina
>Assignee: Julia Bakulina
>Priority: Minor
> Labels: ise
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Remove MvccMessage
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21159) Deserialization of Instant field in a Marshallable fails
[ https://issues.apache.org/jira/browse/IGNITE-21159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-21159: --- Description: Instant is a final class, so we assume that an Instant field will always contain an instance of Instant (so 'the type is known upfront'), so we apply an optimization of not writing the descriptor ID for this field's content. But at the same time, Instant defines writeReplace() which replaces it with an instance of another type (Ser) when serializing, so the type can actually change during serialization, so we cannot apply the optimization in such cases. > Deserialization of Instant field in a Marshallable fails > > > Key: IGNITE-21159 > URL: https://issues.apache.org/jira/browse/IGNITE-21159 > Project: Ignite > Issue Type: Bug >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Instant is a final class, so we assume that an Instant field will always > contain an instance of Instant (so 'the type is known upfront'), so we apply > an optimization of not writing the descriptor ID for this field's content. > But at the same time, Instant defines writeReplace() which replaces it with > an instance of another type (Ser) when serializing, so the type can actually > change during serialization, so we cannot apply the optimization in such > cases. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21160) .NET: Thin 3.0: TestExecuteColocatedUpdatesTableCacheOnTableDrop is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-21160:
Description:
Apache.Ignite.Tests.Compute.ComputeTests.TestExecuteColocatedUpdatesTableCacheOnTableDrop
is flaky:
{code}
Apache.Ignite.TableNotFoundException : Table not found: 46
> Apache.Ignite.IgniteException :
org.apache.ignite.lang.TableNotFoundException: IGN-TBL-2
TraceId:ee0df118-c9cf-499e-9325-6fe842d5251b Table not found: 46
at
org.apache.ignite.client.handler.ClientPrimaryReplicaTracker.tableNotFoundException(ClientPrimaryReplicaTracker.java:344)
at
org.apache.ignite.client.handler.ClientPrimaryReplicaTracker.partitionsNoWait(ClientPrimaryReplicaTracker.java:231)
at
org.apache.ignite.client.handler.ClientPrimaryReplicaTracker.lambda$partitionsAsync$3(ClientPrimaryReplicaTracker.java:224)
at
java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:642)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
at
org.apache.ignite.internal.util.PendingComparableValuesTracker.lambda$completeWaitersOnUpdate$0(PendingComparableValuesTracker.java:169)
at
java.base/java.util.concurrent.ConcurrentMap.forEach(ConcurrentMap.java:122)
at
org.apache.ignite.internal.util.PendingComparableValuesTracker.completeWaitersOnUpdate(PendingComparableValuesTracker.java:169)
at
org.apache.ignite.internal.util.PendingComparableValuesTracker.update(PendingComparableValuesTracker.java:103)
at
org.apache.ignite.internal.metastorage.server.time.ClusterTimeImpl.updateSafeTime(ClusterTimeImpl.java:146)
at
org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl.onSafeTimeAdvanced(MetaStorageManagerImpl.java:849)
at
org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl$1.onSafeTimeAdvanced(MetaStorageManagerImpl.java:456)
at
org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$advanceSafeTime$9(WatchProcessor.java:322)
at
java.base/java.util.concurrent.CompletableFuture$UniRun.tryFire(CompletableFuture.java:783)
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)
at Apache.Ignite.Internal.ClientSocket.DoOutInOpAsync(ClientOp clientOp,
PooledArrayBuffer request, Boolean expectNotifications) in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/ClientSocket.cs:line
304
at
Apache.Ignite.Internal.ClientFailoverSocket.DoOutInOpAndGetSocketAsync(ClientOp
clientOp, Transaction tx, PooledArrayBuffer request, PreferredNode
preferredNode, IRetryPolicy retryPolicyOverride, Boolean expectNotifications)
in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/ClientFailoverSocket.cs:line
204
at Apache.Ignite.Internal.ClientFailoverSocket.DoOutInOpAsync(ClientOp
clientOp, PooledArrayBuffer request, PreferredNode preferredNode, Boolean
expectNotifications) in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/ClientFailoverSocket.cs:line
153
at Apache.Ignite.Internal.Table.Table.LoadPartitionAssignmentAsync(Int64
timestamp) in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/Table.cs:line
404
at Apache.Ignite.Internal.Table.Table.GetPartitionAssignmentAsync() in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/Table.cs:line
239
at Apache.Ignite.Internal.Table.Table.GetPreferredNode(Int32 colocationHash,
ITransaction transaction) in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/Table.cs:line
198
at
Apache.Ignite.Internal.Compute.Compute.ExecuteColocatedAsync[T,TKey](String
tableName, TKey key, Func`2 serializerHandlerFunc, IEnumerable`1 units, String
jobClassName, Object[] args) in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Compute/Compute.cs:line
268
at Apache.Ignite.Internal.Compute.Compute.ExecuteColocatedAsync[T](String
tableName, IIgniteTuple key, IEnumerable`1 units, String jobClassName, Object[]
args) in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Compute/Compute.cs:line
82
at
Apache.Ignite.Tests.Compute.ComputeTests.TestExecuteColocatedUpdatesTableCacheOnTableDrop()
in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Compute/ComputeTests.cs:line
321
at
[jira] [Updated] (IGNITE-21160) .NET: Thin 3.0: TestExecuteColocatedUpdatesTableCacheOnTableDrop is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-21160:
Description:
Apache.Ignite.Tests.Compute.ComputeTests.TestExecuteColocatedUpdatesTableCacheOnTableDrop
is flaky:
{code}
Apache.Ignite.TableNotFoundException : Table not found: 46
> Apache.Ignite.IgniteException :
org.apache.ignite.lang.TableNotFoundException: IGN-TBL-2
TraceId:ee0df118-c9cf-499e-9325-6fe842d5251b Table not found: 46
at
org.apache.ignite.client.handler.ClientPrimaryReplicaTracker.tableNotFoundException(ClientPrimaryReplicaTracker.java:344)
at
org.apache.ignite.client.handler.ClientPrimaryReplicaTracker.partitionsNoWait(ClientPrimaryReplicaTracker.java:231)
at
org.apache.ignite.client.handler.ClientPrimaryReplicaTracker.lambda$partitionsAsync$3(ClientPrimaryReplicaTracker.java:224)
at
java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:642)
at
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at
java.base/java.util.concurrent.CompletableFuture.complete(CompletableFuture.java:2073)
at
org.apache.ignite.internal.util.PendingComparableValuesTracker.lambda$completeWaitersOnUpdate$0(PendingComparableValuesTracker.java:169)
at
java.base/java.util.concurrent.ConcurrentMap.forEach(ConcurrentMap.java:122)
at
org.apache.ignite.internal.util.PendingComparableValuesTracker.completeWaitersOnUpdate(PendingComparableValuesTracker.java:169)
at
org.apache.ignite.internal.util.PendingComparableValuesTracker.update(PendingComparableValuesTracker.java:103)
at
org.apache.ignite.internal.metastorage.server.time.ClusterTimeImpl.updateSafeTime(ClusterTimeImpl.java:146)
at
org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl.onSafeTimeAdvanced(MetaStorageManagerImpl.java:849)
at
org.apache.ignite.internal.metastorage.impl.MetaStorageManagerImpl$1.onSafeTimeAdvanced(MetaStorageManagerImpl.java:456)
at
org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$advanceSafeTime$9(WatchProcessor.java:322)
at
java.base/java.util.concurrent.CompletableFuture$UniRun.tryFire(CompletableFuture.java:783)
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)
at Apache.Ignite.Internal.ClientSocket.DoOutInOpAsync(ClientOp clientOp,
PooledArrayBuffer request, Boolean expectNotifications) in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/ClientSocket.cs:line
304
at
Apache.Ignite.Internal.ClientFailoverSocket.DoOutInOpAndGetSocketAsync(ClientOp
clientOp, Transaction tx, PooledArrayBuffer request, PreferredNode
preferredNode, IRetryPolicy retryPolicyOverride, Boolean expectNotifications)
in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/ClientFailoverSocket.cs:line
204
at Apache.Ignite.Internal.ClientFailoverSocket.DoOutInOpAsync(ClientOp
clientOp, PooledArrayBuffer request, PreferredNode preferredNode, Boolean
expectNotifications) in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/ClientFailoverSocket.cs:line
153
at Apache.Ignite.Internal.Table.Table.LoadPartitionAssignmentAsync(Int64
timestamp) in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/Table.cs:line
404
at Apache.Ignite.Internal.Table.Table.GetPartitionAssignmentAsync() in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/Table.cs:line
239
at Apache.Ignite.Internal.Table.Table.GetPreferredNode(Int32 colocationHash,
ITransaction transaction) in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Table/Table.cs:line
198
at
Apache.Ignite.Internal.Compute.Compute.ExecuteColocatedAsync[T,TKey](String
tableName, TKey key, Func`2 serializerHandlerFunc, IEnumerable`1 units, String
jobClassName, Object[] args) in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Compute/Compute.cs:line
268
at Apache.Ignite.Internal.Compute.Compute.ExecuteColocatedAsync[T](String
tableName, IIgniteTuple key, IEnumerable`1 units, String jobClassName, Object[]
args) in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite/Internal/Compute/Compute.cs:line
82
at
Apache.Ignite.Tests.Compute.ComputeTests.TestExecuteColocatedUpdatesTableCacheOnTableDrop()
in
/opt/buildagent/work/b8d4df1365f1f1e5/modules/platforms/dotnet/Apache.Ignite.Tests/Compute/ComputeTests.cs:line
321
at
[jira] [Created] (IGNITE-21160) .NET: Thin 3.0: TestExecuteColocatedUpdatesTableCacheOnTableDrop is flaky
Pavel Tupitsyn created IGNITE-21160: --- Summary: .NET: Thin 3.0: TestExecuteColocatedUpdatesTableCacheOnTableDrop is flaky Key: IGNITE-21160 URL: https://issues.apache.org/jira/browse/IGNITE-21160 Project: Ignite Issue Type: Bug Components: platforms, thin client Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21159) Deserialization of Instant field in a Marshallable fails
Roman Puchkovskiy created IGNITE-21159: -- Summary: Deserialization of Instant field in a Marshallable fails Key: IGNITE-21159 URL: https://issues.apache.org/jira/browse/IGNITE-21159 Project: Ignite Issue Type: Bug Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20931) ignite-website: Add documentation, release notes and download links for 2.16.0 release
[ https://issues.apache.org/jira/browse/IGNITE-20931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Amelchev updated IGNITE-20931: - Ignite Flags: (was: Docs Required,Release Notes Required) > ignite-website: Add documentation, release notes and download links for > 2.16.0 release > -- > > Key: IGNITE-20931 > URL: https://issues.apache.org/jira/browse/IGNITE-20931 > Project: Ignite > Issue Type: Sub-task >Reporter: Nikita Amelchev >Assignee: Nikita Amelchev >Priority: Major > > ignite-website: Add documentation, release notes and download links for > 2.16.0 release -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-20931) ignite-website: Add documentation, release notes and download links for 2.16.0 release
[ https://issues.apache.org/jira/browse/IGNITE-20931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Amelchev resolved IGNITE-20931. -- Resolution: Fixed > ignite-website: Add documentation, release notes and download links for > 2.16.0 release > -- > > Key: IGNITE-20931 > URL: https://issues.apache.org/jira/browse/IGNITE-20931 > Project: Ignite > Issue Type: Sub-task >Reporter: Nikita Amelchev >Assignee: Nikita Amelchev >Priority: Major > > ignite-website: Add documentation, release notes and download links for > 2.16.0 release -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-19854) ODBC 3.0: Implement parameter metadata fetching for the non-executed query
[ https://issues.apache.org/jira/browse/IGNITE-19854?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800695#comment-17800695 ] Pavel Tupitsyn commented on IGNITE-19854: - [~isapego] looks good to me. > ODBC 3.0: Implement parameter metadata fetching for the non-executed query > -- > > Key: IGNITE-19854 > URL: https://issues.apache.org/jira/browse/IGNITE-19854 > Project: Ignite > Issue Type: New Feature > Components: odbc >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > We currently do not have a prepare feature, but sometimes user application > wants to get a parameter meta information without execution of the query. See > [SQLDescribeParam|https://learn.microsoft.com/en-us/sql/odbc/reference/syntax/sqldescribeparam-function]. > We need to implement this feature. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21143) SQL: Backslash cannot be escaped in LIKE ESCAPE operator
[
https://issues.apache.org/jira/browse/IGNITE-21143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky reassigned IGNITE-21143:
---
Assignee: Evgeny Stanilovsky
> SQL: Backslash cannot be escaped in LIKE ESCAPE operator
>
>
> Key: IGNITE-21143
> URL: https://issues.apache.org/jira/browse/IGNITE-21143
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3, sql
>
> When using custom escape symbol in LIKE operator, we cannot escape backslash.
> A error is raised here:
> {code:sql}
> sql-cli> select 'Dev_ops' like 'Dev#_ops' escape '#'; -- works as
> expected
> ╔═╗
> ║ EXPR$0 ║
> ╠═╣
> ║ true║
> ╚═╝
> sql-cli> select 'Dev\ops' like 'Dev#\ops' escape '#'; -- doesn't work
> SQL query execution error
> Invalid escape sequence 'Dev#\ops', 3
> {code}
> In AI2 or some other DBMS, the latter query works without error:
> {code}
> select 'Dev\ops' like 'Dev#\ops' escape '#' -> true
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21143) SQL: Backslash cannot be escaped in LIKE ESCAPE operator
[
https://issues.apache.org/jira/browse/IGNITE-21143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-21143:
Ignite Flags: (was: Docs Required,Release Notes Required)
> SQL: Backslash cannot be escaped in LIKE ESCAPE operator
>
>
> Key: IGNITE-21143
> URL: https://issues.apache.org/jira/browse/IGNITE-21143
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3, sql
>
> When using custom escape symbol in LIKE operator, we cannot escape backslash.
> A error is raised here:
> {code:sql}
> sql-cli> select 'Dev_ops' like 'Dev#_ops' escape '#'; -- works as
> expected
> ╔═╗
> ║ EXPR$0 ║
> ╠═╣
> ║ true║
> ╚═╝
> sql-cli> select 'Dev\ops' like 'Dev#\ops' escape '#'; -- doesn't work
> SQL query execution error
> Invalid escape sequence 'Dev#\ops', 3
> {code}
> In AI2 or some other DBMS, the latter query works without error:
> {code}
> select 'Dev\ops' like 'Dev#\ops' escape '#' -> true
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19854) ODBC 3.0: Implement parameter metadata fetching for the non-executed query
[ https://issues.apache.org/jira/browse/IGNITE-19854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-19854: - Description: We currently do not have a prepare feature, but sometimes user application wants to get a parameter meta information without execution of the query. See [SQLDescribeParam|https://learn.microsoft.com/en-us/sql/odbc/reference/syntax/sqldescribeparam-function]. We need to implement this feature. (was: We currently do not have a prepare feature, but sometimes user application wants to get a result set meta information without execution of the query. We need to implement this feature.) > ODBC 3.0: Implement parameter metadata fetching for the non-executed query > -- > > Key: IGNITE-19854 > URL: https://issues.apache.org/jira/browse/IGNITE-19854 > Project: Ignite > Issue Type: New Feature > Components: odbc >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > > We currently do not have a prepare feature, but sometimes user application > wants to get a parameter meta information without execution of the query. See > [SQLDescribeParam|https://learn.microsoft.com/en-us/sql/odbc/reference/syntax/sqldescribeparam-function]. > We need to implement this feature. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19854) ODBC 3.0: Implement parameter metadata fetching for the non-executed query
[ https://issues.apache.org/jira/browse/IGNITE-19854?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-19854: - Summary: ODBC 3.0: Implement parameter metadata fetching for the non-executed query (was: ODBC 3.0: Implement metadata fetching for the non-executed query) > ODBC 3.0: Implement parameter metadata fetching for the non-executed query > -- > > Key: IGNITE-19854 > URL: https://issues.apache.org/jira/browse/IGNITE-19854 > Project: Ignite > Issue Type: New Feature > Components: odbc >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > > We currently do not have a prepare feature, but sometimes user application > wants to get a result set meta information without execution of the query. We > need to implement this feature. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21158) ODBC 3.0: Implement column metadata fetching for the non-executed query
Igor Sapego created IGNITE-21158: Summary: ODBC 3.0: Implement column metadata fetching for the non-executed query Key: IGNITE-21158 URL: https://issues.apache.org/jira/browse/IGNITE-21158 Project: Ignite Issue Type: New Feature Components: odbc Reporter: Igor Sapego Assignee: Igor Sapego Fix For: 3.0.0-beta2 We currently do not have a prepare feature, but sometimes user application wants to get a result set meta information without execution of the query. We need to implement this feature. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20850) Worker node shutdown failover
[ https://issues.apache.org/jira/browse/IGNITE-20850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-20850: -- Assignee: Aleksandr > Worker node shutdown failover > - > > Key: IGNITE-20850 > URL: https://issues.apache.org/jira/browse/IGNITE-20850 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Mikhail Pochatkin >Assignee: Aleksandr >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > In this case, the job execution stops and you need to restart it. In this > case, the coordinator will see that the worker node has turned off and all > the tasks that this coordinator sent for execution must be redistributed to > other nodes. In this context, it does not matter what state the tasks were > in, in the queue or in the process of execution, we do not offer a safepoint > mechanism, and all states of jobs can be written to the cache, so when a task > is launched on another worker node, it will be able to read from the cache > the state that the job I wrote it down last time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20850) Worker node shutdown failover
[ https://issues.apache.org/jira/browse/IGNITE-20850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-20850: -- Assignee: (was: Aleksandr) > Worker node shutdown failover > - > > Key: IGNITE-20850 > URL: https://issues.apache.org/jira/browse/IGNITE-20850 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > In this case, the job execution stops and you need to restart it. In this > case, the coordinator will see that the worker node has turned off and all > the tasks that this coordinator sent for execution must be redistributed to > other nodes. In this context, it does not matter what state the tasks were > in, in the queue or in the process of execution, we do not offer a safepoint > mechanism, and all states of jobs can be written to the cache, so when a task > is launched on another worker node, it will be able to read from the cache > the state that the job I wrote it down last time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20927) Update IgniteReleasedVersion for compatibility tests to 2.16.0
[ https://issues.apache.org/jira/browse/IGNITE-20927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Amelchev updated IGNITE-20927: - Fix Version/s: 2.17 > Update IgniteReleasedVersion for compatibility tests to 2.16.0 > -- > > Key: IGNITE-20927 > URL: https://issues.apache.org/jira/browse/IGNITE-20927 > Project: Ignite > Issue Type: Sub-task >Reporter: Nikita Amelchev >Assignee: Nikita Amelchev >Priority: Major > Fix For: 2.17 > > Time Spent: 10m > Remaining Estimate: 0h > > Update IgniteReleasedVersion for compatibility tests to 2.16.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20927) Update IgniteReleasedVersion for compatibility tests to 2.16.0
[ https://issues.apache.org/jira/browse/IGNITE-20927?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita Amelchev updated IGNITE-20927: - Ignite Flags: (was: Docs Required,Release Notes Required) > Update IgniteReleasedVersion for compatibility tests to 2.16.0 > -- > > Key: IGNITE-20927 > URL: https://issues.apache.org/jira/browse/IGNITE-20927 > Project: Ignite > Issue Type: Sub-task >Reporter: Nikita Amelchev >Assignee: Nikita Amelchev >Priority: Major > Fix For: 2.17 > > Time Spent: 10m > Remaining Estimate: 0h > > Update IgniteReleasedVersion for compatibility tests to 2.16.0 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21155) Adding a in-flight RW transaction counter by catalog version on a node
[ https://issues.apache.org/jira/browse/IGNITE-21155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko reassigned IGNITE-21155: Assignee: Kirill Tkalenko > Adding a in-flight RW transaction counter by catalog version on a node > -- > > Key: IGNITE-21155 > URL: https://issues.apache.org/jira/browse/IGNITE-21155 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > To implement IGNITE-21112, we need an in-flight transaction counter based on > catalog versions. To begin putting the index into backfilling state. > We also need to implement request that can tell whether there are > transactions on a node before the index appears. > See IGNITE-21112 for more details. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21157) Introducing transaction priority to resolve user and service transaction conflicts
Ivan Gagarkin created IGNITE-21157: -- Summary: Introducing transaction priority to resolve user and service transaction conflicts Key: IGNITE-21157 URL: https://issues.apache.org/jira/browse/IGNITE-21157 Project: Ignite Issue Type: Improvement Reporter: Ivan Gagarkin We need to introduce a new transaction attribute: transaction priority. This addition is necessary to resolve potential conflicts between user transactions and internal Ignite services transactions. Transactions from services should be assigned a LOW priority. In the event of a conflict, the DeadlockPreventionPolicy will assess the priorities of the involved transactions. If the priorities are the same, the policy will then compare timestamps; otherwise, the transaction with the lower priority will be rolled back. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21156) [IEP-114] Custom metrics introduction
[ https://issues.apache.org/jira/browse/IGNITE-21156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800510#comment-17800510 ] Vladimir Steshin edited comment on IGNITE-21156 at 12/26/23 3:54 PM: - This ticket introduces Custom Metrics proposed by IEP-114. was (Author: vladsz83): This ticket introduces custom metrics proposed by IEP-114. > [IEP-114] Custom metrics introduction > - > > Key: IGNITE-21156 > URL: https://issues.apache.org/jira/browse/IGNITE-21156 > Project: Ignite > Issue Type: Task >Reporter: Vladimir Steshin >Priority: Major > Labels: eip-144 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21156) [IEP-114] Custom metrics introduction
[ https://issues.apache.org/jira/browse/IGNITE-21156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-21156: -- Summary: [IEP-114] Custom metrics introduction (was: Custom metrics introduction) > [IEP-114] Custom metrics introduction > - > > Key: IGNITE-21156 > URL: https://issues.apache.org/jira/browse/IGNITE-21156 > Project: Ignite > Issue Type: Task >Reporter: Vladimir Steshin >Priority: Major > Labels: eip-144 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21156) Custom metrics introduction
[ https://issues.apache.org/jira/browse/IGNITE-21156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800510#comment-17800510 ] Vladimir Steshin commented on IGNITE-21156: --- This ticket introduces custom metrics proposed by IEP-114. > Custom metrics introduction > --- > > Key: IGNITE-21156 > URL: https://issues.apache.org/jira/browse/IGNITE-21156 > Project: Ignite > Issue Type: Task >Reporter: Vladimir Steshin >Priority: Major > Labels: eip-144 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21156) Custom metrics introduction
[ https://issues.apache.org/jira/browse/IGNITE-21156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-21156: -- Labels: eip-144 (was: ) > Custom metrics introduction > --- > > Key: IGNITE-21156 > URL: https://issues.apache.org/jira/browse/IGNITE-21156 > Project: Ignite > Issue Type: Task >Reporter: Vladimir Steshin >Priority: Major > Labels: eip-144 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21156) Custom metrics introduction
Vladimir Steshin created IGNITE-21156: - Summary: Custom metrics introduction Key: IGNITE-21156 URL: https://issues.apache.org/jira/browse/IGNITE-21156 Project: Ignite Issue Type: Task Reporter: Vladimir Steshin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21155) Adding a in-flight RW transaction counter by catalog version on a node
Kirill Tkalenko created IGNITE-21155: Summary: Adding a in-flight RW transaction counter by catalog version on a node Key: IGNITE-21155 URL: https://issues.apache.org/jira/browse/IGNITE-21155 Project: Ignite Issue Type: Improvement Reporter: Kirill Tkalenko Fix For: 3.0.0-beta2 To implement IGNITE-21112, we need an in-flight transaction counter based on catalog versions. To begin putting the index into backfilling state. We also need to implement request that can tell whether there are transactions on a node before the index appears. See IGNITE-21112 for more details. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21153) Rethink LockManager extensions
[
https://issues.apache.org/jira/browse/IGNITE-21153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Sizov updated IGNITE-21153:
---
Summary: Rethink LockManager extensions (was: Better LockManager extension)
> Rethink LockManager extensions
> --
>
> Key: IGNITE-21153
> URL: https://issues.apache.org/jira/browse/IGNITE-21153
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Sizov
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> There is a {{LockManager}} "extension" - {{OrphanDetector}} - that checks
> whether the lock holder is no longer available and fails the waiting
> transaction.
> So we have a two-way stream of control here - {{LockManager}} notifies
> {{OrphanDetector}} and expects a response from it.
> Currently {{OrphanDetector}} binds to {{LockManager}} using event
> notifications, the response from it is handled in an extremely hacky way -
> using exceptionally completed future.
> *Definition of Done*
> There should be a way to ask {{OrphanDetector}} and handle its response in a
> more straightforward and synchronous way.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21154) Improve InternalTable API
Ivan Gagarkin created IGNITE-21154:
--
Summary: Improve InternalTable API
Key: IGNITE-21154
URL: https://issues.apache.org/jira/browse/IGNITE-21154
Project: Ignite
Issue Type: Improvement
Components: sql
Reporter: Ivan Gagarkin
Currently, {{org.apache.ignite.internal.table.InternalTable}} contains two
methods, {{deleteAllExact}} and {{{}deleteExact{}}}, which compare all columns
of the stored and provided rows, subsequently deleting the rows if their
columns are equal. We need to introduce an option allowing specification of
only selected columns for equality checks.
Additionally, there is a need for methods capable of deleting rows in a
specific partition. This would involve implementing functionality like
{code:java}
CompletableFuture delete(BinaryRowEx keyRow, int partitionId,
@Nullable InternalTransaction tx);{code}
to enable targeted row deletion within an exact partition.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21153) Better LockManager extension
[
https://issues.apache.org/jira/browse/IGNITE-21153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Sizov updated IGNITE-21153:
---
Summary: Better LockManager extension (was: Create better LockManager
extension)
> Better LockManager extension
>
>
> Key: IGNITE-21153
> URL: https://issues.apache.org/jira/browse/IGNITE-21153
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Sizov
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> There is a {{LockManager}} "extension" - {{OrphanDetector}} - that checks
> whether the lock holder is no longer available and fails the waiting
> transaction.
> So we have a two-way stream of control here - {{LockManager}} notifies
> {{OrphanDetector}} and expects a response from it.
> Currently {{OrphanDetector}} binds to {{LockManager}} using event
> notifications, the response from it is handled in an extremely hacky way -
> using exceptionally completed future.
> *Definition of Done*
> There should be a way to ask {{OrphanDetector}} and handle its response in a
> more straightforward and synchronous way.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21153) Create better LockManager extension
Kirill Sizov created IGNITE-21153:
--
Summary: Create better LockManager extension
Key: IGNITE-21153
URL: https://issues.apache.org/jira/browse/IGNITE-21153
Project: Ignite
Issue Type: Task
Reporter: Kirill Sizov
*Motivation*
There is a {{LockManager}} "extension" - {{OrphanDetector}} - that checks
whether the lock holder is no longer available and fails the waiting
transaction.
So we have a two-way stream of control here - {{LockManager}} notifies
{{OrphanDetector}} and expects a response from it.
Currently {{OrphanDetector}} binds to {{LockManager}} using event
notifications, the response from it is handled in an extremely hacky way -
using exceptionally completed future.
*Definition of Done*
There should be a way to ask {{OrphanDetector}} and handle its response in a
more straightforward and synchronous way.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21102) Incorrect cluster state output for ACTIVE_READ_ONLY in --baseline
[
https://issues.apache.org/jira/browse/IGNITE-21102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800481#comment-17800481
]
Oleg Valuyskiy edited comment on IGNITE-21102 at 12/26/23 1:01 PM:
---
[~yuri.naryshkin], please review my changes.
The ‘ClusterState’ property has been added to the ‘BaseLineTaskResult’ class;
this property is now used to indicate the state of a cluster in the
‘AbstractBaselineCommand#printResult’ method – instead of the ‘active/inactive’
flag.
was (Author: JIRAUSER303481):
[~nizhikov], please review my changes.
The ‘ClusterState’ property has been added to the ‘BaseLineTaskResult’ class;
this property is now used to indicate the state of a cluster in the
‘AbstractBaselineCommand#printResult’ method – instead of the ‘active/inactive’
flag.
> Incorrect cluster state output for ACTIVE_READ_ONLY in --baseline
> -
>
> Key: IGNITE-21102
> URL: https://issues.apache.org/jira/browse/IGNITE-21102
> Project: Ignite
> Issue Type: Bug
>Reporter: Julia Bakulina
>Assignee: Oleg Valuyskiy
>Priority: Major
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Incorrect cluster state output for ACTIVE_READ_ONLY in --baseline.
> org.apache.ignite.internal.commandline.BaselineCommand#baselinePrint0
> {code:java}
> logger.info("Cluster state: " + (res.isActive() ? "active" :
> "inactive"));
> {code}
> org.apache.ignite.cluster.ClusterState#ACTIVE_READ_ONLY
>
> An example of changing the cluster state:
> {code:java}
> Command [SET-STATE] started
> Arguments: ... --set-state ACTIVE_READ_ONLY
>
> Cluster state changed to ACTIVE_READ_ONLY
> Command [SET-STATE] finished with code: 0 {code}
> Cluster state in control.sh --baseline
> {code:java}
> Command [BASELINE] started
> Arguments: ... --baseline
>
> Cluster state: active
> Current topology version: 1
> Baseline auto adjustment disabled:...
> Current topology version: 1 (...)
> Baseline nodes:
> ...
>
> Number of baseline nodes: 1
> Other nodes not found.
> Command [BASELINE] finished with code: 0 {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21102) Incorrect cluster state output for ACTIVE_READ_ONLY in --baseline
[
https://issues.apache.org/jira/browse/IGNITE-21102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800481#comment-17800481
]
Oleg Valuyskiy commented on IGNITE-21102:
-
[~nizhikov], please review my changes.
The ‘ClusterState’ property has been added to the ‘BaseLineTaskResult’ class;
this property is now used to indicate the state of a cluster in the
‘AbstractBaselineCommand#printResult’ method – instead of the ‘active/inactive’
flag.
> Incorrect cluster state output for ACTIVE_READ_ONLY in --baseline
> -
>
> Key: IGNITE-21102
> URL: https://issues.apache.org/jira/browse/IGNITE-21102
> Project: Ignite
> Issue Type: Bug
>Reporter: Julia Bakulina
>Assignee: Oleg Valuyskiy
>Priority: Major
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Incorrect cluster state output for ACTIVE_READ_ONLY in --baseline.
> org.apache.ignite.internal.commandline.BaselineCommand#baselinePrint0
> {code:java}
> logger.info("Cluster state: " + (res.isActive() ? "active" :
> "inactive"));
> {code}
> org.apache.ignite.cluster.ClusterState#ACTIVE_READ_ONLY
>
> An example of changing the cluster state:
> {code:java}
> Command [SET-STATE] started
> Arguments: ... --set-state ACTIVE_READ_ONLY
>
> Cluster state changed to ACTIVE_READ_ONLY
> Command [SET-STATE] finished with code: 0 {code}
> Cluster state in control.sh --baseline
> {code:java}
> Command [BASELINE] started
> Arguments: ... --baseline
>
> Cluster state: active
> Current topology version: 1
> Baseline auto adjustment disabled:...
> Current topology version: 1 (...)
> Baseline nodes:
> ...
>
> Number of baseline nodes: 1
> Other nodes not found.
> Command [BASELINE] finished with code: 0 {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21102) Incorrect cluster state output for ACTIVE_READ_ONLY in --baseline
[
https://issues.apache.org/jira/browse/IGNITE-21102?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800480#comment-17800480
]
Ignite TC Bot commented on IGNITE-21102:
{panel:title=Branch: [pull/11138/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11138/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=7676154buildTypeId=IgniteTests24Java8_RunAll]
> Incorrect cluster state output for ACTIVE_READ_ONLY in --baseline
> -
>
> Key: IGNITE-21102
> URL: https://issues.apache.org/jira/browse/IGNITE-21102
> Project: Ignite
> Issue Type: Bug
>Reporter: Julia Bakulina
>Assignee: Oleg Valuyskiy
>Priority: Major
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Incorrect cluster state output for ACTIVE_READ_ONLY in --baseline.
> org.apache.ignite.internal.commandline.BaselineCommand#baselinePrint0
> {code:java}
> logger.info("Cluster state: " + (res.isActive() ? "active" :
> "inactive"));
> {code}
> org.apache.ignite.cluster.ClusterState#ACTIVE_READ_ONLY
>
> An example of changing the cluster state:
> {code:java}
> Command [SET-STATE] started
> Arguments: ... --set-state ACTIVE_READ_ONLY
>
> Cluster state changed to ACTIVE_READ_ONLY
> Command [SET-STATE] finished with code: 0 {code}
> Cluster state in control.sh --baseline
> {code:java}
> Command [BASELINE] started
> Arguments: ... --baseline
>
> Cluster state: active
> Current topology version: 1
> Baseline auto adjustment disabled:...
> Current topology version: 1 (...)
> Baseline nodes:
> ...
>
> Number of baseline nodes: 1
> Other nodes not found.
> Command [BASELINE] finished with code: 0 {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20882) Append performance tests
[ https://issues.apache.org/jira/browse/IGNITE-20882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17800470#comment-17800470 ] Andrey Novikov commented on IGNITE-20882: - Single-node embedded: ||Benchmark||Score(us/op)|| |CriteriaSingleNodeBenchmark.criteriaGet|1780,171 ± 35,306| |CriteriaSingleNodeBenchmark.kvGet|121,114 ± 1,726| |CriteriaSingleNodeBenchmark.sqlGet|1703,928 ± 34,945| > Append performance tests > > > Key: IGNITE-20882 > URL: https://issues.apache.org/jira/browse/IGNITE-20882 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Novikov >Assignee: Andrey Novikov >Priority: Major > Labels: ignite-3 > > # Compare single-key criteria vs single-key SQL vs table.get(PK) > * Expect to have similar performance > * Check single-node embedded, distributed with no partition awareness, > distributed with partition awareness > * NOTE: future improvement for criteria query – lookup affinity node if PK > or colocation key is in the criteria. > # Compare criteria vs SQL when affinity key is specified (unicast when > partition pruning is added) > # Compare criteria vs SQL for broadcast queries – latency and throughput > # Compare criteria vs SQL – time it takes to iterate over 10kk entries -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21068) Ignite node must not communicate with a node removed from the Physical Topology
[ https://issues.apache.org/jira/browse/IGNITE-21068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy reassigned IGNITE-21068: -- Assignee: Roman Puchkovskiy > Ignite node must not communicate with a node removed from the Physical > Topology > --- > > Key: IGNITE-21068 > URL: https://issues.apache.org/jira/browse/IGNITE-21068 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > It is possible for a node to be considered DEAD due to a timeout (because it > did not respond to a series of pings in a timely manner) even though the > network channel is still operational. Currently, even after a nodes is > removed from the Physical Topology, it can still send/receive messages. > This breaks an invariant that such a node must not be able to communicate > with the cluster. -- This message was sent by Atlassian Jira (v8.20.10#820010)
