[jira] [Created] (IGNITE-16520) Refactor IgniteCliInterfaceTest
Roman Puchkovskiy created IGNITE-16520: -- Summary: Refactor IgniteCliInterfaceTest Key: IGNITE-16520 URL: https://issues.apache.org/jira/browse/IGNITE-16520 Project: Ignite Issue Type: Improvement Components: general Reporter: Roman Puchkovskiy Fix For: 3.0.0-alpha5 IgniteCliInterfaceTest is already pretty long and it will become even longer when we add more commands. It makes sense to pull the test classes (like Config, Node, etc) to the upper level and make them independent from each other. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16505) Calcite engine. Move row count approximation from ignite-indexing
[
https://issues.apache.org/jira/browse/IGNITE-16505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16505:
---
Labels: calcite calcite3-required (was: calcite calcite2-required
calcite3-required)
> Calcite engine. Move row count approximation from ignite-indexing
> --
>
> Key: IGNITE-16505
> URL: https://issues.apache.org/jira/browse/IGNITE-16505
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite3-required
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Method {{GridH2Table.getRowCountApproximationNoCheck}} was introduced only
> for the Calcite-based SQL engine. This method is not used by
> {{ignite-indexing}} module, this method doesn't use almost anything from
> {{ignite-indexing}} module. It can be easily moved {{ignite-calcite}} module,
> that allow to reduce dependencies from {{ignite-calcite}} to
> {{ignite-indexing}} and avoid merge conflicts.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16505) Calcite engine. Move row count approximation from ignite-indexing
[
https://issues.apache.org/jira/browse/IGNITE-16505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17490011#comment-17490011
]
Aleksey Plekhanov commented on IGNITE-16505:
[~zstan], thanks for the review! Merged to sql-calcite branch.
> Calcite engine. Move row count approximation from ignite-indexing
> --
>
> Key: IGNITE-16505
> URL: https://issues.apache.org/jira/browse/IGNITE-16505
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Method {{GridH2Table.getRowCountApproximationNoCheck}} was introduced only
> for the Calcite-based SQL engine. This method is not used by
> {{ignite-indexing}} module, this method doesn't use almost anything from
> {{ignite-indexing}} module. It can be easily moved {{ignite-calcite}} module,
> that allow to reduce dependencies from {{ignite-calcite}} to
> {{ignite-indexing}} and avoid merge conflicts.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16483) Improve ComputeGridMonitor test coverage
[ https://issues.apache.org/jira/browse/IGNITE-16483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-16483: - Reviewer: Sergey Chugunov [~sergeychugunov] Please make code review. > Improve ComputeGridMonitor test coverage > > > Key: IGNITE-16483 > URL: https://issues.apache.org/jira/browse/IGNITE-16483 > Project: Ignite > Issue Type: Bug > Components: compute >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Minor > Fix For: 2.13 > > Time Spent: 10m > Remaining Estimate: 0h > > Fix flaky *ComputeJobChangePriorityTest#testChangeTaskPriorityAttribute* > The problem is in the test itself, there could be a rare race between > completing a compute task and waiting for its attribute, so it was enough to > add task completion after receiving the expected attribute. > Add tests for *ComputeGridMonitor* in case of a client node. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16519) Adding a system view for recently completed compute tasks
Kirill Tkalenko created IGNITE-16519: Summary: Adding a system view for recently completed compute tasks Key: IGNITE-16519 URL: https://issues.apache.org/jira/browse/IGNITE-16519 Project: Ignite Issue Type: Improvement Components: compute Reporter: Kirill Tkalenko Assignee: Kirill Tkalenko Fix For: 2.13 It would be useful to do a system view to get the latest *N(system property)* completed compute tasks. It is proposed to make it look like the existing system view *org.apache.ignite.spi.systemview.view.ComputeTaskView* using a *org.apache.ignite.internal.processors.task.monitor.ComputeGridMonitor* (based on a ring buffer). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16518) BPlusTreeReuseListPageMemoryImplTest.testMassiveRemove2_true flaky
Kirill Tkalenko created IGNITE-16518:
Summary:
BPlusTreeReuseListPageMemoryImplTest.testMassiveRemove2_true flaky
Key: IGNITE-16518
URL: https://issues.apache.org/jira/browse/IGNITE-16518
Project: Ignite
Issue Type: Bug
Components: data structures
Reporter: Kirill Tkalenko
Assignee: Kirill Tkalenko
Fix For: 2.13
Found that the test sometimes fails:
*BPlusTreeReuseListPageMemoryImplTest.testMassiveRemove2_true* flaky.
https://ci.ignite.apache.org/project.html?tab=testDetails&projectId=IgniteTests24Java8&testNameId=7031624718556126435&page=1
Explanation
{noformat}
Here’s a tree and a set of operations that lead to undesired results:
[ 2 ]
/ \
[ 1 ] [ 3 | 4 ]
/ \ / |\
[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
// Remove 2
[ 1 ]
/ \
[ ] [ 3 | 4 ]
| /|\
[ 1 ] [ 3 ] [ 4 ] [ 5 ]
// Remove 5
[ 1 ]
/ \
[ ] [ 3 ]
| /\
[ 1 ] [ 3 ] [ 4 ]
// Remove 4
[ 1 ]
/ \
[ ] [ ]
| |
[ 1 ] [ 3 ]
// Remove 3
[ 1 ]
|
[ ]
|
[ 1 ]
// Remove 1
[ ]
|
[ ]
{noformat}
It’s clear that at some point we have a whole level consisting of routing
nodes. This later leads to somewhat incorrect “cut tree root” operation that
leaves empty leaf.
Possible solutions
root cutting should probably be recursive and should proceed until root node is
not empty or is a leaf.
merge operation should work better with routing nodes - every time there’s a
merge, we should consider the possibility to merge empty neighbor as well.
re-balance data from neighbor when node becomes a router node. Might be
impossible or very challenging in current implementation.
Option 1 is the easiest one. Given the rarity of the case, I’d go with it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16518) BPlusTreeReuseListPageMemoryImplTest.testMassiveRemove2_true flaky
[
https://issues.apache.org/jira/browse/IGNITE-16518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-16518:
-
Description:
Found that the test sometimes fails:
*BPlusTreeReuseListPageMemoryImplTest.testMassiveRemove2_true* flaky.
https://ci.ignite.apache.org/project.html?tab=testDetails&projectId=IgniteTests24Java8&testNameId=7031624718556126435&page=1
Explanation
{noformat}
Here’s a tree and a set of operations that lead to undesired results:
[ 2 ]
/ \
[ 1 ] [ 3 | 4 ]
/ \ / |\
[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
// Remove 2
[ 1 ]
/ \
[ ] [ 3 | 4 ]
| /|\
[ 1 ] [ 3 ] [ 4 ] [ 5 ]
// Remove 5
[ 1 ]
/ \
[ ] [ 3 ]
| /\
[ 1 ] [ 3 ] [ 4 ]
// Remove 4
[ 1 ]
/ \
[ ] [ ]
| |
[ 1 ] [ 3 ]
// Remove 3
[ 1 ]
|
[ ]
|
[ 1 ]
// Remove 1
[ ]
|
[ ]
{noformat}
It’s clear that at some point we have a whole level consisting of routing
nodes. This later leads to somewhat incorrect “cut tree root” operation that
leaves empty leaf.
Possible solutions
* root cutting should probably be recursive and should proceed until root node
is not empty or is a leaf.
* merge operation should work better with routing nodes - every time there’s a
merge, we should consider the possibility to merge empty neighbor as well.
* re-balance data from neighbor when node becomes a router node. Might be
impossible or very challenging in current implementation.
Option 1 is the easiest one. Given the rarity of the case, I’d go with it.
was:
Found that the test sometimes fails:
*BPlusTreeReuseListPageMemoryImplTest.testMassiveRemove2_true* flaky.
https://ci.ignite.apache.org/project.html?tab=testDetails&projectId=IgniteTests24Java8&testNameId=7031624718556126435&page=1
Explanation
{noformat}
Here’s a tree and a set of operations that lead to undesired results:
[ 2 ]
/ \
[ 1 ] [ 3 | 4 ]
/ \ / |\
[ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
// Remove 2
[ 1 ]
/ \
[ ] [ 3 | 4 ]
| /|\
[ 1 ] [ 3 ] [ 4 ] [ 5 ]
// Remove 5
[ 1 ]
/ \
[ ] [ 3 ]
| /\
[ 1 ] [ 3 ] [ 4 ]
// Remove 4
[ 1 ]
/ \
[ ] [ ]
| |
[ 1 ] [ 3 ]
// Remove 3
[ 1 ]
|
[ ]
|
[ 1 ]
// Remove 1
[ ]
|
[ ]
{noformat}
It’s clear that at some point we have a whole level consisting of routing
nodes. This later leads to somewhat incorrect “cut tree root” operation that
leaves empty leaf.
Possible solutions
root cutting should probably be recursive and should proceed until root node is
not empty or is a leaf.
merge operation should work better with routing nodes - every time there’s a
merge, we should consider the possibility to merge empty neighbor as well.
re-balance data from neighbor when node becomes a router node. Might be
impossible or very challenging in current implementation.
Option 1 is the easiest one. Given the rarity of the case, I’d go with it.
> BPlusTreeReuseListPageMemoryImplTest.testMassiveRemove2_true flaky
> --
>
> Key: IGNITE-16518
> URL: https://issues.apache.org/jira/browse/IGNITE-16518
> Project: Ignite
> Issue Type: Bug
> Components: data structures
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.13
>
>
> Found that the test sometimes fails:
> *BPlusTreeReuseListPageMemoryImplTest.testMassiveRemove2_true* flaky.
> https://ci.ignite.apache.org/project.html?tab=testDetails&projectId=IgniteTests24Java8&testNameId=7031624718556126435&page=1
> Explanation
> {noformat}
> Here’s a tree and a set of operations that lead to undesired results:
>[ 2 ]
> / \
>[ 1 ] [ 3 | 4 ]
>/ \ / |\
> [ 1 ] [ 2 ] [ 3 ] [ 4 ] [ 5 ]
> // Remove 2
> [ 1 ]
> / \
> [ ] [ 3 | 4 ]
> | /|\
> [ 1 ] [ 3 ] [ 4 ] [ 5 ]
> // Remove 5
> [ 1 ]
> / \
> [ ] [ 3 ]
> | /\
> [ 1 ] [ 3 ] [ 4 ]
> // Remove 4
> [ 1 ]
>/ \
> [ ] [ ]
> | |
> [ 1 ] [ 3 ]
> // Remove 3
> [ 1 ]
> |
> [ ]
> |
> [ 1 ]
> // Remove 1
> [ ]
> |
> [ ]
> {noformat}
> It’s clear that at some point we have a whole level consisting of routing
> nodes. This later leads to somewhat incorrect “cut tree root” operation that
> leaves empty leaf.
> Possible solutions
> * root cutting should probably be recursive and should proceed until root
> node is not empty or is a leaf.
> * merge operation should work better with routing nodes - every time there’s
> a merge, we should consider the possibility to merge empty neighbor as well.
> * re-
[jira] [Commented] (IGNITE-16483) Improve ComputeGridMonitor test coverage
[
https://issues.apache.org/jira/browse/IGNITE-16483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489951#comment-17489951
]
Ignite TC Bot commented on IGNITE-16483:
{panel:title=Branch: [pull/9810/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9810/head] Base: [master] : New Tests
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Compute (Grid){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=6409982]]
* {color:#013220}IgniteBinaryObjectsComputeGridTestSuite:
ComputeGridMonitorTest.simpleClientNodeTest - PASSED{color}
* {color:#013220}IgniteBinaryObjectsComputeGridTestSuite:
ComputeGridMonitorTest.snapshotsClientNodeTest - PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6410044&buildTypeId=IgniteTests24Java8_RunAll]
> Improve ComputeGridMonitor test coverage
>
>
> Key: IGNITE-16483
> URL: https://issues.apache.org/jira/browse/IGNITE-16483
> Project: Ignite
> Issue Type: Bug
> Components: compute
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Minor
> Fix For: 2.13
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Fix flaky *ComputeJobChangePriorityTest#testChangeTaskPriorityAttribute*
> The problem is in the test itself, there could be a rare race between
> completing a compute task and waiting for its attribute, so it was enough to
> add task completion after receiving the expected attribute.
> Add tests for *ComputeGridMonitor* in case of a client node.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16030) Partition reservation for cache queries
[ https://issues.apache.org/jira/browse/IGNITE-16030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-16030: Summary: Partition reservation for cache queries (was: Sync topology and affinity on map side of IndexQuery) > Partition reservation for cache queries > --- > > Key: IGNITE-16030 > URL: https://issues.apache.org/jira/browse/IGNITE-16030 > Project: Ignite > Issue Type: Task >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-71 > > Currently IndexQuery extract info about primary partitions in runtime for > every entry. It can lead to situation that different nodes can run query over > different topology versions. > > It's required to sync map side of IndexQuery. > > Fail query if sync isn't successfull. Retry of query isn't part of this > ticket. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16030) Partition reservation for cache queries
[ https://issues.apache.org/jira/browse/IGNITE-16030?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-16030: Description: Currently IndexQuery extract info about primary partitions in runtime for every entry. It can lead to situation that different nodes can run query over different topology versions. It's required to sync map side of IndexQuery. Fail query if sync isn't successfull. Retry of query isn't part of this ticket. Also, ScanQuery / TextQuery should reserve partitions too. was: Currently IndexQuery extract info about primary partitions in runtime for every entry. It can lead to situation that different nodes can run query over different topology versions. It's required to sync map side of IndexQuery. Fail query if sync isn't successfull. Retry of query isn't part of this ticket. > Partition reservation for cache queries > --- > > Key: IGNITE-16030 > URL: https://issues.apache.org/jira/browse/IGNITE-16030 > Project: Ignite > Issue Type: Task >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-71 > > Currently IndexQuery extract info about primary partitions in runtime for > every entry. It can lead to situation that different nodes can run query over > different topology versions. > > It's required to sync map side of IndexQuery. > > Fail query if sync isn't successfull. Retry of query isn't part of this > ticket. > > Also, ScanQuery / TextQuery should reserve partitions too. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16517) Fix documentation for the snapshot restore procedure on different topologyies
Maxim Muzafarov created IGNITE-16517: Summary: Fix documentation for the snapshot restore procedure on different topologyies Key: IGNITE-16517 URL: https://issues.apache.org/jira/browse/IGNITE-16517 Project: Ignite Issue Type: Bug Reporter: Maxim Muzafarov Assignee: Maxim Muzafarov Fix For: 2.12 https://ignite.apache.org/docs/latest/snapshots/snapshots#restoring-from-snapshot The *Restore On Cluster of Different Topology* topic needs to be updated father the IGNITE-14744 was merged. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16517) Fix documentation for the snapshot restore procedure on different topologyies
[ https://issues.apache.org/jira/browse/IGNITE-16517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-16517: - Ignite Flags: (was: Docs Required,Release Notes Required) > Fix documentation for the snapshot restore procedure on different topologyies > - > > Key: IGNITE-16517 > URL: https://issues.apache.org/jira/browse/IGNITE-16517 > Project: Ignite > Issue Type: Bug >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: docuentation > Fix For: 2.12 > > > https://ignite.apache.org/docs/latest/snapshots/snapshots#restoring-from-snapshot > The *Restore On Cluster of Different Topology* topic needs to be updated > father the IGNITE-14744 was merged. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16494) Query engine allows to insert rows with logically equal compound PK
[
https://issues.apache.org/jira/browse/IGNITE-16494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489706#comment-17489706
]
Ignite TC Bot commented on IGNITE-16494:
{panel:title=Branch: [pull/9808/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9808/head] Base: [master] : New Tests
(6)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Continuous Query 4{color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=6411036]]
* {color:#013220}IgniteCacheQuerySelfTestSuite6:
IgniteInsertNullableDuplicatesSqlTest.testInsertKeyWithNullKeyPartsDefaultCacheApi
- PASSED{color}
* {color:#013220}IgniteCacheQuerySelfTestSuite6:
IgniteInsertNullableDuplicatesSqlTest.testInsertKeyWithNullKeyParts -
PASSED{color}
* {color:#013220}IgniteCacheQuerySelfTestSuite6:
IgniteInsertNullableDuplicatesSqlTest.testInsertKeyWithNullKeys - PASSED{color}
* {color:#013220}IgniteCacheQuerySelfTestSuite6:
IgniteInsertNullableDuplicatesSqlTest.testInsertKeyWithNullKeyPartsDefault -
PASSED{color}
* {color:#013220}IgniteCacheQuerySelfTestSuite6:
IgniteInsertNullableDuplicatesSqlTest.testInsertKeyWithNullKeyParts2 -
PASSED{color}
* {color:#013220}IgniteCacheQuerySelfTestSuite6:
IgniteInsertNullableDuplicatesSqlTest.testInsertKeyWhenKeyIsNotSet -
PASSED{color}
{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6410302&buildTypeId=IgniteTests24Java8_RunAll]
> Query engine allows to insert rows with logically equal compound PK
> ---
>
> Key: IGNITE-16494
> URL: https://issues.apache.org/jira/browse/IGNITE-16494
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.11.1
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It's possible now to insert two logically equal yet physically different keys
> with SQL API into a table, that will bring indexes into inconsistent state.
> For example follow snippet will pass, although it should have fallen on the
> third statement:
> {code}
> create table test (id1 int, id2 int, val int, constraint primary key(id1,
> id2));
> insert into test (id1, id2, val) values (1, null, 1);
> insert into test (id1, val) values (1, 1); <-- should fail here because there
> is already exists such key, but it's
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16516) Fix documentations for TDE
Maksim Timonin created IGNITE-16516:
---
Summary: Fix documentations for TDE
Key: IGNITE-16516
URL: https://issues.apache.org/jira/browse/IGNITE-16516
Project: Ignite
Issue Type: Bug
Components: documentation
Affects Versions: 2.12
Reporter: Maksim Timonin
Assignee: Maksim Timonin
Fix For: 2.13
Since 2.12 encrypted snapshots are supported, and docs are irrelevant. Also TDE
is not a beta feature.
[https://ignite.apache.org/docs/latest/snapshots/snapshots]
{quote}Encrypted caches are not included in the snapshot.{quote}
[https://ignite.apache.org/docs/latest/security/tde]
{quote}No support for snapshots. Snapshots are not encrypted and it’s not
possible to recover from a snapshot that includes an encrypted table or
cache.{quote}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16390) Improvements of event listeners for SqlQueryProcessor
[ https://issues.apache.org/jira/browse/IGNITE-16390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Denis Chudov reassigned IGNITE-16390: - Assignee: Denis Chudov > Improvements of event listeners for SqlQueryProcessor > - > > Key: IGNITE-16390 > URL: https://issues.apache.org/jira/browse/IGNITE-16390 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > > Listeners for SqlQueryProcessor should rely on causality tokens while > handling notifications. > Listeners of SqlQueryProcessor should rely on the causality token futures to > finish all the logic that depends on other components or other listeners. > Therefore, this logic should be implemented in thenCompose blocks of > causality futures. > The listeners should be aware of the current state of the component and do > every action in order to change the current state to the state that the > component should have after applying the metastorage update. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15860) [Extensions] Automated RC preparation and testing at Apache TeamCity
[ https://issues.apache.org/jira/browse/IGNITE-15860?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489632#comment-17489632 ] Maxim Muzafarov commented on IGNITE-15860: -- I think prior to this task the following must be prepared in the ignite-extension repository: - create the release guide .md file describing the release process of an Ignite extension (e.g. create a new branch for extension, change the version from a snapshot to the release one in this branch, build a project using mvn); - add release scripts (e.g. maven assembly plugin) which will prepare binary, sources packages for the module being released (assume that the source package of the releases module contains only sources of this module); - add scripts that will sign binary and sources using the release manager credentials (e.g. maven sign plugin); - add scripts that will deploy artefacts to the maven staging repository; - add scripts for checking checksums, gpg; > [Extensions] Automated RC preparation and testing at Apache TeamCity > > > Key: IGNITE-15860 > URL: https://issues.apache.org/jira/browse/IGNITE-15860 > Project: Ignite > Issue Type: Task >Reporter: Amelchev Nikita >Assignee: Petr Ivanov >Priority: Major > Labels: ise > > Implement automated ignite-extensions RC preparation and testing at Apache > TeamCity. > The script should support: > - binary releases > - proper source package without not-releasing modules, dev-scripts, gitignore > - several modules release > - different modules versions -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16515) RocksDbSortedIndexStorageTest is flaky
Aleksandr Polovtcev created IGNITE-16515:
Summary: RocksDbSortedIndexStorageTest is flaky
Key: IGNITE-16515
URL: https://issues.apache.org/jira/browse/IGNITE-16515
Project: Ignite
Issue Type: Bug
Reporter: Aleksandr Polovtcev
Assignee: Aleksandr Polovtcev
RocksDbSortedIndexStorageTest has a method called
\{{shuffledRandomDefinitions}} which uses random booleans to filter columns
that are used to create an index. In rare cases all random booleans can be
{{false}} which will result in tests trying to create an index without any
columns, which is illegal.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-14871) Add cluster initialization commands to the Ignite CLI
[
https://issues.apache.org/jira/browse/IGNITE-14871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489613#comment-17489613
]
Roman Puchkovskiy commented on IGNITE-14871:
The CL interface is implemented a bit differently.
First, to pass a few node names, we repeat the option name, like this:
cluster init --node-endpoint ... --meta-storage-node node1 --meta-storage-node
node2 --cmg-node node3 --cmg-node node4
Second, the option names are now singular, not plural.
Third, the --meta-storage is now separated with a dash to 'meta' and 'storage'.
> Add cluster initialization commands to the Ignite CLI
> -
>
> Key: IGNITE-14871
> URL: https://issues.apache.org/jira/browse/IGNITE-14871
> Project: Ignite
> Issue Type: Task
> Components: networking
>Reporter: Vyacheslav Koptilin
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> According to the
> [IEP|https://cwiki.apache.org/confluence/display/IGNITE/IEP-77%3A+Node+Join+Protocol+and+Initialization],
> we are going to have some new CLI commands:
> h3. Cluster initialization
> h4. Proposed API
> {code:bash}
> ./ignite cluster init --node-endpoint=??? --metastorage-nodes=???
> [---cmg-nodes=???]
> {code}
> * {{--node-endpoint}} - address of the REST endpoint of the receiving node
> in host:port format
> * {{--metastorage-nodes}} - space-separated list of addresses of the nodes
> that will host the Metastorage Raft group. If the "-cmg-nodes" parameter is
> empty, the same nodes will also host the Cluster Management Raft group.
> * {{--cmg-nodes}} - space-separated list of addresses of the nodes that will
> host the Cluster Management Raft group (optional parameter)
> h4. Description
> The purpose of this command is to deliver the initial cluster settings. The
> recipient node should propagate this message to the specified nodes, so that
> they will start the corresponding Raft groups. In case some nodes are
> inaccessible or the Raft groups are already started, an error message should
> be returned and the command must fail.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16445) Always specify charset explicitly
[ https://issues.apache.org/jira/browse/IGNITE-16445?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489600#comment-17489600 ] Roman Puchkovskiy commented on IGNITE-16445: Thanks for your review > Always specify charset explicitly > - > > Key: IGNITE-16445 > URL: https://issues.apache.org/jira/browse/IGNITE-16445 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 1h > Remaining Estimate: 0h > > Calls like new String(byte[]), String#getBytes() and others that implicitly > use default charset are dangerous because we never know what charset is > chosen as a default for this particular JVM. > Even when the text we are encoding only contains ASCII characters, it could > be encoded differently by some charsets (like cp1140). > We could always mandate 'specify -Dfile.encoding=utf-8 when launching a JVM', > but it would make deployment a little bit difficult as the setting could be > easily overlooked. > It seems not too hard to always specify a charset in the code. > For the cases when it is the correct thing to use the system default charset, > it can be passed directly using Charset.defaultCharset(). > To make sure that we not forget it somewhere accidentally, we could use a > tool like Maven Modernizer plugin. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (IGNITE-16259) Improve detection of objects that cannot participate in object graph cycles
[ https://issues.apache.org/jira/browse/IGNITE-16259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy resolved IGNITE-16259. Resolution: Won't Do This task is not relevant anymore as we must write an object ID for any value that can have an identity (due to IGNITE-16298). > Improve detection of objects that cannot participate in object graph cycles > --- > > Key: IGNITE-16259 > URL: https://issues.apache.org/jira/browse/IGNITE-16259 > Project: Ignite > Issue Type: Improvement > Components: networking >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > Currently, only built-ins are considered to be immune to participating in > object graph cycles. But more classes are immune: for example, a class that > only contains primitive fields cannot participate in cycles. > Representation of a non-cycleable object is a bit more compact (as we do not > need to store object ID for it), so we can save a bit of space here. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16514) Loza#prepareRaftGroup contains incorrent javadoc and @Experimental tag
Kirill Gusakov created IGNITE-16514: --- Summary: Loza#prepareRaftGroup contains incorrent javadoc and @Experimental tag Key: IGNITE-16514 URL: https://issues.apache.org/jira/browse/IGNITE-16514 Project: Ignite Issue Type: Task Reporter: Kirill Gusakov Method from description marked as Experimental and has incorrect javadoc "IMPORTANT: DON'T USE". But these descriptions were created for another version with explicit timeout arguments. It seems, that we need to fix javadoc or roll back the old overloaded version and move these docs to it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16512) Change the style of named options in the CLI
[ https://issues.apache.org/jira/browse/IGNITE-16512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy reassigned IGNITE-16512: -- Assignee: (was: Roman Puchkovskiy) > Change the style of named options in the CLI > > > Key: IGNITE-16512 > URL: https://issues.apache.org/jira/browse/IGNITE-16512 > Project: Ignite > Issue Type: Improvement > Components: general >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > Some named CLI options may have multiple values. There are few different ways > to use such multi-valued options from the CLI: > # --nodes "one two three" (that is, put all the values in the same command > line argument) > # --nodes one two three (that is, put each value as a separate command line > argument) > # --node one --node two --node three (repeat the option name with each > value; please note that here the option name is in singular form) > A team-wide discussion was caried on in a Slack channel, and it was suggested > that we use option 2. But the existing commands (like 'module add ' with > --repo option) already use option 3. > The style needs to be changed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (IGNITE-16229) Improve unmarshalling of immutable containers in the User Object Serialization component
[ https://issues.apache.org/jira/browse/IGNITE-16229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy resolved IGNITE-16229. Resolution: Won't Do Currently, we have only two cases for which this might be used: SingletonList and Proxy. For both cases, our 'hacky' way works well, does not seem to cause any problems and it is very simple, so it seems that we can just leave it as is. List.of(...) and friends added in Java 9 are not a problem because their implementing classes use writeReplace()/readResolve() which we support, so everything just works. Hence, it looks like this task is simply not worth implementing as the 'correct and less hacky way' to implement it would also be slower at runtime (and produce more garbage) as it simply makes more work. > Improve unmarshalling of immutable containers in the User Object > Serialization component > > > Key: IGNITE-16229 > URL: https://issues.apache.org/jira/browse/IGNITE-16229 > Project: Ignite > Issue Type: Improvement > Components: networking >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > At the moment, we support just one type of immutable containers > (singletonList), but we'll probably want to support other types like > List.of(), Set.of() and so on. > Immutable built-in containers pose a challenge: on the one hand, they can > participate in cycles and hence need to be read in two phases (instantiate, > store reference, fill), but on the other hand, they cannot be modified after > instantiation. > Right now, we implemented a hack: we still read immutable containers in two > phases, but for filling them we have a custom code that breaks their > 'immutability' invariant and pushes the values by force via reflection to > fill such containers. It seems to work, but it's ugly and potentially > dangerous (as we are violating the immutability invariant). > There is another possibility. > # Handle all the values that are not built-in immutable containers in the > same way they are handled now > # For immutable containers, during instantiation phase, create mutable > placeholders instead of the immutable container instances themselves > # Such placeholders need to track the slots of other objects in the graph > that reference them > # They are filled normally on the 'fill' phase > # After the graph is read into memory, it consists of (mainly) normal > objects and placeholders; the placeholders need to be resolved and replaced > with proper immutable container values > # It is impossible to create a cycle of immutable containers (without using > hacks like Reflection), so we can find connectivity components of the graph > (each of such component will be a tree) and then instantiate immutable > containers from placeholders in the leaf-to-root order > # Placeholders need to be replaced with the instantiated immutable > containers in the graph; here, the knowledge about the set of slots which > reference a placeholder (mentioned in item 3) will be useful > # If we encounter a cycle comprised completely of immutable containers (such > cycle can only be creafted using some sort of a hack), we can either fail > with an exception or use a hack (reflection) to forge just one connection of > the cycle. > This is a hybrid approach of > * always having 'real' objects in the graph - which is not realistic when we > have immutable containers > * and always constructing a graph of placeholders first and then turning > them into real objects (this is what Spring does with Bean Definitions and > then Beans) - which seems to incur too much overhead, especially having in > mind that most of the objects are not immutable containers and hence do not > need placeholders to represent them in the intermediate graph -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16508) Travis check should be duplicated at TC
[
https://issues.apache.org/jira/browse/IGNITE-16508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov updated IGNITE-16508:
--
Description:
Travis is broken now (INFRA-22827), and should be at least duplicated at TC
Build step (sh) in TC
{code:java}
cd modules/ducktests/tests
tox -e codestyle,py38 || exit 1
{code}
was:
Travis is broken now (INFRA-22827), and should be at least duplicated at TC
Build step (sh) in TC
{code}
set -o nounset; set -o errexit; set -o pipefail; set -o errtrace; set -o
functrace
set -x
cd modules/ducktests/tests
tox -e codestyle,py38 || exit 1
{code}
> Travis check should be duplicated at TC
> ---
>
> Key: IGNITE-16508
> URL: https://issues.apache.org/jira/browse/IGNITE-16508
> Project: Ignite
> Issue Type: Improvement
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Travis is broken now (INFRA-22827), and should be at least duplicated at TC
> Build step (sh) in TC
> {code:java}
> cd modules/ducktests/tests
> tox -e codestyle,py38 || exit 1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16508) Travis check should be duplicated at TC
[
https://issues.apache.org/jira/browse/IGNITE-16508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489593#comment-17489593
]
Anton Vinogradov commented on IGNITE-16508:
---
New step added:
[https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_CheckCodeStyleDucktests?mode=builds]
As well as ducktests codestyle fixed
> Travis check should be duplicated at TC
> ---
>
> Key: IGNITE-16508
> URL: https://issues.apache.org/jira/browse/IGNITE-16508
> Project: Ignite
> Issue Type: Improvement
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Travis is broken now (INFRA-22827), and should be at least duplicated at TC
> Build step (sh) in TC
> {code}
> set -o nounset; set -o errexit; set -o pipefail; set -o errtrace; set -o
> functrace
> set -x
> cd modules/ducktests/tests
> tox -e codestyle,py38 || exit 1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (IGNITE-16508) Travis check should be duplicated at TC
[
https://issues.apache.org/jira/browse/IGNITE-16508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anton Vinogradov resolved IGNITE-16508.
---
Resolution: Fixed
> Travis check should be duplicated at TC
> ---
>
> Key: IGNITE-16508
> URL: https://issues.apache.org/jira/browse/IGNITE-16508
> Project: Ignite
> Issue Type: Improvement
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Travis is broken now (INFRA-22827), and should be at least duplicated at TC
> Build step (sh) in TC
> {code}
> set -o nounset; set -o errexit; set -o pipefail; set -o errtrace; set -o
> functrace
> set -x
> cd modules/ducktests/tests
> tox -e codestyle,py38 || exit 1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16513) Add an integration test for 'cluster init' CLI command
Roman Puchkovskiy created IGNITE-16513: -- Summary: Add an integration test for 'cluster init' CLI command Key: IGNITE-16513 URL: https://issues.apache.org/jira/browse/IGNITE-16513 Project: Ignite Issue Type: Improvement Components: general Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy Fix For: 3.0.0-alpha5 Currently, 'cluster init' command does not have an end-to-end test because the init functionality is still being developed in IGNITE-16471 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16512) Change the style of named options in the CLI
Roman Puchkovskiy created IGNITE-16512: -- Summary: Change the style of named options in the CLI Key: IGNITE-16512 URL: https://issues.apache.org/jira/browse/IGNITE-16512 Project: Ignite Issue Type: Improvement Components: general Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy Fix For: 3.0.0-alpha5 Some named CLI options may have multiple values. There are few different ways to use such multi-valued options from the CLI: # --nodes "one two three" (that is, put all the values in the same command line argument) # --nodes one two three (that is, put each value as a separate command line argument) # --node one --node two --node three (repeat the option name with each value; please note that here the option name is in singular form) A team-wide discussion was caried on in a Slack channel, and it was suggested that we use option 2. But the existing commands (like 'module add ' with --repo option) already use option 3. The style needs to be changed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16496) SSLException: closing inbound before receiving peer's close_notify
[
https://issues.apache.org/jira/browse/IGNITE-16496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kukushkin updated IGNITE-16496:
--
Summary: SSLException: closing inbound before receiving peer's close_notify
(was: SSLException: closing inbound before receiving peer's close_notify (TLS
1.2))
> SSLException: closing inbound before receiving peer's close_notify
> --
>
> Key: IGNITE-16496
> URL: https://issues.apache.org/jira/browse/IGNITE-16496
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.12
>Reporter: Alexey Kukushkin
>Priority: Major
> Labels: cggg
>
> Ignite nodes output the warning below on startup when TLS protocol v1.2 is
> used:
> {noformat}
> 2022-02-08 11:53:05.705 WARN 19384 --- [1:62095]-#4-#51]
> o.a.i.spi.discovery.tcp.TcpDiscoverySpi : Failed to shutdown socket: closing
> inbound before receiving peer's close_notify
> javax.net.ssl.SSLException: closing inbound before receiving peer's
> close_notify
>at
> java.base/sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl.java:745)
> ~[na:na]
>at
> java.base/sun.security.ssl.SSLSocketImpl.shutdownInput(SSLSocketImpl.java:724)
> ~[na:na]
>at
> org.apache.ignite.internal.util.IgniteUtils.close(IgniteUtils.java:4249)
> ~[ignite-core-2.12.0.jar!/:2.12.0]
>at
> org.apache.ignite.spi.discovery.tcp.ServerImpl$SocketReader.body(ServerImpl.java:7370)
> ~[ignite-core-2.12.0.jar!/:2.12.0]
>at org.apache.ignite.spi.IgniteSpiThread.run(IgniteSpiThread.java:58)
> ~[ignite-core-2.12.0.jar!/:2.12.0] {noformat}
> To reproduce the problem just start two server nodes with TLS v1.3 enabled
> and the warnings will be printed in the log before the cluster is formed.
> h3. h3. Analysis
> The problem _probably_ happens due to [this
> code|https://github.com/apache/ignite/blob/2.12.0/modules/core/src/main/java/org/apache/ignite/internal/util/IgniteUtils.java#L4426]
> calling {{Socket#shutdownInput()}} before receiving SSL {{close_notify}}
> alert, which TLS 1.2 is expecting (see [RFC
> 8446|https://datatracker.ietf.org/doc/html/rfc8446#section-6]). I guess the
> right approach to close an SSL socket is just calling {{Socke#close}}, which
> should properly wait/send a {{close_notify}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16511) Calcite engine. Move system properties constants to IgniteSystemProperties class
Aleksey Plekhanov created IGNITE-16511:
--
Summary: Calcite engine. Move system properties constants to
IgniteSystemProperties class
Key: IGNITE-16511
URL: https://issues.apache.org/jira/browse/IGNITE-16511
Project: Ignite
Issue Type: Task
Reporter: Aleksey Plekhanov
We have a set of system properties constants for the Calcite-based SQL engine,
which are placed in different classes and not documented:
{noformat}
IGNITE_CALCITE_EXEC_IN_BUFFER_SIZE
IGNITE_CALCITE_EXEC_BATCH_SIZE
IGNITE_CALCITE_EXEC_IO_BATCH_SIZE
IGNITE_CALCITE_EXEC_IO_BATCH_CNT
IGNITE_CALCITE_REL_JSON_PRETTY_PRINT{noformat}
They should be moved to {{IgniteSystemProperties}} class with a proper
{{@SystemProperty}} annotation.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15554) Add logic for assignment recalculation in case of replicas changes
[ https://issues.apache.org/jira/browse/IGNITE-15554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev updated IGNITE-15554: - Description: We need to provide the trigger when the number of partition replicas changes. At the moment, replicas is a table configuration. But at the same time, rebalance trigger mechanism assumes that changes triggered by metastore’s key change (IGNITE-16063). So, we need provide the bridge between configuration changes and metastore key, it can be: separate metastore key, which duplicate the field from configuration and mirror all configuration changes any better ways here… was: TBD (Phase 1) > Add logic for assignment recalculation in case of replicas changes > -- > > Key: IGNITE-15554 > URL: https://issues.apache.org/jira/browse/IGNITE-15554 > Project: Ignite > Issue Type: Task >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > > We need to provide the trigger when the number of partition replicas changes. > At the moment, replicas is a table configuration. But at the same time, > rebalance trigger mechanism assumes that changes triggered by metastore’s key > change (IGNITE-16063). So, we need provide the bridge between configuration > changes and metastore key, it can be: > separate metastore key, which duplicate the field from configuration and > mirror all configuration changes > any better ways here… -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-15554) Add logic for assignment recalculation in case of replicas changes
[ https://issues.apache.org/jira/browse/IGNITE-15554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev reassigned IGNITE-15554: Assignee: Mirza Aliev > Add logic for assignment recalculation in case of replicas changes > -- > > Key: IGNITE-15554 > URL: https://issues.apache.org/jira/browse/IGNITE-15554 > Project: Ignite > Issue Type: Task >Reporter: Alexander Lapin >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > > We need to provide the trigger when the number of partition replicas changes. > At the moment, replicas is a table configuration. But at the same time, > rebalance trigger mechanism assumes that changes triggered by metastore’s key > change (IGNITE-16063). So, we need provide the bridge between configuration > changes and metastore key, it can be: > separate metastore key, which duplicate the field from configuration and > mirror all configuration changes > any better ways here… -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16133) IndexQuery should check indexes for rebuild
[ https://issues.apache.org/jira/browse/IGNITE-16133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489525#comment-17489525 ] Maksim Timonin commented on IGNITE-16133: - duplicate of IGNITE-16452 > IndexQuery should check indexes for rebuild > --- > > Key: IGNITE-16133 > URL: https://issues.apache.org/jira/browse/IGNITE-16133 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-71 > > IndexQuery doesn't check that index it runs over to is rebuilding. Then query > result can be inconsistent, as it returns only part of result. > > IndexQuery should check index status and throw an exception if index is > concurrently rebuilding. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (IGNITE-16133) IndexQuery should check indexes for rebuild
[ https://issues.apache.org/jira/browse/IGNITE-16133?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin resolved IGNITE-16133. - Resolution: Duplicate > IndexQuery should check indexes for rebuild > --- > > Key: IGNITE-16133 > URL: https://issues.apache.org/jira/browse/IGNITE-16133 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-71 > > IndexQuery doesn't check that index it runs over to is rebuilding. Then query > result can be inconsistent, as it returns only part of result. > > IndexQuery should check index status and throw an exception if index is > concurrently rebuilding. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16510) Calcite engine. Support "keep binary" flag
Aleksey Plekhanov created IGNITE-16510: -- Summary: Calcite engine. Support "keep binary" flag Key: IGNITE-16510 URL: https://issues.apache.org/jira/browse/IGNITE-16510 Project: Ignite Issue Type: New Feature Reporter: Aleksey Plekhanov The "keep binary" flag is currently ignored by the Calcite-based SQL engine and there is no way to return a deserialized object: all POJO returned in binary format. We should support the "keep binary" flag and deserialize objects if needed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16509) Calcite engine. Support OTHER data type
Aleksey Plekhanov created IGNITE-16509:
--
Summary: Calcite engine. Support OTHER data type
Key: IGNITE-16509
URL: https://issues.apache.org/jira/browse/IGNITE-16509
Project: Ignite
Issue Type: New Feature
Reporter: Aleksey Plekhanov
Table with {{OTHER}} (Object) data type can be created by H2-based SQL engine:
{noformat}
CREATE TABLE t(val OTHER)
{noformat}
But such a data type is not supported by Calcite-based SQL engine (at least in
DDL)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16452) IndexQuery can run on non-ready dynamically created index or rebuilding indexes
[ https://issues.apache.org/jira/browse/IGNITE-16452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-16452: Labels: IEP-49 IEP-71 (was: IEP-71) > IndexQuery can run on non-ready dynamically created index or rebuilding > indexes > --- > > Key: IGNITE-16452 > URL: https://issues.apache.org/jira/browse/IGNITE-16452 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.12 >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-49, IEP-71 > Fix For: 2.13 > > Time Spent: 10m > Remaining Estimate: 0h > > IndexProcessor register dynamically created index earlier than fill it with > data. > Then IndexQuery can reach the index before it actually ready. So we need to > restrict access for such indexes. > The same behavior is for rebuilding indexes. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16452) IndexQuery can run on non-ready dynamically created index or rebuilding indexes
[ https://issues.apache.org/jira/browse/IGNITE-16452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-16452: Summary: IndexQuery can run on non-ready dynamically created index or rebuilding indexes (was: IndexQuery can run on non-ready dynamically created index) > IndexQuery can run on non-ready dynamically created index or rebuilding > indexes > --- > > Key: IGNITE-16452 > URL: https://issues.apache.org/jira/browse/IGNITE-16452 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.12 >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-71 > Fix For: 2.13 > > Time Spent: 10m > Remaining Estimate: 0h > > IndexProcessor register dynamically created index earlier than fill it with > data. > Then IndexQuery can reach the index before it actually ready. So we need to > restrict access for such indexes. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16452) IndexQuery can run on non-ready dynamically created index or rebuilding indexes
[ https://issues.apache.org/jira/browse/IGNITE-16452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-16452: Description: IndexProcessor register dynamically created index earlier than fill it with data. Then IndexQuery can reach the index before it actually ready. So we need to restrict access for such indexes. The same behavior is for rebuilding indexes. was: IndexProcessor register dynamically created index earlier than fill it with data. Then IndexQuery can reach the index before it actually ready. So we need to restrict access for such indexes. > IndexQuery can run on non-ready dynamically created index or rebuilding > indexes > --- > > Key: IGNITE-16452 > URL: https://issues.apache.org/jira/browse/IGNITE-16452 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.12 >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-71 > Fix For: 2.13 > > Time Spent: 10m > Remaining Estimate: 0h > > IndexProcessor register dynamically created index earlier than fill it with > data. > Then IndexQuery can reach the index before it actually ready. So we need to > restrict access for such indexes. > The same behavior is for rebuilding indexes. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16483) Improve ComputeGridMonitor test coverage
[ https://issues.apache.org/jira/browse/IGNITE-16483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-16483: - Description: Fix flaky *ComputeJobChangePriorityTest#testChangeTaskPriorityAttribute* The problem is in the test itself, there could be a rare race between completing a compute task and waiting for its attribute, so it was enough to add task completion after receiving the expected attribute. Add tests for *ComputeGridMonitor* in case of a client node. was: Fix flaky *ComputeJobChangePriorityTest#testChangeTaskPriorityAttribute* The problem is in the test itself, there could be a rare race between completing a compute task and waiting for its attribute, so it was enough to add task completion after receiving the expected attribute. Add tests for monitors in case of a client node. > Improve ComputeGridMonitor test coverage > > > Key: IGNITE-16483 > URL: https://issues.apache.org/jira/browse/IGNITE-16483 > Project: Ignite > Issue Type: Bug > Components: compute >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Minor > Fix For: 2.13 > > Time Spent: 10m > Remaining Estimate: 0h > > Fix flaky *ComputeJobChangePriorityTest#testChangeTaskPriorityAttribute* > The problem is in the test itself, there could be a rare race between > completing a compute task and waiting for its attribute, so it was enough to > add task completion after receiving the expected attribute. > Add tests for *ComputeGridMonitor* in case of a client node. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16483) Improve ComputeGridMonitor test coverage
[ https://issues.apache.org/jira/browse/IGNITE-16483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-16483: - Description: Fix flaky *ComputeJobChangePriorityTest#testChangeTaskPriorityAttribute* The problem is in the test itself, there could be a rare race between completing a compute task and waiting for its attribute, so it was enough to add task completion after receiving the expected attribute. Add tests for monitors in case of a client node. was: Fix flaky *ComputeJobChangePriorityTest#testChangeTaskPriorityAttribute* The problem is in the test itself, there could be a rare race between completing a compute task and waiting for its attribute, so it was enough to add task completion after receiving the expected attribute. > Improve ComputeGridMonitor test coverage > > > Key: IGNITE-16483 > URL: https://issues.apache.org/jira/browse/IGNITE-16483 > Project: Ignite > Issue Type: Bug > Components: compute >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Minor > Fix For: 2.13 > > Time Spent: 10m > Remaining Estimate: 0h > > Fix flaky *ComputeJobChangePriorityTest#testChangeTaskPriorityAttribute* > The problem is in the test itself, there could be a rare race between > completing a compute task and waiting for its attribute, so it was enough to > add task completion after receiving the expected attribute. > Add tests for monitors in case of a client node. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16483) Improve ComputeGridMonitor test coverage
[ https://issues.apache.org/jira/browse/IGNITE-16483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-16483: - Summary: Improve ComputeGridMonitor test coverage (was: Fix flaky ComputeJobChangePriorityTest#testChangeTaskPriorityAttribute) > Improve ComputeGridMonitor test coverage > > > Key: IGNITE-16483 > URL: https://issues.apache.org/jira/browse/IGNITE-16483 > Project: Ignite > Issue Type: Bug > Components: compute >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Minor > Fix For: 2.13 > > Time Spent: 10m > Remaining Estimate: 0h > > Fix flaky *ComputeJobChangePriorityTest#testChangeTaskPriorityAttribute* > The problem is in the test itself, there could be a rare race between > completing a compute task and waiting for its attribute, so it was enough to > add task completion after receiving the expected attribute. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16508) Travis check should be duplicated at TC
[
https://issues.apache.org/jira/browse/IGNITE-16508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky updated IGNITE-16508:
-
Description:
Travis is broken now (INFRA-22827), and should be at least duplicated at TC
Build step (sh) in TC
{code}
set -o nounset; set -o errexit; set -o pipefail; set -o errtrace; set -o
functrace
set -x
cd modules/ducktests/tests
tox -e codestyle,py38 || exit 1
{code}
was:Travis is broken now (INFRA-22827), and should be at least duplicated at
TC
> Travis check should be duplicated at TC
> ---
>
> Key: IGNITE-16508
> URL: https://issues.apache.org/jira/browse/IGNITE-16508
> Project: Ignite
> Issue Type: Improvement
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
>
> Travis is broken now (INFRA-22827), and should be at least duplicated at TC
> Build step (sh) in TC
> {code}
> set -o nounset; set -o errexit; set -o pipefail; set -o errtrace; set -o
> functrace
> set -x
> cd modules/ducktests/tests
> tox -e codestyle,py38 || exit 1
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16508) Travis check should be duplicated at TC
Anton Vinogradov created IGNITE-16508: - Summary: Travis check should be duplicated at TC Key: IGNITE-16508 URL: https://issues.apache.org/jira/browse/IGNITE-16508 Project: Ignite Issue Type: Improvement Reporter: Anton Vinogradov Assignee: Anton Vinogradov Travis is broken now (INFRA-22827), and should be at least duplicated at TC -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16507) Calcite engine. Redundant sort node when rewriting index scan on index rebuild
Aleksey Plekhanov created IGNITE-16507:
--
Summary: Calcite engine. Redundant sort node when rewriting index
scan on index rebuild
Key: IGNITE-16507
URL: https://issues.apache.org/jira/browse/IGNITE-16507
Project: Ignite
Issue Type: Improvement
Reporter: Aleksey Plekhanov
When the query plan has an index scan, but the index is rebuilding we rewrite
this scan to the chain of table scan/sort/spool/project nodes (see
IGNITE-16111). In some cases sort node is redundant, but still created, for
example, when index scan is used only for filtering:
{noformat}
SELECT * FROM emp WHERE dep_id = 10
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-13389) Append additional settings to obtain full stack trace on thin client side if an error occurs on server side.
[
https://issues.apache.org/jira/browse/IGNITE-13389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489504#comment-17489504
]
Evgeny Stanilovsky commented on IGNITE-13389:
-
I have no time for this issue, possibly someone could proceed with it.
[~northdragon], [~ivandasch]
> Append additional settings to obtain full stack trace on thin client side if
> an error occurs on server side.
>
>
> Key: IGNITE-13389
> URL: https://issues.apache.org/jira/browse/IGNITE-13389
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 2.8.1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ise
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Some server side errors have deeply nested _suppressed_ or _caused by_ errors
> which contains informative messages for further problem recognition. Possible
> such mechanism need to be disabled on production environment. Example of non
> informative error on client side:
> {noformat}
> org.apache.ignite.internal.client.thin.ClientServerError: Ignite failed to
> process request [1]: Failed to update keys (retry update if possible).: [1]
> (server status code [1])
> {noformat}
> but full stack holds the root case:
> {noformat}
> Caused by: class
> org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException:
> Failed to update keys (retry update if possible).: [1]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:397)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2567)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2544)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1316)
> ... 13 more
> Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to
> update keys.
> ... 23 more
> Suppressed: class org.apache.ignite.IgniteCheckedException:
> Runtime failure on search row: SearchRow
> ... 25 more
> Caused by: class org.apache.ignite.IgniteCheckedException:
> org.apache.ignite.internal.binary.BinaryObjectImpl cannot be cast to
> org.apache.ignite.client.IgniteBinaryTest$ThinBinaryValue <-- here !!!
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.update(GridCacheMapEntry.java:6379)
> ... 30 more
> {noformat}
> looks like it would be useful to have additional setting in
> ThinClientConfiguration#showFullStackOnClientSide configured both as direct
> setting and through JMX (ClientProcessorMXBean#showFullStackOnClientSide).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-13389) Append additional settings to obtain full stack trace on thin client side if an error occurs on server side.
[
https://issues.apache.org/jira/browse/IGNITE-13389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky reassigned IGNITE-13389:
---
Assignee: (was: Evgeny Stanilovsky)
> Append additional settings to obtain full stack trace on thin client side if
> an error occurs on server side.
>
>
> Key: IGNITE-13389
> URL: https://issues.apache.org/jira/browse/IGNITE-13389
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 2.8.1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ise
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Some server side errors have deeply nested _suppressed_ or _caused by_ errors
> which contains informative messages for further problem recognition. Possible
> such mechanism need to be disabled on production environment. Example of non
> informative error on client side:
> {noformat}
> org.apache.ignite.internal.client.thin.ClientServerError: Ignite failed to
> process request [1]: Failed to update keys (retry update if possible).: [1]
> (server status code [1])
> {noformat}
> but full stack holds the root case:
> {noformat}
> Caused by: class
> org.apache.ignite.internal.processors.cache.CachePartialUpdateCheckedException:
> Failed to update keys (retry update if possible).: [1]
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.onPrimaryError(GridNearAtomicAbstractUpdateFuture.java:397)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2567)
> at
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2544)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1316)
> ... 13 more
> Suppressed: class org.apache.ignite.IgniteCheckedException: Failed to
> update keys.
> ... 23 more
> Suppressed: class org.apache.ignite.IgniteCheckedException:
> Runtime failure on search row: SearchRow
> ... 25 more
> Caused by: class org.apache.ignite.IgniteCheckedException:
> org.apache.ignite.internal.binary.BinaryObjectImpl cannot be cast to
> org.apache.ignite.client.IgniteBinaryTest$ThinBinaryValue <-- here !!!
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.update(GridCacheMapEntry.java:6379)
> ... 30 more
> {noformat}
> looks like it would be useful to have additional setting in
> ThinClientConfiguration#showFullStackOnClientSide configured both as direct
> setting and through JMX (ClientProcessorMXBean#showFullStackOnClientSide).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-14740) Add multiple python versions on TC agents for testing pyignite
[
https://issues.apache.org/jira/browse/IGNITE-14740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489488#comment-17489488
]
Anton Vinogradov commented on IGNITE-14740:
---
[~vveider], could you please schedule this task for the nearest future.
Currently, we are unable to check Python using the Travis (see INFRA-22827),
so, we need to relocate this check to TeamCity.
> Add multiple python versions on TC agents for testing pyignite
> --
>
> Key: IGNITE-14740
> URL: https://issues.apache.org/jira/browse/IGNITE-14740
> Project: Ignite
> Issue Type: New Feature
> Components: python, thin client
>Reporter: Ivan Daschinsky
>Assignee: Petr Ivanov
>Priority: Major
> Labels: python, teamcity
>
> In order to test {{pyignite}} against different python versions, I suggests
> followings
> 1. Install [pyenv|https://github.com/pyenv/pyenv]
> 2. Install through {{pyenv}} different python versions (3.6, 3.7, 3.8, 3.9)
> Before invoking {{tox}}, script should invoke {{pyenv init --path}} and
> {{pyenv shell}} with specific python version.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16483) Fix flaky ComputeJobChangePriorityTest#testChangeTaskPriorityAttribute
[ https://issues.apache.org/jira/browse/IGNITE-16483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-16483: - Description: Fix flaky *ComputeJobChangePriorityTest#testChangeTaskPriorityAttribute* The problem is in the test itself, there could be a rare race between completing a compute task and waiting for its attribute, so it was enough to add task completion after receiving the expected attribute. was: Fix flaky ComputeJobChangePriorityTest#testChangeTaskPriorityAttribute The problem is in the test itself, there could be a rare race between completing a compute task and waiting for its attribute, so it was enough to add task completion after receiving the expected attribute. > Fix flaky ComputeJobChangePriorityTest#testChangeTaskPriorityAttribute > -- > > Key: IGNITE-16483 > URL: https://issues.apache.org/jira/browse/IGNITE-16483 > Project: Ignite > Issue Type: Bug > Components: compute >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Minor > Fix For: 2.13 > > > Fix flaky *ComputeJobChangePriorityTest#testChangeTaskPriorityAttribute* > The problem is in the test itself, there could be a rare race between > completing a compute task and waiting for its attribute, so it was enough to > add task completion after receiving the expected attribute. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16483) Fix flaky ComputeJobChangePriorityTest#testChangeTaskPriorityAttribute
[ https://issues.apache.org/jira/browse/IGNITE-16483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-16483: - Description: Fix flaky ComputeJobChangePriorityTest#testChangeTaskPriorityAttribute The problem is in the test itself, there could be a rare race between completing a compute task and waiting for its attribute, so it was enough to add task completion after receiving the expected attribute. was:Fix flaky ComputeJobChangePriorityTest#testChangeTaskPriorityAttribute > Fix flaky ComputeJobChangePriorityTest#testChangeTaskPriorityAttribute > -- > > Key: IGNITE-16483 > URL: https://issues.apache.org/jira/browse/IGNITE-16483 > Project: Ignite > Issue Type: Bug > Components: compute >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Minor > Fix For: 2.13 > > > Fix flaky ComputeJobChangePriorityTest#testChangeTaskPriorityAttribute > The problem is in the test itself, there could be a rare race between > completing a compute task and waiting for its attribute, so it was enough to > add task completion after receiving the expected attribute. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15710) .NET: Some tests fail on Windows and net461
[ https://issues.apache.org/jira/browse/IGNITE-15710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-15710: Description: The following tests fail on Windows with .NET 4.6.1 and were disabled in IGNITE-15504 with conditional compilation: * DataStreamerClientTest.TestFlushThrowsOnCacheStoreException * PartitionAwarenessTest.CacheGet_NewNodeEnteredTopology_RequestIsRoutedToNewNode * ClientClusterDiscoveryTestsNoLocalhost.TestClientWithOneEndpointDiscoversAllServers * PartitionLossTest.TestReadWriteSafe Re-enable the tests and fix them. was: The following tests fail on Windows with .NET 4.6.1 and were disabled in IGNITE-15504 with conditional compilation: * DataStreamerClientTest.TestFlushThrowsOnCacheStoreException * PartitionAwarenessTest.CacheGet_NewNodeEnteredTopology_RequestIsRoutedToNewNode * ClientClusterDiscoveryTestsNoLocalhost.TestClientWithOneEndpointDiscoversAllServers Re-enable the tests and fix them. > .NET: Some tests fail on Windows and net461 > --- > > Key: IGNITE-15710 > URL: https://issues.apache.org/jira/browse/IGNITE-15710 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.11 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Minor > Labels: .NET > Fix For: 2.13 > > > The following tests fail on Windows with .NET 4.6.1 and were disabled in > IGNITE-15504 with conditional compilation: > * DataStreamerClientTest.TestFlushThrowsOnCacheStoreException > * > PartitionAwarenessTest.CacheGet_NewNodeEnteredTopology_RequestIsRoutedToNewNode > * > ClientClusterDiscoveryTestsNoLocalhost.TestClientWithOneEndpointDiscoversAllServers > * PartitionLossTest.TestReadWriteSafe > Re-enable the tests and fix them. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16377) Notification listeners of TableManager should rely on causality tokens when referring to dependee components
[ https://issues.apache.org/jira/browse/IGNITE-16377?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov reassigned IGNITE-16377: -- Assignee: Vladislav Pyatkov > Notification listeners of TableManager should rely on causality tokens when > referring to dependee components > > > Key: IGNITE-16377 > URL: https://issues.apache.org/jira/browse/IGNITE-16377 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > While handling the notifications, listeners should rely on the fact that the > components that they depend on, won’t return stale or inconsistent data. It > should be guaranteed by causality tokens mechanism. > Listeners of TableManager should rely on the causality token futures to > finish all the logic that depends on other components or other listeners. > Therefore, this logic should be implemented in thenCompose blocks of > causality futures. > The listeners should be aware of the current state of the component and do > every action in order to change the current state to the state that the > component should have after applying the metastorage update. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-11402) SQL: Add ability to specify inline size of PK and affinity key indexes from CREATE TABLE
[
https://issues.apache.org/jira/browse/IGNITE-11402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489461#comment-17489461
]
Taras Ledkov commented on IGNITE-11402:
---
*Final decision:*
- inline size of primary and affinity sorted indexes can be defined only by
CREATE TABLE command.
- {{QueryEntity}} cannot be changed, {{unwrapPk}} property cannot be set up by
public API because a lot of compatibility issues are discovered.
> SQL: Add ability to specify inline size of PK and affinity key indexes from
> CREATE TABLE
>
>
> Key: IGNITE-11402
> URL: https://issues.apache.org/jira/browse/IGNITE-11402
> Project: Ignite
> Issue Type: Task
> Components: sql
>Reporter: Vladimir Ozerov
>Assignee: Taras Ledkov
>Priority: Major
> Labels: newbie
> Fix For: 2.13
>
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Currently it is not possible to set inline size for automatically created
> indexes easily. We need to make sure that user has a convenient way to set
> them both programmatically and from DDL.
> Start point for automatically created indexes is
> org.apache.ignite.internal.processors.query.h2.H2TableDescriptor#createSystemIndexes
> where passed parameter inlineSize as -1 for
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing#createSortedIndex
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-11402) SQL: Add ability to specify inline size of PK and affinity key indexes from CREATE TABLE
[ https://issues.apache.org/jira/browse/IGNITE-11402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Taras Ledkov updated IGNITE-11402: -- Summary: SQL: Add ability to specify inline size of PK and affinity key indexes from CREATE TABLE (was: SQL: Add ability to specify inline size of PK and affinity key indexes from CREATE TABLE and QueryEntity) > SQL: Add ability to specify inline size of PK and affinity key indexes from > CREATE TABLE > > > Key: IGNITE-11402 > URL: https://issues.apache.org/jira/browse/IGNITE-11402 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Vladimir Ozerov >Assignee: Taras Ledkov >Priority: Major > Labels: newbie > Fix For: 2.13 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > Currently it is not possible to set inline size for automatically created > indexes easily. We need to make sure that user has a convenient way to set > them both programmatically and from DDL. > Start point for automatically created indexes is > org.apache.ignite.internal.processors.query.h2.H2TableDescriptor#createSystemIndexes > where passed parameter inlineSize as -1 for > org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing#createSortedIndex -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16207) JDBC driver for 3.0: Calcite throws class cast exception
[ https://issues.apache.org/jira/browse/IGNITE-16207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich reassigned IGNITE-16207: -- Assignee: Vladimir Ermakov > JDBC driver for 3.0: Calcite throws class cast exception > > > Key: IGNITE-16207 > URL: https://issues.apache.org/jira/browse/IGNITE-16207 > Project: Ignite > Issue Type: New Feature > Components: jdbc >Reporter: Vladimir Ermakov >Assignee: Vladimir Ermakov >Priority: Blocker > Labels: ignite-3 > > Calcite throws > java.lang.ClassCastException: class java.lang.String cannot be cast to class > java.lang.Integer (java.lang.String and java.lang.Integer are in module > java.base of loader 'bootstrap') > when > ItJdbcComplexDmlDdlSelfTest#testCreateSelectDrop() test running after > ItJdbcInsertStatementSelfTest#testDuplicateKeys(). > However, single run passed correctly. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16071) Read Repair futures should be rewritten to use wait-free sync instead of synchronized
[ https://issues.apache.org/jira/browse/IGNITE-16071?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-16071: -- Reviewer: Maksim Timonin > Read Repair futures should be rewritten to use wait-free sync instead of > synchronized > - > > Key: IGNITE-16071 > URL: https://issues.apache.org/jira/browse/IGNITE-16071 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Vinogradov >Assignee: Anton Vinogradov >Priority: Major > Labels: iep-31 > Fix For: 2.13 > > Time Spent: 10m > Remaining Estimate: 0h > > Read Repair was implemented as a PoC, so synchronized sync was suitable, but > now this should be replaced with CompoundFuture logic. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16071) Read Repair futures should be rewritten to use wait-free sync instead of synchronized
[
https://issues.apache.org/jira/browse/IGNITE-16071?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489437#comment-17489437
]
Ignite TC Bot commented on IGNITE-16071:
{panel:title=Branch: [pull/9807/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9807/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6408784&buildTypeId=IgniteTests24Java8_RunAll]
> Read Repair futures should be rewritten to use wait-free sync instead of
> synchronized
> -
>
> Key: IGNITE-16071
> URL: https://issues.apache.org/jira/browse/IGNITE-16071
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: iep-31
> Fix For: 2.13
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Read Repair was implemented as a PoC, so synchronized sync was suitable, but
> now this should be replaced with CompoundFuture logic.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (IGNITE-16484) sqlOnheapCacheEnabled leads to B+Tree corruption
[
https://issues.apache.org/jira/browse/IGNITE-16484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich resolved IGNITE-16484.
Resolution: Duplicate
> sqlOnheapCacheEnabled leads to B+Tree corruption
>
>
> Key: IGNITE-16484
> URL: https://issues.apache.org/jira/browse/IGNITE-16484
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.12
>Reporter: Ilya Kazakov
>Priority: Major
>
> This code leads to B+Tree corruption:
> {code:java}
> public static void main(String[] args) {
> IgniteConfiguration cfg = new IgniteConfiguration()
> .setCacheConfiguration(new CacheConfiguration()
> .setSqlOnheapCacheEnabled(true)
> .setName("PERSON")
> .setIndexedTypes(PersonKey.class, Integer.class));
> Ignite ignite = Ignition.start(cfg);
> try (IgniteCache cache = ignite.cache("PERSON")) {
> for (int i = 0; i < Integer.MAX_VALUE; i++) {
> cache.put(new PersonKey(i), i);
> if (i % 100 == 0)
> System.out.println(i);
> }
> }
> }
> private static class PersonKey {
> @QuerySqlField
> private long id;
> public PersonKey(long id) {
> this.id = id;
> }
> }{code}
> {code:java}
> class
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
> B+Tree is corrupted [groupId=-1938387115, pageIds=[844420635166787],
> cacheId=-1938387115, cacheName=PERSON, indexName=_key_PK, msg=Runtime failure
> on row: Row@6c2ed0cd[ key: org.apache.ignite.examples.CacheStore$PersonKey
> [idHash=2107543287, hash=-1581735888, id=4870], val: 4870 ][ ]]
> at
> org.apache.ignite.internal.cache.query.index.sorted.inline.InlineIndexTree.corruptedTreeException(InlineIndexTree.java:585)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.doPut(BPlusTree.java:2572)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.putx(BPlusTree.java:2512)
> at
> org.apache.ignite.internal.cache.query.index.sorted.inline.InlineIndexImpl.putx(InlineIndexImpl.java:265)
> at
> org.apache.ignite.internal.cache.query.index.sorted.inline.InlineIndexImpl.onUpdate(InlineIndexImpl.java:247)
> at
> org.apache.ignite.internal.cache.query.index.IndexProcessor.updateIndex(IndexProcessor.java:452)
> at
> org.apache.ignite.internal.cache.query.index.IndexProcessor.updateIndexes(IndexProcessor.java:295)
> at
> org.apache.ignite.internal.cache.query.index.IndexProcessor.store(IndexProcessor.java:142)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.store(GridQueryProcessor.java:2548)
> at
> org.apache.ignite.internal.processors.cache.query.GridCacheQueryManager.store(GridCacheQueryManager.java:422)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.finishUpdate(IgniteCacheOffheapManagerImpl.java:2674)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1750)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1725)
> at
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:449)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:2331)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2541)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:2004)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1821)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1694)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:300)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:481)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:441)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:249)
> at
> org.apache.ignite.internal.process
[jira] [Commented] (IGNITE-16363) Provide a guarantee of completeness of pre-recovery actions
[ https://issues.apache.org/jira/browse/IGNITE-16363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17489367#comment-17489367 ] Vladislav Pyatkov commented on IGNITE-16363: LGTM > Provide a guarantee of completeness of pre-recovery actions > --- > > Key: IGNITE-16363 > URL: https://issues.apache.org/jira/browse/IGNITE-16363 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > > We need to be sure that recovery should perform on the node after it has > joined physical topology and has been validated via node join protocol. > Necessary prerequisites for the recovery start are following: > * the node has retrieved the information and metastorage group from Vault; > * the node has received a join response in case of non-standalone mode, > meaning that the node is validated and is allowed to join the cluster. This > step can be mocked for now; > * all components have started and subscribed on configuration updates and > events. After this, notifications should be allowed and the recovery actually > starts. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16506) Modernizer plugin does not find any violations during the build even if they exist
Roman Puchkovskiy created IGNITE-16506: -- Summary: Modernizer plugin does not find any violations during the build even if they exist Key: IGNITE-16506 URL: https://issues.apache.org/jira/browse/IGNITE-16506 Project: Ignite Issue Type: Bug Components: build Reporter: Roman Puchkovskiy Assignee: Petr Ivanov Fix For: 3.0.0-alpha5 If I add the following code in any java class (except the excluded packages) String s = new String(new byte[0]); then the modernizer plugin should fail the build, but the build finishes successfully. I build using 'mvn clean verify -DskipTests'. -- This message was sent by Atlassian Jira (v8.20.1#820001)
