[jira] [Comment Edited] (IGNITE-22032) Sql. JSON_OBJECT. Internal representation DATE values leaks into resulting JSON object
[
https://issues.apache.org/jira/browse/IGNITE-22032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836407#comment-17836407
]
Maksim Zhuravkov edited comment on IGNITE-22032 at 4/12/24 5:00 AM:
Adding a cast to VARCHAR can be used as a workaround:
{code}
select json_object('date': '2010-01-01'::DATE::VARCHAR)
{"date":"2010-01-01"}
{code}
was (Author: JIRAUSER298618):
Adding a cast to VARCHAR can be used as a workaround:
{code}
select json_object('date': '2010-01-01'::DATE::VARCHAR)
{"date":"2010-01-01"}
{code}
> Sql. JSON_OBJECT. Internal representation DATE values leaks into resulting
> JSON object
> --
>
> Key: IGNITE-22032
> URL: https://issues.apache.org/jira/browse/IGNITE-22032
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> Most databases (see calcite issue) return a json that contains a date string,
> but calcite returns its internal representation of date values (number of
> days as int)
> {code}
> SELECT JSON_OBJECT('a': CAST('2010-01-01' AS DATE)) as c1
> {"a":14610}
> {code}
> Expected behaviour:
> {code}
> SELECT JSON_OBJECT('a': CAST('2010-01-01' AS DATE)) as c1
> {"a":"2010-01-01"}
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-22032) Sql. JSON_OBJECT. Internal representation DATE values leaks into resulting JSON object
[
https://issues.apache.org/jira/browse/IGNITE-22032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836407#comment-17836407
]
Maksim Zhuravkov commented on IGNITE-22032:
---
Adding a cast to VARCHAR can be used as workaround:
{code}
select json_object('date': '2010-01-01'::DATE::VARCHAR)
{"date":"2010-01-01"}
{code}
> Sql. JSON_OBJECT. Internal representation DATE values leaks into resulting
> JSON object
> --
>
> Key: IGNITE-22032
> URL: https://issues.apache.org/jira/browse/IGNITE-22032
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> Most databases (see calcite issue) return a json that contains a date string,
> but calcite returns its internal representation of date values (number of
> days as int)
> {code}
> SELECT JSON_OBJECT('a': CAST('2010-01-01' AS DATE)) as c1
> {"a":14610}
> {code}
> Expected behaviour:
> {code}
> SELECT JSON_OBJECT('a': CAST('2010-01-01' AS DATE)) as c1
> {"a":"2010-01-01"}
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-22032) Sql. JSON_OBJECT. Internal representation DATE values leaks into resulting JSON object
[
https://issues.apache.org/jira/browse/IGNITE-22032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836407#comment-17836407
]
Maksim Zhuravkov edited comment on IGNITE-22032 at 4/12/24 4:52 AM:
Adding a cast to VARCHAR can be used as a workaround:
{code}
select json_object('date': '2010-01-01'::DATE::VARCHAR)
{"date":"2010-01-01"}
{code}
was (Author: JIRAUSER298618):
Adding a cast to VARCHAR can be used as workaround:
{code}
select json_object('date': '2010-01-01'::DATE::VARCHAR)
{"date":"2010-01-01"}
{code}
> Sql. JSON_OBJECT. Internal representation DATE values leaks into resulting
> JSON object
> --
>
> Key: IGNITE-22032
> URL: https://issues.apache.org/jira/browse/IGNITE-22032
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> Most databases (see calcite issue) return a json that contains a date string,
> but calcite returns its internal representation of date values (number of
> days as int)
> {code}
> SELECT JSON_OBJECT('a': CAST('2010-01-01' AS DATE)) as c1
> {"a":14610}
> {code}
> Expected behaviour:
> {code}
> SELECT JSON_OBJECT('a': CAST('2010-01-01' AS DATE)) as c1
> {"a":"2010-01-01"}
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21961) Don't remove entries one-by-one for in-memory node on shutdown
[
https://issues.apache.org/jira/browse/IGNITE-21961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836357#comment-17836357
]
Ignite TC Bot commented on IGNITE-21961:
{panel:title=Branch: [pull/11302/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11302/head] Base: [master] : New Tests
(8)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 13{color} [[tests
8|https://ci2.ignite.apache.org/viewLog.html?buildId=7811907]]
* {color:#013220}IgniteCacheTestSuite13:
EntriesRemoveOnShutdownTest.testCacheGroupDestroy[pds=true] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
EntriesRemoveOnShutdownTest.testCacheDestroy[pds=true] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
EntriesRemoveOnShutdownTest.testCacheGroupDestroy[pds=false] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
EntriesRemoveOnShutdownTest.testCacheDestroy[pds=false] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
EntriesRemoveOnShutdownTest.testShutdown[pds=true] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
EntriesRemoveOnShutdownTest.testDeactivate[pds=true] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
EntriesRemoveOnShutdownTest.testShutdown[pds=false] - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
EntriesRemoveOnShutdownTest.testDeactivate[pds=false] - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7812005buildTypeId=IgniteTests24Java8_RunAll]
> Don't remove entries one-by-one for in-memory node on shutdown
> --
>
> Key: IGNITE-21961
> URL: https://issues.apache.org/jira/browse/IGNITE-21961
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently, for in-memory node we remove each entry one-by-one on cluster
> deactivation or on node shutdown. If there are a lot of entries in cache it
> can take a long time. But it's a redundant action, since all page memory will
> be released after deactivation/shutdown.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21884) Removal of MvccIO and MvccVersionAware
[ https://issues.apache.org/jira/browse/IGNITE-21884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836318#comment-17836318 ] Ilya Shishkov commented on IGNITE-21884: [~av], can you take a look, please? > Removal of MvccIO and MvccVersionAware > -- > > Key: IGNITE-21884 > URL: https://issues.apache.org/jira/browse/IGNITE-21884 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Ilya Shishkov >Assignee: Ilya Shishkov >Priority: Minor > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > > MvccIO and MvccVersionAware classes and corresponding code have to be removed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21884) Removal of MvccIO and MvccVersionAware
[
https://issues.apache.org/jira/browse/IGNITE-21884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836317#comment-17836317
]
Ignite TC Bot commented on IGNITE-21884:
{panel:title=Branch: [pull/11299/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11299/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=7821169buildTypeId=IgniteTests24Java8_RunAll]
> Removal of MvccIO and MvccVersionAware
> --
>
> Key: IGNITE-21884
> URL: https://issues.apache.org/jira/browse/IGNITE-21884
> Project: Ignite
> Issue Type: Sub-task
> Components: mvcc
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> MvccIO and MvccVersionAware classes and corresponding code have to be removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-22029) Change default configuration according to default RAFT option
[ https://issues.apache.org/jira/browse/IGNITE-22029?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov reassigned IGNITE-22029: -- Assignee: Vladislav Pyatkov > Change default configuration according to default RAFT option > - > > Key: IGNITE-22029 > URL: https://issues.apache.org/jira/browse/IGNITE-22029 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > h3. Motivation > The stripes default abount is changed in IGNITE-21907, but it did not > modified in RaftConfigurationSchema. > h3. Defenition of done > Need change the default in RAFT configuration as it is done in RAFT option. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22030) Thin 3.0: Remove jackson-dataformat-msgpack dependency
[ https://issues.apache.org/jira/browse/IGNITE-22030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836239#comment-17836239 ] Pavel Tupitsyn commented on IGNITE-22030: - Merged to master: d1635529efecf298b0c0d8761c89e89f316e8dbe > Thin 3.0: Remove jackson-dataformat-msgpack dependency > -- > > Key: IGNITE-22030 > URL: https://issues.apache.org/jira/browse/IGNITE-22030 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > jackson-dataformat-msgpack dependency is not used, remove it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22030) Thin 3.0: Remove jackson-dataformat-msgpack dependency
[ https://issues.apache.org/jira/browse/IGNITE-22030?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836235#comment-17836235 ] Igor Sapego commented on IGNITE-22030: -- Looks good to me. > Thin 3.0: Remove jackson-dataformat-msgpack dependency > -- > > Key: IGNITE-22030 > URL: https://issues.apache.org/jira/browse/IGNITE-22030 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > jackson-dataformat-msgpack dependency is not used, remove it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22026) Fix incorrect retry logic in GridCacheIoManager send method
[
https://issues.apache.org/jira/browse/IGNITE-22026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov reassigned IGNITE-22026:
--
Assignee: Ilya Shishkov
> Fix incorrect retry logic in GridCacheIoManager send method
> ---
>
> Key: IGNITE-22026
> URL: https://issues.apache.org/jira/browse/IGNITE-22026
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise
> Attachments: GridCacheIoManagerRetryTest.patch
>
>
> {{GridCacheIoManager#send}}[1] and
> {{GridCacheIoManager#sendOrderedMessage}}[2] have incorrect {{retryCnt}}
> comparison in catch block and real retries count will be one less, than
> configured.
> Thus, if you set {{IgniteConfiguration#setNetworkSendRetryCount}} to 1 and
> {{IgniteCheckedException}} has been thrown during sending of message because
> of network timeout, error, etc., then no actual retries will happen and
> message will be lost.
> Reproducer: [^GridCacheIoManagerRetryTest.patch]
> Links:
> #
> https://github.com/apache/ignite/blob/6286f67735b2eb7312bc61d5e0549b22f424348f/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheIoManager.java#L1222
> #
> https://github.com/apache/ignite/blob/6286f67735b2eb7312bc61d5e0549b22f424348f/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheIoManager.java#L1289
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21902) Add an option to configure log storage path
[ https://issues.apache.org/jira/browse/IGNITE-21902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philipp Shergalis reassigned IGNITE-21902: -- Assignee: Philipp Shergalis > Add an option to configure log storage path > --- > > Key: IGNITE-21902 > URL: https://issues.apache.org/jira/browse/IGNITE-21902 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Philipp Shergalis >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Option to store log and data on separate devices can substantially improve > the performance in a long run for many users, we should implement it. > There is such an option in Ignite 2, and people use it all the time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22032) Sql. JSON_OBJECT. Internal representation DATE values leaks into resulting JSON object
[
https://issues.apache.org/jira/browse/IGNITE-22032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22032:
--
Description:
Most databases (see calcite issue) return a json that contains a date string,
but calcite returns its internal representation of date values (number of days
as int)
{code}
SELECT JSON_OBJECT('a': CAST('2010-01-01' AS DATE)) as c1
{"a":14610}
{code}
Expected behaviour:
{code}
SELECT JSON_OBJECT('a': CAST('2010-01-01' AS DATE)) as c1
{"a":"2010-01-01"}
{code}
was:
Most databases (see calcite issue) return a json that contains a date string,
but calcite returns its internal representation of date values (number of days
as int)
{code}
SELECT JSON_OBJECT('a': CAST('2010-01-01' AS DATE)) as c1
{"a":14610}
{code}
> Sql. JSON_OBJECT. Internal representation DATE values leaks into resulting
> JSON object
> --
>
> Key: IGNITE-22032
> URL: https://issues.apache.org/jira/browse/IGNITE-22032
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> Most databases (see calcite issue) return a json that contains a date string,
> but calcite returns its internal representation of date values (number of
> days as int)
> {code}
> SELECT JSON_OBJECT('a': CAST('2010-01-01' AS DATE)) as c1
> {"a":14610}
> {code}
> Expected behaviour:
> {code}
> SELECT JSON_OBJECT('a': CAST('2010-01-01' AS DATE)) as c1
> {"a":"2010-01-01"}
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22032) Sql. JSON_OBJECT. Internal representation DATE values leaks into resulting JSON object
[
https://issues.apache.org/jira/browse/IGNITE-22032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22032:
--
Component/s: sql
> Sql. JSON_OBJECT. Internal representation DATE values leaks into resulting
> JSON object
> --
>
> Key: IGNITE-22032
> URL: https://issues.apache.org/jira/browse/IGNITE-22032
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> Most databases (see calcite issue) return a json that contains a date string,
> but calcite returns its internal representation of date values (number of
> days as int)
> {code}
> SELECT JSON_OBJECT('a': CAST('2010-01-01' AS DATE)) as c1
> {"a":14610}
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22032) Sql. JSON_OBJECT. Internal representation DATE values leaks into resulting JSON object
[
https://issues.apache.org/jira/browse/IGNITE-22032?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-22032:
--
Labels: ignite-3 (was: )
> Sql. JSON_OBJECT. Internal representation DATE values leaks into resulting
> JSON object
> --
>
> Key: IGNITE-22032
> URL: https://issues.apache.org/jira/browse/IGNITE-22032
> Project: Ignite
> Issue Type: Bug
>Reporter: Maksim Zhuravkov
>Priority: Minor
> Labels: ignite-3
>
> Most databases (see calcite issue) return a json that contains a date string,
> but calcite returns its internal representation of date values (number of
> days as int)
> {code}
> SELECT JSON_OBJECT('a': CAST('2010-01-01' AS DATE)) as c1
> {"a":14610}
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22031) .NET: Thin 3.0: Remove DataStreamer.PartitionAssignmentUpdateFrequency
[ https://issues.apache.org/jira/browse/IGNITE-22031?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-22031: Description: Timer-based partition assignment check is not necessary. *Table.GetPartitionAssignmentAsync* is backed by a cache with a double-checked locking, and uses a *ValueTask*, so there is no overhead in case of unchanged assignment - we can call it as often as needed. > .NET: Thin 3.0: Remove DataStreamer.PartitionAssignmentUpdateFrequency > -- > > Key: IGNITE-22031 > URL: https://issues.apache.org/jira/browse/IGNITE-22031 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > Timer-based partition assignment check is not necessary. > *Table.GetPartitionAssignmentAsync* is backed by a cache with a > double-checked locking, and uses a *ValueTask*, so there is no overhead in > case of unchanged assignment - we can call it as often as needed. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22032) Sql. JSON_OBJECT. Internal representation DATE values leaks into resulting JSON object
Maksim Zhuravkov created IGNITE-22032:
-
Summary: Sql. JSON_OBJECT. Internal representation DATE values
leaks into resulting JSON object
Key: IGNITE-22032
URL: https://issues.apache.org/jira/browse/IGNITE-22032
Project: Ignite
Issue Type: Bug
Reporter: Maksim Zhuravkov
Most databases (see calcite issue) return a json that contains a date string,
but calcite returns its internal representation of date values (number of days
as int)
{code}
SELECT JSON_OBJECT('a': CAST('2010-01-01' AS DATE)) as c1
{"a":14610}
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22031) .NET: Thin 3.0: Remove DataStreamer.PartitionAssignmentUpdateFrequency
Pavel Tupitsyn created IGNITE-22031: --- Summary: .NET: Thin 3.0: Remove DataStreamer.PartitionAssignmentUpdateFrequency Key: IGNITE-22031 URL: https://issues.apache.org/jira/browse/IGNITE-22031 Project: Ignite Issue Type: Improvement Components: platforms, thin client Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22027) ItPrimaryReplicaChoiceTest#testPrimaryChangeLongHandling is flaky
[
https://issues.apache.org/jira/browse/IGNITE-22027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin reassigned IGNITE-22027:
Assignee: Alexander Lapin
> ItPrimaryReplicaChoiceTest#testPrimaryChangeLongHandling is flaky
> -
>
> Key: IGNITE-22027
> URL: https://issues.apache.org/jira/browse/IGNITE-22027
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
>
> {code:java}
> org.opentest4j.AssertionFailedError: expected: but was: at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at app//org.junit.jupiter.api.AssertFalse.failNotFalse(AssertFalse.java:63)
> at app//org.junit.jupiter.api.AssertFalse.assertFalse(AssertFalse.java:36)
> at app//org.junit.jupiter.api.AssertFalse.assertFalse(AssertFalse.java:31)
> at app//org.junit.jupiter.api.Assertions.assertFalse(Assertions.java:231) at
> app//org.apache.ignite.internal.placementdriver.ItPrimaryReplicaChoiceTest.testPrimaryChangeLongHandling(ItPrimaryReplicaChoiceTest.java:189)
> {code}
> Long story short, it's because of minor bug in NodeUtils#transferPrimary.
> While choosing new primary in case of null preferablePrimary following logic
> was used
> {code:java}
> if (preferablePrimary == null) {
> preferablePrimary = nodes.stream()
> .map(IgniteImpl::name)
> .filter(n -> n.equals(currentLeaseholder.getLeaseholder()))
> .findFirst()
> .orElseThrow();
> } {code}
> that always selects current primary as new one. Apparently "!" was missing in
> {code:java}
> .filter(n -> n.equals(currentLeaseholder.getLeaseholder())){code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-22030) Thin 3.0: Remove jackson-dataformat-msgpack dependency
Pavel Tupitsyn created IGNITE-22030: --- Summary: Thin 3.0: Remove jackson-dataformat-msgpack dependency Key: IGNITE-22030 URL: https://issues.apache.org/jira/browse/IGNITE-22030 Project: Ignite Issue Type: Improvement Components: thin client Affects Versions: 3.0.0-beta1 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-beta2 jackson-dataformat-msgpack dependency is not used, remove it. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22029) Change default configuration according to default RAFT option
Vladislav Pyatkov created IGNITE-22029: -- Summary: Change default configuration according to default RAFT option Key: IGNITE-22029 URL: https://issues.apache.org/jira/browse/IGNITE-22029 Project: Ignite Issue Type: Bug Reporter: Vladislav Pyatkov h3. Motivation The stripes default abount is changed in IGNITE-21907, but it did not modified in RaftConfigurationSchema. h3. Defenition of done Need change the default in RAFT configuration as it is done in RAFT option. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22028) Thin client: Implement invoke/invokeAll operations
Aleksey Plekhanov created IGNITE-22028: -- Summary: Thin client: Implement invoke/invokeAll operations Key: IGNITE-22028 URL: https://issues.apache.org/jira/browse/IGNITE-22028 Project: Ignite Issue Type: New Feature Reporter: Aleksey Plekhanov Assignee: Aleksey Plekhanov We must implement invoke/invokeAll methods for thin client. Dev. list thread and IEP should be started to discuss protocol and implementation details. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21830) Add logging of connection check for each address
[ https://issues.apache.org/jira/browse/IGNITE-21830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Davydov reassigned IGNITE-21830: --- Assignee: Maksim Davydov (was: Luchnikov Alexander) > Add logging of connection check for each address > > > Key: IGNITE-21830 > URL: https://issues.apache.org/jira/browse/IGNITE-21830 > Project: Ignite > Issue Type: Improvement >Reporter: Ilya Shishkov >Assignee: Maksim Davydov >Priority: Trivial > Labels: ise, newbie > > Currently, exception thrown during checking of address is ignored [1]. It > would be useful to print message with connection check summary including each > address checking state and error message (if any). > # > https://github.com/apache/ignite/blob/7cd0c7a7d1150bbf6be6aae5efe80627a73757c0/modules/core/src/main/java/org/apache/ignite/spi/discovery/tcp/ServerImpl.java#L7293 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20163) Sql. Investigate how to JSON functions in BinaryTuple-based execution.
[ https://issues.apache.org/jira/browse/IGNITE-20163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-20163: - Assignee: (was: Maksim Zhuravkov) > Sql. Investigate how to JSON functions in BinaryTuple-based execution. > -- > > Key: IGNITE-20163 > URL: https://issues.apache.org/jira/browse/IGNITE-20163 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > > After migration to BinaryTuple-backed it is not possible to store arbitrary > data in row fields because every field is typed, hence it is not possible to > support JSON functions (functions that return type ANY). Investigate how to > support such case from BinaryTuple-backed rows. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21999) Merge partition free-lists into one
[ https://issues.apache.org/jira/browse/IGNITE-21999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov reassigned IGNITE-21999: -- Assignee: Philipp Shergalis (was: Ivan Bessonov) > Merge partition free-lists into one > --- > > Key: IGNITE-21999 > URL: https://issues.apache.org/jira/browse/IGNITE-21999 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Philipp Shergalis >Priority: Major > Labels: ignite-3 > > Current implementation has 2 free-lists: > * version chains > * index tuples > These lists have separate buckets for different types of data pages. There's > an issue with this approach: > * overhead on pages - we have to allocate more pages to store buckets > * overhead on checkpoints - we have to save twice as many free-lists on > every checkpoint > The reason, to my understanding, is the fact that FreeList class is > parameterized with the specific type of data that it stores. It makes no > sense to me, to be completely honest, because the algorithm is always the > same, and we always use the code from abstract free-list implementation. > What I propose: > * get rid of abstract implementation and only have the concrete > implementation of free lists > * same for data pages > * serialization code will be fully moved to implementations of Storeable > We're losing some guarantees if we do this change - we can no longer check > that type of the page is correct. My response to this issue is that every > Storeable could add a 1-byte header to the data, in order to validate it when > being read, that should be enough. If we could find a way to store less than > 1 byte then that's nice, I didn't look too much into the question. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21999) Merge partition free-lists into one
[ https://issues.apache.org/jira/browse/IGNITE-21999?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov reassigned IGNITE-21999: -- Assignee: Ivan Bessonov > Merge partition free-lists into one > --- > > Key: IGNITE-21999 > URL: https://issues.apache.org/jira/browse/IGNITE-21999 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > > Current implementation has 2 free-lists: > * version chains > * index tuples > These lists have separate buckets for different types of data pages. There's > an issue with this approach: > * overhead on pages - we have to allocate more pages to store buckets > * overhead on checkpoints - we have to save twice as many free-lists on > every checkpoint > The reason, to my understanding, is the fact that FreeList class is > parameterized with the specific type of data that it stores. It makes no > sense to me, to be completely honest, because the algorithm is always the > same, and we always use the code from abstract free-list implementation. > What I propose: > * get rid of abstract implementation and only have the concrete > implementation of free lists > * same for data pages > * serialization code will be fully moved to implementations of Storeable > We're losing some guarantees if we do this change - we can no longer check > that type of the page is correct. My response to this issue is that every > Storeable could add a 1-byte header to the data, in order to validate it when > being read, that should be enough. If we could find a way to store less than > 1 byte then that's nice, I didn't look too much into the question. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21538) Rework component lifecycle mode to asynchronous
[
https://issues.apache.org/jira/browse/IGNITE-21538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836096#comment-17836096
]
Kirill Sizov edited comment on IGNITE-21538 at 4/11/24 10:53 AM:
--
The suggested design includes:
1. Add a counter to track all running async requests for each component.
2. Each root async method (that creates a new future) of a component will
increment the counter. Once the future completes, the counter decrements.
3. When beforeShutdown() is called, it waits for the counter to become 0.
4. No counter increments is expected when a synchronous method is called.
The node design states that all synchronous methods are called from
asynchronous ones and we will anyway wait for this operation to complete on the
upper level.
The calls from the bottom to the top (from leaf components to their containers)
should be safe as we expect that the container components stop only when all
leaf components are stopped.
5. The schedulers and scheduled tasks should be stopped in the components that
started them.
was (Author: JIRAUSER301198):
The suggested design includes:
1. Add a counter to track all running async requests for each component.
2. Each root async method (that creates a new future) of a component will
increment the counter. Once the future completes, the counter decrements.
3. When beforeShutdown() is called, it waits for the counter to become 0.
4. No counter increments is expected when a synchronous method is called.
The node design states that all synchronous methods are called from
asynchronous ones and we will anyway wait for this operation to complete on the
upper level.
The calls from the bottom to the top (from leaf components to their containers)
should be safe as we expect that the container components stop only when all
leaf components are stopped.
> Rework component lifecycle mode to asynchronous
> ---
>
> Key: IGNITE-21538
> URL: https://issues.apache.org/jira/browse/IGNITE-21538
> Project: Ignite
> Issue Type: Task
>Affects Versions: 3.0.0-beta2
>Reporter: Alexey Scherbakov
>Assignee: Kirill Sizov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0
>
>
> Current design for comp lifecycle has issues:
> 1. It was designed for synchronous components, but almost all components are
> asynchronous.
> This causes to appear ugly things like _inBusyLockAsync_ and inefficient code
> like
> _public @Nullable TxStateMeta stateMeta(UUID txId) \{ return
> inBusyLock(busyLock, () -> txStateVolatileStorage.state(txId)); }_
> 2. Currently it's not possible to do truly graceful node shutdown, because IO
> layer is disabled out-of-order, causing operation failures without a chance
> to finish.
> I suggest reworking comp lifecycle to async model:
> 1. Each component tracks it's inflight async ops (as list of async chains)
> 2. On start components are initialized using _CompletableFuture
> startAsync()_ method from root to leafs of dependency tree
> 3. On shutdown
> 3.1 _CompletableFuturebeforeShutdown_ is called on comp from leafs to
> root direction in dependency tree. This step waits for all active futures to
> complete. Any new operation return a future completed with
> _NodeStoppingException_
> 3.2 stop is called on comp from leafs to root direction in dependency tree.
> This step destroys component resources, like pools, etc.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20163) Sql. Investigate how to JSON functions in BinaryTuple-based execution.
[ https://issues.apache.org/jira/browse/IGNITE-20163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-20163: - Assignee: Maksim Zhuravkov > Sql. Investigate how to JSON functions in BinaryTuple-based execution. > -- > > Key: IGNITE-20163 > URL: https://issues.apache.org/jira/browse/IGNITE-20163 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > > After migration to BinaryTuple-backed it is not possible to store arbitrary > data in row fields because every field is typed, hence it is not possible to > support JSON functions (functions that return type ANY). Investigate how to > support such case from BinaryTuple-backed rows. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21859) Causality token stays 0 for default zone
[
https://issues.apache.org/jira/browse/IGNITE-21859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836098#comment-17836098
]
Konstantin Orlov commented on IGNITE-21859:
---
This won't be changed. We need to deal with it in
{{org.apache.ignite.internal.distributionzones.causalitydatanodes.CausalityDataNodesEngine#dataNodes}}.
> Causality token stays 0 for default zone
>
>
> Key: IGNITE-21859
> URL: https://issues.apache.org/jira/browse/IGNITE-21859
> Project: Ignite
> Issue Type: Task
>Affects Versions: 3.0.0-beta1
>Reporter: Ivan Zlenko
>Priority: Major
> Labels: ignite-3
>
> We have a problem where if no alter or other action was performed on default
> zone causality token in CatalogZoneDescriptor will remain 0.
> It will cause an error on any attempt of rebalacing any tables in that zone:
> {code}
> [2024-03-27T14:27:22,231][ERROR][%icbt_tacwdws_0%rebalance-scheduler-18][DistributionZoneRebalanceEngine]
> Failed to update stable keys for tables [[TESTTABLE]]
> {code}
> If we will add stacktrace to output we will get following:
> {code}
> [2024-03-27T14:27:22,231][ERROR][%icbt_tacwdws_0%rebalance-scheduler-13][DistributionZoneRebalanceEngine]
> CATCH,
> java.lang.IllegalArgumentException: causalityToken must be greater then zero
> [causalityToken=0"
> at
> org.apache.ignite.internal.distributionzones.causalitydatanodes.CausalityDataNodesEngine.dataNodes(CausalityDataNodesEngine.java:139)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.DistributionZoneManager.dataNodes(DistributionZoneManager.java:324)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine.calculateAssignments(DistributionZoneRebalanceEngine.java:346)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.RebalanceRaftGroupEventsListener.doStableKeySwitch(RebalanceRaftGroupEventsListener.java:408)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine$3.lambda$onUpdate$0(DistributionZoneRebalanceEngine.java:294)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at java.base/java.util.HashMap.forEach(HashMap.java:1337) ~[?:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine$3.lambda$onUpdate$1(DistributionZoneRebalanceEngine.java:293)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> [?:?]
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> [?:?]
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> [?:?]
> 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:829) [?:?]
> {code}
> The workaround is creating a zone and specifying this zone to table.
> Also wouldn't be a bad idea to print stacktrace for "Failed to update stable
> keys for tables" at least on DEBUG log level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21859) Causality token stays 0 for default zone
[
https://issues.apache.org/jira/browse/IGNITE-21859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-21859:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Causality token stays 0 for default zone
>
>
> Key: IGNITE-21859
> URL: https://issues.apache.org/jira/browse/IGNITE-21859
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta1
>Reporter: Ivan Zlenko
>Priority: Major
> Labels: ignite-3
>
> We have a problem where if no alter or other action was performed on default
> zone causality token in CatalogZoneDescriptor will remain 0.
> It will cause an error on any attempt of rebalacing any tables in that zone:
> {code}
> [2024-03-27T14:27:22,231][ERROR][%icbt_tacwdws_0%rebalance-scheduler-18][DistributionZoneRebalanceEngine]
> Failed to update stable keys for tables [[TESTTABLE]]
> {code}
> If we will add stacktrace to output we will get following:
> {code}
> [2024-03-27T14:27:22,231][ERROR][%icbt_tacwdws_0%rebalance-scheduler-13][DistributionZoneRebalanceEngine]
> CATCH,
> java.lang.IllegalArgumentException: causalityToken must be greater then zero
> [causalityToken=0"
> at
> org.apache.ignite.internal.distributionzones.causalitydatanodes.CausalityDataNodesEngine.dataNodes(CausalityDataNodesEngine.java:139)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.DistributionZoneManager.dataNodes(DistributionZoneManager.java:324)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine.calculateAssignments(DistributionZoneRebalanceEngine.java:346)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.RebalanceRaftGroupEventsListener.doStableKeySwitch(RebalanceRaftGroupEventsListener.java:408)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine$3.lambda$onUpdate$0(DistributionZoneRebalanceEngine.java:294)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at java.base/java.util.HashMap.forEach(HashMap.java:1337) ~[?:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine$3.lambda$onUpdate$1(DistributionZoneRebalanceEngine.java:293)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> [?:?]
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> [?:?]
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> [?:?]
> 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:829) [?:?]
> {code}
> The workaround is creating a zone and specifying this zone to table.
> Also wouldn't be a bad idea to print stacktrace for "Failed to update stable
> keys for tables" at least on DEBUG log level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21859) Causality token stays 0 for default zone
[
https://issues.apache.org/jira/browse/IGNITE-21859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-21859:
--
Issue Type: Bug (was: Task)
> Causality token stays 0 for default zone
>
>
> Key: IGNITE-21859
> URL: https://issues.apache.org/jira/browse/IGNITE-21859
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta1
>Reporter: Ivan Zlenko
>Priority: Major
> Labels: ignite-3
>
> We have a problem where if no alter or other action was performed on default
> zone causality token in CatalogZoneDescriptor will remain 0.
> It will cause an error on any attempt of rebalacing any tables in that zone:
> {code}
> [2024-03-27T14:27:22,231][ERROR][%icbt_tacwdws_0%rebalance-scheduler-18][DistributionZoneRebalanceEngine]
> Failed to update stable keys for tables [[TESTTABLE]]
> {code}
> If we will add stacktrace to output we will get following:
> {code}
> [2024-03-27T14:27:22,231][ERROR][%icbt_tacwdws_0%rebalance-scheduler-13][DistributionZoneRebalanceEngine]
> CATCH,
> java.lang.IllegalArgumentException: causalityToken must be greater then zero
> [causalityToken=0"
> at
> org.apache.ignite.internal.distributionzones.causalitydatanodes.CausalityDataNodesEngine.dataNodes(CausalityDataNodesEngine.java:139)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.DistributionZoneManager.dataNodes(DistributionZoneManager.java:324)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine.calculateAssignments(DistributionZoneRebalanceEngine.java:346)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.RebalanceRaftGroupEventsListener.doStableKeySwitch(RebalanceRaftGroupEventsListener.java:408)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine$3.lambda$onUpdate$0(DistributionZoneRebalanceEngine.java:294)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at java.base/java.util.HashMap.forEach(HashMap.java:1337) ~[?:?]
> at
> org.apache.ignite.internal.distributionzones.rebalance.DistributionZoneRebalanceEngine$3.lambda$onUpdate$1(DistributionZoneRebalanceEngine.java:293)
> ~[ignite-distribution-zones-9.0.127-SNAPSHOT.jar:?]
> at
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
> [?:?]
> at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
> [?:?]
> at
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
> [?:?]
> 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:829) [?:?]
> {code}
> The workaround is creating a zone and specifying this zone to table.
> Also wouldn't be a bad idea to print stacktrace for "Failed to update stable
> keys for tables" at least on DEBUG log level.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21538) Rework component lifecycle mode to asynchronous
[
https://issues.apache.org/jira/browse/IGNITE-21538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836096#comment-17836096
]
Kirill Sizov edited comment on IGNITE-21538 at 4/11/24 10:16 AM:
--
The suggested design includes:
1. Add a counter to track all running async requests for each component.
2. Each root async method (that creates a new future) of a component will
increment the counter. Once the future completes, the counter decrements.
3. When beforeShutdown() is called, it waits for the counter to become 0.
4. No counter increments is expected when a synchronous method is called.
The node design states that all synchronous methods are called from
asynchronous ones and we will anyway wait for this operation to complete on the
upper level.
The calls from the bottom to the top (from leaf components to their containers)
should be safe as we expect that the container components stop only when all
leaf components are stopped.
was (Author: JIRAUSER301198):
The suggested design includes:
1. Add a counter to track all running async requests for each component.
2. Each root async method (that creates a new future) of a component will
increment the counter. Once the future completes, the counter decrements.
3. When beforeShutdown() is called, it waits for the counter to become 0.
4. No counter increments is expected when a synchronous method is called.
The node design states that all synchronous methods are called from
asynchronous ones and we will anyway wait for this operation to complete on the
upper level.
The calls from the bottom to the top (from leaf components to their containers)
should be safe as we expect that the container components stop after all leaf
components are stopped.
> Rework component lifecycle mode to asynchronous
> ---
>
> Key: IGNITE-21538
> URL: https://issues.apache.org/jira/browse/IGNITE-21538
> Project: Ignite
> Issue Type: Task
>Affects Versions: 3.0.0-beta2
>Reporter: Alexey Scherbakov
>Assignee: Kirill Sizov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0
>
>
> Current design for comp lifecycle has issues:
> 1. It was designed for synchronous components, but almost all components are
> asynchronous.
> This causes to appear ugly things like _inBusyLockAsync_ and inefficient code
> like
> _public @Nullable TxStateMeta stateMeta(UUID txId) \{ return
> inBusyLock(busyLock, () -> txStateVolatileStorage.state(txId)); }_
> 2. Currently it's not possible to do truly graceful node shutdown, because IO
> layer is disabled out-of-order, causing operation failures without a chance
> to finish.
> I suggest reworking comp lifecycle to async model:
> 1. Each component tracks it's inflight async ops (as list of async chains)
> 2. On start components are initialized using _CompletableFuture
> startAsync()_ method from root to leafs of dependency tree
> 3. On shutdown
> 3.1 _CompletableFuturebeforeShutdown_ is called on comp from leafs to
> root direction in dependency tree. This step waits for all active futures to
> complete. Any new operation return a future completed with
> _NodeStoppingException_
> 3.2 stop is called on comp from leafs to root direction in dependency tree.
> This step destroys component resources, like pools, etc.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21538) Rework component lifecycle mode to asynchronous
[
https://issues.apache.org/jira/browse/IGNITE-21538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836096#comment-17836096
]
Kirill Sizov commented on IGNITE-21538:
The suggested design includes:
1. Add a counter to track all running async requests for each component.
2. Each root async method (that creates a new future) of a component will
increment the counter. Once the future completes, the counter decrements.
3. When beforeShutdown() is called, it waits for the counter to become 0.
4. No counter increments is expected when a synchronous method is called.
The node design states that all synchronous methods are called from
asynchronous ones and we will anyway wait for this operation to complete on the
upper level.
The calls from the bottom to the top (from leaf components to their containers)
should be safe as we expect that the container components stop after all leaf
components are stopped.
> Rework component lifecycle mode to asynchronous
> ---
>
> Key: IGNITE-21538
> URL: https://issues.apache.org/jira/browse/IGNITE-21538
> Project: Ignite
> Issue Type: Task
>Affects Versions: 3.0.0-beta2
>Reporter: Alexey Scherbakov
>Assignee: Kirill Sizov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0
>
>
> Current design for comp lifecycle has issues:
> 1. It was designed for synchronous components, but almost all components are
> asynchronous.
> This causes to appear ugly things like _inBusyLockAsync_ and inefficient code
> like
> _public @Nullable TxStateMeta stateMeta(UUID txId) \{ return
> inBusyLock(busyLock, () -> txStateVolatileStorage.state(txId)); }_
> 2. Currently it's not possible to do truly graceful node shutdown, because IO
> layer is disabled out-of-order, causing operation failures without a chance
> to finish.
> I suggest reworking comp lifecycle to async model:
> 1. Each component tracks it's inflight async ops (as list of async chains)
> 2. On start components are initialized using _CompletableFuture
> startAsync()_ method from root to leafs of dependency tree
> 3. On shutdown
> 3.1 _CompletableFuturebeforeShutdown_ is called on comp from leafs to
> root direction in dependency tree. This step waits for all active futures to
> complete. Any new operation return a future completed with
> _NodeStoppingException_
> 3.2 stop is called on comp from leafs to root direction in dependency tree.
> This step destroys component resources, like pools, etc.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-21538) Rework component lifecycle mode to asynchronous
[
https://issues.apache.org/jira/browse/IGNITE-21538?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836096#comment-17836096
]
Kirill Sizov edited comment on IGNITE-21538 at 4/11/24 10:15 AM:
--
The suggested design includes:
1. Add a counter to track all running async requests for each component.
2. Each root async method (that creates a new future) of a component will
increment the counter. Once the future completes, the counter decrements.
3. When beforeShutdown() is called, it waits for the counter to become 0.
4. No counter increments is expected when a synchronous method is called.
The node design states that all synchronous methods are called from
asynchronous ones and we will anyway wait for this operation to complete on the
upper level.
The calls from the bottom to the top (from leaf components to their containers)
should be safe as we expect that the container components stop after all leaf
components are stopped.
was (Author: JIRAUSER301198):
The suggested design includes:
1. Add a counter to track all running async requests for each component.
2. Each root async method (that creates a new future) of a component will
increment the counter. Once the future completes, the counter decrements.
3. When beforeShutdown() is called, it waits for the counter to become 0.
4. No counter increments is expected when a synchronous method is called.
The node design states that all synchronous methods are called from
asynchronous ones and we will anyway wait for this operation to complete on the
upper level.
The calls from the bottom to the top (from leaf components to their containers)
should be safe as we expect that the container components stop after all leaf
components are stopped.
> Rework component lifecycle mode to asynchronous
> ---
>
> Key: IGNITE-21538
> URL: https://issues.apache.org/jira/browse/IGNITE-21538
> Project: Ignite
> Issue Type: Task
>Affects Versions: 3.0.0-beta2
>Reporter: Alexey Scherbakov
>Assignee: Kirill Sizov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0
>
>
> Current design for comp lifecycle has issues:
> 1. It was designed for synchronous components, but almost all components are
> asynchronous.
> This causes to appear ugly things like _inBusyLockAsync_ and inefficient code
> like
> _public @Nullable TxStateMeta stateMeta(UUID txId) \{ return
> inBusyLock(busyLock, () -> txStateVolatileStorage.state(txId)); }_
> 2. Currently it's not possible to do truly graceful node shutdown, because IO
> layer is disabled out-of-order, causing operation failures without a chance
> to finish.
> I suggest reworking comp lifecycle to async model:
> 1. Each component tracks it's inflight async ops (as list of async chains)
> 2. On start components are initialized using _CompletableFuture
> startAsync()_ method from root to leafs of dependency tree
> 3. On shutdown
> 3.1 _CompletableFuturebeforeShutdown_ is called on comp from leafs to
> root direction in dependency tree. This step waits for all active futures to
> complete. Any new operation return a future completed with
> _NodeStoppingException_
> 3.2 stop is called on comp from leafs to root direction in dependency tree.
> This step destroys component resources, like pools, etc.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22027) ItPrimaryReplicaChoiceTest#testPrimaryChangeLongHandling is flaky
[
https://issues.apache.org/jira/browse/IGNITE-22027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-22027:
-
Description:
{code:java}
org.opentest4j.AssertionFailedError: expected: but was: at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertFalse.failNotFalse(AssertFalse.java:63)
at app//org.junit.jupiter.api.AssertFalse.assertFalse(AssertFalse.java:36) at
app//org.junit.jupiter.api.AssertFalse.assertFalse(AssertFalse.java:31) at
app//org.junit.jupiter.api.Assertions.assertFalse(Assertions.java:231) at
app//org.apache.ignite.internal.placementdriver.ItPrimaryReplicaChoiceTest.testPrimaryChangeLongHandling(ItPrimaryReplicaChoiceTest.java:189)
{code}
Long story short, it's because of minor bug in NodeUtils#transferPrimary.
While choosing new primary in case of null preferablePrimary following logic
was used
{code:java}
if (preferablePrimary == null) {
preferablePrimary = nodes.stream()
.map(IgniteImpl::name)
.filter(n -> n.equals(currentLeaseholder.getLeaseholder()))
.findFirst()
.orElseThrow();
} {code}
that always selects current primary as new one. Apparently "!" was missing in
{code:java}
.filter(n -> n.equals(currentLeaseholder.getLeaseholder())){code}
> ItPrimaryReplicaChoiceTest#testPrimaryChangeLongHandling is flaky
> -
>
> Key: IGNITE-22027
> URL: https://issues.apache.org/jira/browse/IGNITE-22027
> Project: Ignite
> Issue Type: Bug
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3
>
>
> {code:java}
> org.opentest4j.AssertionFailedError: expected: but was: at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at app//org.junit.jupiter.api.AssertFalse.failNotFalse(AssertFalse.java:63)
> at app//org.junit.jupiter.api.AssertFalse.assertFalse(AssertFalse.java:36)
> at app//org.junit.jupiter.api.AssertFalse.assertFalse(AssertFalse.java:31)
> at app//org.junit.jupiter.api.Assertions.assertFalse(Assertions.java:231) at
> app//org.apache.ignite.internal.placementdriver.ItPrimaryReplicaChoiceTest.testPrimaryChangeLongHandling(ItPrimaryReplicaChoiceTest.java:189)
> {code}
> Long story short, it's because of minor bug in NodeUtils#transferPrimary.
> While choosing new primary in case of null preferablePrimary following logic
> was used
> {code:java}
> if (preferablePrimary == null) {
> preferablePrimary = nodes.stream()
> .map(IgniteImpl::name)
> .filter(n -> n.equals(currentLeaseholder.getLeaseholder()))
> .findFirst()
> .orElseThrow();
> } {code}
> that always selects current primary as new one. Apparently "!" was missing in
> {code:java}
> .filter(n -> n.equals(currentLeaseholder.getLeaseholder())){code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-20632) Fix tests in Apache Ignite 3 after init script with default zone will be introduced
[ https://issues.apache.org/jira/browse/IGNITE-20632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov resolved IGNITE-20632. --- Resolution: Won't Fix See explanation in IGNITE-20631. > Fix tests in Apache Ignite 3 after init script with default zone will be > introduced > > > Key: IGNITE-20632 > URL: https://issues.apache.org/jira/browse/IGNITE-20632 > Project: Ignite > Issue Type: Improvement >Reporter: Mirza Aliev >Priority: Major > Labels: ignite-3 > > h3. *Motivation* > After https://issues.apache.org/jira/browse/IGNITE-20631 will be implemented, > and after we remove creation of default zone on a Catalog manager start in > this ticket, tests that use default zone will start to fail, and we need to > provide a way to use init script with default zone setting in those tests -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-20631) Provide init script for creating default zone
[ https://issues.apache.org/jira/browse/IGNITE-20631?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov resolved IGNITE-20631. --- Resolution: Won't Fix At the moment, we don't have init script, and introducing one brings number of questions that have to be answered first. Besides, default zone will still remain in place. It come in handy for new users of Ignite who not familiar with Distribution Zone concept yet, but want play with Ignite cluster. In other words, this ticket is out of scope of the Epic it attached to, so I just closed it. > Provide init script for creating default zone > -- > > Key: IGNITE-20631 > URL: https://issues.apache.org/jira/browse/IGNITE-20631 > Project: Ignite > Issue Type: Improvement >Reporter: Mirza Aliev >Priority: Major > Labels: ignite-3 > > h3. *Motivation* > In https://issues.apache.org/jira/browse/IGNITE-20613 we provide a new way to > work with default zone. There won't be any predefined default zone, it will > be possible to set already created zone as a default one. In this task we > need to provide a way to have initial script for cluster, which will be taken > on the init phase of a cluster and will set default zone. > h3. *Implementation notes* > We need to check the packaging, seems like we already have something similar -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22027) ItPrimaryReplicaChoiceTest#testPrimaryChangeLongHandling is flaky
[ https://issues.apache.org/jira/browse/IGNITE-22027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-22027: - Labels: ignite-3 (was: ) > ItPrimaryReplicaChoiceTest#testPrimaryChangeLongHandling is flaky > - > > Key: IGNITE-22027 > URL: https://issues.apache.org/jira/browse/IGNITE-22027 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22027) ItPrimaryReplicaChoiceTest#testPrimaryChangeLongHandling is flaky
Alexander Lapin created IGNITE-22027: Summary: ItPrimaryReplicaChoiceTest#testPrimaryChangeLongHandling is flaky Key: IGNITE-22027 URL: https://issues.apache.org/jira/browse/IGNITE-22027 Project: Ignite Issue Type: Bug Reporter: Alexander Lapin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22027) ItPrimaryReplicaChoiceTest#testPrimaryChangeLongHandling is flaky
[ https://issues.apache.org/jira/browse/IGNITE-22027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-22027: - Ignite Flags: (was: Docs Required,Release Notes Required) > ItPrimaryReplicaChoiceTest#testPrimaryChangeLongHandling is flaky > - > > Key: IGNITE-22027 > URL: https://issues.apache.org/jira/browse/IGNITE-22027 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22027) ItPrimaryReplicaChoiceTest#testPrimaryChangeLongHandling is flaky
[ https://issues.apache.org/jira/browse/IGNITE-22027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-22027: - Epic Link: IGNITE-21389 > ItPrimaryReplicaChoiceTest#testPrimaryChangeLongHandling is flaky > - > > Key: IGNITE-22027 > URL: https://issues.apache.org/jira/browse/IGNITE-22027 > Project: Ignite > Issue Type: Bug >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-22022) Sql. Json object with nested object creation fails
[
https://issues.apache.org/jira/browse/IGNITE-22022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov reassigned IGNITE-22022:
-
Assignee: Maksim Zhuravkov
> Sql. Json object with nested object creation fails
> --
>
> Key: IGNITE-22022
> URL: https://issues.apache.org/jira/browse/IGNITE-22022
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Pavel Pereslegin
>Assignee: Maksim Zhuravkov
>Priority: Major
> Labels: ignite-3
>
> {{json_object}} function fails when trying to create object with nested object
> {code:java}
> assertQuery("select json_object('name': 'Alex', 'address':
> json_object('city': 'City 17', 'street': 'Elm'))")
> .returns("{\"name\":\"Alex\",\"address\":{\"city\":\"City
> 17\",\"street\":\"Elm\"}}")
> .check();
> {code}
> {noformat}
> Caused by: java.lang.reflect.UndeclaredThrowableException
> at com.sun.proxy.$Proxy96.getExpressionList(Unknown Source)
> at org.apache.calcite.rel.core.Project.(Project.java:142)
> at
> org.apache.ignite.internal.sql.engine.rel.IgniteProject.(IgniteProject.java:83)
> at SC.apply(Unknown Source)
> at
> org.apache.ignite.internal.sql.engine.externalize.RelJson$RelFactory.apply(RelJson.java:128)
> at
> org.apache.ignite.internal.sql.engine.externalize.RelJsonReader.readRel(RelJsonReader.java:140)
> at
> org.apache.ignite.internal.sql.engine.externalize.RelJsonReader.readRels(RelJsonReader.java:132)
> at
> org.apache.ignite.internal.sql.engine.externalize.RelJsonReader.read(RelJsonReader.java:123)
> at
> org.apache.ignite.internal.sql.engine.externalize.RelJsonReader.fromJson(RelJsonReader.java:86)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.lambda$relationalTreeFromJsonString$6(ExecutionServiceImpl.java:300)
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.lambda$doComputeIfAbsent$13(BoundedLocalCache.java:2457)
> at
> java.base/java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1908)
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.doComputeIfAbsent(BoundedLocalCache.java:2455)
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.computeIfAbsent(BoundedLocalCache.java:2438)
> at
> com.github.benmanes.caffeine.cache.LocalCache.computeIfAbsent(LocalCache.java:107)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.relationalTreeFromJsonString(ExecutionServiceImpl.java:298)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.submitFragment(ExecutionServiceImpl.java:833)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.submitFragment(ExecutionServiceImpl.java:514)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.onMessage(ExecutionServiceImpl.java:413)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.lambda$start$1(ExecutionServiceImpl.java:262)
> at
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:151)
> at
> org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.lambda$onMessage$0(MessageServiceImpl.java:115)
> ... 4 more
> Caused by: java.lang.reflect.InvocationTargetException
> at java.base/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.apache.ignite.internal.sql.engine.trait.TraitUtils.lambda$changeTraits$0(TraitUtils.java:265)
> ... 26 more
> Caused by: java.lang.NullPointerException: operator
> at java.base/java.util.Objects.requireNonNull(Objects.java:246)
> at org.apache.calcite.rex.RexCall.(RexCall.java:81)
> at org.apache.calcite.rex.RexBuilder.makeCall(RexBuilder.java:258)
> at
> org.apache.ignite.internal.sql.engine.externalize.RelJson.toRex(RelJson.java:828)
> at
> org.apache.ignite.internal.sql.engine.externalize.RelJson.toRexList(RelJson.java:1027)
> at
> org.apache.ignite.internal.sql.engine.externalize.RelJson.toRex(RelJson.java:787)
> at
> org.apache.ignite.internal.sql.engine.externalize.RelJsonReader$RelInputImpl.getExpressionList(RelJsonReader.java:303)
> ... 28 more
> {noformat}
> At first glance, this looks like a bug on the Ignite side.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22026) Fix incorrect retry logic in GridCacheIoManager send method
[
https://issues.apache.org/jira/browse/IGNITE-22026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-22026:
---
Ignite Flags: (was: Docs Required,Release Notes Required)
> Fix incorrect retry logic in GridCacheIoManager send method
> ---
>
> Key: IGNITE-22026
> URL: https://issues.apache.org/jira/browse/IGNITE-22026
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: ise
> Attachments: GridCacheIoManagerRetryTest.patch
>
>
> {{GridCacheIoManager#send}}[1] and
> {{GridCacheIoManager#sendOrderedMessage}}[2] have incorrect {{retryCnt}}
> comparison in catch block and real retries count will be one less, than
> configured.
> Thus, if you set {{IgniteConfiguration#setNetworkSendRetryCount}} to 1 and
> {{IgniteCheckedException}} has been thrown during sending of message because
> of network timeout, error, etc., then no actual retries will happen and
> message will be lost.
> Reproducer: [^GridCacheIoManagerRetryTest.patch]
> Links:
> #
> https://github.com/apache/ignite/blob/6286f67735b2eb7312bc61d5e0549b22f424348f/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheIoManager.java#L1222
> #
> https://github.com/apache/ignite/blob/6286f67735b2eb7312bc61d5e0549b22f424348f/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheIoManager.java#L1289
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-22007) Optimise Read-only index scan for RocksDB
[ https://issues.apache.org/jira/browse/IGNITE-22007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philipp Shergalis resolved IGNITE-22007. Resolution: Duplicate h1. Added in IGNITE-21987 > Optimise Read-only index scan for RocksDB > -- > > Key: IGNITE-22007 > URL: https://issues.apache.org/jira/browse/IGNITE-22007 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Philipp Shergalis >Priority: Major > Labels: ignite-3 > > In IGNITE-21987 we added readOnlyScan method for SortedIndexStorage, but > RocksDB currently RocksDB uses default method, relying on read-write > implementation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Closed] (IGNITE-22007) Optimise Read-only index scan for RocksDB
[ https://issues.apache.org/jira/browse/IGNITE-22007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Philipp Shergalis closed IGNITE-22007. -- > Optimise Read-only index scan for RocksDB > -- > > Key: IGNITE-22007 > URL: https://issues.apache.org/jira/browse/IGNITE-22007 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Philipp Shergalis >Priority: Major > Labels: ignite-3 > > In IGNITE-21987 we added readOnlyScan method for SortedIndexStorage, but > RocksDB currently RocksDB uses default method, relying on read-write > implementation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20416) IncompatibleSchemaException thrown when schema change is compatible
[
https://issues.apache.org/jira/browse/IGNITE-20416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836074#comment-17836074
]
Roman Puchkovskiy commented on IGNITE-20416:
Thanks!
> IncompatibleSchemaException thrown when schema change is compatible
> ---
>
> Key: IGNITE-20416
> URL: https://issues.apache.org/jira/browse/IGNITE-20416
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Roman Puchkovskiy
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> The following code performs compatible schema change (add column with a
> default value), but causes *IncompatibleSchemaException* (add to
> *ItSqlSynchronousApiTest* and run):
> {code:java}
> @Test
> public void schemaMigration() {
> IgniteSql sql = igniteSql();
> Session ses = sql.createSession();
> checkDdl(true, ses, "CREATE TABLE TEST(ID INT PRIMARY KEY, VAL0
> INT)");
> var view = CLUSTER_NODES.get(0).tables().table("TEST").recordView();
> var upsertFut = CompletableFuture.runAsync(() -> {
> for (int i = 0; i < 1000; i++) {
> view.upsert(null, Tuple.create().set("ID", i).set("VAL0", i));
> }
> });
> checkDdl(true, ses, "ALTER TABLE TEST ADD COLUMN VAL1 INT DEFAULT
> -1");
> upsertFut.join();
> }
> {code}
> If we perform schema update before, after, or between upserts, then there is
> no error. Only when thy happen concurrently.
> *Result:*
> {code}
> java.util.concurrent.CompletionException:
> org.apache.ignite.internal.table.distributed.replicator.IncompatibleSchemaException:
> IGN-TX-12 TraceId:52bbae8c-4706-4394-8bd3-30bac5747da5 Table schema was
> updated after the transaction was started [table=1, startSchema=1,
> operationSchema=2]
> at
> java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.uniApplyNow(CompletableFuture.java:683)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.uniApplyStage(CompletableFuture.java:658)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.thenApply(CompletableFuture.java:2094)
> ~[?:?]
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.validateAtTimestampAndBuildUpdateCommand(PartitionReplicaListener.java:2643)
> ~[ignite-table-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.validateAtTimestampAndBuildUpdateCommand(PartitionReplicaListener.java:2586)
> ~[ignite-table-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processSingleEntryAction$109(PartitionReplicaListener.java:2058)
> ~[ignite-table-3.0.0-SNAPSHOT.jar:?]
> at
> java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> ~[?:?]
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processSingleEntryAction$112(PartitionReplicaListener.java:2058)
> ~[ignite-table-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.continueResolvingByPk(PartitionReplicaListener.java:1448)
> ~[ignite-table-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$resolveRowByPk$68(PartitionReplicaListener.java:1428)
> ~[ignite-table-3.0.0-SNAPSHOT.jar:?]
> at
> java.util.concurrent.CompletableFuture.uniComposeStage(CompletableFuture.java:1106)
> ~[?:?]
> at
> java.util.concurrent.CompletableFuture.thenCompose(CompletableFuture.java:2235)
> ~[?:?]
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.resolveRowByPk(PartitionReplicaListener.java:1419)
> ~[ignite-table-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.processSingleEntryAction(PartitionReplicaListener.java:2048)
> ~[ignite-table-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.lambda$processRequest$2(PartitionReplicaListener.java:363)
> ~[ignite-table-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener.appendTxCommand(PartitionReplicaListener.java:1494)
> ~[ignite-table-3.0.0-SNAPSHOT.jar:?]
>
[jira] [Updated] (IGNITE-22026) Fix incorrect retry logic in GridCacheIoManager send method
[
https://issues.apache.org/jira/browse/IGNITE-22026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-22026:
---
Description:
{{GridCacheIoManager#send}}[1] and {{GridCacheIoManager#sendOrderedMessage}}[2]
have incorrect {{retryCnt}} comparison in catch block and real retries count
will be one less, than configured.
Thus, if you set {{IgniteConfiguration#setNetworkSendRetryCount}} to 1 and
{{IgniteCheckedException}} has been thrown during sending of message because of
network timeout, error, etc., then no actual retries will happen and message
will be lost.
Reproducer: [^GridCacheIoManagerRetryTest.patch]
Links:
#
https://github.com/apache/ignite/blob/6286f67735b2eb7312bc61d5e0549b22f424348f/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheIoManager.java#L1222
#
https://github.com/apache/ignite/blob/6286f67735b2eb7312bc61d5e0549b22f424348f/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheIoManager.java#L1289
was:
GridCacheIoManager#send[1] and GridCacheIoManager#sendOrderedMessage[2] have
incorrect retryCnt comparison in catch block and real retries count will be one
less, than configured.
If you set retryCnt to 1 and IgniteCheckedException has been thrown, then no
actual retries will happen.
Reproducer: [^GridCacheIoManagerRetryTest.patch]
Links:
#
https://github.com/apache/ignite/blob/6286f67735b2eb7312bc61d5e0549b22f424348f/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheIoManager.java#L1222
#
https://github.com/apache/ignite/blob/6286f67735b2eb7312bc61d5e0549b22f424348f/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheIoManager.java#L1289
> Fix incorrect retry logic in GridCacheIoManager send method
> ---
>
> Key: IGNITE-22026
> URL: https://issues.apache.org/jira/browse/IGNITE-22026
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: ise
> Attachments: GridCacheIoManagerRetryTest.patch
>
>
> {{GridCacheIoManager#send}}[1] and
> {{GridCacheIoManager#sendOrderedMessage}}[2] have incorrect {{retryCnt}}
> comparison in catch block and real retries count will be one less, than
> configured.
> Thus, if you set {{IgniteConfiguration#setNetworkSendRetryCount}} to 1 and
> {{IgniteCheckedException}} has been thrown during sending of message because
> of network timeout, error, etc., then no actual retries will happen and
> message will be lost.
> Reproducer: [^GridCacheIoManagerRetryTest.patch]
> Links:
> #
> https://github.com/apache/ignite/blob/6286f67735b2eb7312bc61d5e0549b22f424348f/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheIoManager.java#L1222
> #
> https://github.com/apache/ignite/blob/6286f67735b2eb7312bc61d5e0549b22f424348f/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheIoManager.java#L1289
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21835) Cleanup MvccUtils and enum RowData
[ https://issues.apache.org/jira/browse/IGNITE-21835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-21835: Description: To delete unused Mvcc code from enum RowData: * LINK_ONLY * LINK_WITH_HEADER * NO_KEY_WTH_HINTS and cleanup MvccUtils. The remaining MvccUtils.tx(..) methods will be removed in IGNITE-21345 was: To delete unused Mvcc code from enum RowData: * LINK_ONLY * LINK_WITH_HEADER * NO_KEY_WTH_HINTS and cleanup MvccUtils. > Cleanup MvccUtils and enum RowData > --- > > Key: IGNITE-21835 > URL: https://issues.apache.org/jira/browse/IGNITE-21835 > Project: Ignite > Issue Type: Sub-task >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Major > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > > To delete unused Mvcc code from enum RowData: > * LINK_ONLY > * LINK_WITH_HEADER > * NO_KEY_WTH_HINTS > and cleanup MvccUtils. > The remaining MvccUtils.tx(..) methods will be removed in IGNITE-21345 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21835) Cleanup MvccUtils and enum RowData
[ https://issues.apache.org/jira/browse/IGNITE-21835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-21835: Summary: Cleanup MvccUtils and enum RowData (was: Remove MvccUtils and cleanup enum RowData) > Cleanup MvccUtils and enum RowData > --- > > Key: IGNITE-21835 > URL: https://issues.apache.org/jira/browse/IGNITE-21835 > Project: Ignite > Issue Type: Sub-task >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Major > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > > To delete unused Mvcc code from enum RowData: > * LINK_ONLY > * LINK_WITH_HEADER > * NO_KEY_WTH_HINTS > and all MvccUtils classes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21835) Cleanup MvccUtils and enum RowData
[ https://issues.apache.org/jira/browse/IGNITE-21835?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-21835: Description: To delete unused Mvcc code from enum RowData: * LINK_ONLY * LINK_WITH_HEADER * NO_KEY_WTH_HINTS and cleanup MvccUtils. was: To delete unused Mvcc code from enum RowData: * LINK_ONLY * LINK_WITH_HEADER * NO_KEY_WTH_HINTS and all MvccUtils classes. > Cleanup MvccUtils and enum RowData > --- > > Key: IGNITE-21835 > URL: https://issues.apache.org/jira/browse/IGNITE-21835 > Project: Ignite > Issue Type: Sub-task >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Major > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > > To delete unused Mvcc code from enum RowData: > * LINK_ONLY > * LINK_WITH_HEADER > * NO_KEY_WTH_HINTS > and cleanup MvccUtils. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21835) Remove MvccUtils and cleanup enum RowData
[
https://issues.apache.org/jira/browse/IGNITE-21835?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17836025#comment-17836025
]
Ignite TC Bot commented on IGNITE-21835:
{panel:title=Branch: [pull/11308/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11308/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=7820128buildTypeId=IgniteTests24Java8_RunAll]
> Remove MvccUtils and cleanup enum RowData
> -
>
> Key: IGNITE-21835
> URL: https://issues.apache.org/jira/browse/IGNITE-21835
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Julia Bakulina
>Assignee: Julia Bakulina
>Priority: Major
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> To delete unused Mvcc code from enum RowData:
> * LINK_ONLY
> * LINK_WITH_HEADER
> * NO_KEY_WTH_HINTS
> and all MvccUtils classes.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
