[jira] [Updated] (IGNITE-16501) TX Recovery protocol in Cockroach in case the tx coordinator failure
[ https://issues.apache.org/jira/browse/IGNITE-16501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16501: - Fix Version/s: (was: 3.0.0-alpha5) > TX Recovery protocol in Cockroach in case the tx coordinator failure > > > Key: IGNITE-16501 > URL: https://issues.apache.org/jira/browse/IGNITE-16501 > Project: Ignite > Issue Type: Task >Reporter: Vyacheslav Koptilin >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3 > Attachments: Cockroach transaction status recovery.pdf > > > The flowchart [^Cockroach transaction status recovery.pdf] describe > transaction recovery if txn coordinator was failed. > Need to investigate other failures: a txn record leaseholder fail, a write > intent leaseholder fail and etc. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17142) Docs: Review the AI 3.0.0 Alpha 5 documentation
[ https://issues.apache.org/jira/browse/IGNITE-17142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita A. Safonov updated IGNITE-17142: --- Description: We need to check the new sections throughout the documentation. (was: We need to change the version of the new Alpha release throughout the documentation.) > Docs: Review the AI 3.0.0 Alpha 5 documentation > --- > > Key: IGNITE-17142 > URL: https://issues.apache.org/jira/browse/IGNITE-17142 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 3.0.0-alpha5 >Reporter: Nikita A. Safonov >Assignee: Nikita A. Safonov >Priority: Major > Labels: docuentation, documentaion, documentation > Fix For: 3.0.0-alpha5 > > > We need to check the new sections throughout the documentation. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17142) Docs: Review the AI 3.0.0 Alpha 5 documentation
[ https://issues.apache.org/jira/browse/IGNITE-17142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikita A. Safonov updated IGNITE-17142: --- Summary: Docs: Review the AI 3.0.0 Alpha 5 documentation (was: Docs: Change AI Alpha 4 version to AI Alpha 5) > Docs: Review the AI 3.0.0 Alpha 5 documentation > --- > > Key: IGNITE-17142 > URL: https://issues.apache.org/jira/browse/IGNITE-17142 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 3.0.0-alpha5 >Reporter: Nikita A. Safonov >Assignee: Nikita A. Safonov >Priority: Major > Labels: docuentation, documentaion, documentation > Fix For: 3.0.0-alpha5 > > > We need to change the version of the new Alpha release throughout the > documentation. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-17142) Docs: Change AI Alpha 4 version to AI Alpha 5
Nikita A. Safonov created IGNITE-17142: -- Summary: Docs: Change AI Alpha 4 version to AI Alpha 5 Key: IGNITE-17142 URL: https://issues.apache.org/jira/browse/IGNITE-17142 Project: Ignite Issue Type: Task Components: documentation Affects Versions: 3.0.0-alpha5 Reporter: Nikita A. Safonov Assignee: Nikita A. Safonov Fix For: 3.0.0-alpha5 We need to change the version of the new Alpha release throughout the documentation. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17139) It is impossible to dynamically configure a RocksDB data region
[
https://issues.apache.org/jira/browse/IGNITE-17139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Semyon Danilov updated IGNITE-17139:
Reviewer: Semyon Danilov
> It is impossible to dynamically configure a RocksDB data region
> ---
>
> Key: IGNITE-17139
> URL: https://issues.apache.org/jira/browse/IGNITE-17139
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> It is currently impossible to create a RocksDB data region (e.g. through the
> Ignite CLI) and use it in a CREATE TABLE statement. The reason for this is
> that {{RocksDbStorageEngine}} is missing a configuration listener that will
> register new data regions.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-17114) Idle_verify must print and compare full partition counter state instead of just LWM
[
https://issues.apache.org/jira/browse/IGNITE-17114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17551756#comment-17551756
]
Ignite TC Bot commented on IGNITE-17114:
{panel:title=Branch: [pull/10071/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10071/head] Base: [master] : New Tests
(6)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Control Utility (Zookeeper){color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=6617716]]
* {color:#013220}ZookeeperIgniteControlUtilityTestSuite:
GridCommandHandlerTest.testCacheIdleVerifyChecksGapsTx - PASSED{color}
* {color:#013220}ZookeeperIgniteControlUtilityTestSuite:
GridCommandHandlerTest.testCacheIdleVerifyChecksGapsAtomic - PASSED{color}
{color:#8b}Control Utility{color} [[tests
4|https://ci.ignite.apache.org/viewLog.html?buildId=6618051]]
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerTest.testCacheIdleVerifyChecksGapsAtomic - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerTest.testCacheIdleVerifyChecksGapsTx - PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerWithSSLTest.testCacheIdleVerifyChecksGapsAtomic -
PASSED{color}
* {color:#013220}IgniteControlUtilityTestSuite:
GridCommandHandlerWithSSLTest.testCacheIdleVerifyChecksGapsTx - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6617784buildTypeId=IgniteTests24Java8_RunAll]
> Idle_verify must print and compare full partition counter state instead of
> just LWM
> ---
>
> Key: IGNITE-17114
> URL: https://issues.apache.org/jira/browse/IGNITE-17114
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Anton Vinogradov
>Priority: Major
> Labels: ise
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Gaps also should be printed/compared.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (IGNITE-15155) Utils IgniteWalConverter add ability to skip reading errors
[ https://issues.apache.org/jira/browse/IGNITE-15155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexand Polyakov reassigned IGNITE-15155: - Assignee: (was: Alexand Polyakov) > Utils IgniteWalConverter add ability to skip reading errors > --- > > Key: IGNITE-15155 > URL: https://issues.apache.org/jira/browse/IGNITE-15155 > Project: Ignite > Issue Type: Improvement > Components: extensions >Affects Versions: 2.10 >Reporter: Alexand Polyakov >Priority: Major > > When reading WAL in IgniteWalConverter with error, it is useful not to stop > at the first error, but to output all the data that can be read -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (IGNITE-17016) Rest api get call
[ https://issues.apache.org/jira/browse/IGNITE-17016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-17016: Assignee: Vyacheslav Koptilin > Rest api get call > -- > > Key: IGNITE-17016 > URL: https://issues.apache.org/jira/browse/IGNITE-17016 > Project: Ignite > Issue Type: Bug > Components: rest >Affects Versions: 2.12, 2.13 >Reporter: Denis Dijak >Assignee: Vyacheslav Koptilin >Priority: Critical > Labels: rest, rest_api > Attachments: ignite-rest-test.zip > > > It seems that the call to CacheStore load method from REST API (get command) > is broken from v2.12 onwards. I've attached a simple test program, and > calling > [http://127.0.0.1:8080/ignite?cacheName=RestApiTest=get=6|http://localhost:8080/ignite?cacheName=RestApiTest=get=6] > dosen't seems to call the load method at all. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17016) Rest api get call
[ https://issues.apache.org/jira/browse/IGNITE-17016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-17016: - Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Rest api get call > -- > > Key: IGNITE-17016 > URL: https://issues.apache.org/jira/browse/IGNITE-17016 > Project: Ignite > Issue Type: Bug > Components: rest >Affects Versions: 2.12, 2.13 >Reporter: Denis Dijak >Assignee: Vyacheslav Koptilin >Priority: Critical > Labels: rest, rest_api > Attachments: ignite-rest-test.zip > > > It seems that the call to CacheStore load method from REST API (get command) > is broken from v2.12 onwards. I've attached a simple test program, and > calling > [http://127.0.0.1:8080/ignite?cacheName=RestApiTest=get=6|http://localhost:8080/ignite?cacheName=RestApiTest=get=6] > dosen't seems to call the load method at all. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17141) Use maven to build .NET thin client
[ https://issues.apache.org/jira/browse/IGNITE-17141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-17141: - Description: It seems we can build the .NET using maven + maven-ant-plugin. This will simplify the Apache Ignite release build distribution and will add a single build point for the whole release. Discussion: https://lists.apache.org/thread/9os553vhcryko1jlfzywmx977o6lyor5 was: It seems we can build the .NET using maven + maven-ant-plugin. This will simplify the Apache Ignite release build distribution. Discussion: https://lists.apache.org/thread/9os553vhcryko1jlfzywmx977o6lyor5 > Use maven to build .NET thin client > > > Key: IGNITE-17141 > URL: https://issues.apache.org/jira/browse/IGNITE-17141 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.14 > > > It seems we can build the .NET using maven + maven-ant-plugin. This will > simplify the Apache Ignite release build distribution and will add a single > build point for the whole release. > Discussion: > https://lists.apache.org/thread/9os553vhcryko1jlfzywmx977o6lyor5 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17141) Use maven to build .NET thin client
[ https://issues.apache.org/jira/browse/IGNITE-17141?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-17141: - Ignite Flags: (was: Docs Required,Release Notes Required) > Use maven to build .NET thin client > > > Key: IGNITE-17141 > URL: https://issues.apache.org/jira/browse/IGNITE-17141 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.14 > > > It seems we can build the .NET using maven + maven-ant-plugin. This will > simplify the Apache Ignite release build distribution. > Discussion: > https://lists.apache.org/thread/9os553vhcryko1jlfzywmx977o6lyor5 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-17141) Use maven to build .NET thin client
Maxim Muzafarov created IGNITE-17141: Summary: Use maven to build .NET thin client Key: IGNITE-17141 URL: https://issues.apache.org/jira/browse/IGNITE-17141 Project: Ignite Issue Type: Task Reporter: Maxim Muzafarov Assignee: Maxim Muzafarov Fix For: 2.14 It seems we can build the .NET using maven + maven-ant-plugin. This will simplify the Apache Ignite release build distribution. Discussion: https://lists.apache.org/thread/9os553vhcryko1jlfzywmx977o6lyor5 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17140) Snapshot restore: use the snapshot pool to copy transferred partitions.
[ https://issues.apache.org/jira/browse/IGNITE-17140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-17140: - Fix Version/s: 2.14 > Snapshot restore: use the snapshot pool to copy transferred partitions. > --- > > Key: IGNITE-17140 > URL: https://issues.apache.org/jira/browse/IGNITE-17140 > Project: Ignite > Issue Type: Bug >Reporter: Amelchev Nikita >Assignee: Amelchev Nikita >Priority: Major > Fix For: 2.14 > > > For now, TransmissionHandler#fileHandler is used to process transferred > partitions (files move I/O operation). It can cause socket timeout and > restore process stop. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-17140) Snapshot restore: use the snapshot pool to copy transferred partitions.
Amelchev Nikita created IGNITE-17140: Summary: Snapshot restore: use the snapshot pool to copy transferred partitions. Key: IGNITE-17140 URL: https://issues.apache.org/jira/browse/IGNITE-17140 Project: Ignite Issue Type: Bug Reporter: Amelchev Nikita Assignee: Amelchev Nikita For now, TransmissionHandler#fileHandler is used to process transferred partitions (files move I/O operation). It can cause socket timeout and restore process stop. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17139) It is impossible to dynamically configure a RocksDB data region
[
https://issues.apache.org/jira/browse/IGNITE-17139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey N. Gura updated IGNITE-17139:
Fix Version/s: 3.0.0-alpha5
> It is impossible to dynamically configure a RocksDB data region
> ---
>
> Key: IGNITE-17139
> URL: https://issues.apache.org/jira/browse/IGNITE-17139
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
>
> It is currently impossible to create a RocksDB data region (e.g. through the
> Ignite CLI) and use it in a CREATE TABLE statement. The reason for this is
> that {{RocksDbStorageEngine}} is missing a configuration listener that will
> register new data regions.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17139) It is impossible to dynamically configure a RocksDB data region
[
https://issues.apache.org/jira/browse/IGNITE-17139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-17139:
-
Priority: Blocker (was: Major)
> It is impossible to dynamically configure a RocksDB data region
> ---
>
> Key: IGNITE-17139
> URL: https://issues.apache.org/jira/browse/IGNITE-17139
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
> Labels: ignite-3
>
> It is currently impossible to create a RocksDB data region (e.g. through the
> Ignite CLI) and use it in a CREATE TABLE statement. The reason for this is
> that {{RocksDbStorageEngine}} is missing a configuration listener that will
> register new data regions.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (IGNITE-17126) Update README.md to reflect changes in CLI
[ https://issues.apache.org/jira/browse/IGNITE-17126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17551691#comment-17551691 ] Andrey Mashenkov edited comment on IGNITE-17126 at 6/8/22 4:21 PM: --- [~aleksandr.pakhomov], merged. Thanks for your contribution. main: 937a980c197b573a411a498bf2706dcb92f2d413 ignite-3.0.0-alpha5: 7fa7b61f991dd48a0f59dde506ba602f656f9942 was (Author: amashenkov): [~aleksandr.pakhomov], merged. Thanks for your contribution. > Update README.md to reflect changes in CLI > -- > > Key: IGNITE-17126 > URL: https://issues.apache.org/jira/browse/IGNITE-17126 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Critical > Labels: ignite-3, ignite-3-cli-tool > Fix For: 3.0.0-alpha5 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > It still says alpha3 inside and `ignite init` was changed to `ignite > bootstrap` in the current version. I would suggest also adding a few steps on > `node start` and `cluster init` with a few examples. > All examples in the `examples` folder have to be adjusted too. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17123) Optimize update counter assignment on backup nodes.
[ https://issues.apache.org/jira/browse/IGNITE-17123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-17123: -- Description: Transaction reserves partition counters on primary. On the backup side, TxEntries must be commited with counters from the reserved range. However, a range of update counters, which were reserved on primary, is NOT validated on backup. Thus means NOOP invoke operation may cause partition counter difference on the primary and backup nodes. 1. Let's pass NOOP result of invoke operation to the backup and avoid incorrect partition counter change on backup nodes (see DhtTxPrepareFuture). 2. Update counter can be assigned to TxEntry instantly on tx commit on Remote node (for the WAL purposes) instead of allocating+iterating over a new collection (see GridDistributedTxRemoteAdapter.commitIfLocked). was: Update counter can be assigned to TxEntry instantly on tx commit on Remote node (for the WAL purposes) instead of allocating+iterating over a new collection (see GridDistributedTxRemoteAdapter.commitIfLocked). > Optimize update counter assignment on backup nodes. > --- > > Key: IGNITE-17123 > URL: https://issues.apache.org/jira/browse/IGNITE-17123 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Minor > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > Transaction reserves partition counters on primary. > On the backup side, TxEntries must be commited with counters from the > reserved range. > However, a range of update counters, which were reserved on primary, is NOT > validated on backup. Thus means NOOP invoke operation may cause partition > counter difference on the primary and backup nodes. > 1. Let's pass NOOP result of invoke operation to the backup and avoid > incorrect partition counter change on backup nodes (see DhtTxPrepareFuture). > 2. Update counter can be assigned to TxEntry instantly on tx commit on Remote > node (for the WAL purposes) instead of allocating+iterating over a new > collection (see GridDistributedTxRemoteAdapter.commitIfLocked). -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17123) Fix wrong update counter assignment on backup nodes for noop invoke operation.
[ https://issues.apache.org/jira/browse/IGNITE-17123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-17123: -- Issue Type: Bug (was: Improvement) > Fix wrong update counter assignment on backup nodes for noop invoke operation. > -- > > Key: IGNITE-17123 > URL: https://issues.apache.org/jira/browse/IGNITE-17123 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Minor > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > Transaction reserves partition counters on primary. > On the backup side, TxEntries must be commited with counters from the > reserved range. > However, a range of update counters, which were reserved on primary, is NOT > validated on backup. Thus means NOOP invoke operation may cause partition > counter difference on the primary and backup nodes. > 1. Let's pass NOOP result of invoke operation to the backup and avoid > incorrect partition counter change on backup nodes (see DhtTxPrepareFuture). > 2. Update counter can be assigned to TxEntry instantly on tx commit on Remote > node (for the WAL purposes) instead of allocating+iterating over a new > collection (see GridDistributedTxRemoteAdapter.commitIfLocked). -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17123) Fix wrong update counter assignment on backup nodes for noop invoke operation.
[ https://issues.apache.org/jira/browse/IGNITE-17123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-17123: -- Summary: Fix wrong update counter assignment on backup nodes for noop invoke operation. (was: Optimize update counter assignment on backup nodes.) > Fix wrong update counter assignment on backup nodes for noop invoke operation. > -- > > Key: IGNITE-17123 > URL: https://issues.apache.org/jira/browse/IGNITE-17123 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Minor > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > Transaction reserves partition counters on primary. > On the backup side, TxEntries must be commited with counters from the > reserved range. > However, a range of update counters, which were reserved on primary, is NOT > validated on backup. Thus means NOOP invoke operation may cause partition > counter difference on the primary and backup nodes. > 1. Let's pass NOOP result of invoke operation to the backup and avoid > incorrect partition counter change on backup nodes (see DhtTxPrepareFuture). > 2. Update counter can be assigned to TxEntry instantly on tx commit on Remote > node (for the WAL purposes) instead of allocating+iterating over a new > collection (see GridDistributedTxRemoteAdapter.commitIfLocked). -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-17139) It is impossible to dynamically configure a RocksDB data region
Aleksandr Polovtcev created IGNITE-17139:
Summary: It is impossible to dynamically configure a RocksDB data
region
Key: IGNITE-17139
URL: https://issues.apache.org/jira/browse/IGNITE-17139
Project: Ignite
Issue Type: Bug
Reporter: Aleksandr Polovtcev
Assignee: Aleksandr Polovtcev
It is currently impossible to create a RocksDB data region (e.g. through the
Ignite CLI) and use it in a CREATE TABLE statement. The reason for this is that
{{RocksDbStorageEngine}} is missing a configuration listener that will register
new data regions.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17139) It is impossible to dynamically configure a RocksDB data region
[
https://issues.apache.org/jira/browse/IGNITE-17139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-17139:
-
Labels: ignite-3 (was: )
> It is impossible to dynamically configure a RocksDB data region
> ---
>
> Key: IGNITE-17139
> URL: https://issues.apache.org/jira/browse/IGNITE-17139
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> It is currently impossible to create a RocksDB data region (e.g. through the
> Ignite CLI) and use it in a CREATE TABLE statement. The reason for this is
> that {{RocksDbStorageEngine}} is missing a configuration listener that will
> register new data regions.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17139) It is impossible to dynamically configure a RocksDB data region
[
https://issues.apache.org/jira/browse/IGNITE-17139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-17139:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> It is impossible to dynamically configure a RocksDB data region
> ---
>
> Key: IGNITE-17139
> URL: https://issues.apache.org/jira/browse/IGNITE-17139
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> It is currently impossible to create a RocksDB data region (e.g. through the
> Ignite CLI) and use it in a CREATE TABLE statement. The reason for this is
> that {{RocksDbStorageEngine}} is missing a configuration listener that will
> register new data regions.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-17126) Update README.md to reflect changes in CLI
[ https://issues.apache.org/jira/browse/IGNITE-17126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17551662#comment-17551662 ] Andrey Mashenkov commented on IGNITE-17126: --- [~aleksandr.pakhomov], I've left a comment to the PR > Update README.md to reflect changes in CLI > -- > > Key: IGNITE-17126 > URL: https://issues.apache.org/jira/browse/IGNITE-17126 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Critical > Labels: ignite-3, ignite-3-cli-tool > Fix For: 3.0.0-alpha5 > > Time Spent: 1.5h > Remaining Estimate: 0h > > It still says alpha3 inside and `ignite init` was changed to `ignite > bootstrap` in the current version. I would suggest also adding a few steps on > `node start` and `cluster init` with a few examples. > All examples in the `examples` folder have to be adjusted too. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17123) Optimize update counter assignment on backup nodes.
[ https://issues.apache.org/jira/browse/IGNITE-17123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-17123: -- Summary: Optimize update counter assignment on backup nodes. (was: Fix update counter assignment on backup nodes.) > Optimize update counter assignment on backup nodes. > --- > > Key: IGNITE-17123 > URL: https://issues.apache.org/jira/browse/IGNITE-17123 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > Update counter can be assigned to TxEntry instantly on tx commit on Remote > node (for the WAL purposes) instead of allocating+iterating over a new > collection (see GridDistributedTxRemoteAdapter.commitIfLocked). -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17123) Optimize update counter assignment on backup nodes.
[ https://issues.apache.org/jira/browse/IGNITE-17123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-17123: -- Priority: Minor (was: Major) > Optimize update counter assignment on backup nodes. > --- > > Key: IGNITE-17123 > URL: https://issues.apache.org/jira/browse/IGNITE-17123 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Minor > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > Update counter can be assigned to TxEntry instantly on tx commit on Remote > node (for the WAL purposes) instead of allocating+iterating over a new > collection (see GridDistributedTxRemoteAdapter.commitIfLocked). -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17123) Fix update counter assignment on backup nodes.
[ https://issues.apache.org/jira/browse/IGNITE-17123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-17123: -- Description: Update counter can be assigned to TxEntry instantly on tx commit on Remote node (for the WAL purposes) instead of allocating+iterating over a new collection (see GridDistributedTxRemoteAdapter.commitIfLocked). was: Transaction reserves partition counters on primary. On the backup side, TxEntries must be commited with counters from the reserved range. However, a range of update counters, which were reserved on primary, is NOT validated on backup. Thus means NOOP invoke operation may cause partition counter difference on the primary and backup nodes. 1. Let's pass NOOP result of invoke operation to the backup and avoid incorrect partition counter change on backup nodes (see DhtTxPrepareFuture). 2. Update counter can be assigned to TxEntry instantly on tx commit on Remote node (for the WAL purposes) instead of allocating+iterating over a new collection (see GridDistributedTxRemoteAdapter.commitIfLocked). > Fix update counter assignment on backup nodes. > -- > > Key: IGNITE-17123 > URL: https://issues.apache.org/jira/browse/IGNITE-17123 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > Update counter can be assigned to TxEntry instantly on tx commit on Remote > node (for the WAL purposes) instead of allocating+iterating over a new > collection (see GridDistributedTxRemoteAdapter.commitIfLocked). -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17123) Fix update counter assignment on backup nodes.
[ https://issues.apache.org/jira/browse/IGNITE-17123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-17123: -- Issue Type: Improvement (was: Bug) > Fix update counter assignment on backup nodes. > -- > > Key: IGNITE-17123 > URL: https://issues.apache.org/jira/browse/IGNITE-17123 > Project: Ignite > Issue Type: Improvement > Components: cache >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > Transaction reserves partition counters on primary. > On the backup side, TxEntries must be commited with counters from the > reserved range. > However, a range of update counters, which were reserved on primary, is NOT > validated on backup. Thus means NOOP invoke operation may cause partition > counter difference on the primary and backup nodes. > 1. Let's pass NOOP result of invoke operation to the backup and avoid > incorrect partition counter change on backup nodes (see DhtTxPrepareFuture). > 2. Update counter can be assigned to TxEntry instantly on tx commit on Remote > node (for the WAL purposes) instead of allocating+iterating over a new > collection (see GridDistributedTxRemoteAdapter.commitIfLocked). -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (IGNITE-17057) Thin 3.0: Implement synchronous SQL API for java thin client
[ https://issues.apache.org/jira/browse/IGNITE-17057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17551642#comment-17551642 ] Pavel Tupitsyn edited comment on IGNITE-17057 at 6/8/22 1:57 PM: - Merged to main: c4588a2b6f78391ac3f71dc317b880ac23f455e2 Cherry-picked to ignite-3.0.0-alpha5: 535523c6321967735c7662cfb8dd0b000720d729 was (Author: ptupitsyn): Merged to main: c4588a2b6f78391ac3f71dc317b880ac23f455e2 > Thin 3.0: Implement synchronous SQL API for java thin client > > > Key: IGNITE-17057 > URL: https://issues.apache.org/jira/browse/IGNITE-17057 > Project: Ignite > Issue Type: Improvement >Affects Versions: 3.0.0-alpha4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 1.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-17057) Thin 3.0: Implement synchronous SQL API for java thin client
[ https://issues.apache.org/jira/browse/IGNITE-17057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17551642#comment-17551642 ] Pavel Tupitsyn commented on IGNITE-17057: - Merged to main: c4588a2b6f78391ac3f71dc317b880ac23f455e2 > Thin 3.0: Implement synchronous SQL API for java thin client > > > Key: IGNITE-17057 > URL: https://issues.apache.org/jira/browse/IGNITE-17057 > Project: Ignite > Issue Type: Improvement >Affects Versions: 3.0.0-alpha4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 1.5h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (IGNITE-17138) IndexKeyFactory can't register custom index types
[
https://issues.apache.org/jira/browse/IGNITE-17138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-17138:
--
Assignee: Aleksey Plekhanov
> IndexKeyFactory can't register custom index types
> -
>
> Key: IGNITE-17138
> URL: https://issues.apache.org/jira/browse/IGNITE-17138
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Fix For: 2.14
>
>
> {code}
> [14:57:27][Step 3/3] symbol: method register(int,(k)->new G[...]ry)k))
> [14:57:27][Step 3/3] location: class
> org.apache.ignite.internal.cache.query.index.sorted.keys.IndexKeyFactory
> [14:57:27][Step 3/3] [INFO] 1 error
> [14:57:27][Step 3/3] [INFO]
> -
> [14:57:27][Step 3/3] Compiler
> [14:57:27][Compiler] Compilation failure
> /opt/buildagent/work/9319dd66c384518/modules/geospatial-ext/geospatial/src/main/java/org/apache/ignite/internal/processors/query/h2/opt/GeoSpatialUtils.java:[45,24]
> cannot find symbol
> symbol: method register(int,(k)->new G[...]ry)k))
> location: class
> org.apache.ignite.internal.cache.query.index.sorted.keys.IndexKeyFactory
> [14:57:27][Step 3/3] [INFO]
>
> [14:57:27][Step 3/3] [INFO] Reactor Summary for
> ignite-geospatial-parent-ext 1.0.0-SNAPSHOT:
> [14:57:27][Step 3/3] [INFO]
> [14:57:27][Step 3/3] [INFO] ignite-geospatial-parent-ext
> ... SUCCESS [ 3.145 s]
> [14:57:27][Step 3/3] [INFO] ignite-geospatial-ext
> .. FAILURE [ 3.208 s]
> [14:57:27][Step 3/3] [INFO] ignite-geospatial-ext-examples
> . SKIPPED
> [14:57:27][Step 3/3] [INFO]
>
> [14:57:27][Step 3/3] [INFO] BUILD FAILURE
> [14:57:27][Step 3/3] [INFO]
>
> [14:57:27][Step 3/3] [INFO] Total time: 7.728 s
> [14:57:27][Step 3/3] [INFO] Finished at: 2022-06-07T14:57:27+03:00
> [14:57:27][Step 3/3] [INFO]
>
> [14:57:27][Step 3/3] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project ignite-geospatial-ext: Compilation failure
> [14:57:27][Step 3/3] [ERROR]
> /opt/buildagent/work/9319dd66c384518/modules/geospatial-ext/geospatial/src/main/java/org/apache/ignite/internal/processors/query/h2/opt/GeoSpatialUtils.java:[45,24]
> cannot find symbol
> {code}
> https://ci.ignite.apache.org/viewLog.html?buildId=6615340=IgniteExtensions_Tests_Geospatial=buildLog
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17138) IndexKeyFactory can't register custom index types
[
https://issues.apache.org/jira/browse/IGNITE-17138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-17138:
---
Affects Version/s: 2.14
> IndexKeyFactory can't register custom index types
> -
>
> Key: IGNITE-17138
> URL: https://issues.apache.org/jira/browse/IGNITE-17138
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.14
>Reporter: Maxim Muzafarov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Fix For: 2.14
>
>
> {code}
> [14:57:27][Step 3/3] symbol: method register(int,(k)->new G[...]ry)k))
> [14:57:27][Step 3/3] location: class
> org.apache.ignite.internal.cache.query.index.sorted.keys.IndexKeyFactory
> [14:57:27][Step 3/3] [INFO] 1 error
> [14:57:27][Step 3/3] [INFO]
> -
> [14:57:27][Step 3/3] Compiler
> [14:57:27][Compiler] Compilation failure
> /opt/buildagent/work/9319dd66c384518/modules/geospatial-ext/geospatial/src/main/java/org/apache/ignite/internal/processors/query/h2/opt/GeoSpatialUtils.java:[45,24]
> cannot find symbol
> symbol: method register(int,(k)->new G[...]ry)k))
> location: class
> org.apache.ignite.internal.cache.query.index.sorted.keys.IndexKeyFactory
> [14:57:27][Step 3/3] [INFO]
>
> [14:57:27][Step 3/3] [INFO] Reactor Summary for
> ignite-geospatial-parent-ext 1.0.0-SNAPSHOT:
> [14:57:27][Step 3/3] [INFO]
> [14:57:27][Step 3/3] [INFO] ignite-geospatial-parent-ext
> ... SUCCESS [ 3.145 s]
> [14:57:27][Step 3/3] [INFO] ignite-geospatial-ext
> .. FAILURE [ 3.208 s]
> [14:57:27][Step 3/3] [INFO] ignite-geospatial-ext-examples
> . SKIPPED
> [14:57:27][Step 3/3] [INFO]
>
> [14:57:27][Step 3/3] [INFO] BUILD FAILURE
> [14:57:27][Step 3/3] [INFO]
>
> [14:57:27][Step 3/3] [INFO] Total time: 7.728 s
> [14:57:27][Step 3/3] [INFO] Finished at: 2022-06-07T14:57:27+03:00
> [14:57:27][Step 3/3] [INFO]
>
> [14:57:27][Step 3/3] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project ignite-geospatial-ext: Compilation failure
> [14:57:27][Step 3/3] [ERROR]
> /opt/buildagent/work/9319dd66c384518/modules/geospatial-ext/geospatial/src/main/java/org/apache/ignite/internal/processors/query/h2/opt/GeoSpatialUtils.java:[45,24]
> cannot find symbol
> {code}
> https://ci.ignite.apache.org/viewLog.html?buildId=6615340=IgniteExtensions_Tests_Geospatial=buildLog
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17138) IndexKeyFactory can't register custom index types
[
https://issues.apache.org/jira/browse/IGNITE-17138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-17138:
-
Ignite Flags: (was: Release Notes Required)
> IndexKeyFactory can't register custom index types
> -
>
> Key: IGNITE-17138
> URL: https://issues.apache.org/jira/browse/IGNITE-17138
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Priority: Major
> Fix For: 2.14
>
>
> {code}
> [14:57:27][Step 3/3] symbol: method register(int,(k)->new G[...]ry)k))
> [14:57:27][Step 3/3] location: class
> org.apache.ignite.internal.cache.query.index.sorted.keys.IndexKeyFactory
> [14:57:27][Step 3/3] [INFO] 1 error
> [14:57:27][Step 3/3] [INFO]
> -
> [14:57:27][Step 3/3] Compiler
> [14:57:27][Compiler] Compilation failure
> /opt/buildagent/work/9319dd66c384518/modules/geospatial-ext/geospatial/src/main/java/org/apache/ignite/internal/processors/query/h2/opt/GeoSpatialUtils.java:[45,24]
> cannot find symbol
> symbol: method register(int,(k)->new G[...]ry)k))
> location: class
> org.apache.ignite.internal.cache.query.index.sorted.keys.IndexKeyFactory
> [14:57:27][Step 3/3] [INFO]
>
> [14:57:27][Step 3/3] [INFO] Reactor Summary for
> ignite-geospatial-parent-ext 1.0.0-SNAPSHOT:
> [14:57:27][Step 3/3] [INFO]
> [14:57:27][Step 3/3] [INFO] ignite-geospatial-parent-ext
> ... SUCCESS [ 3.145 s]
> [14:57:27][Step 3/3] [INFO] ignite-geospatial-ext
> .. FAILURE [ 3.208 s]
> [14:57:27][Step 3/3] [INFO] ignite-geospatial-ext-examples
> . SKIPPED
> [14:57:27][Step 3/3] [INFO]
>
> [14:57:27][Step 3/3] [INFO] BUILD FAILURE
> [14:57:27][Step 3/3] [INFO]
>
> [14:57:27][Step 3/3] [INFO] Total time: 7.728 s
> [14:57:27][Step 3/3] [INFO] Finished at: 2022-06-07T14:57:27+03:00
> [14:57:27][Step 3/3] [INFO]
>
> [14:57:27][Step 3/3] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project ignite-geospatial-ext: Compilation failure
> [14:57:27][Step 3/3] [ERROR]
> /opt/buildagent/work/9319dd66c384518/modules/geospatial-ext/geospatial/src/main/java/org/apache/ignite/internal/processors/query/h2/opt/GeoSpatialUtils.java:[45,24]
> cannot find symbol
> {code}
> https://ci.ignite.apache.org/viewLog.html?buildId=6615340=IgniteExtensions_Tests_Geospatial=buildLog
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17138) IndexKeyFactory can't register custom index types
[
https://issues.apache.org/jira/browse/IGNITE-17138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-17138:
-
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> IndexKeyFactory can't register custom index types
> -
>
> Key: IGNITE-17138
> URL: https://issues.apache.org/jira/browse/IGNITE-17138
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Priority: Major
> Fix For: 2.14
>
>
> {code}
> [14:57:27][Step 3/3] symbol: method register(int,(k)->new G[...]ry)k))
> [14:57:27][Step 3/3] location: class
> org.apache.ignite.internal.cache.query.index.sorted.keys.IndexKeyFactory
> [14:57:27][Step 3/3] [INFO] 1 error
> [14:57:27][Step 3/3] [INFO]
> -
> [14:57:27][Step 3/3] Compiler
> [14:57:27][Compiler] Compilation failure
> /opt/buildagent/work/9319dd66c384518/modules/geospatial-ext/geospatial/src/main/java/org/apache/ignite/internal/processors/query/h2/opt/GeoSpatialUtils.java:[45,24]
> cannot find symbol
> symbol: method register(int,(k)->new G[...]ry)k))
> location: class
> org.apache.ignite.internal.cache.query.index.sorted.keys.IndexKeyFactory
> [14:57:27][Step 3/3] [INFO]
>
> [14:57:27][Step 3/3] [INFO] Reactor Summary for
> ignite-geospatial-parent-ext 1.0.0-SNAPSHOT:
> [14:57:27][Step 3/3] [INFO]
> [14:57:27][Step 3/3] [INFO] ignite-geospatial-parent-ext
> ... SUCCESS [ 3.145 s]
> [14:57:27][Step 3/3] [INFO] ignite-geospatial-ext
> .. FAILURE [ 3.208 s]
> [14:57:27][Step 3/3] [INFO] ignite-geospatial-ext-examples
> . SKIPPED
> [14:57:27][Step 3/3] [INFO]
>
> [14:57:27][Step 3/3] [INFO] BUILD FAILURE
> [14:57:27][Step 3/3] [INFO]
>
> [14:57:27][Step 3/3] [INFO] Total time: 7.728 s
> [14:57:27][Step 3/3] [INFO] Finished at: 2022-06-07T14:57:27+03:00
> [14:57:27][Step 3/3] [INFO]
>
> [14:57:27][Step 3/3] [ERROR] Failed to execute goal
> org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile
> (default-compile) on project ignite-geospatial-ext: Compilation failure
> [14:57:27][Step 3/3] [ERROR]
> /opt/buildagent/work/9319dd66c384518/modules/geospatial-ext/geospatial/src/main/java/org/apache/ignite/internal/processors/query/h2/opt/GeoSpatialUtils.java:[45,24]
> cannot find symbol
> {code}
> https://ci.ignite.apache.org/viewLog.html?buildId=6615340=IgniteExtensions_Tests_Geospatial=buildLog
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (IGNITE-17138) IndexKeyFactory can't register custom index types
Maxim Muzafarov created IGNITE-17138:
Summary: IndexKeyFactory can't register custom index types
Key: IGNITE-17138
URL: https://issues.apache.org/jira/browse/IGNITE-17138
Project: Ignite
Issue Type: Bug
Reporter: Maxim Muzafarov
Fix For: 2.14
{code}
[14:57:27] [Step 3/3] symbol: method register(int,(k)->new G[...]ry)k))
[14:57:27] [Step 3/3] location: class
org.apache.ignite.internal.cache.query.index.sorted.keys.IndexKeyFactory
[14:57:27] [Step 3/3] [INFO] 1 error
[14:57:27] [Step 3/3] [INFO]
-
[14:57:27] [Step 3/3] Compiler
[14:57:27] [Compiler] Compilation failure
/opt/buildagent/work/9319dd66c384518/modules/geospatial-ext/geospatial/src/main/java/org/apache/ignite/internal/processors/query/h2/opt/GeoSpatialUtils.java:[45,24]
cannot find symbol
symbol: method register(int,(k)->new G[...]ry)k))
location: class
org.apache.ignite.internal.cache.query.index.sorted.keys.IndexKeyFactory
[14:57:27] [Step 3/3] [INFO]
[14:57:27] [Step 3/3] [INFO] Reactor Summary for
ignite-geospatial-parent-ext 1.0.0-SNAPSHOT:
[14:57:27] [Step 3/3] [INFO]
[14:57:27] [Step 3/3] [INFO] ignite-geospatial-parent-ext
... SUCCESS [ 3.145 s]
[14:57:27] [Step 3/3] [INFO] ignite-geospatial-ext
.. FAILURE [ 3.208 s]
[14:57:27] [Step 3/3] [INFO] ignite-geospatial-ext-examples
. SKIPPED
[14:57:27] [Step 3/3] [INFO]
[14:57:27] [Step 3/3] [INFO] BUILD FAILURE
[14:57:27] [Step 3/3] [INFO]
[14:57:27] [Step 3/3] [INFO] Total time: 7.728 s
[14:57:27] [Step 3/3] [INFO] Finished at: 2022-06-07T14:57:27+03:00
[14:57:27] [Step 3/3] [INFO]
[14:57:27] [Step 3/3] [ERROR] Failed to execute goal
org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile)
on project ignite-geospatial-ext: Compilation failure
[14:57:27] [Step 3/3] [ERROR]
/opt/buildagent/work/9319dd66c384518/modules/geospatial-ext/geospatial/src/main/java/org/apache/ignite/internal/processors/query/h2/opt/GeoSpatialUtils.java:[45,24]
cannot find symbol
{code}
https://ci.ignite.apache.org/viewLog.html?buildId=6615340=IgniteExtensions_Tests_Geospatial=buildLog
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-17126) Update README.md to reflect changes in CLI
[ https://issues.apache.org/jira/browse/IGNITE-17126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17551619#comment-17551619 ] Aleksandr commented on IGNITE-17126: [~amashenkov] ok, I've created a fresh Pr. > Update README.md to reflect changes in CLI > -- > > Key: IGNITE-17126 > URL: https://issues.apache.org/jira/browse/IGNITE-17126 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Critical > Labels: ignite-3, ignite-3-cli-tool > Fix For: 3.0.0-alpha5 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > It still says alpha3 inside and `ignite init` was changed to `ignite > bootstrap` in the current version. I would suggest also adding a few steps on > `node start` and `cluster init` with a few examples. > All examples in the `examples` folder have to be adjusted too. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-17137) Move ignite-cloud to the Ignite Extensions project
Maxim Muzafarov created IGNITE-17137: Summary: Move ignite-cloud to the Ignite Extensions project Key: IGNITE-17137 URL: https://issues.apache.org/jira/browse/IGNITE-17137 Project: Ignite Issue Type: Task Reporter: Maxim Muzafarov Assignee: Maxim Muzafarov Fix For: 2.14 Move ignite-cloud to the Ignite Extensions project -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (IGNITE-17126) Update README.md to reflect changes in CLI
[
https://issues.apache.org/jira/browse/IGNITE-17126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17551597#comment-17551597
]
Andrey Mashenkov edited comment on IGNITE-17126 at 6/8/22 12:47 PM:
[~aleksandr.pakhomov], I've merged the PR #863 by mistake, then reverted
(PR#866).
Please revert back the changes.
{code:java}
* `SqlJdbcExample` - demonstrates the usage of the Apache Ignite JDBC driver.
{code}
Actually, we have 2 different examples SqlJdbcExample for JDBC driver and
SqlApiExample for native Java API.
was (Author: amashenkov):
[~aleksandr.pakhomov], I've merged the PR by mistake, then reverted.
Please revert back the changes.
{code:java}
* `SqlJdbcExample` - demonstrates the usage of the Apache Ignite JDBC driver.
{code}
Actually, we have 2 different examples SqlJdbcExample for JDBC driver and
SqlApiExample for native Java API.
> Update README.md to reflect changes in CLI
> --
>
> Key: IGNITE-17126
> URL: https://issues.apache.org/jira/browse/IGNITE-17126
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr
>Assignee: Aleksandr
>Priority: Critical
> Labels: ignite-3, ignite-3-cli-tool
> Fix For: 3.0.0-alpha5
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> It still says alpha3 inside and `ignite init` was changed to `ignite
> bootstrap` in the current version. I would suggest also adding a few steps on
> `node start` and `cluster init` with a few examples.
> All examples in the `examples` folder have to be adjusted too.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Comment Edited] (IGNITE-17106) Create documentation for Java SQL API
[ https://issues.apache.org/jira/browse/IGNITE-17106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17551599#comment-17551599 ] Andrey Mashenkov edited comment on IGNITE-17106 at 6/8/22 12:44 PM: [~igusev], merged to main. Thanks for your contribution! main: e807d547daf93cc42a1db23027a79b86160a8d6d ignite-3.0.0-alpha5: 3c88b04d3258e41221819acfcc83f0bda733c504 was (Author: amashenkov): [~igusev], merged to main. Thanks for your contribution! > Create documentation for Java SQL API > - > > Key: IGNITE-17106 > URL: https://issues.apache.org/jira/browse/IGNITE-17106 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 2h 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-17126) Update README.md to reflect changes in CLI
[
https://issues.apache.org/jira/browse/IGNITE-17126?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17551597#comment-17551597
]
Andrey Mashenkov commented on IGNITE-17126:
---
[~aleksandr.pakhomov], I've merged the PR by mistake, then reverted.
Please revert back the changes.
{code:java}
* `SqlJdbcExample` - demonstrates the usage of the Apache Ignite JDBC driver.
{code}
Actually, we have 2 different examples SqlJdbcExample for JDBC driver and
SqlApiExample for native Java API.
> Update README.md to reflect changes in CLI
> --
>
> Key: IGNITE-17126
> URL: https://issues.apache.org/jira/browse/IGNITE-17126
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr
>Assignee: Aleksandr
>Priority: Critical
> Labels: ignite-3, ignite-3-cli-tool
> Fix For: 3.0.0-alpha5
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> It still says alpha3 inside and `ignite init` was changed to `ignite
> bootstrap` in the current version. I would suggest also adding a few steps on
> `node start` and `cluster init` with a few examples.
> All examples in the `examples` folder have to be adjusted too.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] (IGNITE-17126) Update README.md to reflect changes in CLI
[ https://issues.apache.org/jira/browse/IGNITE-17126 ] Andrey Mashenkov deleted comment on IGNITE-17126: --- was (Author: amashenkov): [~aleksandr.pakhomov] LGTM, merged to main. > Update README.md to reflect changes in CLI > -- > > Key: IGNITE-17126 > URL: https://issues.apache.org/jira/browse/IGNITE-17126 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Critical > Labels: ignite-3, ignite-3-cli-tool > Fix For: 3.0.0-alpha5 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > It still says alpha3 inside and `ignite init` was changed to `ignite > bootstrap` in the current version. I would suggest also adding a few steps on > `node start` and `cluster init` with a few examples. > All examples in the `examples` folder have to be adjusted too. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Reopened] (IGNITE-17126) Update README.md to reflect changes in CLI
[ https://issues.apache.org/jira/browse/IGNITE-17126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov reopened IGNITE-17126: --- > Update README.md to reflect changes in CLI > -- > > Key: IGNITE-17126 > URL: https://issues.apache.org/jira/browse/IGNITE-17126 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Critical > Labels: ignite-3, ignite-3-cli-tool > Fix For: 3.0.0-alpha5 > > Time Spent: 50m > Remaining Estimate: 0h > > It still says alpha3 inside and `ignite init` was changed to `ignite > bootstrap` in the current version. I would suggest also adding a few steps on > `node start` and `cluster init` with a few examples. > All examples in the `examples` folder have to be adjusted too. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-17106) Create documentation for Java SQL API
[ https://issues.apache.org/jira/browse/IGNITE-17106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17551577#comment-17551577 ] Konstantin Orlov commented on IGNITE-17106: --- LGTM > Create documentation for Java SQL API > - > > Key: IGNITE-17106 > URL: https://issues.apache.org/jira/browse/IGNITE-17106 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 2h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-17065) CorruptedTreeException: B+Tree is corrupted(Duplicate row in index)
[ https://issues.apache.org/jira/browse/IGNITE-17065?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17551562#comment-17551562 ] YuJue Li commented on IGNITE-17065: --- This problem only happens twice, which is difficult to reproduce. This cache does not have persistence enabled, so there are no wal and pds files, > CorruptedTreeException: B+Tree is corrupted(Duplicate row in index) > --- > > Key: IGNITE-17065 > URL: https://issues.apache.org/jira/browse/IGNITE-17065 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.10 >Reporter: YuJue Li >Priority: Major > Attachments: 2021-12-21_13-59-27.574.log > > > In a pure memory cluster, the B+Tree is corrupted during node restart. > See the attachment log for details. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-17119) DiscoveryClientSocketTest.sslSocketTest fails regularly on TC and locally
[ https://issues.apache.org/jira/browse/IGNITE-17119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17551557#comment-17551557 ] Roman Puchkovskiy commented on IGNITE-17119: This was caused by two problems: 1. Some JDK versions (including 1.8.0_261) contain a bug https://bugs.openjdk.java.net/browse/JDK-8241239 due to which close() on a socket is blocked when a write() is blocked on its output stream. This causes the test to always fail on such JDKs. The test models a situation which may be faced by our customers, so there is no point in working this around just in our test. 2. If the original 'handshake' takes long time (I saw it around 1 second), then the test may block on a write attempt for a long time (handshake time multiplied by 10), in my case 10 seconds, which makes the test fail. We can't do anything with item 1, but we did alleviate item 2: write wait time is bounded. > DiscoveryClientSocketTest.sslSocketTest fails regularly on TC and locally > - > > Key: IGNITE-17119 > URL: https://issues.apache.org/jira/browse/IGNITE-17119 > Project: Ignite > Issue Type: Bug > Components: networking >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1051723478826841368=testDetails -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-17136) Update Ignite dependency: Tomcat Servlet API
Aleksandr created IGNITE-17136: -- Summary: Update Ignite dependency: Tomcat Servlet API Key: IGNITE-17136 URL: https://issues.apache.org/jira/browse/IGNITE-17136 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Assignee: Aleksandr Fix For: 2.14 Update Tomcat Servlet API dependency 9.0.10 to 9.0.63 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-17057) Thin 3.0: Implement synchronous SQL API for java thin client
[ https://issues.apache.org/jira/browse/IGNITE-17057?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17551550#comment-17551550 ] Igor Sapego commented on IGNITE-17057: -- [~ptupitsyn] looks good to me > Thin 3.0: Implement synchronous SQL API for java thin client > > > Key: IGNITE-17057 > URL: https://issues.apache.org/jira/browse/IGNITE-17057 > Project: Ignite > Issue Type: Improvement >Affects Versions: 3.0.0-alpha4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-17123) Fix update counter assignment on backup nodes.
[
https://issues.apache.org/jira/browse/IGNITE-17123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17551546#comment-17551546
]
Ignite TC Bot commented on IGNITE-17123:
{panel:title=Branch: [pull/10075/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10075/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=6615893buildTypeId=IgniteTests24Java8_RunAll]
> Fix update counter assignment on backup nodes.
> --
>
> Key: IGNITE-17123
> URL: https://issues.apache.org/jira/browse/IGNITE-17123
> Project: Ignite
> Issue Type: Bug
> Components: cache
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Transaction reserves partition counters on primary.
> On the backup side, TxEntries must be commited with counters from the
> reserved range.
> However, a range of update counters, which were reserved on primary, is NOT
> validated on backup. Thus means NOOP invoke operation may cause partition
> counter difference on the primary and backup nodes.
> 1. Let's pass NOOP result of invoke operation to the backup and avoid
> incorrect partition counter change on backup nodes (see DhtTxPrepareFuture).
> 2. Update counter can be assigned to TxEntry instantly on tx commit on Remote
> node (for the WAL purposes) instead of allocating+iterating over a new
> collection (see GridDistributedTxRemoteAdapter.commitIfLocked).
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-16963) SQL API: Add batched DML queries support.
[ https://issues.apache.org/jira/browse/IGNITE-16963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-16963: --- Fix Version/s: 3.0.0-alpha6 (was: 3.0.0-alpha5) > SQL API: Add batched DML queries support. > - > > Key: IGNITE-16963 > URL: https://issues.apache.org/jira/browse/IGNITE-16963 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Taras Ledkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Add batching for DML queries. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-17106) Create documentation for Java SQL API
[ https://issues.apache.org/jira/browse/IGNITE-17106?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17551536#comment-17551536 ] Yury Gerzhedovich commented on IGNITE-17106: [~igusev] , LGTM > Create documentation for Java SQL API > - > > Key: IGNITE-17106 > URL: https://issues.apache.org/jira/browse/IGNITE-17106 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 2h > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-17120) Move ignite-yarn to the Ignite Extensions project
[
https://issues.apache.org/jira/browse/IGNITE-17120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17551522#comment-17551522
]
Ignite TC Bot commented on IGNITE-17120:
{panel:title=Branch: [pull/10074/head] Base: [master] : Possible Blockers
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}SPI (Discovery){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6614689]]
* IgniteSpiDiscoverySelfTestSuite:
TcpDiscoveryPendingMessageDeliveryTest.testPendingMessagesOverflow - Test has
low fail rate in base branch 0,0% and is not flaky
{color:#d04437}Yarn{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6615621]]
{panel}
{panel:title=Branch: [pull/10074/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=6614698buildTypeId=IgniteTests24Java8_RunAll]
> Move ignite-yarn to the Ignite Extensions project
> -
>
> Key: IGNITE-17120
> URL: https://issues.apache.org/jira/browse/IGNITE-17120
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Move ignite-yarn to the Ignite Extensions project.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17135) SQL API: Exceptions are different on server and client
[ https://issues.apache.org/jira/browse/IGNITE-17135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-17135: Epic Link: IGNITE-16952 > SQL API: Exceptions are different on server and client > --- > > Key: IGNITE-17135 > URL: https://issues.apache.org/jira/browse/IGNITE-17135 > Project: Ignite > Issue Type: Bug > Components: sql, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > > Server and client SQL API implementations throw different exception types > (when cursor is closed, when SQL is incorrect, etc). Check > *ItSqlClientAsynchronousApiTest* and *ItSqlAsynchronousApiTest*. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17134) Thin 3.0: Implement client SQL session management
[ https://issues.apache.org/jira/browse/IGNITE-17134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-17134: Labels: ignite-3 (was: ) > Thin 3.0: Implement client SQL session management > - > > Key: IGNITE-17134 > URL: https://issues.apache.org/jira/browse/IGNITE-17134 > Project: Ignite > Issue Type: Improvement > Components: sql, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > > Close all active cursors and cancel queries when client SQL session is closed -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-17135) SQL API: Exceptions are different on server and client
Pavel Tupitsyn created IGNITE-17135: --- Summary: SQL API: Exceptions are different on server and client Key: IGNITE-17135 URL: https://issues.apache.org/jira/browse/IGNITE-17135 Project: Ignite Issue Type: Bug Components: sql, thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-alpha6 Server and client SQL API implementations throw different exception types (when cursor is closed, when SQL is incorrect, etc). Check *ItSqlClientAsynchronousApiTest* and *ItSqlAsynchronousApiTest*. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-17134) Thin 3.0: Implement client SQL session management
Pavel Tupitsyn created IGNITE-17134: --- Summary: Thin 3.0: Implement client SQL session management Key: IGNITE-17134 URL: https://issues.apache.org/jira/browse/IGNITE-17134 Project: Ignite Issue Type: Improvement Components: sql, thin client Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-alpha6 Close all active cursors and cancel queries when client SQL session is closed -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17128) PersistentPageMemoryStorageExample cannot be run twice
[
https://issues.apache.org/jira/browse/IGNITE-17128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17128:
-
Epic Link: IGNITE-16232
> PersistentPageMemoryStorageExample cannot be run twice
> --
>
> Key: IGNITE-17128
> URL: https://issues.apache.org/jira/browse/IGNITE-17128
> Project: Ignite
> Issue Type: Bug
> Components: examples
>Affects Versions: 3.0.0-alpha5
>Reporter: Andrey Khitrin
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {*}Issue{*}: example PersistentPageMemoryStorageExample cannot be run twice.
> At the first attempt it runs fine. But at the second attempt, it fails with
> the following exception:
> {code:java}
> Exception in thread "main" java.sql.SQLException: Exception while executing
> query INSERT INTO ACCOUNTS (ACCOUNT_ID, FIRST_NAME, LAST_NAME, BALANCE)
> values (?, ?, ?, ?). Error message: java.util.concurrent.CompletionException:
> class org.apache.ignite.lang.IgniteException: Failed to INSERT some keys
> because they are already in cache. [rows=[Row[1, John, Doe, 1000.0]]]
> at
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
> at
> java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:932)
> at
> java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
> at
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
> at
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.lambda$closeAsync$0(AsyncRootNode.java:194)
> at
> java.base/java.util.concurrent.LinkedBlockingQueue.forEachFrom(LinkedBlockingQueue.java:1010)
> at
> java.base/java.util.concurrent.LinkedBlockingQueue.forEach(LinkedBlockingQueue.java:979)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.closeAsync(AsyncRootNode.java:194)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.onError(AsyncRootNode.java:149)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:157)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:157)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:157)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:298)
> at
> org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:78)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: class org.apache.ignite.lang.IgniteException: Failed to INSERT
> some keys because they are already in cache. [rows=[Row[1, John, Doe,
> 1000.0]]]
> at
> org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$0(AsyncSqlCursorImpl.java:74)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> ... 16 more
> Caused by: class org.apache.ignite.lang.IgniteInternalException: Failed to
> INSERT some keys because they are already in cache. [rows=[Row[1, John, Doe,
> 1000.0]]]
> at
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.conflictKeysException(ModifyNode.java:256)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.flushTuples(ModifyNode.java:233)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.tryEnd(ModifyNode.java:175)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.end(ModifyNode.java:148)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.ProjectNode.end(ProjectNode.java:81)
> at
> org.apache.ignite.internal.sql.engine.exec.rel.ScanNode.push(ScanNode.java:132)
> at
> org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:295)
> ... 4 more at
> org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
> at
> org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:147)
> at
>
[jira] [Updated] (IGNITE-17131) Wrong result if subquery is on the left child of LEFT JOIN operator
[
https://issues.apache.org/jira/browse/IGNITE-17131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-17131:
--
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Wrong result if subquery is on the left child of LEFT JOIN operator
> ---
>
> Key: IGNITE-17131
> URL: https://issues.apache.org/jira/browse/IGNITE-17131
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.13
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Critical
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently a query with a filtering subquery of a left side of a LEFT JOIN
> returns an invalid result. Looks like the problem is somewhere inside
> {{{}GridSubqueryJoinOptimizer{}}}.
> The possible workaround is to turn the join rewriting off by setting the
> system property {{IGNITE_ENABLE_SUBQUERY_REWRITE_OPTIMIZATION}} to false.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (IGNITE-17133) Implement user flow for CLI
Vadim Pakhnushev created IGNITE-17133:
-
Summary: Implement user flow for CLI
Key: IGNITE-17133
URL: https://issues.apache.org/jira/browse/IGNITE-17133
Project: Ignite
Issue Type: Task
Reporter: Vadim Pakhnushev
Assignee: Vadim Pakhnushev
In the REPL mode, allow the user to flow through the sequence of commands after
bootstrapping local cluster or starting a node.
{code:bash}
[disconnected]> bootstrap
Apache Ignite is successfully initialized. Do you want to start a new local
node? [Y/n]
[disconnected]> y
Enter a name for the new local node:
[disconnected]> test1
Starting a new Ignite node...
...
Node is successfully started. To stop, type node stop test1
Do you want to connect to the new node? [Y/n]
[disconnected]> y
Connected to http://localhost:10300
[http://localhost:10300]>
{code}
In order to autoconnect to the node we need to know the node url.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-17131) Wrong result if subquery is on the left child of LEFT JOIN operator
[
https://issues.apache.org/jira/browse/IGNITE-17131?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17551508#comment-17551508
]
Konstantin Orlov commented on IGNITE-17131:
---
[~tledkov-gridgain] , could you please take a look?
> Wrong result if subquery is on the left child of LEFT JOIN operator
> ---
>
> Key: IGNITE-17131
> URL: https://issues.apache.org/jira/browse/IGNITE-17131
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.13
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Critical
>
> Currently a query with a filtering subquery of a left side of a LEFT JOIN
> returns an invalid result. Looks like the problem is somewhere inside
> {{{}GridSubqueryJoinOptimizer{}}}.
> The possible workaround is to turn the join rewriting off by setting the
> system property {{IGNITE_ENABLE_SUBQUERY_REWRITE_OPTIMIZATION}} to false.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17123) Fix update counter assignment on backup nodes.
[ https://issues.apache.org/jira/browse/IGNITE-17123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-17123: -- Ignite Flags: (was: Docs Required,Release Notes Required) > Fix update counter assignment on backup nodes. > -- > > Key: IGNITE-17123 > URL: https://issues.apache.org/jira/browse/IGNITE-17123 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > Transaction reserves partition counters on primary. > On the backup side, TxEntries must be commited with counters from the > reserved range. > However, a range of update counters, which were reserved on primary, is NOT > validated on backup. Thus means NOOP invoke operation may cause partition > counter difference on the primary and backup nodes. > 1. Let's pass NOOP result of invoke operation to the backup and avoid > incorrect partition counter change on backup nodes (see DhtTxPrepareFuture). > 2. Update counter can be assigned to TxEntry instantly on tx commit on Remote > node (for the WAL purposes) instead of allocating+iterating over a new > collection (see GridDistributedTxRemoteAdapter.commitIfLocked). -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17123) Fix update counter assignment on backup nodes.
[ https://issues.apache.org/jira/browse/IGNITE-17123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-17123: -- Fix Version/s: 2.14 > Fix update counter assignment on backup nodes. > -- > > Key: IGNITE-17123 > URL: https://issues.apache.org/jira/browse/IGNITE-17123 > Project: Ignite > Issue Type: Bug > Components: cache >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > Transaction reserves partition counters on primary. > On the backup side, TxEntries must be commited with counters from the > reserved range. > However, a range of update counters, which were reserved on primary, is NOT > validated on backup. Thus means NOOP invoke operation may cause partition > counter difference on the primary and backup nodes. > 1. Let's pass NOOP result of invoke operation to the backup and avoid > incorrect partition counter change on backup nodes (see DhtTxPrepareFuture). > 2. Update counter can be assigned to TxEntry instantly on tx commit on Remote > node (for the WAL purposes) instead of allocating+iterating over a new > collection (see GridDistributedTxRemoteAdapter.commitIfLocked). -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-17119) DiscoveryClientSocketTest.sslSocketTest fails regularly on TC and locally
[ https://issues.apache.org/jira/browse/IGNITE-17119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17551495#comment-17551495 ] Roman Puchkovskiy commented on IGNITE-17119: Thanks! > DiscoveryClientSocketTest.sslSocketTest fails regularly on TC and locally > - > > Key: IGNITE-17119 > URL: https://issues.apache.org/jira/browse/IGNITE-17119 > Project: Ignite > Issue Type: Bug > Components: networking >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=1051723478826841368=testDetails -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (IGNITE-17106) Create documentation for Java SQL API
[ https://issues.apache.org/jira/browse/IGNITE-17106?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Gusev reassigned IGNITE-17106: --- Assignee: Igor Gusev > Create documentation for Java SQL API > - > > Key: IGNITE-17106 > URL: https://issues.apache.org/jira/browse/IGNITE-17106 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 1h 40m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-17132) [Native Persistence 3.0] Implement partition destruction for persistent PageMemory
Kirill Tkalenko created IGNITE-17132: Summary: [Native Persistence 3.0] Implement partition destruction for persistent PageMemory Key: IGNITE-17132 URL: https://issues.apache.org/jira/browse/IGNITE-17132 Project: Ignite Issue Type: Task Reporter: Kirill Tkalenko Fix For: 3.0.0-alpha6 At the moment, the partition destruction operation does not work quite correctly, we just go through all the records and explicitly delete them, but we cannot delete the partition file, because the checkpoint will then not be able to write pages to this partition file and it will have an error. Before implementation, you need to think about how to do it, but in any case, deleting the partition file should definitely do a checkpoint. See: *org.apache.ignite.internal.storage.pagememory.PersistentPageMemoryPartitionStorage#destroy* -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17013) Implement failure handling for changePeerAsync invocation regarding rebalance algorithm
[
https://issues.apache.org/jira/browse/IGNITE-17013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17013:
-
Reviewer: Alexander Lapin
> Implement failure handling for changePeerAsync invocation regarding rebalance
> algorithm
> -
>
> Key: IGNITE-17013
> URL: https://issues.apache.org/jira/browse/IGNITE-17013
> Project: Ignite
> Issue Type: Task
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> According to the relalance algorithm
> https://github.com/apache/ignite-3/blob/main/modules/table/tech-notes/rebalance.md
> after leader node receives an updating of a pending key, it starts a raft
> group reconfiguration by calling {{RaftGroupService#changePeersAsync}} which
> returns future, that can be completed exceptionally. We should provide the
> way to retry {{RaftGroupService#changePeersAsync}} invocation, with some
> throttling, and in case of failure cancel the current rebalance.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-17013) Implement failure handling for changePeerAsync invocation regarding rebalance algorithm
[
https://issues.apache.org/jira/browse/IGNITE-17013?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17551474#comment-17551474
]
Alexander Lapin commented on IGNITE-17013:
--
[~maliev] LGTM
> Implement failure handling for changePeerAsync invocation regarding rebalance
> algorithm
> -
>
> Key: IGNITE-17013
> URL: https://issues.apache.org/jira/browse/IGNITE-17013
> Project: Ignite
> Issue Type: Task
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
>
> According to the relalance algorithm
> https://github.com/apache/ignite-3/blob/main/modules/table/tech-notes/rebalance.md
> after leader node receives an updating of a pending key, it starts a raft
> group reconfiguration by calling {{RaftGroupService#changePeersAsync}} which
> returns future, that can be completed exceptionally. We should provide the
> way to retry {{RaftGroupService#changePeersAsync}} invocation, with some
> throttling, and in case of failure cancel the current rebalance.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17131) Wrong result if subquery is on the left child of LEFT JOIN operator
[
https://issues.apache.org/jira/browse/IGNITE-17131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-17131:
--
Summary: Wrong result if subquery is on the left child of LEFT JOIN
operator (was: Wrong result if subquery is the left child of LEFT JOIN
operator)
> Wrong result if subquery is on the left child of LEFT JOIN operator
> ---
>
> Key: IGNITE-17131
> URL: https://issues.apache.org/jira/browse/IGNITE-17131
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.13
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Critical
>
> Currently a query with a filtering subquery of a left side of a LEFT JOIN
> returns an invalid result. Looks like the problem is somewhere inside
> {{{}GridSubqueryJoinOptimizer{}}}.
> The possible workaround is to turn the join rewriting off by setting the
> system property {{IGNITE_ENABLE_SUBQUERY_REWRITE_OPTIMIZATION}} to false.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (IGNITE-17131) Wrong result if subquery is the left child of LEFT JOIN operator
Konstantin Orlov created IGNITE-17131:
-
Summary: Wrong result if subquery is the left child of LEFT JOIN
operator
Key: IGNITE-17131
URL: https://issues.apache.org/jira/browse/IGNITE-17131
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 2.13
Reporter: Konstantin Orlov
Assignee: Konstantin Orlov
Currently a query with a filtering subquery of a left side of a LEFT JOIN
returns an invalid result. Looks like the problem is somewhere inside
{{{}GridSubqueryJoinOptimizer{}}}.
The possible workaround is to turn the join rewriting off by setting the system
property {{IGNITE_ENABLE_SUBQUERY_REWRITE_OPTIMIZATION}} to false.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-17111) Remove the ability to set the lazy flag in SqlFieldsQuery
[ https://issues.apache.org/jira/browse/IGNITE-17111?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17551428#comment-17551428 ] Luchnikov Alexander commented on IGNITE-17111: -- [~jooger] I understand this, I started the task so as not to forget. Not the first year we have to solve problems caused by lazy=false. In the first iteration, I would like not to remove setLazy from the public API, so as not to force everyone to update the application code. It is enough to mark this method as deprecated, with a detailed comment. When trying to use this method, write to the WARN log, but so as not to spam the log - for example, once an hour. I'll discuss it on the dev list. > Remove the ability to set the lazy flag in SqlFieldsQuery > - > > Key: IGNITE-17111 > URL: https://issues.apache.org/jira/browse/IGNITE-17111 > Project: Ignite > Issue Type: Improvement >Reporter: Luchnikov Alexander >Priority: Minor > Labels: ise > > Remove the ability to set the lazy flag in SqlFieldsQuery. SqlFieldsQuery > must always be executed as lazy=true. > This property > (org.apache.igniteIgniteSystemProperties#IGNITE_SQL_FORCE_LAZY_RESULT_SET) > refers to the same functionality, but is not used in the code. -- This message was sent by Atlassian Jira (v8.20.7#820007)
