[jira] [Commented] (IGNITE-21906) Consider disabling inline in PK index by default
[ https://issues.apache.org/jira/browse/IGNITE-21906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834856#comment-17834856 ] Aleksandr Polovtcev commented on IGNITE-21906: -- I've run the benchmark a couple more times and every time the results were a little bit worse than the baseline. Therefore, we decided to stop further investigation and close this ticket. > Consider disabling inline in PK index by default > > > Key: IGNITE-21906 > URL: https://issues.apache.org/jira/browse/IGNITE-21906 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > In aipersist/aimem we attempt to inline binary tuples into pages for hash > indexes by default. This, in theory, saves us from the necessity of accessing > binary tuples from data pages for comparison, which is slower than comparing > inlined data. > But, assuming the good hash distribution, we would only have to do the real > comparison for the matched tuple. At the same time, inlined data might be > substantially larger than hash+link, meaning that B+Tree with inlined data > has bigger height, which correlates with slower search speed. > So, we have both pros and cons for inlining, and the only real way to > reconcile them is to compare them with some benchmarks. This is exactly what > I propose. > TL;DR: force inline size to be 0 for hash indices and benchmark for put/get > operations, with large enough amount of data. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21906) Consider disabling inline in PK index by default
[ https://issues.apache.org/jira/browse/IGNITE-21906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev resolved IGNITE-21906. -- Resolution: Won't Fix > Consider disabling inline in PK index by default > > > Key: IGNITE-21906 > URL: https://issues.apache.org/jira/browse/IGNITE-21906 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > In aipersist/aimem we attempt to inline binary tuples into pages for hash > indexes by default. This, in theory, saves us from the necessity of accessing > binary tuples from data pages for comparison, which is slower than comparing > inlined data. > But, assuming the good hash distribution, we would only have to do the real > comparison for the matched tuple. At the same time, inlined data might be > substantially larger than hash+link, meaning that B+Tree with inlined data > has bigger height, which correlates with slower search speed. > So, we have both pros and cons for inlining, and the only real way to > reconcile them is to compare them with some benchmarks. This is exactly what > I propose. > TL;DR: force inline size to be 0 for hash indices and benchmark for put/get > operations, with large enough amount of data. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21906) Consider disabling inline in PK index by default
[ https://issues.apache.org/jira/browse/IGNITE-21906?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17834334#comment-17834334 ] Aleksandr Polovtcev commented on IGNITE-21906: -- I've set the inline size to 0 in all HashIndexTrees and got the following results running YCSB KV scenario: Baseline: [OVERALL] RunTime(ms): 40648 Throughput(ops/sec): 6150.364101554812 Operations(payload): 25 Operations(warm-up): 5 [READ] Operations: 25 AverageLatency(us): 152.338772 MinLatency(us): 125 MaxLatency(us): 16355 95thPercentileLatency(us): 179 99thPercentileLatency(us): 232 Return=OK: 25 No inlining [OVERALL] RunTime(ms): 41874 Throughput(ops/sec): 5970.291827864546 Operations(payload): 25 Operations(warm-up): 5 [READ] Operations: 25 AverageLatency(us): 158.05806 MinLatency(us): 126 MaxLatency(us): 23661 95thPercentileLatency(us): 186 99thPercentileLatency(us): 245 Return=OK: 25 Looks like everything got a little bit slower. > Consider disabling inline in PK index by default > > > Key: IGNITE-21906 > URL: https://issues.apache.org/jira/browse/IGNITE-21906 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > In aipersist/aimem we attempt to inline binary tuples into pages for hash > indexes by default. This, in theory, saves us from the necessity of accessing > binary tuples from data pages for comparison, which is slower than comparing > inlined data. > But, assuming the good hash distribution, we would only have to do the real > comparison for the matched tuple. At the same time, inlined data might be > substantially larger than hash+link, meaning that B+Tree with inlined data > has bigger height, which correlates with slower search speed. > So, we have both pros and cons for inlining, and the only real way to > reconcile them is to compare them with some benchmarks. This is exactly what > I propose. > TL;DR: force inline size to be 0 for hash indices and benchmark for put/get > operations, with large enough amount of data. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21906) Consider disabling inline in PK index by default
[ https://issues.apache.org/jira/browse/IGNITE-21906?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev reassigned IGNITE-21906: Assignee: Aleksandr Polovtcev > Consider disabling inline in PK index by default > > > Key: IGNITE-21906 > URL: https://issues.apache.org/jira/browse/IGNITE-21906 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > > In aipersist/aimem we attempt to inline binary tuples into pages for hash > indexes by default. This, in theory, saves us from the necessity of accessing > binary tuples from data pages for comparison, which is slower than comparing > inlined data. > But, assuming the good hash distribution, we would only have to do the real > comparison for the matched tuple. At the same time, inlined data might be > substantially larger than hash+link, meaning that B+Tree with inlined data > has bigger height, which correlates with slower search speed. > So, we have both pros and cons for inlining, and the only real way to > reconcile them is to compare them with some benchmarks. This is exactly what > I propose. > TL;DR: force inline size to be 0 for hash indices and benchmark for put/get > operations, with large enough amount of data. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17591) Refactor toString generation for network messages
[ https://issues.apache.org/jira/browse/IGNITE-17591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-17591: - Fix Version/s: 3.0.0-beta2 > Refactor toString generation for network messages > - > > Key: IGNITE-17591 > URL: https://issues.apache.org/jira/browse/IGNITE-17591 > Project: Ignite > Issue Type: Task > Components: networking >Reporter: Semyon Danilov >Assignee: Philipp Shergalis >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > toString method generation for the network message should be taking into > account several things: > 1) Message may contain large objects (such as byte arrays) > 2) Some data can be sensitive, so it should be possible to ignore or mask a > field in the toString method -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17591) Refactor toString generation for network messages
[ https://issues.apache.org/jira/browse/IGNITE-17591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-17591: - Ignite Flags: (was: Docs Required,Release Notes Required) > Refactor toString generation for network messages > - > > Key: IGNITE-17591 > URL: https://issues.apache.org/jira/browse/IGNITE-17591 > Project: Ignite > Issue Type: Task > Components: networking >Reporter: Semyon Danilov >Assignee: Philipp Shergalis >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > toString method generation for the network message should be taking into > account several things: > 1) Message may contain large objects (such as byte arrays) > 2) Some data can be sensitive, so it should be possible to ignore or mask a > field in the toString method -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21909) RocksDbMvTableStorageTest#testDestroyIndex is flaky
Aleksandr Polovtcev created IGNITE-21909:
Summary: RocksDbMvTableStorageTest#testDestroyIndex is flaky
Key: IGNITE-21909
URL: https://issues.apache.org/jira/browse/IGNITE-21909
Project: Ignite
Issue Type: Bug
Reporter: Aleksandr Polovtcev
Assignee: Aleksandr Polovtcev
There's a race between destroying and getting an index storage in
{{RocksDbMvTableStorage}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21890) AbstractSortedIndexStorageTest#testScan is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21890:
-
Description: Looks like {{BinaryTupleComparator}} handles decimal values
incorrectly, this test fails sometimes if a {{DECIMAL}} column is present in
the index descriptor.
> AbstractSortedIndexStorageTest#testScan is flaky
>
>
> Key: IGNITE-21890
> URL: https://issues.apache.org/jira/browse/IGNITE-21890
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Looks like {{BinaryTupleComparator}} handles decimal values incorrectly, this
> test fails sometimes if a {{DECIMAL}} column is present in the index
> descriptor.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21890) AbstractSortedIndexStorageTest#testScan is flaky
Aleksandr Polovtcev created IGNITE-21890: Summary: AbstractSortedIndexStorageTest#testScan is flaky Key: IGNITE-21890 URL: https://issues.apache.org/jira/browse/IGNITE-21890 Project: Ignite Issue Type: Bug Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21890) AbstractSortedIndexStorageTest#testScan is flaky
[ https://issues.apache.org/jira/browse/IGNITE-21890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21890: - Fix Version/s: 3.0.0-beta2 > AbstractSortedIndexStorageTest#testScan is flaky > > > Key: IGNITE-21890 > URL: https://issues.apache.org/jira/browse/IGNITE-21890 > Project: Ignite > Issue Type: Bug >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21885) AssertionError in RocksDbSortedIndexStorage
[
https://issues.apache.org/jira/browse/IGNITE-21885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21885:
-
Description:
{{RocksDbSortedIndexStorage}} scan is actually broken, the following error is
thrown when trying to call this method:
{noformat}
Caused by: java.lang.AssertionError
at
org.apache.ignite.internal.storage.rocksdb.index.RocksDbSortedIndexStorage.decodeRow(RocksDbSortedIndexStorage.java:207)
~[ignite-storage-rocksdb-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.storage.rocksdb.index.RocksDbSortedIndexStorage$1.map(RocksDbSortedIndexStorage.java:196)
~[ignite-storage-rocksdb-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.storage.rocksdb.index.AbstractRocksDbIndexStorage$UpToDatePeekCursor.lambda$next$0(AbstractRocksDbIndexStorage.java:323)
~[ignite-storage-rocksdb-3.0.0-SNAPSHOT.jar:?]
{noformat}
This happens because there's an assertion check that uses an incorrect
partition ID offset inside of the index row. Existing tests are working only
because we always use partition ID equal to 0.
> AssertionError in RocksDbSortedIndexStorage
> ---
>
> Key: IGNITE-21885
> URL: https://issues.apache.org/jira/browse/IGNITE-21885
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> {{RocksDbSortedIndexStorage}} scan is actually broken, the following error is
> thrown when trying to call this method:
> {noformat}
> Caused by: java.lang.AssertionError
> at
> org.apache.ignite.internal.storage.rocksdb.index.RocksDbSortedIndexStorage.decodeRow(RocksDbSortedIndexStorage.java:207)
> ~[ignite-storage-rocksdb-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.storage.rocksdb.index.RocksDbSortedIndexStorage$1.map(RocksDbSortedIndexStorage.java:196)
> ~[ignite-storage-rocksdb-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.storage.rocksdb.index.AbstractRocksDbIndexStorage$UpToDatePeekCursor.lambda$next$0(AbstractRocksDbIndexStorage.java:323)
> ~[ignite-storage-rocksdb-3.0.0-SNAPSHOT.jar:?]
> {noformat}
> This happens because there's an assertion check that uses an incorrect
> partition ID offset inside of the index row. Existing tests are working only
> because we always use partition ID equal to 0.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21885) AssertionError in RocksDbSortedIndexStorage
[ https://issues.apache.org/jira/browse/IGNITE-21885?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21885: - Fix Version/s: 3.0.0-beta2 > AssertionError in RocksDbSortedIndexStorage > --- > > Key: IGNITE-21885 > URL: https://issues.apache.org/jira/browse/IGNITE-21885 > Project: Ignite > Issue Type: Bug >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Blocker > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21885) AssertionError in RocksDbSortedIndexStorage
Aleksandr Polovtcev created IGNITE-21885: Summary: AssertionError in RocksDbSortedIndexStorage Key: IGNITE-21885 URL: https://issues.apache.org/jira/browse/IGNITE-21885 Project: Ignite Issue Type: Bug Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21862) Rename table catalog command must also rename the PK index
[
https://issues.apache.org/jira/browse/IGNITE-21862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21862:
-
Fix Version/s: 3.0.0-beta2
> Rename table catalog command must also rename the PK index
> --
>
> Key: IGNITE-21862
> URL: https://issues.apache.org/jira/browse/IGNITE-21862
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {{RenameTableCommand}} is used to rename a table. However, it does not rename
> its primary key, which is tied to the table's name. This leads to a bug, for
> example, when you rename a table and create a new table with the old name an
> exception is thrown indicating that an index with this name already exists.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21870) SharedRocksDbInstance#sortedIndexes method is not thread-safe
[
https://issues.apache.org/jira/browse/IGNITE-21870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21870:
-
Fix Version/s: 3.0.0-beta2
> SharedRocksDbInstance#sortedIndexes method is not thread-safe
> -
>
> Key: IGNITE-21870
> URL: https://issues.apache.org/jira/browse/IGNITE-21870
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> It is possible to obtain a {{ConcurrentModificationException}} when calling
> {{SharedRocksDbInstance#sortedIndexes}}, because it performs a scan over a
> non-concurrent map that can actually be concurrently modified.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21870) SharedRocksDbInstance#sortedIndexes method is not thread-safe
[
https://issues.apache.org/jira/browse/IGNITE-21870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21870:
-
Labels: ignite-3 (was: )
> SharedRocksDbInstance#sortedIndexes method is not thread-safe
> -
>
> Key: IGNITE-21870
> URL: https://issues.apache.org/jira/browse/IGNITE-21870
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
> Labels: ignite-3
>
> It is possible to obtain a {{ConcurrentModificationException}} when calling
> {{SharedRocksDbInstance#sortedIndexes}}, because it performs a scan over a
> non-concurrent map that can actually be concurrently modified.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21870) SharedRocksDbInstance#sortedIndexes method is not thread-safe
[
https://issues.apache.org/jira/browse/IGNITE-21870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21870:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> SharedRocksDbInstance#sortedIndexes method is not thread-safe
> -
>
> Key: IGNITE-21870
> URL: https://issues.apache.org/jira/browse/IGNITE-21870
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
>
> It is possible to obtain a {{ConcurrentModificationException}} when calling
> {{SharedRocksDbInstance#sortedIndexes}}, because it performs a scan over a
> non-concurrent map that can actually be concurrently modified.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21871) SharedRocksDbInstance#sortedIndexes method is not thread-safe
Aleksandr Polovtcev created IGNITE-21871:
Summary: SharedRocksDbInstance#sortedIndexes method is not
thread-safe
Key: IGNITE-21871
URL: https://issues.apache.org/jira/browse/IGNITE-21871
Project: Ignite
Issue Type: Bug
Reporter: Aleksandr Polovtcev
Assignee: Aleksandr Polovtcev
It is possible to obtain a {{ConcurrentModificationException}} when calling
{{SharedRocksDbInstance#sortedIndexes}}, because it performs a scan over a
non-concurrent map that can actually be concurrently modified.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21870) SharedRocksDbInstance#sortedIndexes method is not thread-safe
Aleksandr Polovtcev created IGNITE-21870:
Summary: SharedRocksDbInstance#sortedIndexes method is not
thread-safe
Key: IGNITE-21870
URL: https://issues.apache.org/jira/browse/IGNITE-21870
Project: Ignite
Issue Type: Bug
Reporter: Aleksandr Polovtcev
Assignee: Aleksandr Polovtcev
It is possible to obtain a {{ConcurrentModificationException}} when calling
{{SharedRocksDbInstance#sortedIndexes}}, because it performs a scan over a
non-concurrent map that can actually be concurrently modified.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21862) Rename table catalog command must also rename the PK index
[
https://issues.apache.org/jira/browse/IGNITE-21862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21862:
-
Description: {{RenameTableCommand}} is used to rename a table. However, it
does not rename its primary key, which is tied to the table's name. This leads
to a bug, for example, when you rename a table and create a new table with the
old name an exception is thrown indicating that an index with this name already
exists.
> Rename table catalog command must also rename the PK index
> --
>
> Key: IGNITE-21862
> URL: https://issues.apache.org/jira/browse/IGNITE-21862
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> {{RenameTableCommand}} is used to rename a table. However, it does not rename
> its primary key, which is tied to the table's name. This leads to a bug, for
> example, when you rename a table and create a new table with the old name an
> exception is thrown indicating that an index with this name already exists.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21862) Rename table catalog command must also rename the PK index
Aleksandr Polovtcev created IGNITE-21862: Summary: Rename table catalog command must also rename the PK index Key: IGNITE-21862 URL: https://issues.apache.org/jira/browse/IGNITE-21862 Project: Ignite Issue Type: Bug Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21851) Remove RocksDB cache type support
[
https://issues.apache.org/jira/browse/IGNITE-21851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21851:
-
Description: {{RocksDbDataRegionConfigurationSchema}} allows to choose
between two RocksDB cache types: {{LRU}} and {{Clock}}. However, {{Clock}}
cache implementation has actually been removed from RocksDB and the new
implementation, called {{HyperClock}} is still experimental. I suggest to
remove the cache type feature for now, it serves no purpose and complicates the
code. (was: {{RocksDbDataRegionConfigurationSchema}} allows to choose between
two RocksDB cache types: LRU and Clock. However, Clock cache implementation has
actually been removed from RocksDB and the new implementation, called
{{HyperClock}} is still experimental. I suggest to remove the cache type
feature for now, it serves no purpose and complicates the code.)
> Remove RocksDB cache type support
> -
>
> Key: IGNITE-21851
> URL: https://issues.apache.org/jira/browse/IGNITE-21851
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> {{RocksDbDataRegionConfigurationSchema}} allows to choose between two RocksDB
> cache types: {{LRU}} and {{Clock}}. However, {{Clock}} cache implementation
> has actually been removed from RocksDB and the new implementation, called
> {{HyperClock}} is still experimental. I suggest to remove the cache type
> feature for now, it serves no purpose and complicates the code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21851) Remove RocksDB cache type support
[
https://issues.apache.org/jira/browse/IGNITE-21851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21851:
-
Description: {{RocksDbDataRegionConfigurationSchema}} allows to choose
between two RocksDB cache types: LRU and Clock. However, Clock cache
implementation has actually been removed from RocksDB and the new
implementation, called {{HyperClock}} is still experimental. I suggest to
remove the cache type feature for now, it serves no purpose and complicates the
code.
> Remove RocksDB cache type support
> -
>
> Key: IGNITE-21851
> URL: https://issues.apache.org/jira/browse/IGNITE-21851
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> {{RocksDbDataRegionConfigurationSchema}} allows to choose between two RocksDB
> cache types: LRU and Clock. However, Clock cache implementation has actually
> been removed from RocksDB and the new implementation, called {{HyperClock}}
> is still experimental. I suggest to remove the cache type feature for now, it
> serves no purpose and complicates the code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21851) Remove RocksDB cache type support
[ https://issues.apache.org/jira/browse/IGNITE-21851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21851: - Fix Version/s: 3.0.0-beta2 > Remove RocksDB cache type support > - > > Key: IGNITE-21851 > URL: https://issues.apache.org/jira/browse/IGNITE-21851 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21851) Remove RocksDB cache type support
Aleksandr Polovtcev created IGNITE-21851: Summary: Remove RocksDB cache type support Key: IGNITE-21851 URL: https://issues.apache.org/jira/browse/IGNITE-21851 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21848) Move thread hijack protection to wrappers
[ https://issues.apache.org/jira/browse/IGNITE-21848?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21848: - Reviewer: Aleksandr Polovtcev (was: Aleksandr Polovtsev) > Move thread hijack protection to wrappers > - > > Key: IGNITE-21848 > URL: https://issues.apache.org/jira/browse/IGNITE-21848 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Public APIs that return CompletableFuture instances need protection that > would not allow users to execute their code in Ignite internal threads (in > which the futures get completed). This is done by switching to an 'async > continuation executor' upon completion of such futures (by default the common > FJP is used as such an executor). > But when we use the same public APIs internally, we don't need this > protection (Thin client handler is an example). So we need a separate 'entry' > to use the same APIs without this protection. > This can be achieved easily by moving the anti-hijack logic to wrappers (aka > decorators) that are only applied when going through the public APIs. The > internal components can use under-the-hood implementations directly, thus > bypassing the wrappers. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21760) Remove destroyed tables on recovery - RocksDB
[ https://issues.apache.org/jira/browse/IGNITE-21760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21760: - Reviewer: Kirill Tkalenko > Remove destroyed tables on recovery - RocksDB > - > > Key: IGNITE-21760 > URL: https://issues.apache.org/jira/browse/IGNITE-21760 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Pligin >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > We need to destroy tables on node recovery that fall under the low watermark > for the rocks db storage engine. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21760) Remove destroyed tables on recovery - RocksDB
[ https://issues.apache.org/jira/browse/IGNITE-21760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21760: - Fix Version/s: 3.0.0-beta2 > Remove destroyed tables on recovery - RocksDB > - > > Key: IGNITE-21760 > URL: https://issues.apache.org/jira/browse/IGNITE-21760 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Pligin >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > We need to destroy tables on node recovery that fall under the low watermark > for the rocks db storage engine. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21831) RocksDb indexes are not table aware
[ https://issues.apache.org/jira/browse/IGNITE-21831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21831: - Fix Version/s: 3.0.0-beta2 > RocksDb indexes are not table aware > --- > > Key: IGNITE-21831 > URL: https://issues.apache.org/jira/browse/IGNITE-21831 > Project: Ignite > Issue Type: Bug >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 50m > Remaining Estimate: 0h > > When implementing indexes restoration in IGNITE-21680 I messed up and didn't > notice, that all indexes are stored in the RocksDB instance without any > connection to their table IDs. Therefore, every table, started in the same > data region, got the same (full) set of indexes recovered. > Another problem is that right now it is impossible to drop a table only using > its ID, needed for IGNITE-21760, because we need to know, which indexes it > has. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21831) RocksDb indexes are not table aware
[ https://issues.apache.org/jira/browse/IGNITE-21831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21831: - Description: When implementing indexes restoration in IGNITE-21680 I messed up and didn't notice, that all indexes are stored in the RocksDB instance without any connection to their table IDs. Therefore, every table, started in the same data region, got the same (full) set of indexes recovered. Another problem is that right now it is impossible to drop a table only using its ID, needed for IGNITE-21760, because we need to know, which indexes it has. > RocksDb indexes are not table aware > --- > > Key: IGNITE-21831 > URL: https://issues.apache.org/jira/browse/IGNITE-21831 > Project: Ignite > Issue Type: Bug >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > When implementing indexes restoration in IGNITE-21680 I messed up and didn't > notice, that all indexes are stored in the RocksDB instance without any > connection to their table IDs. Therefore, every table, started in the same > data region, got the same (full) set of indexes recovered. > Another problem is that right now it is impossible to drop a table only using > its ID, needed for IGNITE-21760, because we need to know, which indexes it > has. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21831) RocksDb indexes are not table aware
Aleksandr Polovtcev created IGNITE-21831: Summary: RocksDb indexes are not table aware Key: IGNITE-21831 URL: https://issues.apache.org/jira/browse/IGNITE-21831 Project: Ignite Issue Type: Bug Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21760) Remove destroyed tables on recovery - RocksDB
[ https://issues.apache.org/jira/browse/IGNITE-21760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21760: - Ignite Flags: (was: Docs Required,Release Notes Required) > Remove destroyed tables on recovery - RocksDB > - > > Key: IGNITE-21760 > URL: https://issues.apache.org/jira/browse/IGNITE-21760 > Project: Ignite > Issue Type: Improvement >Reporter: Vladimir Pligin >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > > We need to destroy tables on node recovery that fall under the low watermark > for the rocks db storage engine. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-18159) Implement splitting of an Ignite node hosting a learner and a follower from the same Raft group
[
https://issues.apache.org/jira/browse/IGNITE-18159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev resolved IGNITE-18159.
--
Resolution: Won't Fix
> Implement splitting of an Ignite node hosting a learner and a follower from
> the same Raft group
> ---
>
> Key: IGNITE-18159
> URL: https://issues.apache.org/jira/browse/IGNITE-18159
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> As described in IGNITE-18070, we need to implement one of the scenarios that
> will allow us to have a single Ignite node hosting a follower and a learner
> from the same Raft group. This ticket focuses on a case when a node gets
> "split", that is, when after calculating the assignments, a follower (or a
> learner) gets moved to a different Ignite node.
> The algorithm looks like the following: after stable assignments have been
> changes, we simply destroy the follower's (or learner's, whichever gets
> moved) storage data (looks like a good place for that would be inside the
> {{metaStorageMgr.registerWatchByPrefix(ByteArray.fromString(STABLE_ASSIGNMENTS_PREFIX)}}
> listener in the {{TableManager}}) on the node that gets "split" . The other
> node should simply start the corresponding Raft service as usual, its data
> would be transferred by Raft replication.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-21575) Destroy index storages on rebalance
[ https://issues.apache.org/jira/browse/IGNITE-21575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev resolved IGNITE-21575. -- Resolution: Invalid > Destroy index storages on rebalance > --- > > Key: IGNITE-21575 > URL: https://issues.apache.org/jira/browse/IGNITE-21575 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21575) Destroy index storages on rebalance
[ https://issues.apache.org/jira/browse/IGNITE-21575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17829588#comment-17829588 ] Aleksandr Polovtcev commented on IGNITE-21575: -- Originally this ticket was intended to check that index storages are destroyed when a node is no longer present for a partition's assignments. Looks like this has already been implemented in IGNITE-18160. > Destroy index storages on rebalance > --- > > Key: IGNITE-21575 > URL: https://issues.apache.org/jira/browse/IGNITE-21575 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21819) NextRowIdToBuild does not get cleared on rebalance
[
https://issues.apache.org/jira/browse/IGNITE-21819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21819:
-
Fix Version/s: 3.0.0-beta2
> NextRowIdToBuild does not get cleared on rebalance
> --
>
> Key: IGNITE-21819
> URL: https://issues.apache.org/jira/browse/IGNITE-21819
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> During a rebalance, partition storages and their indexes get cleaned up.
> However, {{nextRowIdToBuild}}-related logic used by all index implementations
> does not take this into account and does not remove the current value as well
> as doesn't reset the cached field. In addition, Page Memory-based index
> storages don't reset their index meta trees and can access destroyed trees
> after a rebalance.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21819) NextRowIdToBuild does not get cleared on rebalance
[
https://issues.apache.org/jira/browse/IGNITE-21819?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21819:
-
Description: During a rebalance, partition storages and their indexes get
cleaned up. However, {{nextRowIdToBuild}}-related logic used by all index
implementations does not take this into account and does not remove the current
value as well as doesn't reset the cached field. In addition, Page Memory-based
index storages don't reset their index meta trees and can access destroyed
trees after a rebalance.
> NextRowIdToBuild does not get cleared on rebalance
> --
>
> Key: IGNITE-21819
> URL: https://issues.apache.org/jira/browse/IGNITE-21819
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> During a rebalance, partition storages and their indexes get cleaned up.
> However, {{nextRowIdToBuild}}-related logic used by all index implementations
> does not take this into account and does not remove the current value as well
> as doesn't reset the cached field. In addition, Page Memory-based index
> storages don't reset their index meta trees and can access destroyed trees
> after a rebalance.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21819) NextRowIdToBuild does not get cleared on rebalance
Aleksandr Polovtcev created IGNITE-21819: Summary: NextRowIdToBuild does not get cleared on rebalance Key: IGNITE-21819 URL: https://issues.apache.org/jira/browse/IGNITE-21819 Project: Ignite Issue Type: Bug Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21811) Cleanup RocksDbClusterStateStorage
[ https://issues.apache.org/jira/browse/IGNITE-21811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21811: - Fix Version/s: 3.0.0-beta2 > Cleanup RocksDbClusterStateStorage > -- > > Key: IGNITE-21811 > URL: https://issues.apache.org/jira/browse/IGNITE-21811 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 40m > Remaining Estimate: 0h > > RocksDbClusterStateStorage#restoreSnapshot does not await the start future. > Also looks like snapshot restoration stops the thread pool, which will > prevent taking snapshots after that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21811) Cleanup RocksDbClusterStateStorage
Aleksandr Polovtcev created IGNITE-21811: Summary: Cleanup RocksDbClusterStateStorage Key: IGNITE-21811 URL: https://issues.apache.org/jira/browse/IGNITE-21811 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev RocksDbClusterStateStorage#restoreSnapshot does not await the start future. Also looks like snapshot restoration stops the thread pool, which will prevent taking snapshots after that. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21764) PersistentPageMemoryMvTableStorageTest.testIndexDestructionOnRecovery is flaky
[ https://issues.apache.org/jira/browse/IGNITE-21764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21764: - Fix Version/s: 3.0.0-beta2 > PersistentPageMemoryMvTableStorageTest.testIndexDestructionOnRecovery is flaky > -- > > Key: IGNITE-21764 > URL: https://issues.apache.org/jira/browse/IGNITE-21764 > Project: Ignite > Issue Type: Bug >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Blocker > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 40m > Remaining Estimate: 0h > > A failure can be found here: > https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7936530 > There's a race between destroying and creating an index, I believe this is a > test problem, because we shouldn't have identical index IDs in such > situations in real life. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21764) PersistentPageMemoryMvTableStorageTest.testIndexDestructionOnRecovery is flaky
Aleksandr Polovtcev created IGNITE-21764: Summary: PersistentPageMemoryMvTableStorageTest.testIndexDestructionOnRecovery is flaky Key: IGNITE-21764 URL: https://issues.apache.org/jira/browse/IGNITE-21764 Project: Ignite Issue Type: Bug Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev A failure can be found here: https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7936530 There's a race between destroying and creating an index, I believe this is a test problem, because we shouldn't have identical index IDs in such situations in real life. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21680) Remove destroyed RocksDB indexes on recovery
[
https://issues.apache.org/jira/browse/IGNITE-21680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21680:
-
Epic Link: IGNITE-20782
> Remove destroyed RocksDB indexes on recovery
>
>
> Key: IGNITE-21680
> URL: https://issues.apache.org/jira/browse/IGNITE-21680
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> When {{RocksDbTableStorage}} is started, we need to perform the following
> recovery actions:
> # Check the existing indices in the shared RocksDB instance;
> # Check the observable Catalog history (i.e. up to the LWM value);
> # Eagerly populate the maps containing the indices unless a given index is
> not present in the Catalog, in which case it must be destroyed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21671) Remove destroyed PageMemory indexes on recovery
[
https://issues.apache.org/jira/browse/IGNITE-21671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21671:
-
Epic Link: IGNITE-20782
> Remove destroyed PageMemory indexes on recovery
> ---
>
> Key: IGNITE-21671
> URL: https://issues.apache.org/jira/browse/IGNITE-21671
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When {{AbstractPageMemoryMvPartitionStorage}} is started, we need to perform
> the following recovery actions:
> # Scan the index meta tree;
> # Check the observable Catalog history (i.e. up to the LWM value);
> # If an index is present in the meta tree, but not in the Catalog - destroy
> it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21742) Refactor creating and managing of Page Memory Indexes
[
https://issues.apache.org/jira/browse/IGNITE-21742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21742:
-
Fix Version/s: 3.0.0-beta2
> Refactor creating and managing of Page Memory Indexes
> --
>
> Key: IGNITE-21742
> URL: https://issues.apache.org/jira/browse/IGNITE-21742
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current logic of managing Page Memory indexes (like recovery, creation of new
> indexes and updates during rebalance) is all contained within the
> {{AbstractPageMemoryMvPartitionStorage}} which makes it complicated to modify
> it (like, for example when implementing recovery in IGNITE-21671). Also,
> current approach of creating or restoring Index Trees is not very convenient
> as it relies on a boolean flag passed to the corresponding constructor. It
> would be more readable and maintainable to have distinct factory methods for
> that.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21742) Refactor creating and managing of Page Memory Indexes
[
https://issues.apache.org/jira/browse/IGNITE-21742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21742:
-
Summary: Refactor creating and managing of Page Memory Indexes (was:
Refactor creating and managing Page Memory Indexes )
> Refactor creating and managing of Page Memory Indexes
> --
>
> Key: IGNITE-21742
> URL: https://issues.apache.org/jira/browse/IGNITE-21742
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current logic of managing Page Memory indexes (like recovery, creation of new
> indexes and updates during rebalance) is all contained within the
> {{AbstractPageMemoryMvPartitionStorage}} which makes it complicated to modify
> it (like, for example when implementing recovery in IGNITE-21671). Also,
> current approach of creating or restoring Index Trees is not very convenient
> as it relies on a boolean flag passed to the corresponding constructor. It
> would be more readable and maintainable to have distinct factory methods for
> that.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21742) Refactor creating and managing Page Memory Indexes
[
https://issues.apache.org/jira/browse/IGNITE-21742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21742:
-
Epic Link: IGNITE-20782
Reviewer: Kirill Tkalenko
> Refactor creating and managing Page Memory Indexes
> ---
>
> Key: IGNITE-21742
> URL: https://issues.apache.org/jira/browse/IGNITE-21742
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current logic of managing Page Memory indexes (like recovery, creation of new
> indexes and updates during rebalance) is all contained within the
> {{AbstractPageMemoryMvPartitionStorage}} which makes it complicated to modify
> it (like, for example when implementing recovery in IGNITE-21671). Also,
> current approach of creating or restoring Index Trees is not very convenient
> as it relies on a boolean flag passed to the corresponding constructor. It
> would be more readable and maintainable to have distinct factory methods for
> that.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21742) Refactor creating and managing Page Memory Indexes
[
https://issues.apache.org/jira/browse/IGNITE-21742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21742:
-
Description: Current logic of managing Page Memory indexes (like recovery,
creation of new indexes and updates during rebalance) is all contained within
the {{AbstractPageMemoryMvPartitionStorage}} which makes it complicated to
modify it (like, for example when implementing recovery in IGNITE-21671). Also,
current approach of creating or restoring Index Trees is not very convenient as
it relies on a boolean flag passed to the corresponding constructor. It would
be more readable and maintainable to have distinct factory methods for that.
> Refactor creating and managing Page Memory Indexes
> ---
>
> Key: IGNITE-21742
> URL: https://issues.apache.org/jira/browse/IGNITE-21742
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Current logic of managing Page Memory indexes (like recovery, creation of new
> indexes and updates during rebalance) is all contained within the
> {{AbstractPageMemoryMvPartitionStorage}} which makes it complicated to modify
> it (like, for example when implementing recovery in IGNITE-21671). Also,
> current approach of creating or restoring Index Trees is not very convenient
> as it relies on a boolean flag passed to the corresponding constructor. It
> would be more readable and maintainable to have distinct factory methods for
> that.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21742) Refactor creating and managing Page Memory Indexes
Aleksandr Polovtcev created IGNITE-21742: Summary: Refactor creating and managing Page Memory Indexes Key: IGNITE-21742 URL: https://issues.apache.org/jira/browse/IGNITE-21742 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21728) Close cursors synchronously in ExecutionServiceImplTest
[
https://issues.apache.org/jira/browse/IGNITE-21728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21728:
-
Fix Version/s: 3.0.0-beta2
> Close cursors synchronously in ExecutionServiceImplTest
> ---
>
> Key: IGNITE-21728
> URL: https://issues.apache.org/jira/browse/IGNITE-21728
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{AsyncCursor}} in {{ExecutionServiceImplTest}} is closed using
> {{closeAsync}} but in some tests nobody waits for the return future to
> complete, which may pose race conditions.
> An example that was found in the logs during
> {{testErrorIsPropagatedToPrefetchCallback}} execution:
> {noformat}
> [2024-03-11T15:24:02,481][INFO
> ][%node_1%sql-execution-pool-0][ExecutionServiceImpl] Unable to send error
> message
> java.util.concurrent.RejectedExecutionException: Task
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl$$Lambda$1368/0x000800820c40@4ff7a879
> rejected from java.util.concurrent.ThreadPoolExecutor@145a1f2a[Terminated,
> pool size = 0, active threads = 0, queued tasks = 0, completed tasks = 5]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2055)
> ~[?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:825)
> ~[?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1355)
> ~[?:?]
> at
> org.apache.ignite.internal.thread.AbstractStripedThreadPoolExecutor.execute(AbstractStripedThreadPoolExecutor.java:61)
> ~[main/:?]
> at
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.execute(QueryTaskExecutorImpl.java:82)
> ~[main/:?]
> at
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.execute(QueryTaskExecutorImpl.java:104)
> ~[main/:?]
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImplTest$TestCluster$TestNode.lambda$onReceive$2(ExecutionServiceImplTest.java:1088)
> ~[test/:?]
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImplTest$TestCluster$TestNode.onReceive(ExecutionServiceImplTest.java:1098)
> ~[test/:?]
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImplTest$TestCluster$TestNode$1.send(ExecutionServiceImplTest.java:1017)
> ~[test/:?]
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.handleError(ExecutionServiceImpl.java:842)
> ~[main/:?]
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$submitFragment$11(ExecutionServiceImpl.java:829)
> ~[main/:?]
> at
> java.base/java.util.concurrent.CompletableFuture.uniExceptionally(CompletableFuture.java:986)
> ~[?:?]
> at
> java.base/java.util.concurrent.CompletableFuture.uniExceptionallyStage(CompletableFuture.java:1004)
> ~[?:?]
> at
> java.base/java.util.concurrent.CompletableFuture.exceptionally(CompletableFuture.java:2307)
> ~[?:?]
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.submitFragment(ExecutionServiceImpl.java:828)
> ~[main/:?]
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.submitFragment(ExecutionServiceImpl.java:505)
> ~[main/:?]
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.onMessage(ExecutionServiceImpl.java:404)
> ~[main/:?]
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl.lambda$start$1(ExecutionServiceImpl.java:253)
> ~[main/:?]
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImplTest$TestCluster$TestNode.lambda$onReceive$0(ExecutionServiceImplTest.java:1086)
> ~[test/:?]
> at
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:85)
> ~[main/:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.base/java.lang.Thread.run(Thread.java:834) [?:?]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21728) Close cursors synchronously in ExecutionServiceImplTest
[
https://issues.apache.org/jira/browse/IGNITE-21728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21728:
-
Description: {{AsyncCursor}} in {{ExecutionServiceImplTest}} is closed
using {{closeAsync}} but in some tests nobody waits for the return future to
complete, which may pose race conditions. (was: {{AsyncCursor}} in )
> Close cursors synchronously in ExecutionServiceImplTest
> ---
>
> Key: IGNITE-21728
> URL: https://issues.apache.org/jira/browse/IGNITE-21728
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> {{AsyncCursor}} in {{ExecutionServiceImplTest}} is closed using
> {{closeAsync}} but in some tests nobody waits for the return future to
> complete, which may pose race conditions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21727) Close cursors synchronously in ExecutionServiceImplTest
Aleksandr Polovtcev created IGNITE-21727:
Summary: Close cursors synchronously in ExecutionServiceImplTest
Key: IGNITE-21727
URL: https://issues.apache.org/jira/browse/IGNITE-21727
Project: Ignite
Issue Type: Improvement
Reporter: Aleksandr Polovtcev
Assignee: Aleksandr Polovtcev
{{AsyncCursor}} in {{ExecutionServiceImplTest}} is closed using {{closeAsync}},
but in some tests nobody waits for the future to complete, which can pose race
conditions.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21728) Close cursors synchronously in ExecutionServiceImplTest
[
https://issues.apache.org/jira/browse/IGNITE-21728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21728:
-
Description: {{AsyncCursor}} in
> Close cursors synchronously in ExecutionServiceImplTest
> ---
>
> Key: IGNITE-21728
> URL: https://issues.apache.org/jira/browse/IGNITE-21728
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> {{AsyncCursor}} in
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21728) Close cursors synchronously in ExecutionServiceImplTest
Aleksandr Polovtcev created IGNITE-21728: Summary: Close cursors synchronously in ExecutionServiceImplTest Key: IGNITE-21728 URL: https://issues.apache.org/jira/browse/IGNITE-21728 Project: Ignite Issue Type: Bug Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21718) Extract volatile state in AbstractPageMemoryMvPartitionStorage into a separate class
[
https://issues.apache.org/jira/browse/IGNITE-21718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21718:
-
Fix Version/s: 3.0.0-beta2
> Extract volatile state in AbstractPageMemoryMvPartitionStorage into a
> separate class
>
>
> Key: IGNITE-21718
> URL: https://issues.apache.org/jira/browse/IGNITE-21718
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> {{AbstractPageMemoryMvPartitionStorage}} contains a bunch of volatile fields
> that get replaced during a rebalance cleanup. I propose to wrap this fields
> in a single class in order to make the code a little bit more maintainable. I
> see the following benefits:
> # It will become easy to understand, what components of the storage may be
> updated;
> # It will be easier to add more volatile components and not forget to update
> them;
> # It will become easier to avoid unnecessary volatile reads, because the
> whole state can be fetched using a single read.
>
> The only downside I can see is that the code may become a little bit more
> verbose, because you will need to access the state class first.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21714) Prevent threads from being hijacked in KV/Record view APIs
[ https://issues.apache.org/jira/browse/IGNITE-21714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21714: - Reviewer: Aleksandr Polovtcev (was: Aleksandr Polovtsev) > Prevent threads from being hijacked in KV/Record view APIs > -- > > Key: IGNITE-21714 > URL: https://issues.apache.org/jira/browse/IGNITE-21714 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 2h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21718) Extract volatile state in AbstractPageMemoryMvPartitionStorage into a separate class
[
https://issues.apache.org/jira/browse/IGNITE-21718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21718:
-
Description:
{{AbstractPageMemoryMvPartitionStorage}} contains a bunch of volatile fields
that get replaced during a rebalance cleanup. I propose to wrap this fields in
a single class in order to make the code a little bit more maintainable. I see
the following benefits:
# It will become easy to understand, what components of the storage may be
updated;
# It will be easier to add more volatile components and not forget to update
them;
# It will become easier to avoid unnecessary volatile reads, because the whole
state can be fetched using a single read.
The only downside I can see is that the code may become a little bit more
verbose, because you will need to access the state class first.
> Extract volatile state in AbstractPageMemoryMvPartitionStorage into a
> separate class
>
>
> Key: IGNITE-21718
> URL: https://issues.apache.org/jira/browse/IGNITE-21718
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Minor
> Labels: ignite-3
>
> {{AbstractPageMemoryMvPartitionStorage}} contains a bunch of volatile fields
> that get replaced during a rebalance cleanup. I propose to wrap this fields
> in a single class in order to make the code a little bit more maintainable. I
> see the following benefits:
> # It will become easy to understand, what components of the storage may be
> updated;
> # It will be easier to add more volatile components and not forget to update
> them;
> # It will become easier to avoid unnecessary volatile reads, because the
> whole state can be fetched using a single read.
>
> The only downside I can see is that the code may become a little bit more
> verbose, because you will need to access the state class first.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21718) Extract volatile state in AbstractPageMemoryMvPartitionStorage into a separate class
Aleksandr Polovtcev created IGNITE-21718: Summary: Extract volatile state in AbstractPageMemoryMvPartitionStorage into a separate class Key: IGNITE-21718 URL: https://issues.apache.org/jira/browse/IGNITE-21718 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21718) Extract volatile state in AbstractPageMemoryMvPartitionStorage into a separate class
[ https://issues.apache.org/jira/browse/IGNITE-21718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21718: - Ignite Flags: (was: Docs Required,Release Notes Required) > Extract volatile state in AbstractPageMemoryMvPartitionStorage into a > separate class > > > Key: IGNITE-21718 > URL: https://issues.apache.org/jira/browse/IGNITE-21718 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Minor > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21683) Remove thread pools used for BTree destruction
[
https://issues.apache.org/jira/browse/IGNITE-21683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21683:
-
Description: We have two separate executors that are used in
{{GradualTaskExecutor}} for destroying Persistent and Volatile Page Memory
based structures. They should probably be removed and replaced with a common
pool. (was: We have two separate executors that are used in
{{GradualTaskExecutor}} for destroying Persistent and Volatile Page
Memory-based structures. They should probably be removed and replaced with a
common pool.)
> Remove thread pools used for BTree destruction
> --
>
> Key: IGNITE-21683
> URL: https://issues.apache.org/jira/browse/IGNITE-21683
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> We have two separate executors that are used in {{GradualTaskExecutor}} for
> destroying Persistent and Volatile Page Memory based structures. They should
> probably be removed and replaced with a common pool.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21683) Remove thread pools used for BTree destruction
[
https://issues.apache.org/jira/browse/IGNITE-21683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21683:
-
Description: We have two separate executors that are used in
{{GradualTaskExecutor}} for destroying Persistent and Volatile Page
Memory-based structures. They should probably be removed and replaced with a
common pool. (was: We have two separate executors that are used in a
`GradualTaskExecutor` for destroying Persistent and Volatile Page Memory-based
structures. They should probably be removed and replaced with a common pool.)
> Remove thread pools used for BTree destruction
> --
>
> Key: IGNITE-21683
> URL: https://issues.apache.org/jira/browse/IGNITE-21683
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> We have two separate executors that are used in {{GradualTaskExecutor}} for
> destroying Persistent and Volatile Page Memory-based structures. They should
> probably be removed and replaced with a common pool.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21683) Remove thread pools used for BTree destruction
[ https://issues.apache.org/jira/browse/IGNITE-21683?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21683: - Description: We have two separate executors that are used in a `GradualTaskExecutor` for destroying Persistent and Volatile Page Memory-based structures. They should probably be removed and replaced with a common pool. > Remove thread pools used for BTree destruction > -- > > Key: IGNITE-21683 > URL: https://issues.apache.org/jira/browse/IGNITE-21683 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > > We have two separate executors that are used in a `GradualTaskExecutor` for > destroying Persistent and Volatile Page Memory-based structures. They should > probably be removed and replaced with a common pool. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21683) Remove thread pools used for BTree destruction
Aleksandr Polovtcev created IGNITE-21683: Summary: Remove thread pools used for BTree destruction Key: IGNITE-21683 URL: https://issues.apache.org/jira/browse/IGNITE-21683 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20126) Check that the index exists before reading from it
[ https://issues.apache.org/jira/browse/IGNITE-20126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17823941#comment-17823941 ] Aleksandr Polovtcev commented on IGNITE-20126: -- I think this ticket should be updated to handle writing to a destroyed index as well > Check that the index exists before reading from it > -- > > Key: IGNITE-20126 > URL: https://issues.apache.org/jira/browse/IGNITE-20126 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Before each read-from-index operation (like opening a scan cursor or getting > next batch of such a cursor), we should check whether the index physically > exists. If not, the operation must be failed and the current RW tx must be > aborted. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21680) Remove destroyed RocksDB indexes on recovery
[
https://issues.apache.org/jira/browse/IGNITE-21680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21680:
-
Description:
When {{RocksDbTableStorage}} is started, we need to perform the following
recovery actions:
# Check the existing indices in the shared RocksDB instance;
# Check the observable Catalog history (i.e. up to the LWM value);
# Eagerly populate the maps containing the indices unless a given index is not
present in the Catalog, in which case it must be destroyed.
was:
When {{AbstractPageMemoryMvPartitionStorage}} is started, we need to perform
the following recovery actions:
# Scan the index meta tree;
# Check the observable Catalog history (i.e. up to the LWM value);
# If an index is present in the meta tree, but not in the Catalog - destroy it.
> Remove destroyed RocksDB indexes on recovery
>
>
> Key: IGNITE-21680
> URL: https://issues.apache.org/jira/browse/IGNITE-21680
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> When {{RocksDbTableStorage}} is started, we need to perform the following
> recovery actions:
> # Check the existing indices in the shared RocksDB instance;
> # Check the observable Catalog history (i.e. up to the LWM value);
> # Eagerly populate the maps containing the indices unless a given index is
> not present in the Catalog, in which case it must be destroyed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21680) Remove destroyed RocksDB indexes on recovery
Aleksandr Polovtcev created IGNITE-21680:
Summary: Remove destroyed RocksDB indexes on recovery
Key: IGNITE-21680
URL: https://issues.apache.org/jira/browse/IGNITE-21680
Project: Ignite
Issue Type: Improvement
Reporter: Aleksandr Polovtcev
Assignee: Aleksandr Polovtcev
Fix For: 3.0.0-beta2
When {{AbstractPageMemoryMvPartitionStorage}} is started, we need to perform
the following recovery actions:
# Scan the index meta tree;
# Check the observable Catalog history (i.e. up to the LWM value);
# If an index is present in the meta tree, but not in the Catalog - destroy it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21576) Unmute tests after index removal API is implemented
[ https://issues.apache.org/jira/browse/IGNITE-21576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21576: - Fix Version/s: 3.0.0-beta2 > Unmute tests after index removal API is implemented > --- > > Key: IGNITE-21576 > URL: https://issues.apache.org/jira/browse/IGNITE-21576 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > I've disabled some tests with a link pointing to this ticket. These tests > must be unmuted after IGNITE-21574 and IGNITE-21583 are fixed -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21671) Remove destroyed PageMemory indexes on recovery
[
https://issues.apache.org/jira/browse/IGNITE-21671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21671:
-
Description:
When {{AbstractPageMemoryMvPartitionStorage}} is started, we need to perform
the following recovery actions:
# Scan the index meta tree;
# Check the observable Catalog history (i.e. up to the LWM value);
# If an index is present in the meta tree, but not in the Catalog - destroy it.
> Remove destroyed PageMemory indexes on recovery
> ---
>
> Key: IGNITE-21671
> URL: https://issues.apache.org/jira/browse/IGNITE-21671
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> When {{AbstractPageMemoryMvPartitionStorage}} is started, we need to perform
> the following recovery actions:
> # Scan the index meta tree;
> # Check the observable Catalog history (i.e. up to the LWM value);
> # If an index is present in the meta tree, but not in the Catalog - destroy
> it.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21671) Remove destroyed PageMemory indexes on recovery
[ https://issues.apache.org/jira/browse/IGNITE-21671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21671: - Summary: Remove destroyed PageMemory indexes on recovery (was: Remove destroyed indexes on recovery) > Remove destroyed PageMemory indexes on recovery > --- > > Key: IGNITE-21671 > URL: https://issues.apache.org/jira/browse/IGNITE-21671 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21671) Remove destroyed indexes on recovery
[ https://issues.apache.org/jira/browse/IGNITE-21671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21671: - Fix Version/s: 3.0.0-beta2 > Remove destroyed indexes on recovery > > > Key: IGNITE-21671 > URL: https://issues.apache.org/jira/browse/IGNITE-21671 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21671) Remove destroyed indexes on recovery
Aleksandr Polovtcev created IGNITE-21671: Summary: Remove destroyed indexes on recovery Key: IGNITE-21671 URL: https://issues.apache.org/jira/browse/IGNITE-21671 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21670) Remove MvTableStorage#start method
[ https://issues.apache.org/jira/browse/IGNITE-21670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21670: - Fix Version/s: 3.0.0-beta2 > Remove MvTableStorage#start method > -- > > Key: IGNITE-21670 > URL: https://issues.apache.org/jira/browse/IGNITE-21670 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > This method is probably some legacy remnant after table schema has been moved > away from the configuration. Currently this method is always called after an > instance of MvTableStorage is created and does nothing useful, all its code > can be moved to the corresponding constructors. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21670) Remove MvTableStorage#start method
[ https://issues.apache.org/jira/browse/IGNITE-21670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21670: - Ignite Flags: (was: Docs Required,Release Notes Required) > Remove MvTableStorage#start method > -- > > Key: IGNITE-21670 > URL: https://issues.apache.org/jira/browse/IGNITE-21670 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > > This method is probably some legacy remnant after table schema has been moved > away from the configuration. Currently this method is always called after an > instance of MvTableStorage is created and does nothing useful, all its code > can be moved to the corresponding constructors. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21670) Remove MvTableStorage#start method
[ https://issues.apache.org/jira/browse/IGNITE-21670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21670: - Labels: ignite-3 (was: ) > Remove MvTableStorage#start method > -- > > Key: IGNITE-21670 > URL: https://issues.apache.org/jira/browse/IGNITE-21670 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > > This method is probably some legacy remnant after table schema has been moved > away from the configuration. Currently this method is always called after an > instance of MvTableStorage is created and does nothing useful, all its code > can be moved to the corresponding constructors. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21670) Remove MvTableStorage#start method
Aleksandr Polovtcev created IGNITE-21670: Summary: Remove MvTableStorage#start method Key: IGNITE-21670 URL: https://issues.apache.org/jira/browse/IGNITE-21670 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev This method is probably some legacy remnant after table schema has been moved away from the configuration. Currently this method is always called after an instance of MvTableStorage is created and does nothing useful, all its code can be moved to the corresponding constructors. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21645) Fix tests extending AbstractPlannerTest on Java 21
[
https://issues.apache.org/jira/browse/IGNITE-21645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21645:
-
Release Note: (was: Looks good!)
> Fix tests extending AbstractPlannerTest on Java 21
> --
>
> Key: IGNITE-21645
> URL: https://issues.apache.org/jira/browse/IGNITE-21645
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The tests change a final field value. In such a situation, the corresponding
> IgniteTestUtils method changes the corresponding Field's {{modifiers}} to
> remove the {{final}} flag from them. The modifiers are changed through a
> MethodHandle, and on highest Java versions, a MethodHandle of a final Field
> now throws an UnsupportedOperationException.
> It turns out, this modification of the modifiers is actually not needed on
> any of the currently LTS Java versions (11, 17, 21), so we can just remove
> this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21645) Fix tests extending AbstractPlannerTest on Java 21
[
https://issues.apache.org/jira/browse/IGNITE-21645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17822681#comment-17822681
]
Aleksandr Polovtcev commented on IGNITE-21645:
--
Looks good!
> Fix tests extending AbstractPlannerTest on Java 21
> --
>
> Key: IGNITE-21645
> URL: https://issues.apache.org/jira/browse/IGNITE-21645
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> The tests change a final field value. In such a situation, the corresponding
> IgniteTestUtils method changes the corresponding Field's {{modifiers}} to
> remove the {{final}} flag from them. The modifiers are changed through a
> MethodHandle, and on highest Java versions, a MethodHandle of a final Field
> now throws an UnsupportedOperationException.
> It turns out, this modification of the modifiers is actually not needed on
> any of the currently LTS Java versions (11, 17, 21), so we can just remove
> this.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21625) Improve WatchEvent assertion message
[
https://issues.apache.org/jira/browse/IGNITE-21625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21625:
-
Fix Version/s: 3.0.0-beta2
> Improve WatchEvent assertion message
>
>
> Key: IGNITE-21625
> URL: https://issues.apache.org/jira/browse/IGNITE-21625
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> {{WatchEvent#entryEvent}} method throws an {{AssertionError}} if the event
> contains multiple entries, but the exception does not contain any information
> about these entries.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21625) Improve WatchEvent assertion message
Aleksandr Polovtcev created IGNITE-21625:
Summary: Improve WatchEvent assertion message
Key: IGNITE-21625
URL: https://issues.apache.org/jira/browse/IGNITE-21625
Project: Ignite
Issue Type: Improvement
Reporter: Aleksandr Polovtcev
Assignee: Aleksandr Polovtcev
{{WatchEvent#entryEvent}} method throws an {{AssertionError}} if the event
contains multiple entries, but the exception does not contain any information
about these entries.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21614) Incorrect BindException handling in ClientHandlerModule
[ https://issues.apache.org/jira/browse/IGNITE-21614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21614: - Ignite Flags: (was: Docs Required,Release Notes Required) > Incorrect BindException handling in ClientHandlerModule > --- > > Key: IGNITE-21614 > URL: https://issues.apache.org/jira/browse/IGNITE-21614 > Project: Ignite > Issue Type: Bug > Components: networking >Reporter: Philipp Shergalis >Priority: Major > > [https://github.com/apache/ignite-3/blob/main/modules/client-handler/src/main/java/org/apache/ignite/client/handler/ClientHandlerModule.java#L327] > > Any bind exception is thrown as "PORT_IN_USE_ERR", although there could be a > problem with address -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21614) Incorrect BindException handling in ClientHandlerModule
[ https://issues.apache.org/jira/browse/IGNITE-21614?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21614: - Labels: ignite-3 (was: ) > Incorrect BindException handling in ClientHandlerModule > --- > > Key: IGNITE-21614 > URL: https://issues.apache.org/jira/browse/IGNITE-21614 > Project: Ignite > Issue Type: Bug > Components: networking >Reporter: Philipp Shergalis >Priority: Major > Labels: ignite-3 > > [https://github.com/apache/ignite-3/blob/main/modules/client-handler/src/main/java/org/apache/ignite/client/handler/ClientHandlerModule.java#L327] > > Any bind exception is thrown as "PORT_IN_USE_ERR", although there could be a > problem with address -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21583) Implement API for dropping PageMemory indexes
[ https://issues.apache.org/jira/browse/IGNITE-21583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21583: - Description: This task is identical to IGNITE-21574, but this time it should be implemented on the Page Memory's side. > Implement API for dropping PageMemory indexes > - > > Key: IGNITE-21583 > URL: https://issues.apache.org/jira/browse/IGNITE-21583 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > > This task is identical to IGNITE-21574, but this time it should be > implemented on the Page Memory's side. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21590) Remove MvTableStorage#stop method
[ https://issues.apache.org/jira/browse/IGNITE-21590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21590: - Fix Version/s: 3.0.0-beta2 > Remove MvTableStorage#stop method > - > > Key: IGNITE-21590 > URL: https://issues.apache.org/jira/browse/IGNITE-21590 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > This method is duplicated by the "close" method inherited from > "ManuallyCloseable" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21590) Remove MvTableStorage#stop method
[ https://issues.apache.org/jira/browse/IGNITE-21590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21590: - Ignite Flags: (was: Docs Required,Release Notes Required) > Remove MvTableStorage#stop method > - > > Key: IGNITE-21590 > URL: https://issues.apache.org/jira/browse/IGNITE-21590 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > This method is duplicated by the "close" method inherited from > "ManuallyCloseable" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21590) Remove MvTableStorage#stop method
[ https://issues.apache.org/jira/browse/IGNITE-21590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21590: - Labels: ignite-3 (was: ) > Remove MvTableStorage#stop method > - > > Key: IGNITE-21590 > URL: https://issues.apache.org/jira/browse/IGNITE-21590 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > This method is duplicated by the "close" method inherited from > "ManuallyCloseable" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21576) Unmute tests after index removal API is implemented
[ https://issues.apache.org/jira/browse/IGNITE-21576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21576: - Description: I've disabled some tests with a link pointing to this ticket. These tests must be unmuted after IGNITE-21574 and IGNITE-21583 are fixed > Unmute tests after index removal API is implemented > --- > > Key: IGNITE-21576 > URL: https://issues.apache.org/jira/browse/IGNITE-21576 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > > I've disabled some tests with a link pointing to this ticket. These tests > must be unmuted after IGNITE-21574 and IGNITE-21583 are fixed -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21576) Unmute tests after index removal API is implemented
[ https://issues.apache.org/jira/browse/IGNITE-21576?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21576: - Summary: Unmute tests after index removal API is implemented (was: Destroy index storages on Catalog compaction) > Unmute tests after index removal API is implemented > --- > > Key: IGNITE-21576 > URL: https://issues.apache.org/jira/browse/IGNITE-21576 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21590) Remove MvTableStorage#stop method
Aleksandr Polovtcev created IGNITE-21590: Summary: Remove MvTableStorage#stop method Key: IGNITE-21590 URL: https://issues.apache.org/jira/browse/IGNITE-21590 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev This method is duplicated by the "close" method inherited from "ManuallyCloseable" -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17626) Add API for dropping indexes
[ https://issues.apache.org/jira/browse/IGNITE-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-17626: - Reviewer: Kirill Tkalenko > Add API for dropping indexes > > > Key: IGNITE-17626 > URL: https://issues.apache.org/jira/browse/IGNITE-17626 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > We need to figure out how dropping sorted and hash indexes for all storages > should work. > At the moment we have 2 api synchronous and asynchronous, also for some > reason there is only a drop in the index hash but not for sorted. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21574) Implement API for dropping RocksDb indexes
[
https://issues.apache.org/jira/browse/IGNITE-21574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21574:
-
Description: Implement destruction of all types of index storages for the
RocksDb engine. See {{RocksDbTableStorage#destroyIndex(int)}}.
> Implement API for dropping RocksDb indexes
> --
>
> Key: IGNITE-21574
> URL: https://issues.apache.org/jira/browse/IGNITE-21574
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> Implement destruction of all types of index storages for the RocksDb engine.
> See {{RocksDbTableStorage#destroyIndex(int)}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17626) Add API for dropping indexes
[ https://issues.apache.org/jira/browse/IGNITE-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-17626: - Fix Version/s: 3.0.0-beta2 > Add API for dropping indexes > > > Key: IGNITE-17626 > URL: https://issues.apache.org/jira/browse/IGNITE-17626 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > We need to figure out how dropping sorted and hash indexes for all storages > should work. > At the moment we have 2 api synchronous and asynchronous, also for some > reason there is only a drop in the index hash but not for sorted. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21583) Implement API for dropping PageMemory indexes
Aleksandr Polovtcev created IGNITE-21583: Summary: Implement API for dropping PageMemory indexes Key: IGNITE-21583 URL: https://issues.apache.org/jira/browse/IGNITE-21583 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21574) Implement API for dropping RocksDb indexes
[ https://issues.apache.org/jira/browse/IGNITE-21574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21574: - Summary: Implement API for dropping RocksDb indexes (was: Implement API for dropping indexes) > Implement API for dropping RocksDb indexes > -- > > Key: IGNITE-21574 > URL: https://issues.apache.org/jira/browse/IGNITE-21574 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21576) Destroy index storages on Catalog compaction
Aleksandr Polovtcev created IGNITE-21576: Summary: Destroy index storages on Catalog compaction Key: IGNITE-21576 URL: https://issues.apache.org/jira/browse/IGNITE-21576 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21575) Destroy index storages on rebalance
[ https://issues.apache.org/jira/browse/IGNITE-21575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21575: - Epic Link: IGNITE-20782 > Destroy index storages on rebalance > --- > > Key: IGNITE-21575 > URL: https://issues.apache.org/jira/browse/IGNITE-21575 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21575) Destroy index storages on rebalance
Aleksandr Polovtcev created IGNITE-21575: Summary: Destroy index storages on rebalance Key: IGNITE-21575 URL: https://issues.apache.org/jira/browse/IGNITE-21575 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21574) Implement API for dropping indexes
[ https://issues.apache.org/jira/browse/IGNITE-21574?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21574: - Epic Link: IGNITE-20782 > Implement API for dropping indexes > -- > > Key: IGNITE-21574 > URL: https://issues.apache.org/jira/browse/IGNITE-21574 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21574) Implement API for dropping indexes
Aleksandr Polovtcev created IGNITE-21574: Summary: Implement API for dropping indexes Key: IGNITE-21574 URL: https://issues.apache.org/jira/browse/IGNITE-21574 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17626) Add API for dropping indexes
[ https://issues.apache.org/jira/browse/IGNITE-17626?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-17626: - Summary: Add API for dropping indexes (was: Fix drop sorted and hash indices for all storages) > Add API for dropping indexes > > > Key: IGNITE-17626 > URL: https://issues.apache.org/jira/browse/IGNITE-17626 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > > We need to figure out how dropping sorted and hash indexes for all storages > should work. > At the moment we have 2 api synchronous and asynchronous, also for some > reason there is only a drop in the index hash but not for sorted. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21573) Fix IDEA warnings in BplusTree
[ https://issues.apache.org/jira/browse/IGNITE-21573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21573: - Fix Version/s: 3.0.0-beta2 > Fix IDEA warnings in BplusTree > -- > > Key: IGNITE-21573 > URL: https://issues.apache.org/jira/browse/IGNITE-21573 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
