[jira] [Created] (IGNITE-16505) Calcite engine. Move row count approximation from ignite-indexing
Aleksey Plekhanov created IGNITE-16505:
--
Summary: 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
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-16265) Integration SQL Index and data storage
[ https://issues.apache.org/jira/browse/IGNITE-16265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-16265: --- Description: Need to think about point of integration of data modification (put/remove/amend) with update data at SQL indexes. Let's as first version for integation will be update index on commit. was:Need to think about point of integration of data modification (put/remove/amend) with update data at SQL indexes. > Integration SQL Index and data storage > -- > > Key: IGNITE-16265 > URL: https://issues.apache.org/jira/browse/IGNITE-16265 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > Need to think about point of integration of data modification > (put/remove/amend) with update data at SQL indexes. > Let's as first version for integation will be update index on commit. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16503) Research distributed TX protocol in FoundationDB
[ https://issues.apache.org/jira/browse/IGNITE-16503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16503: - Priority: Minor (was: Major) > Research distributed TX protocol in FoundationDB > > > Key: IGNITE-16503 > URL: https://issues.apache.org/jira/browse/IGNITE-16503 > Project: Ignite > Issue Type: Task >Reporter: Vyacheslav Koptilin >Priority: Minor > Labels: ignite-3 > > Let's read, understand and discuss the TX architecture that is used in > FoundationDB: > https://www.foundationdb.org/files/fdb-paper.pdf -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16501) TX Recovery protocol in Cockroach
[ https://issues.apache.org/jira/browse/IGNITE-16501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16501: - Ignite Flags: (was: Docs Required,Release Notes Required) > TX Recovery protocol in Cockroach > - > > Key: IGNITE-16501 > URL: https://issues.apache.org/jira/browse/IGNITE-16501 > Project: Ignite > Issue Type: Task >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16501) TX Recovery protocol in Cockroach
[ https://issues.apache.org/jira/browse/IGNITE-16501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-16501: Assignee: Sergey Uttsel > TX Recovery protocol in Cockroach > - > > 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 > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16500) In-depth research of Calvin protocol
[ https://issues.apache.org/jira/browse/IGNITE-16500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16500: - Ignite Flags: (was: Docs Required,Release Notes Required) > In-depth research of Calvin protocol > - > > Key: IGNITE-16500 > URL: https://issues.apache.org/jira/browse/IGNITE-16500 > Project: Ignite > Issue Type: Task >Reporter: Vyacheslav Koptilin >Priority: Minor > Labels: ignite-3 > > Let's read, understand and discuss the following: > http://cs.yale.edu/homes/thomson/publications/calvin-sigmod12.pdf > https://fauna.com/blog/consistency-without-clocks-faunadb-transaction-protocol -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16500) In-depth research of Calvin protocol
[ https://issues.apache.org/jira/browse/IGNITE-16500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16500: - Priority: Minor (was: Major) > In-depth research of Calvin protocol > - > > Key: IGNITE-16500 > URL: https://issues.apache.org/jira/browse/IGNITE-16500 > Project: Ignite > Issue Type: Task >Reporter: Vyacheslav Koptilin >Priority: Minor > Labels: ignite-3 > > Let's read, understand and discuss the following: > http://cs.yale.edu/homes/thomson/publications/calvin-sigmod12.pdf > https://fauna.com/blog/consistency-without-clocks-faunadb-transaction-protocol -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16503) Research distributed TX protocol in FoundationDB
[ https://issues.apache.org/jira/browse/IGNITE-16503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16503: - Summary: Research distributed TX protocol in FoundationDB (was: Research distributed TX protocol in FaunaDB) > Research distributed TX protocol in FoundationDB > > > Key: IGNITE-16503 > URL: https://issues.apache.org/jira/browse/IGNITE-16503 > Project: Ignite > Issue Type: Task >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > > Let's read, understand and discuss the TX architecture that is used in > FoundationDB: > https://www.foundationdb.org/files/fdb-paper.pdf -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16503) Research distributed TX protocol in FaunaDB
[ https://issues.apache.org/jira/browse/IGNITE-16503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16503: - Description: Let's read, understand and discuss the TX architecture that is used in FoundationDB: https://www.foundationdb.org/files/fdb-paper.pdf was: Let's read, understand and discuss the TX architecture that is used in FaunaDB: https://fauna.com/blog/consistency-without-clocks-faunadb-transaction-protocol > Research distributed TX protocol in FaunaDB > --- > > Key: IGNITE-16503 > URL: https://issues.apache.org/jira/browse/IGNITE-16503 > Project: Ignite > Issue Type: Task >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > > Let's read, understand and discuss the TX architecture that is used in > FoundationDB: > https://www.foundationdb.org/files/fdb-paper.pdf -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16500) In-depth research of Calvin protocol
[ https://issues.apache.org/jira/browse/IGNITE-16500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16500: - Description: Let's read, understand and discuss the following: http://cs.yale.edu/homes/thomson/publications/calvin-sigmod12.pdf https://fauna.com/blog/consistency-without-clocks-faunadb-transaction-protocol was: Let's read, understand and discuss the following: http://cs.yale.edu/homes/thomson/publications/calvin-sigmod12.pdf > In-depth research of Calvin protocol > - > > Key: IGNITE-16500 > URL: https://issues.apache.org/jira/browse/IGNITE-16500 > Project: Ignite > Issue Type: Task >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > > Let's read, understand and discuss the following: > http://cs.yale.edu/homes/thomson/publications/calvin-sigmod12.pdf > https://fauna.com/blog/consistency-without-clocks-faunadb-transaction-protocol -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16504) Sort out and merge Calcite tickets to Ignite 3.0 (step 4)
Yury Gerzhedovich created IGNITE-16504: -- Summary: Sort out and merge Calcite tickets to Ignite 3.0 (step 4) Key: IGNITE-16504 URL: https://issues.apache.org/jira/browse/IGNITE-16504 Project: Ignite Issue Type: Improvement Components: sql Reporter: Yury Gerzhedovich Let's sort out tikets contains by [filter|https://issues.apache.org/jira/issues/?jql=project%3DIgnite%20and%20labels%20in(calcite3-required)%20and%20labels%20not%20in(calcite2-required)%20order%20by%20resolutiondate%20ASC]. Tickets that could be simply merged - merge immediately. For hard cases let's create separate tickets with estimation and link them to IGNITE-15658 or links to blocker ticket. h4. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16217) Calcite engine. Upgrade Apache Calcite dependency to 1.29.0
[ https://issues.apache.org/jira/browse/IGNITE-16217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-16217: Labels: calcite (was: calcite3-required) > Calcite engine. Upgrade Apache Calcite dependency to 1.29.0 > --- > > Key: IGNITE-16217 > URL: https://issues.apache.org/jira/browse/IGNITE-16217 > Project: Ignite > Issue Type: Task >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: calcite > Time Spent: 50m > Remaining Estimate: 0h > > New version of Apache Calcite is released, we should upgrade version in > ignite-calcite module. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16091) ItCliServiceTest.testChangePeers is flaky
[
https://issues.apache.org/jira/browse/IGNITE-16091?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Gusakov updated IGNITE-16091:
Attachment: _Integration_Tests_Module_Raft_3747.log.zip
> ItCliServiceTest.testChangePeers is flaky
> -
>
> Key: IGNITE-16091
> URL: https://issues.apache.org/jira/browse/IGNITE-16091
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha3
>Reporter: Vyacheslav Koptilin
>Assignee: Kirill Gusakov
>Priority: Major
> Labels: ignite-3
> Attachments: _Integration_Tests_Module_Raft_3747.log.zip,
> _Integration_Tests_Module_Raft_785.log.zip
>
>
> The ItCliServiceTest#testChangePeers may fail with the following message:
> {noformat}
> org.opentest4j.AssertionFailedError
> org.opentest4j.AssertionFailedError: Peer 172.17.0.5:5009 failed to catch up.
> ==> expected: but was:
> at
> org.apache.ignite.raft.jraft.core.ItCliServiceTest.testChangePeers(ItCliServiceTest.java:320)
> {noformat}
> TeamCity:
> https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_ModuleRaft/6305117
> Logs attached.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16091) ItCliServiceTest.testChangePeers is flaky
[
https://issues.apache.org/jira/browse/IGNITE-16091?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488976#comment-17488976
]
Kirill Gusakov commented on IGNITE-16091:
-
Reproduced: 1 fail from 500 runs. Logs attached, a detailed investigation is
needed. [^_Integration_Tests_Module_Raft_3747.log.zip]
> ItCliServiceTest.testChangePeers is flaky
> -
>
> Key: IGNITE-16091
> URL: https://issues.apache.org/jira/browse/IGNITE-16091
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha3
>Reporter: Vyacheslav Koptilin
>Assignee: Kirill Gusakov
>Priority: Major
> Labels: ignite-3
> Attachments: _Integration_Tests_Module_Raft_3747.log.zip,
> _Integration_Tests_Module_Raft_785.log.zip
>
>
> The ItCliServiceTest#testChangePeers may fail with the following message:
> {noformat}
> org.opentest4j.AssertionFailedError
> org.opentest4j.AssertionFailedError: Peer 172.17.0.5:5009 failed to catch up.
> ==> expected: but was:
> at
> org.apache.ignite.raft.jraft.core.ItCliServiceTest.testChangePeers(ItCliServiceTest.java:320)
> {noformat}
> TeamCity:
> https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_ModuleRaft/6305117
> Logs attached.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16368) Implement a futures for causality tokens
[ https://issues.apache.org/jira/browse/IGNITE-16368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488972#comment-17488972 ] Denis Chudov commented on IGNITE-16368: --- [~v.pyatkov] LGTM. > Implement a futures for causality tokens > > > Key: IGNITE-16368 > URL: https://issues.apache.org/jira/browse/IGNITE-16368 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > Time Spent: 2h 40m > Remaining Estimate: 0h > > One can create a future for some component with some causality token. This > future completes when this component has handled all notifications having the > given causality token. More formally, it completes when the component handles > notification about storage revision update having the given causality token. > When a component listener handles a notification, it must execute the code > that relies on the state of the depended component, after completion of the > future, created for this component with a certain causality token received > within the notification. This guarantees that notifications will be handled > by component listeners in a proper order. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16012) Raft changePeers behavior must be updated to async version
[
https://issues.apache.org/jira/browse/IGNITE-16012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488961#comment-17488961
]
Mirza Aliev commented on IGNITE-16012:
--
Kirill, thanks for the review! Merged to feature branch
{{gridgain/ignite-14209}}
> Raft changePeers behavior must be updated to async version
> --
>
> Key: IGNITE-16012
> URL: https://issues.apache.org/jira/browse/IGNITE-16012
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Gusakov
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We need to update the current {{changePeers}} behavior with the following:
> - it must be asynchronous and returns ASAP when the request processed
> (without waiting for data catchup)
> - it must be updated with {{term}} argument for skipping the updates from
> old terms
>
> (Phase 1)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16406) SQL select operation could return incomplete data
[
https://issues.apache.org/jira/browse/IGNITE-16406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-16406:
-
Description:
For some reasons select operation couldn't return expected number of rows. We
noticed that this happens when raft leader is changing. To increase
reproducibility, we can slow down a bit message handling, for example by adding
this code to {{MessageServiceImpl#onMessage(java.lang.String,
org.apache.ignite.network.NetworkMessage)}}
{code:java}
if (ThreadLocalRandom.current().nextInt(3) % 2 == 0) {
try {
Thread.sleep(300);
} catch (Exception ex) {
ex.printStackTrace();
}
}
{code}
Possible direction of research:
we could check that we do not lose cursor.next command as a raft response
during the process of leader changing.
UPD:
We decided to add checking for consistency between received scan command and
handled scan command in partition listener, so now a user will get state
machine error and could retry his command. But we found another inconsistency
when RocksDB could return hasNext == false after an unexpected step down of the
leader (https://issues.apache.org/jira/browse/IGNITE-16478).
So, we decided then to change the replica factor to 1 in
{{ItMixedQueriesTest}}, so there will be only one node in a partition Raft
group, but we couldn't enable {{ItMixedQueriesTest}} because of new error
https://issues.apache.org/jira/browse/IGNITE-16502
was:
For some reasons select operation couldn't return expected number of rows. We
noticed that this happens when raft leader is changing. To increase
reproducibility, we can slow down a bit message handling, for example by adding
this code to {{MessageServiceImpl#onMessage(java.lang.String,
org.apache.ignite.network.NetworkMessage)}}
{code:java}
if (ThreadLocalRandom.current().nextInt(3) % 2 == 0) {
try {
Thread.sleep(300);
} catch (Exception ex) {
ex.printStackTrace();
}
}
{code}
Possible direction of research:
we could check that we do not lose cursor.next command as a raft response
during the process of leader changing.
UPD: We decided to add checking for consistency between received scan command
and handled scan command in partition listener, so now a user will get state
machine error and could retry his command. But we found another inconsistency
when RocksDB could return hasNext == false after an unexpected step down of the
leader (https://issues.apache.org/jira/browse/IGNITE-16478).
So, we decided then to change the replica factor to 1 in
{{ItMixedQueriesTest}}, so there will be only one node in a partition Raft
group, but we couldn't enable {{ItMixedQueriesTest}} because of new error
https://issues.apache.org/jira/browse/IGNITE-16502
> SQL select operation could return incomplete data
> -
>
> Key: IGNITE-16406
> URL: https://issues.apache.org/jira/browse/IGNITE-16406
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Blocker
> Labels: ignite-3
>
> For some reasons select operation couldn't return expected number of rows. We
> noticed that this happens when raft leader is changing. To increase
> reproducibility, we can slow down a bit message handling, for example by
> adding this code to {{MessageServiceImpl#onMessage(java.lang.String,
> org.apache.ignite.network.NetworkMessage)}}
> {code:java}
> if (ThreadLocalRandom.current().nextInt(3) % 2 == 0) {
> try {
> Thread.sleep(300);
> } catch (Exception ex) {
> ex.printStackTrace();
> }
> }
> {code}
> Possible direction of research:
> we could check that we do not lose cursor.next command as a raft response
> during the process of leader changing.
> UPD:
> We decided to add checking for consistency between received scan command and
> handled scan command in partition listener, so now a user will get state
> machine error and could retry his command. But we found another inconsistency
> when RocksDB could return hasNext == false after an unexpected step down of
> the leader (https://issues.apache.org/jira/browse/IGNITE-16478).
> So, we decided then to change the replica factor to 1 in
> {{ItMixedQueriesTest}}, so there will be only one node in a partition Raft
> group, but we couldn't enable {{ItMixedQueriesTest}} because of new error
> https://issues.apache.org/jira/browse/IGNITE-16502
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16501) TX Recovery protocol in Cockroach
[ https://issues.apache.org/jira/browse/IGNITE-16501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16501: - Summary: TX Recovery protocol in Cockroach (was: TX Recovery protocol that is used by CockroachDB) > TX Recovery protocol in Cockroach > - > > Key: IGNITE-16501 > URL: https://issues.apache.org/jira/browse/IGNITE-16501 > Project: Ignite > Issue Type: Task >Reporter: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16503) Research distributed TX protocol in FaunaDB
Vyacheslav Koptilin created IGNITE-16503: Summary: Research distributed TX protocol in FaunaDB Key: IGNITE-16503 URL: https://issues.apache.org/jira/browse/IGNITE-16503 Project: Ignite Issue Type: Task Reporter: Vyacheslav Koptilin Let's read, understand and discuss the TX architecture that is used in FaunaDB: https://fauna.com/blog/consistency-without-clocks-faunadb-transaction-protocol -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Comment Edited] (IGNITE-16478) RocksDB returns unexpected cursor.hasNext equals false after leader is changed
[
https://issues.apache.org/jira/browse/IGNITE-16478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488932#comment-17488932
]
Mirza Aliev edited comment on IGNITE-16478 at 2/8/22, 3:13 PM:
---
We analysed debug logs from TC in and came up with possible ways of
investigation:
* Why we got {{ETIMEDOUT<1010>: RPC exception:null}}.
Probably it entails further majority death {{[ERAFTTIMEDOUT<10001>: Majority of
the group dies: 1/2]}} and stepping down of the leader.
* In log we could see that we have several {{can't apply,
status=Status[EPERM<1008>: Is not leader.]}} messages, which means that some
task weren't applied to leaders log. Need to figure out what tasks weren't
applied and check if we lost them completely.
* In logs we can see {{called hasNext = false, cur = null}} which was logged
after {{internalBatchCounter = 0 clo.command().getCounter() = 1}}; hasNext =
false is not expected as far as new leader was supposed to return true for our
scan command. That means that we've got {{isValid}} equal false for internal
iterator {{RocksIterator}} of RocksDB. (see
{{org.apache.ignite.internal.rocksdb.RocksIteratorAdapter#hasNext}})
{noformat}
[14:34:42]W: 2022-02-07 14:34:42:780 +0300 [INFO][main][ItMixedQueriesTest] >>>
Starting test: ItMixedQueriesTest#testOrderingByColumnOutsideSelectList,
displayName: repetition 113 of 1000, workDir:
/opt/buildagent/work/b8d4df1365f1f1e5/modules/runner/target/work/ItMixedQueriesTest/static_1644233560390
[14:34:43]W: 2022-02-07 14:34:43:076 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-AppendEntries-Processor-0][Replicator]
Node 3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0:172.17.0.6:3345 received
AppendEntriesResponse from 172.17.0.6:3344 prevLogIndex=1010 prevLogTerm=1
count=1 fail, sleep, status=Status[ETIMEDOUT<1010>: RPC exception:null]
[14:34:43]W: 2022-02-07 14:34:43:076 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-AppendEntries-Processor-0][Replicator]
Blocking 172.17.0.6:3344 for 120 ms
[14:34:43]W: 2022-02-07 14:34:43:077 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-AppendEntries-Processor-0][Replicator]
Replicator Replicator [state=Probe, statInfo=,
peerId=172.17.0.6:3344, type=Follower] is processing RPC responses, after
processed, continue to send entries: false
[14:34:43]W: 2022-02-07 14:34:43:077 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-AppendEntries-Processor-0][Replicator]
Node 3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0:172.17.0.6:3345 received
HeartbeatResponse from 172.17.0.6:3344 prevLogIndex=1010 prevLogTerm=1
[14:34:43]W: 2022-02-07 14:34:43:092 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-AppendEntries-Processor-0][Replicator]
Replicator Replicator [state=Probe, statInfo=,
peerId=172.17.0.6:3344, type=Follower] ignored old version response 78, current
version is 79, request is
org.apache.ignite.raft.jraft.rpc.AppendEntriesRequestImpl@82dd5f83
[14:34:43]W: , and response is null
[14:34:43]W: , status is Status[ETIMEDOUT<1010>: RPC exception:null].
[14:34:43]W: 2022-02-07 14:34:43:197 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-Common-Executor-13][Replicator] Node
<3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0/172.17.0.6:3345> send
HeartbeatRequest to 172.17.0.6:3344 term 1 lastCommittedIndex 1010
[14:34:43]W: 2022-02-07 14:34:43:198 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-Common-Executor-8][Replicator] Node
<3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0/172.17.0.6:3345> send
HeartbeatRequest to 172.17.0.6:3344 term 1 lastCommittedIndex 1010
[14:34:43]W: 2022-02-07 14:34:43:621 +0300
[WARNING][%ItMixedQueriesTest_null_1%JRaft-StepDownTimer-11][NodeImpl] Node
<3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0/172.17.0.6:3345> steps down when
alive nodes don't satisfy quorum, term=1, deadNodes=172.17.0.6:3344,
conf=172.17.0.6:3344,172.17.0.6:3345.
[14:34:43]W: 2022-02-07 14:34:43:621 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-StepDownTimer-11][NodeImpl] Node
<3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0/172.17.0.6:3345> stepDown,
term=1, newTerm=1, wakeupCandidate=false.
[14:34:43]W: 2022-02-07 14:34:43:622 +0300
[INFO][%ItMixedQueriesTest_null_1%JRaft-FSMCaller-Disruptor-_stripe_2-0][StateMachineAdapter]
onLeaderStop: status=Status[ERAFTTIMEDOUT<10001>: Majority of the group dies:
1/2].
[14:34:43]W: 2022-02-07 14:34:43:622 +0300
[INFO][%ItMixedQueriesTest_null_1%JRaft-StepDownTimer-11][Replicator]
Replicator Replicator [state=Probe, statInfo=,
peerId=172.17.0.6:3344, type=Follower] is going to quit
[14:34:43]W: 2022-02-07 14:34:43:681 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-NodeImpl-Disruptor-_stripe_2-0][NodeImpl]
Node <3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0/172.17.0.6:3345> can't
apply, status=Status[EPERM<1008>: Is not leader.].
[14:34:43]W: 2022-02-07 14:34:43:884 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-NodeImpl-Disruptor-_stripe_2-0][NodeImpl]
[jira] [Comment Edited] (IGNITE-16478) RocksDB returns unexpected cursor.hasNext equals false after leader is changed
[
https://issues.apache.org/jira/browse/IGNITE-16478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488932#comment-17488932
]
Mirza Aliev edited comment on IGNITE-16478 at 2/8/22, 3:13 PM:
---
We analysed debug logs from TC in and came up with possible ways of
investigation:
* Why we got {{ETIMEDOUT<1010>: RPC exception:null}}.
Probably it entails further majority death {{[ERAFTTIMEDOUT<10001>: Majority of
the group dies: 1/2]}} and stepping down of the leader.
* In log we could see that we have several {{can't apply,
status=Status[EPERM<1008>: Is not leader.]}} messages, which means that some
task weren't applied to leaders log. Need to figure out what tasks weren't
applied and check if we lost them completely.
* In logs we can see {{called hasNext = false, cur = null}} which was logged
after {{internalBatchCounter = 0 clo.command().getCounter() = 1}}, hasNext =
false is not expected as far as new leader was supposed to return true for our
scan command. That means that we've got {{isValid}} equal false for internal
iterator {{RocksIterator}} of RocksDB. (see
{{org.apache.ignite.internal.rocksdb.RocksIteratorAdapter#hasNext}})
{noformat}
[14:34:42]W: 2022-02-07 14:34:42:780 +0300 [INFO][main][ItMixedQueriesTest] >>>
Starting test: ItMixedQueriesTest#testOrderingByColumnOutsideSelectList,
displayName: repetition 113 of 1000, workDir:
/opt/buildagent/work/b8d4df1365f1f1e5/modules/runner/target/work/ItMixedQueriesTest/static_1644233560390
[14:34:43]W: 2022-02-07 14:34:43:076 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-AppendEntries-Processor-0][Replicator]
Node 3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0:172.17.0.6:3345 received
AppendEntriesResponse from 172.17.0.6:3344 prevLogIndex=1010 prevLogTerm=1
count=1 fail, sleep, status=Status[ETIMEDOUT<1010>: RPC exception:null]
[14:34:43]W: 2022-02-07 14:34:43:076 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-AppendEntries-Processor-0][Replicator]
Blocking 172.17.0.6:3344 for 120 ms
[14:34:43]W: 2022-02-07 14:34:43:077 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-AppendEntries-Processor-0][Replicator]
Replicator Replicator [state=Probe, statInfo=,
peerId=172.17.0.6:3344, type=Follower] is processing RPC responses, after
processed, continue to send entries: false
[14:34:43]W: 2022-02-07 14:34:43:077 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-AppendEntries-Processor-0][Replicator]
Node 3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0:172.17.0.6:3345 received
HeartbeatResponse from 172.17.0.6:3344 prevLogIndex=1010 prevLogTerm=1
[14:34:43]W: 2022-02-07 14:34:43:092 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-AppendEntries-Processor-0][Replicator]
Replicator Replicator [state=Probe, statInfo=,
peerId=172.17.0.6:3344, type=Follower] ignored old version response 78, current
version is 79, request is
org.apache.ignite.raft.jraft.rpc.AppendEntriesRequestImpl@82dd5f83
[14:34:43]W: , and response is null
[14:34:43]W: , status is Status[ETIMEDOUT<1010>: RPC exception:null].
[14:34:43]W: 2022-02-07 14:34:43:197 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-Common-Executor-13][Replicator] Node
<3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0/172.17.0.6:3345> send
HeartbeatRequest to 172.17.0.6:3344 term 1 lastCommittedIndex 1010
[14:34:43]W: 2022-02-07 14:34:43:198 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-Common-Executor-8][Replicator] Node
<3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0/172.17.0.6:3345> send
HeartbeatRequest to 172.17.0.6:3344 term 1 lastCommittedIndex 1010
[14:34:43]W: 2022-02-07 14:34:43:621 +0300
[WARNING][%ItMixedQueriesTest_null_1%JRaft-StepDownTimer-11][NodeImpl] Node
<3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0/172.17.0.6:3345> steps down when
alive nodes don't satisfy quorum, term=1, deadNodes=172.17.0.6:3344,
conf=172.17.0.6:3344,172.17.0.6:3345.
[14:34:43]W: 2022-02-07 14:34:43:621 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-StepDownTimer-11][NodeImpl] Node
<3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0/172.17.0.6:3345> stepDown,
term=1, newTerm=1, wakeupCandidate=false.
[14:34:43]W: 2022-02-07 14:34:43:622 +0300
[INFO][%ItMixedQueriesTest_null_1%JRaft-FSMCaller-Disruptor-_stripe_2-0][StateMachineAdapter]
onLeaderStop: status=Status[ERAFTTIMEDOUT<10001>: Majority of the group dies:
1/2].
[14:34:43]W: 2022-02-07 14:34:43:622 +0300
[INFO][%ItMixedQueriesTest_null_1%JRaft-StepDownTimer-11][Replicator]
Replicator Replicator [state=Probe, statInfo=,
peerId=172.17.0.6:3344, type=Follower] is going to quit
[14:34:43]W: 2022-02-07 14:34:43:681 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-NodeImpl-Disruptor-_stripe_2-0][NodeImpl]
Node <3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0/172.17.0.6:3345> can't
apply, status=Status[EPERM<1008>: Is not leader.].
[14:34:43]W: 2022-02-07 14:34:43:884 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-NodeImpl-Disruptor-_stripe_2-0][NodeImpl]
[jira] [Comment Edited] (IGNITE-16478) RocksDB returns unexpected cursor.hasNext equals false after leader is changed
[
https://issues.apache.org/jira/browse/IGNITE-16478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488932#comment-17488932
]
Mirza Aliev edited comment on IGNITE-16478 at 2/8/22, 3:12 PM:
---
We analysed debug logs from TC in and came up with possible ways of
investigation:
* Why we got {{ETIMEDOUT<1010>: RPC exception:null}}.
Probably it entails further majority death {{[ERAFTTIMEDOUT<10001>: Majority of
the group dies: 1/2]}} and stepping down of the leader.
* In log we could see that we have several {{can't apply,
status=Status[EPERM<1008>: Is not leader.]}} messages, which means that some
task weren't applied to leaders log. Need to figure out what task weren't
applied and check if we lost them completely.
* In logs we can see {{called hasNext = false, cur = null}} which was logged
after {{internalBatchCounter = 0 clo.command().getCounter() = 1}}, hasNext =
false is not expected as far as new leader was supposed to return true for our
scan command. That means that we've got {{isValid}} equal false for internal
iterator {{RocksIterator}} of RocksDB. (see
{{org.apache.ignite.internal.rocksdb.RocksIteratorAdapter#hasNext}})
{noformat}
[14:34:42]W: 2022-02-07 14:34:42:780 +0300 [INFO][main][ItMixedQueriesTest] >>>
Starting test: ItMixedQueriesTest#testOrderingByColumnOutsideSelectList,
displayName: repetition 113 of 1000, workDir:
/opt/buildagent/work/b8d4df1365f1f1e5/modules/runner/target/work/ItMixedQueriesTest/static_1644233560390
[14:34:43]W: 2022-02-07 14:34:43:076 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-AppendEntries-Processor-0][Replicator]
Node 3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0:172.17.0.6:3345 received
AppendEntriesResponse from 172.17.0.6:3344 prevLogIndex=1010 prevLogTerm=1
count=1 fail, sleep, status=Status[ETIMEDOUT<1010>: RPC exception:null]
[14:34:43]W: 2022-02-07 14:34:43:076 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-AppendEntries-Processor-0][Replicator]
Blocking 172.17.0.6:3344 for 120 ms
[14:34:43]W: 2022-02-07 14:34:43:077 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-AppendEntries-Processor-0][Replicator]
Replicator Replicator [state=Probe, statInfo=,
peerId=172.17.0.6:3344, type=Follower] is processing RPC responses, after
processed, continue to send entries: false
[14:34:43]W: 2022-02-07 14:34:43:077 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-AppendEntries-Processor-0][Replicator]
Node 3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0:172.17.0.6:3345 received
HeartbeatResponse from 172.17.0.6:3344 prevLogIndex=1010 prevLogTerm=1
[14:34:43]W: 2022-02-07 14:34:43:092 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-AppendEntries-Processor-0][Replicator]
Replicator Replicator [state=Probe, statInfo=,
peerId=172.17.0.6:3344, type=Follower] ignored old version response 78, current
version is 79, request is
org.apache.ignite.raft.jraft.rpc.AppendEntriesRequestImpl@82dd5f83
[14:34:43]W: , and response is null
[14:34:43]W: , status is Status[ETIMEDOUT<1010>: RPC exception:null].
[14:34:43]W: 2022-02-07 14:34:43:197 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-Common-Executor-13][Replicator] Node
<3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0/172.17.0.6:3345> send
HeartbeatRequest to 172.17.0.6:3344 term 1 lastCommittedIndex 1010
[14:34:43]W: 2022-02-07 14:34:43:198 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-Common-Executor-8][Replicator] Node
<3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0/172.17.0.6:3345> send
HeartbeatRequest to 172.17.0.6:3344 term 1 lastCommittedIndex 1010
[14:34:43]W: 2022-02-07 14:34:43:621 +0300
[WARNING][%ItMixedQueriesTest_null_1%JRaft-StepDownTimer-11][NodeImpl] Node
<3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0/172.17.0.6:3345> steps down when
alive nodes don't satisfy quorum, term=1, deadNodes=172.17.0.6:3344,
conf=172.17.0.6:3344,172.17.0.6:3345.
[14:34:43]W: 2022-02-07 14:34:43:621 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-StepDownTimer-11][NodeImpl] Node
<3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0/172.17.0.6:3345> stepDown,
term=1, newTerm=1, wakeupCandidate=false.
[14:34:43]W: 2022-02-07 14:34:43:622 +0300
[INFO][%ItMixedQueriesTest_null_1%JRaft-FSMCaller-Disruptor-_stripe_2-0][StateMachineAdapter]
onLeaderStop: status=Status[ERAFTTIMEDOUT<10001>: Majority of the group dies:
1/2].
[14:34:43]W: 2022-02-07 14:34:43:622 +0300
[INFO][%ItMixedQueriesTest_null_1%JRaft-StepDownTimer-11][Replicator]
Replicator Replicator [state=Probe, statInfo=,
peerId=172.17.0.6:3344, type=Follower] is going to quit
[14:34:43]W: 2022-02-07 14:34:43:681 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-NodeImpl-Disruptor-_stripe_2-0][NodeImpl]
Node <3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0/172.17.0.6:3345> can't
apply, status=Status[EPERM<1008>: Is not leader.].
[14:34:43]W: 2022-02-07 14:34:43:884 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-NodeImpl-Disruptor-_stripe_2-0][NodeImpl]
[jira] [Commented] (IGNITE-16478) RocksDB returns unexpected cursor.hasNext equals false after leader is changed
[
https://issues.apache.org/jira/browse/IGNITE-16478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488932#comment-17488932
]
Mirza Aliev commented on IGNITE-16478:
--
We analysed debug logs from TC in and came up with possible ways of
investigation:
* Why we got {{ETIMEDOUT<1010>: RPC exception:null}} Probably it entail further
majority death {{[ERAFTTIMEDOUT<10001>: Majority of the group dies: 1/2]}} and
stepping down of the leader.
* In log we could see that we have several {{can't apply,
status=Status[EPERM<1008>: Is not leader.]}} messages, which means that some
task weren't applied to leaders log. Need to figure out what task weren't
applied and check if we lost them completely.
* In logs we can see {{called hasNext = false, cur = null}} which was logged
after {{internalBatchCounter = 0 clo.command().getCounter() = 1}}, hasNext =
false is not expected as far as new leader was supposed to return true for our
scan command. That means that we've got {{isValid}} equal false for internal
iterator {{RocksIterator}} of RocksDB. (see
{{org.apache.ignite.internal.rocksdb.RocksIteratorAdapter#hasNext}})
{noformat}
[14:34:42]W: 2022-02-07 14:34:42:780 +0300 [INFO][main][ItMixedQueriesTest] >>>
Starting test: ItMixedQueriesTest#testOrderingByColumnOutsideSelectList,
displayName: repetition 113 of 1000, workDir:
/opt/buildagent/work/b8d4df1365f1f1e5/modules/runner/target/work/ItMixedQueriesTest/static_1644233560390
[14:34:43]W: 2022-02-07 14:34:43:076 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-AppendEntries-Processor-0][Replicator]
Node 3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0:172.17.0.6:3345 received
AppendEntriesResponse from 172.17.0.6:3344 prevLogIndex=1010 prevLogTerm=1
count=1 fail, sleep, status=Status[ETIMEDOUT<1010>: RPC exception:null]
[14:34:43]W: 2022-02-07 14:34:43:076 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-AppendEntries-Processor-0][Replicator]
Blocking 172.17.0.6:3344 for 120 ms
[14:34:43]W: 2022-02-07 14:34:43:077 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-AppendEntries-Processor-0][Replicator]
Replicator Replicator [state=Probe, statInfo=,
peerId=172.17.0.6:3344, type=Follower] is processing RPC responses, after
processed, continue to send entries: false
[14:34:43]W: 2022-02-07 14:34:43:077 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-AppendEntries-Processor-0][Replicator]
Node 3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0:172.17.0.6:3345 received
HeartbeatResponse from 172.17.0.6:3344 prevLogIndex=1010 prevLogTerm=1
[14:34:43]W: 2022-02-07 14:34:43:092 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-AppendEntries-Processor-0][Replicator]
Replicator Replicator [state=Probe, statInfo=,
peerId=172.17.0.6:3344, type=Follower] ignored old version response 78, current
version is 79, request is
org.apache.ignite.raft.jraft.rpc.AppendEntriesRequestImpl@82dd5f83
[14:34:43]W: , and response is null
[14:34:43]W: , status is Status[ETIMEDOUT<1010>: RPC exception:null].
[14:34:43]W: 2022-02-07 14:34:43:197 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-Common-Executor-13][Replicator] Node
<3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0/172.17.0.6:3345> send
HeartbeatRequest to 172.17.0.6:3344 term 1 lastCommittedIndex 1010
[14:34:43]W: 2022-02-07 14:34:43:198 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-Common-Executor-8][Replicator] Node
<3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0/172.17.0.6:3345> send
HeartbeatRequest to 172.17.0.6:3344 term 1 lastCommittedIndex 1010
[14:34:43]W: 2022-02-07 14:34:43:621 +0300
[WARNING][%ItMixedQueriesTest_null_1%JRaft-StepDownTimer-11][NodeImpl] Node
<3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0/172.17.0.6:3345> steps down when
alive nodes don't satisfy quorum, term=1, deadNodes=172.17.0.6:3344,
conf=172.17.0.6:3344,172.17.0.6:3345.
[14:34:43]W: 2022-02-07 14:34:43:621 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-StepDownTimer-11][NodeImpl] Node
<3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0/172.17.0.6:3345> stepDown,
term=1, newTerm=1, wakeupCandidate=false.
[14:34:43]W: 2022-02-07 14:34:43:622 +0300
[INFO][%ItMixedQueriesTest_null_1%JRaft-FSMCaller-Disruptor-_stripe_2-0][StateMachineAdapter]
onLeaderStop: status=Status[ERAFTTIMEDOUT<10001>: Majority of the group dies:
1/2].
[14:34:43]W: 2022-02-07 14:34:43:622 +0300
[INFO][%ItMixedQueriesTest_null_1%JRaft-StepDownTimer-11][Replicator]
Replicator Replicator [state=Probe, statInfo=,
peerId=172.17.0.6:3344, type=Follower] is going to quit
[14:34:43]W: 2022-02-07 14:34:43:681 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-NodeImpl-Disruptor-_stripe_2-0][NodeImpl]
Node <3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0/172.17.0.6:3345> can't
apply, status=Status[EPERM<1008>: Is not leader.].
[14:34:43]W: 2022-02-07 14:34:43:884 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-NodeImpl-Disruptor-_stripe_2-0][NodeImpl]
Node
[jira] [Comment Edited] (IGNITE-16478) RocksDB returns unexpected cursor.hasNext equals false after leader is changed
[
https://issues.apache.org/jira/browse/IGNITE-16478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488932#comment-17488932
]
Mirza Aliev edited comment on IGNITE-16478 at 2/8/22, 3:12 PM:
---
We analysed debug logs from TC in and came up with possible ways of
investigation:
* Why we got {{ETIMEDOUT<1010>: RPC exception:null}}.
Probably it entail further majority death {{[ERAFTTIMEDOUT<10001>: Majority of
the group dies: 1/2]}} and stepping down of the leader.
* In log we could see that we have several {{can't apply,
status=Status[EPERM<1008>: Is not leader.]}} messages, which means that some
task weren't applied to leaders log. Need to figure out what task weren't
applied and check if we lost them completely.
* In logs we can see {{called hasNext = false, cur = null}} which was logged
after {{internalBatchCounter = 0 clo.command().getCounter() = 1}}, hasNext =
false is not expected as far as new leader was supposed to return true for our
scan command. That means that we've got {{isValid}} equal false for internal
iterator {{RocksIterator}} of RocksDB. (see
{{org.apache.ignite.internal.rocksdb.RocksIteratorAdapter#hasNext}})
{noformat}
[14:34:42]W: 2022-02-07 14:34:42:780 +0300 [INFO][main][ItMixedQueriesTest] >>>
Starting test: ItMixedQueriesTest#testOrderingByColumnOutsideSelectList,
displayName: repetition 113 of 1000, workDir:
/opt/buildagent/work/b8d4df1365f1f1e5/modules/runner/target/work/ItMixedQueriesTest/static_1644233560390
[14:34:43]W: 2022-02-07 14:34:43:076 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-AppendEntries-Processor-0][Replicator]
Node 3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0:172.17.0.6:3345 received
AppendEntriesResponse from 172.17.0.6:3344 prevLogIndex=1010 prevLogTerm=1
count=1 fail, sleep, status=Status[ETIMEDOUT<1010>: RPC exception:null]
[14:34:43]W: 2022-02-07 14:34:43:076 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-AppendEntries-Processor-0][Replicator]
Blocking 172.17.0.6:3344 for 120 ms
[14:34:43]W: 2022-02-07 14:34:43:077 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-AppendEntries-Processor-0][Replicator]
Replicator Replicator [state=Probe, statInfo=,
peerId=172.17.0.6:3344, type=Follower] is processing RPC responses, after
processed, continue to send entries: false
[14:34:43]W: 2022-02-07 14:34:43:077 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-AppendEntries-Processor-0][Replicator]
Node 3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0:172.17.0.6:3345 received
HeartbeatResponse from 172.17.0.6:3344 prevLogIndex=1010 prevLogTerm=1
[14:34:43]W: 2022-02-07 14:34:43:092 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-AppendEntries-Processor-0][Replicator]
Replicator Replicator [state=Probe, statInfo=,
peerId=172.17.0.6:3344, type=Follower] ignored old version response 78, current
version is 79, request is
org.apache.ignite.raft.jraft.rpc.AppendEntriesRequestImpl@82dd5f83
[14:34:43]W: , and response is null
[14:34:43]W: , status is Status[ETIMEDOUT<1010>: RPC exception:null].
[14:34:43]W: 2022-02-07 14:34:43:197 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-Common-Executor-13][Replicator] Node
<3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0/172.17.0.6:3345> send
HeartbeatRequest to 172.17.0.6:3344 term 1 lastCommittedIndex 1010
[14:34:43]W: 2022-02-07 14:34:43:198 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-Common-Executor-8][Replicator] Node
<3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0/172.17.0.6:3345> send
HeartbeatRequest to 172.17.0.6:3344 term 1 lastCommittedIndex 1010
[14:34:43]W: 2022-02-07 14:34:43:621 +0300
[WARNING][%ItMixedQueriesTest_null_1%JRaft-StepDownTimer-11][NodeImpl] Node
<3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0/172.17.0.6:3345> steps down when
alive nodes don't satisfy quorum, term=1, deadNodes=172.17.0.6:3344,
conf=172.17.0.6:3344,172.17.0.6:3345.
[14:34:43]W: 2022-02-07 14:34:43:621 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-StepDownTimer-11][NodeImpl] Node
<3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0/172.17.0.6:3345> stepDown,
term=1, newTerm=1, wakeupCandidate=false.
[14:34:43]W: 2022-02-07 14:34:43:622 +0300
[INFO][%ItMixedQueriesTest_null_1%JRaft-FSMCaller-Disruptor-_stripe_2-0][StateMachineAdapter]
onLeaderStop: status=Status[ERAFTTIMEDOUT<10001>: Majority of the group dies:
1/2].
[14:34:43]W: 2022-02-07 14:34:43:622 +0300
[INFO][%ItMixedQueriesTest_null_1%JRaft-StepDownTimer-11][Replicator]
Replicator Replicator [state=Probe, statInfo=,
peerId=172.17.0.6:3344, type=Follower] is going to quit
[14:34:43]W: 2022-02-07 14:34:43:681 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-NodeImpl-Disruptor-_stripe_2-0][NodeImpl]
Node <3-74778f80-6cef-40db-82ae-5636e926a8ad_part_0/172.17.0.6:3345> can't
apply, status=Status[EPERM<1008>: Is not leader.].
[14:34:43]W: 2022-02-07 14:34:43:884 +0300
[DEBUG][%ItMixedQueriesTest_null_1%JRaft-NodeImpl-Disruptor-_stripe_2-0][NodeImpl]
[jira] [Updated] (IGNITE-16406) SQL select operation could return incomplete data
[
https://issues.apache.org/jira/browse/IGNITE-16406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-16406:
-
Description:
For some reasons select operation couldn't return expected number of rows. We
noticed that this happens when raft leader is changing. To increase
reproducibility, we can slow down a bit message handling, for example by adding
this code to {{MessageServiceImpl#onMessage(java.lang.String,
org.apache.ignite.network.NetworkMessage)}}
{code:java}
if (ThreadLocalRandom.current().nextInt(3) % 2 == 0) {
try {
Thread.sleep(300);
} catch (Exception ex) {
ex.printStackTrace();
}
}
{code}
Possible direction of research:
we could check that we do not lose cursor.next command as a raft response
during the process of leader changing.
UPD: We decided to add checking for consistency between received scan command
and handled scan command in partition listener, so now a user will get state
machine error and could retry his command. But we found another inconsistency
when RocksDB could return hasNext == false after an unexpected step down of the
leader (https://issues.apache.org/jira/browse/IGNITE-16478).
So, we decided then to change the replica factor to 1 in
{{ItMixedQueriesTest}}, so there will be only one node in a partition Raft
group, but we couldn't enable {{ItMixedQueriesTest}} because of new error
https://issues.apache.org/jira/browse/IGNITE-16502
was:
For some reasons select operation couldn't return expected number of rows. We
noticed that this happens when raft leader is changing. To increase
reproducibility, we can slow down a bit message handling, for example by adding
this code to {{MessageServiceImpl#onMessage(java.lang.String,
org.apache.ignite.network.NetworkMessage)}}
{code:java}
if (ThreadLocalRandom.current().nextInt(3) % 2 == 0) {
try {
Thread.sleep(300);
} catch (Exception ex) {
ex.printStackTrace();
}
}
{code}
Possible direction of research:
we could check that we do not lose cursor.next command as a raft response
during the process of leader changing
> SQL select operation could return incomplete data
> -
>
> Key: IGNITE-16406
> URL: https://issues.apache.org/jira/browse/IGNITE-16406
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Blocker
> Labels: ignite-3
>
> For some reasons select operation couldn't return expected number of rows. We
> noticed that this happens when raft leader is changing. To increase
> reproducibility, we can slow down a bit message handling, for example by
> adding this code to {{MessageServiceImpl#onMessage(java.lang.String,
> org.apache.ignite.network.NetworkMessage)}}
> {code:java}
> if (ThreadLocalRandom.current().nextInt(3) % 2 == 0) {
> try {
> Thread.sleep(300);
> } catch (Exception ex) {
> ex.printStackTrace();
> }
> }
> {code}
> Possible direction of research:
> we could check that we do not lose cursor.next command as a raft response
> during the process of leader changing.
> UPD: We decided to add checking for consistency between received scan command
> and handled scan command in partition listener, so now a user will get state
> machine error and could retry his command. But we found another inconsistency
> when RocksDB could return hasNext == false after an unexpected step down of
> the leader (https://issues.apache.org/jira/browse/IGNITE-16478).
> So, we decided then to change the replica factor to 1 in
> {{ItMixedQueriesTest}}, so there will be only one node in a partition Raft
> group, but we couldn't enable {{ItMixedQueriesTest}} because of new error
> https://issues.apache.org/jira/browse/IGNITE-16502
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16502) Some tests in ItMixedQueriesTest could hang
[
https://issues.apache.org/jira/browse/IGNITE-16502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-16502:
-
Description:
Steps to reproduce:
* Run the whole {{ItMixedQueriesTest}}
* Some test could hang (For example,
{{testIgniteSchemaAwaresAlterTableCommand}})
Thread dumps shows that we wait
* {{at
org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}},
* {{at
org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}},
* {{at
org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:550)}}
The whole thread dump is attached.
was:
Steps to reproduce:
* Run the whole {{ItMixedQueriesTest}}
* Some test could hang (For example,
{{testIgniteSchemaAwaresAlterTableCommand}})
Thread dumps shows that we wait {{at
org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}},
{{at
org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}},
{{at
org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:550)}}
The whole thread dump is attached.
> Some tests in ItMixedQueriesTest could hang
> ---
>
> Key: IGNITE-16502
> URL: https://issues.apache.org/jira/browse/IGNITE-16502
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Attachments: Full thread dump
>
>
> Steps to reproduce:
> * Run the whole {{ItMixedQueriesTest}}
> * Some test could hang (For example,
> {{testIgniteSchemaAwaresAlterTableCommand}})
> Thread dumps shows that we wait
> * {{at
> org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}},
>
> * {{at
> org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}},
> * {{at
> org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:550)}}
> The whole thread dump is attached.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16502) Some tests in ItMixedQueriesTest could hang
[
https://issues.apache.org/jira/browse/IGNITE-16502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-16502:
-
Description:
Steps to reproduce:
* Run the whole {{ItMixedQueriesTest}}
* Some test could hang (For example,
{{testIgniteSchemaAwaresAlterTableCommand}})
Thread dumps shows that we wait {{at
org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}},
{{at
org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}},
{{at
org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:550)}}
The whole thread dump is attached.
was:
Steps to reproduce:
* Run the whole {{ItMixedQueriesTest}}
* Some test could hang (For example,
{{testIgniteSchemaAwaresAlterTableCommand}})
Thread dumps shows that we wait {{at
org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}}
and
{{at
org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}}
The whole thread dump is attached.
> Some tests in ItMixedQueriesTest could hang
> ---
>
> Key: IGNITE-16502
> URL: https://issues.apache.org/jira/browse/IGNITE-16502
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Attachments: Full thread dump
>
>
> Steps to reproduce:
> * Run the whole {{ItMixedQueriesTest}}
> * Some test could hang (For example,
> {{testIgniteSchemaAwaresAlterTableCommand}})
> Thread dumps shows that we wait {{at
> org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}},
>
> {{at
> org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}},
> {{at
> org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:550)}}
> The whole thread dump is attached.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16502) Some tests in ItMixedQueriesTest could hang
[
https://issues.apache.org/jira/browse/IGNITE-16502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-16502:
-
Description:
Steps to reproduce:
* Run the whole {{ItMixedQueriesTest}}
* Some test could hang (For example,
{{testIgniteSchemaAwaresAlterTableCommand}})
Thread dumps shows that we wait {{at
org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}}
and
{{at
org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}}
The whole thread dump is attached.
was:
Steps to reproduce:
* Run the whole {{ItMixedQueriesTest}}
* Some test could hang (For example,
{{testIgniteSchemaAwaresAlterTableCommand}})
Thread dumps shows that we wait {{at
org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}}
and {{at
org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}}
The whole thread dump is attached.
> Some tests in ItMixedQueriesTest could hang
> ---
>
> Key: IGNITE-16502
> URL: https://issues.apache.org/jira/browse/IGNITE-16502
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Attachments: Full thread dump
>
>
> Steps to reproduce:
> * Run the whole {{ItMixedQueriesTest}}
> * Some test could hang (For example,
> {{testIgniteSchemaAwaresAlterTableCommand}})
> Thread dumps shows that we wait {{at
> org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}}
> and
> {{at
> org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}}
> The whole thread dump is attached.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16502) Some tests in ItMixedQueriesTest could hang
Mirza Aliev created IGNITE-16502:
Summary: Some tests in ItMixedQueriesTest could hang
Key: IGNITE-16502
URL: https://issues.apache.org/jira/browse/IGNITE-16502
Project: Ignite
Issue Type: Bug
Reporter: Mirza Aliev
Attachments: Full thread dump
Steps to reproduce:
* Run the whole {{ItMixedQueriesTest}}
* Some test could hang (For example {{testIgniteSchemaAwaresAlterTableCommand}}
Thread dumps shows that we wait {{at
org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}}
and {{at
org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}}
The whole thread dump is attached.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16502) Some tests in ItMixedQueriesTest could hang
[
https://issues.apache.org/jira/browse/IGNITE-16502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mirza Aliev updated IGNITE-16502:
-
Description:
Steps to reproduce:
* Run the whole {{ItMixedQueriesTest}}
* Some test could hang (For example,
{{testIgniteSchemaAwaresAlterTableCommand}})
Thread dumps shows that we wait {{at
org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}}
and {{at
org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}}
The whole thread dump is attached.
was:
Steps to reproduce:
* Run the whole {{ItMixedQueriesTest}}
* Some test could hang (For example {{testIgniteSchemaAwaresAlterTableCommand}}
Thread dumps shows that we wait {{at
org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}}
and {{at
org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}}
The whole thread dump is attached.
> Some tests in ItMixedQueriesTest could hang
> ---
>
> Key: IGNITE-16502
> URL: https://issues.apache.org/jira/browse/IGNITE-16502
> Project: Ignite
> Issue Type: Bug
>Reporter: Mirza Aliev
>Priority: Major
> Attachments: Full thread dump
>
>
> Steps to reproduce:
> * Run the whole {{ItMixedQueriesTest}}
> * Some test could hang (For example,
> {{testIgniteSchemaAwaresAlterTableCommand}})
> Thread dumps shows that we wait {{at
> org.apache.ignite.internal.sql.engine.exec.rel.RootNode.exchangeBuffers(RootNode.java:257)}}
> and {{ at
> org.apache.ignite.internal.table.distributed.TableManager.join(TableManager.java:1219)}}
> The whole thread dump is attached.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16501) TX Recovery protocol that is used by CockroachDB
Vyacheslav Koptilin created IGNITE-16501: Summary: TX Recovery protocol that is used by CockroachDB Key: IGNITE-16501 URL: https://issues.apache.org/jira/browse/IGNITE-16501 Project: Ignite Issue Type: Task Reporter: Vyacheslav Koptilin -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16500) In-depth research of Calvin protocol
Vyacheslav Koptilin created IGNITE-16500: Summary: In-depth research of Calvin protocol Key: IGNITE-16500 URL: https://issues.apache.org/jira/browse/IGNITE-16500 Project: Ignite Issue Type: Task Reporter: Vyacheslav Koptilin Let's read, understand and discuss the following: http://cs.yale.edu/homes/thomson/publications/calvin-sigmod12.pdf -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16499) Сonsistency check command should support IGNITE_TO_STRING_INCLUDE_SENSITIVE option
[ https://issues.apache.org/jira/browse/IGNITE-16499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-16499: -- Priority: Critical (was: Minor) > Сonsistency check command should support IGNITE_TO_STRING_INCLUDE_SENSITIVE > option > -- > > Key: IGNITE-16499 > URL: https://issues.apache.org/jira/browse/IGNITE-16499 > Project: Ignite > Issue Type: Sub-task >Reporter: Stepanov Ilya >Assignee: Anton Vinogradov >Priority: Critical > Labels: iep-31, important, ise > Fix For: 2.13 > > > Because keys and values are sensitive data, we need to provide for disabling > the possible output of these data to the log. > > Suggestion: add support for the "IGNITE_TO_STRING_INCLUDE_SENSITIVE" option > in the consistency command(Read Repair). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16499) Сonsistency check command should support IGNITE_TO_STRING_INCLUDE_SENSITIVE option
[ https://issues.apache.org/jira/browse/IGNITE-16499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-16499: -- Labels: iep-31 important ise (was: ise) > Сonsistency check command should support IGNITE_TO_STRING_INCLUDE_SENSITIVE > option > -- > > Key: IGNITE-16499 > URL: https://issues.apache.org/jira/browse/IGNITE-16499 > Project: Ignite > Issue Type: Sub-task >Reporter: Stepanov Ilya >Assignee: Anton Vinogradov >Priority: Minor > Labels: iep-31, important, ise > Fix For: 2.13 > > > Because keys and values are sensitive data, we need to provide for disabling > the possible output of these data to the log. > > Suggestion: add support for the "IGNITE_TO_STRING_INCLUDE_SENSITIVE" option > in the consistency command(Read Repair). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16499) Сonsistency check command should support IGNITE_TO_STRING_INCLUDE_SENSITIVE option
[ https://issues.apache.org/jira/browse/IGNITE-16499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov reassigned IGNITE-16499: - Assignee: Anton Vinogradov > Сonsistency check command should support IGNITE_TO_STRING_INCLUDE_SENSITIVE > option > -- > > Key: IGNITE-16499 > URL: https://issues.apache.org/jira/browse/IGNITE-16499 > Project: Ignite > Issue Type: Sub-task >Reporter: Stepanov Ilya >Assignee: Anton Vinogradov >Priority: Minor > Labels: ise > > Because keys and values are sensitive data, we need to provide for disabling > the possible output of these data to the log. > > Suggestion: add support for the "IGNITE_TO_STRING_INCLUDE_SENSITIVE" option > in the consistency command(Read Repair). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16499) Сonsistency check command should support IGNITE_TO_STRING_INCLUDE_SENSITIVE option
[ https://issues.apache.org/jira/browse/IGNITE-16499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anton Vinogradov updated IGNITE-16499: -- Fix Version/s: 2.13 > Сonsistency check command should support IGNITE_TO_STRING_INCLUDE_SENSITIVE > option > -- > > Key: IGNITE-16499 > URL: https://issues.apache.org/jira/browse/IGNITE-16499 > Project: Ignite > Issue Type: Sub-task >Reporter: Stepanov Ilya >Assignee: Anton Vinogradov >Priority: Minor > Labels: ise > Fix For: 2.13 > > > Because keys and values are sensitive data, we need to provide for disabling > the possible output of these data to the log. > > Suggestion: add support for the "IGNITE_TO_STRING_INCLUDE_SENSITIVE" option > in the consistency command(Read Repair). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16499) Сonsistency check command should support IGNITE_TO_STRING_INCLUDE_SENSITIVE option
Stepanov Ilya created IGNITE-16499: -- Summary: Сonsistency check command should support IGNITE_TO_STRING_INCLUDE_SENSITIVE option Key: IGNITE-16499 URL: https://issues.apache.org/jira/browse/IGNITE-16499 Project: Ignite Issue Type: Sub-task Reporter: Stepanov Ilya Because keys and values are sensitive data, we need to provide for disabling the possible output of these data to the log. Suggestion: add support for the "IGNITE_TO_STRING_INCLUDE_SENSITIVE" option in the consistency command(Read Repair). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16498) Add ability to add handlers to RestModule from other Ignite modules
Roman Puchkovskiy created IGNITE-16498: -- Summary: Add ability to add handlers to RestModule from other Ignite modules Key: IGNITE-16498 URL: https://issues.apache.org/jira/browse/IGNITE-16498 Project: Ignite Issue Type: Improvement Components: rest Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy Fix For: 3.0.0-alpha5 Currently, RestModule defines a handful of REST handlers hard-coded inside the RestModule itselt. The idea is to let other Ignite modules add their own REST handlers that would use RestModule's infrastructure at runtime. Such handlers could be added as plugins (for example, using ServiceLoader). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16495) Make RestModule handlers asynchronous
[ https://issues.apache.org/jira/browse/IGNITE-16495?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488861#comment-17488861 ] Roman Puchkovskiy commented on IGNITE-16495: Looks good to me > Make RestModule handlers asynchronous > - > > Key: IGNITE-16495 > URL: https://issues.apache.org/jira/browse/IGNITE-16495 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Time Spent: 1h 50m > Remaining Estimate: 0h > > Request handlers in the RestModule are executed in a Netty thread, which may > be an issue for long-running request handlers. It should be possible to > execute these handlers on other threads. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16495) Make RestModule handlers asynchronous
[ https://issues.apache.org/jira/browse/IGNITE-16495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-16495: --- Reviewer: Roman Puchkovskiy > Make RestModule handlers asynchronous > - > > Key: IGNITE-16495 > URL: https://issues.apache.org/jira/browse/IGNITE-16495 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Time Spent: 1h 50m > Remaining Estimate: 0h > > Request handlers in the RestModule are executed in a Netty thread, which may > be an issue for long-running request handlers. It should be possible to > execute these handlers on other threads. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16366) Add causality tokens for notifications
[
https://issues.apache.org/jira/browse/IGNITE-16366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov reassigned IGNITE-16366:
--
Assignee: Vladislav Pyatkov
> Add causality tokens for notifications
> --
>
> Key: IGNITE-16366
> URL: https://issues.apache.org/jira/browse/IGNITE-16366
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> Cluster-wide events, such as, for example, configuration changes or
> Metastorage updates, trigger notifications that are propagated to the nodes
> and therefore, to components. Every event can trigger several notifications.
> Every notification has a causality token. Notifications triggered by the same
> event have the same causality token.
> {{Tokens should be added to
> org.apache.ignite.internal.manager.EventParameters}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16191) Calcite engine. Unexpected result of COUNT with multiple parameters
[
https://issues.apache.org/jira/browse/IGNITE-16191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488848#comment-17488848
]
Aleksey Plekhanov commented on IGNITE-16191:
[~Berkov], hmm, looks like you are right, perhaps I misread the calcite
documentation. But there still was an error with {{SELECT COUNT(null, null)}}
and the syntax looks confusing.
> Calcite engine. Unexpected result of COUNT with multiple parameters
> ---
>
> Key: IGNITE-16191
> URL: https://issues.apache.org/jira/browse/IGNITE-16191
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Aleksey Plekhanov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: calcite3-required
> Fix For: 2.13
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The calcite engine supports the {{COUNT}} aggregate function with multiple
> parameters. Such a function should return the number of input rows for which
> parameters are wholly not null.
> But currently queries like:
> {noformat}
> SELECT COUNT(null, 1)
> SELECT COUNT(1, null)
> {noformat}
> Return 0 (expected 1).
> Query:
> {noformat}
> SELECT COUNT(null, null)
> {noformat}
> Throw an exception:
> {noformat}
> Caused by: java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
> at java.util.ArrayList.rangeCheck(ArrayList.java:657)
> at java.util.ArrayList.get(ArrayList.java:433)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.agg.AccumulatorsFactory$WrapperPrototype$1.apply(AccumulatorsFactory.java:226)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.agg.AccumulatorsFactory$WrapperPrototype$1.apply(AccumulatorsFactory.java:223)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.agg.AccumulatorsFactory$AccumulatorWrapperImpl.add(AccumulatorsFactory.java:305)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.HashAggregateNode$Grouping.addOnMapper(HashAggregateNode.java:294)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.HashAggregateNode$Grouping.add(HashAggregateNode.java:265)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.HashAggregateNode$Grouping.access$100(HashAggregateNode.java:222)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.HashAggregateNode.push(HashAggregateNode.java:127)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.ScanNode.push(ScanNode.java:107)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16486) Sql. Adopt: Fix traits at the IgniteLimit. NPE on subquery returning multiple results. Correlates passes through table spools.
[ https://issues.apache.org/jira/browse/IGNITE-16486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-16486: Summary: Sql. Adopt: Fix traits at the IgniteLimit. NPE on subquery returning multiple results. Correlates passes through table spools. (was: Sql. Adopt: Fix traits at the IgniteLimit. NPE on subquery returning multiple results.) > Sql. Adopt: Fix traits at the IgniteLimit. NPE on subquery returning multiple > results. Correlates passes through table spools. > -- > > Key: IGNITE-16486 > URL: https://issues.apache.org/jira/browse/IGNITE-16486 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: calcite, calcite3-required > Fix For: 3.0.0-alpha5 > > > Need to adopt : > [Fix traits at the > IgniteLimit|https://issues.apache.org/jira/browse/IGNITE-13179] > [NPE on subquery returning multiple > results|https://issues.apache.org/jira/browse/IGNITE-15603] > [Correlates passes through table > spools|https://issues.apache.org/jira/browse/IGNITE-15982] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16486) Sql. Adopt: Fix traits at the IgniteLimit. NPE on subquery returning multiple results.
[ https://issues.apache.org/jira/browse/IGNITE-16486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-16486: Description: Need to adopt : [Fix traits at the IgniteLimit|https://issues.apache.org/jira/browse/IGNITE-13179] [NPE on subquery returning multiple results|https://issues.apache.org/jira/browse/IGNITE-15603] [Correlates passes through table spools|https://issues.apache.org/jira/browse/IGNITE-15982] was: Need to adopt : [Fix traits at the IgniteLimit|https://issues.apache.org/jira/browse/IGNITE-13179] [NPE on subquery returning multiple results|https://issues.apache.org/jira/browse/IGNITE-15603] > Sql. Adopt: Fix traits at the IgniteLimit. NPE on subquery returning multiple > results. > -- > > Key: IGNITE-16486 > URL: https://issues.apache.org/jira/browse/IGNITE-16486 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: calcite, calcite3-required > Fix For: 3.0.0-alpha5 > > > Need to adopt : > [Fix traits at the > IgniteLimit|https://issues.apache.org/jira/browse/IGNITE-13179] > [NPE on subquery returning multiple > results|https://issues.apache.org/jira/browse/IGNITE-15603] > [Correlates passes through table > spools|https://issues.apache.org/jira/browse/IGNITE-15982] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16012) Raft changePeers behavior must be updated to async version
[
https://issues.apache.org/jira/browse/IGNITE-16012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488823#comment-17488823
]
Kirill Gusakov commented on IGNITE-16012:
-
LGTM
> Raft changePeers behavior must be updated to async version
> --
>
> Key: IGNITE-16012
> URL: https://issues.apache.org/jira/browse/IGNITE-16012
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Gusakov
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We need to update the current {{changePeers}} behavior with the following:
> - it must be asynchronous and returns ASAP when the request processed
> (without waiting for data catchup)
> - it must be updated with {{term}} argument for skipping the updates from
> old terms
>
> (Phase 1)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16148) Enrich IgniteTransactions javadoc with tx examples
[ https://issues.apache.org/jira/browse/IGNITE-16148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488812#comment-17488812 ] Sergey Uttsel commented on IGNITE-16148: LGTM > Enrich IgniteTransactions javadoc with tx examples > -- > > Key: IGNITE-16148 > URL: https://issues.apache.org/jira/browse/IGNITE-16148 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > Despite the fact the tx api is simple and easy to use some say that it worth > to add some examples to IgniteTransactions javadoc. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16460) Calcite. Fix Calcite TC test suite.
[
https://issues.apache.org/jira/browse/IGNITE-16460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-16460:
-
Labels: calcite calcite3-required (was: calcite)
> Calcite. Fix Calcite TC test suite.
> ---
>
> Key: IGNITE-16460
> URL: https://issues.apache.org/jira/browse/IGNITE-16460
> Project: Ignite
> Issue Type: Test
> Components: build, sql
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: calcite, calcite3-required
> Fix For: 2.13
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Calcite TC suite fails with
> {code:java}
> [11:29:20]Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test (default-cli) on
> project ignite-calcite: Execution default-cli of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed:
> org.apache.ignite.tools.surefire.TestSuiteAwareTestsetReporter
> {code}
> Let's fix it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16460) Calcite. Fix Calcite TC test suite.
[
https://issues.apache.org/jira/browse/IGNITE-16460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-16460:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Calcite. Fix Calcite TC test suite.
> ---
>
> Key: IGNITE-16460
> URL: https://issues.apache.org/jira/browse/IGNITE-16460
> Project: Ignite
> Issue Type: Test
> Components: build, sql
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: calcite, calcite3-required
> Fix For: 2.13
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Calcite TC suite fails with
> {code:java}
> [11:29:20]Failed to execute goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test (default-cli) on
> project ignite-calcite: Execution default-cli of goal
> org.apache.maven.plugins:maven-surefire-plugin:3.0.0-M4:test failed:
> org.apache.ignite.tools.surefire.TestSuiteAwareTestsetReporter
> {code}
> Let's fix it.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16463) CLI can't work with path containing ~
[
https://issues.apache.org/jira/browse/IGNITE-16463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-16463:
-
Labels: cli ignite-3 ignite-3-cli-tool (was: cli)
> CLI can't work with path containing ~
> --
>
> Key: IGNITE-16463
> URL: https://issues.apache.org/jira/browse/IGNITE-16463
> Project: Ignite
> Issue Type: Bug
>Reporter: Fedor Malchikov
>Priority: Minor
> Labels: cli, ignite-3, ignite-3-cli-tool
>
> {code:bash}
> prom1se@prom1se-PC276:~/apache/ignite-3/modules/cli/target$ ./ignite node
> start test --config=~/.ignite-config.json
> Starting a new Ignite node...
> Can't start the node. Read logs for details:
> /home/prom1se/apache/ignite-3/modules/cli/target/ignite-log/test.log
> prom1se@prom1se-PC276:~/apache/ignite-3/modules/cli/target$ cat
> /home/prom1se/apache/ignite-3/modules/cli/target/ignite-log/test.log
> Exception in thread "main" class org.apache.ignite.lang.IgniteException:
> Unable to read user specific configuration.
> at org.apache.ignite.internal.app.IgnitionImpl.start(IgnitionImpl.java:85)
> at org.apache.ignite.internal.app.IgnitionImpl.start(IgnitionImpl.java:70)
> at org.apache.ignite.app.IgniteCliRunner.start(IgniteCliRunner.java:103)
> at org.apache.ignite.app.IgniteCliRunner.main(IgniteCliRunner.java:42)
> Caused by: java.nio.file.NoSuchFileException:
> /home/prom1se/apache/ignite-3/modules/cli/target/~/.ignite-config.json
> at
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
> at
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
> at
> java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:219)
> at java.base/java.nio.file.Files.newByteChannel(Files.java:371)
> at java.base/java.nio.file.Files.newByteChannel(Files.java:422)
> at java.base/java.nio.file.Files.readAllBytes(Files.java:3206)
> at java.base/java.nio.file.Files.readString(Files.java:3284)
> at java.base/java.nio.file.Files.readString(Files.java:3243)
> at org.apache.ignite.internal.app.IgnitionImpl.start(IgnitionImpl.java:80)
> ... 3 more{code}
> but .ignitecfg placed at ~ and work correctly.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16444) Сorrect compaction for Metastorage
[ https://issues.apache.org/jira/browse/IGNITE-16444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16444: - Labels: ignite-3 (was: ) > Сorrect compaction for Metastorage > -- > > Key: IGNITE-16444 > URL: https://issues.apache.org/jira/browse/IGNITE-16444 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > Metastorage has a method _KeyValueStorage#compact_ for removing absolute > history. But today the compaction leads to holes in Metastorage history. It > makes impossible to seek the earliest revision value > _RocksDbKeyValueStorage#earliestRev_. > The mechanism requires of correction that the history has no holes after > compaction. > Also, the logic for updating the earliest revision value should be > implemented. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15239) Calcite. AssertionError SubQueryRemoveRule.rewriteSome
[
https://issues.apache.org/jira/browse/IGNITE-15239?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-15239:
Labels: calcite (was: calcite calcite3-required)
> Calcite. AssertionError SubQueryRemoveRule.rewriteSome
> --
>
> Key: IGNITE-15239
> URL: https://issues.apache.org/jira/browse/IGNITE-15239
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Evgeny Stanilovsky
>Assignee: Ivan Daschinsky
>Priority: Major
> Labels: calcite
>
> {noformat}
> @Test
> public void test0() throws IgniteInterruptedCheckedException {
> sql("CREATE TABLE TABLE_E061_07_01_08 ( A INT )", true);
> sql("SELECT A FROM TABLE_E061_07_01_08 WHERE A <> ANY ( SELECT 1 )",
> true);
> }
> {noformat}
> failed with:
> {noformat}
> java.lang.AssertionError
> at
> org.apache.calcite.rel.rules.SubQueryRemoveRule.rewriteSome(SubQueryRemoveRule.java:162)
> at
> org.apache.calcite.rel.rules.SubQueryRemoveRule.apply(SubQueryRemoveRule.java:92)
> at
> org.apache.calcite.rel.rules.SubQueryRemoveRule.matchFilter(SubQueryRemoveRule.java:629)
> at
> org.apache.calcite.rel.rules.SubQueryRemoveRule.access$100(SubQueryRemoveRule.java:71)
> at
> org.apache.calcite.rel.rules.SubQueryRemoveRule$Config.lambda$static$3(SubQueryRemoveRule.java:693)
> at
> org.apache.calcite.rel.rules.SubQueryRemoveRule.onMatch(SubQueryRemoveRule.java:82)
> at
> org.apache.calcite.plan.AbstractRelOptPlanner.fireRule(AbstractRelOptPlanner.java:341)
> at org.apache.calcite.plan.hep.HepPlanner.applyRule(HepPlanner.java:565)
> at
> org.apache.calcite.plan.hep.HepPlanner.applyRules(HepPlanner.java:428)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeInstruction(HepPlanner.java:282)
> at
> org.apache.calcite.plan.hep.HepInstruction$RuleCollection.execute(HepInstruction.java:77)
> at
> org.apache.calcite.plan.hep.HepPlanner.executeProgram(HepPlanner.java:208)
> at
> org.apache.calcite.plan.hep.HepPlanner.findBestExp(HepPlanner.java:195)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.IgnitePrograms.lambda$hep$0(IgnitePrograms.java:64)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.IgnitePlanner.transform(IgnitePlanner.java:264)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.PlannerHelper.optimize(PlannerHelper.java:78)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareQuery(ExecutionServiceImpl.java:586)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareSingle(ExecutionServiceImpl.java:560)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareQuery(ExecutionServiceImpl.java:514)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.queryPlan(QueryPlanCacheImpl.java:84)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.executeQuery(ExecutionServiceImpl.java:391)
> at
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:259)
> at
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessorTest.sql(CalciteQueryProcessorTest.java:1169)
> at
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessorTest.test0(CalciteQueryProcessorTest.java:1025)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$7.run(GridAbstractTest.java:2432)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15982) Calcite engine. Correlates passes through table spools
[ https://issues.apache.org/jira/browse/IGNITE-15982?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-15982: Labels: calcite calcite3-required (was: calcite3-required) > Calcite engine. Correlates passes through table spools > -- > > Key: IGNITE-15982 > URL: https://issues.apache.org/jira/browse/IGNITE-15982 > Project: Ignite > Issue Type: Bug >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: calcite, calcite3-required > Time Spent: 1h 50m > Remaining Estimate: 0h > > Currently, correlated trait doesn't cleared by the IgniteTableSpool > relational operator. Due to this, plans are possible where correlated > variables are used below the table spool operator. This should be fixed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16486) Sql. Adopt: Fix traits at the IgniteLimit. NPE on subquery returning multiple results.
[ https://issues.apache.org/jira/browse/IGNITE-16486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-16486: Description: Need to adopt : [Fix traits at the IgniteLimit|https://issues.apache.org/jira/browse/IGNITE-13179] [NPE on subquery returning multiple results|https://issues.apache.org/jira/browse/IGNITE-15603] was: Need to adopt : [Fix traits at the IgniteLimit|https://issues.apache.org/jira/browse/IGNITE-13179] > Sql. Adopt: Fix traits at the IgniteLimit. NPE on subquery returning multiple > results. > -- > > Key: IGNITE-16486 > URL: https://issues.apache.org/jira/browse/IGNITE-16486 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: calcite, calcite3-required > Fix For: 3.0.0-alpha5 > > > Need to adopt : > [Fix traits at the > IgniteLimit|https://issues.apache.org/jira/browse/IGNITE-13179] > [NPE on subquery returning multiple > results|https://issues.apache.org/jira/browse/IGNITE-15603] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16486) Sql. Adopt: Fix traits at the IgniteLimit. NPE on subquery returning multiple results.
[ https://issues.apache.org/jira/browse/IGNITE-16486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-16486: Summary: Sql. Adopt: Fix traits at the IgniteLimit. NPE on subquery returning multiple results. (was: Sql. Adopt: Fix traits at the IgniteLimit.) > Sql. Adopt: Fix traits at the IgniteLimit. NPE on subquery returning multiple > results. > -- > > Key: IGNITE-16486 > URL: https://issues.apache.org/jira/browse/IGNITE-16486 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Evgeny Stanilovsky >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: calcite, calcite3-required > Fix For: 3.0.0-alpha5 > > > Need to adopt : > [Fix traits at the > IgniteLimit|https://issues.apache.org/jira/browse/IGNITE-13179] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (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:all-tabpanel ] Denis Chudov reassigned IGNITE-16363: - Assignee: Denis Chudov > 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] [Commented] (IGNITE-16191) Calcite engine. Unexpected result of COUNT with multiple parameters
[
https://issues.apache.org/jira/browse/IGNITE-16191?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488792#comment-17488792
]
Alexander Belyak commented on IGNITE-16191:
---
Return "parameters are wholly not null" rows count, but it should return 0,
isn't it? All rows should be not null, but U pass "null, 1" and "1, null" and
it should return 0 as I understood.
> Calcite engine. Unexpected result of COUNT with multiple parameters
> ---
>
> Key: IGNITE-16191
> URL: https://issues.apache.org/jira/browse/IGNITE-16191
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Aleksey Plekhanov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: calcite3-required
> Fix For: 2.13
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> The calcite engine supports the {{COUNT}} aggregate function with multiple
> parameters. Such a function should return the number of input rows for which
> parameters are wholly not null.
> But currently queries like:
> {noformat}
> SELECT COUNT(null, 1)
> SELECT COUNT(1, null)
> {noformat}
> Return 0 (expected 1).
> Query:
> {noformat}
> SELECT COUNT(null, null)
> {noformat}
> Throw an exception:
> {noformat}
> Caused by: java.lang.IndexOutOfBoundsException: Index: 1, Size: 1
> at java.util.ArrayList.rangeCheck(ArrayList.java:657)
> at java.util.ArrayList.get(ArrayList.java:433)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.agg.AccumulatorsFactory$WrapperPrototype$1.apply(AccumulatorsFactory.java:226)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.agg.AccumulatorsFactory$WrapperPrototype$1.apply(AccumulatorsFactory.java:223)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.exp.agg.AccumulatorsFactory$AccumulatorWrapperImpl.add(AccumulatorsFactory.java:305)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.HashAggregateNode$Grouping.addOnMapper(HashAggregateNode.java:294)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.HashAggregateNode$Grouping.add(HashAggregateNode.java:265)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.HashAggregateNode$Grouping.access$100(HashAggregateNode.java:222)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.HashAggregateNode.push(HashAggregateNode.java:127)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.ScanNode.push(ScanNode.java:107)
> {noformat}
--
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=17488783#comment-17488783 ] Petr Ivanov commented on IGNITE-16445: -- Looks good, merged to main. Thanks for the contribution! > 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] [Updated] (IGNITE-16445) Always specify charset explicitly
[ https://issues.apache.org/jira/browse/IGNITE-16445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-16445: --- Reviewer: Petr Ivanov > 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] [Commented] (IGNITE-16365) Implement a logic of recovery finishing
[ https://issues.apache.org/jira/browse/IGNITE-16365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488776#comment-17488776 ] Denis Chudov commented on IGNITE-16365: --- [~v.pyatkov] lgtm. > Implement a logic of recovery finishing > --- > > Key: IGNITE-16365 > URL: https://issues.apache.org/jira/browse/IGNITE-16365 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > Time Spent: 50m > Remaining Estimate: 0h > > The key point of local state recovery is catching of latest revision applied > in metastorage to apply it locally. In case of standalone mode the node > should finish recovery after restoring components' state from vault, > otherwise it should retrieve updates from metastorage. Notifications from > metastorage should be allowed on recovery stage after all components have > started, and recovery should continue until the node has reached minimal > acceptable difference between itself and the cluster. > Need to implement: > * methods for getting the minimal available revision in Metastorage and the > last applied one; > * some recovery processor class intended to do the logic related to catching > last metastorage revision, and responsile for firing FinishedRecovery message > to cluster management group. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16488) Move a property of revision deviation on start to the configuration
[
https://issues.apache.org/jira/browse/IGNITE-16488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-16488:
--
Epic Link: IGNITE-16362
Ignite Flags: Docs Required (was: Docs Required,Release Notes Required)
> Move a property of revision deviation on start to the configuration
> ---
>
> Key: IGNITE-16488
> URL: https://issues.apache.org/jira/browse/IGNITE-16488
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> Look at the property
> {code}
> IgniteImpl#METADATA_DIFFERENCE
> {code}
> It means the metadata revision on start should be difference from distributed
> revision less than this value.
> This value should be moved to the node configuration, because it might be
> used for tuning.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16497) Data streaming in Apache-Ignite through Apache-Kafka consumes high CPU
Mideen Abdul Gaffoor created IGNITE-16497: - Summary: Data streaming in Apache-Ignite through Apache-Kafka consumes high CPU Key: IGNITE-16497 URL: https://issues.apache.org/jira/browse/IGNITE-16497 Project: Ignite Issue Type: Bug Reporter: Mideen Abdul Gaffoor Attachments: main idc cpu consumption issue.png I am using Ignite Source Connector (Single Kafka connector node) to export the Ignite Events from my ignite cluster(2 Nodes) to Kafka broker nodes (2 Nodes) with a single topic and 29 partitions. I have processed 0.1 Million events (PUT, DELETE) per minute with the 1k size messages(in Avg). My connector node consumes 90% of the CPU (you can see it below). !main idc cpu consumption issue.png! My Connector node machine config. RAM --> 30 GB ROM --> 1TB Configured Heap --> 15GB No of CPU Core --> 40 (20 x 2) # connector name=my-ignite-source-connector connector.class=class of my source connector tasks.max=1 topicNames=ignite-data # cache cacheName=DOCIDS cacheAllowOverwrite=true cacheEvts=put , removed evtBatchSize=100 numberOfPartitions=29 igniteCfg=/myconfig/ignite-config.xml http://www.springframework.org/schema/beans; xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance; xmlns:util="http://www.springframework.org/schema/util; xsi:schemaLocation=" http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd http://www.springframework.org/schema/util http://www.springframework.org/schema/util/spring-util.xsd;> ignite-server-node1:47500..47509ignite-server-node2:47500..47509kafka-conect-node:47500..47509 The data transfer process is working as intended only for a few hours because of this high CPU consumption, after that the Kafka connector node will be OFFLINE in ignite server topology. Any pointers will help. Thanks in advance. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16397) Calcite engine. Failed to insert to table with two or more columns in primary keys
[
https://issues.apache.org/jira/browse/IGNITE-16397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16397:
---
Labels: calcite calcite3-required (was: calcite2-required
calcite3-required)
> Calcite engine. Failed to insert to table with two or more columns in primary
> keys
> --
>
> Key: IGNITE-16397
> URL: https://issues.apache.org/jira/browse/IGNITE-16397
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite3-required
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> For example:
> {noformat}
> CREATE TABLE t(id INT, val VARCHAR, PRIMARY KEY(id, val));
> INSERT INTO t(id, val) VALUES (1, 'a');
> {noformat}
> Fails with:
> {noformat}
> Failed processing message [senderId=8aec0b77-e5a2-49b5-8f77-0f0a7771,
> msg=GridNearAtomicUpdateResponse
> [nodeId=235d7fbc-2a05-4d8b-8e37-3dff3980fc76, futId=1, errs=null,
> ret=GridCacheReturn [v=HashMap
> {SQL_PUBLIC_T_a975cf68_1738_43ca_915b_a52e6b89c049_KEY [idHash=1524322354,
> hash=-904731590, VAL=a, ID=1]=CacheInvokeResult [res=1, err=null]},
> cacheObj=null, success=false, invokeRes=true, loc=true, cacheId=-1578586257],
> remapTopVer=null, nearUpdates=null, partId=552, mapping=ArrayList [],
> nodeLeft=false, super=GridCacheIdMessage [cacheId=-1578586257,
> super=GridCacheMessage [msgId=30, depInfo=null,
> lastAffChangedTopVer=AffinityTopologyVersion [topVer=-1, minorTopVer=0],
> err=null, skipPrepare=false
> class org.apache.ignite.binary.BinaryInvalidTypeException:
> SQL_PUBLIC_T_a975cf68_1738_43ca_915b_a52e6b89c049_KEY
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:719)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1772)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1731)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:826)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:156)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:199)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinariesIfNeeded(CacheObjectUtils.java:126)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:205)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinaryIfNeeded(CacheObjectUtils.java:78)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:138)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1795)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1782)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.completeFuture(GridNearAtomicAbstractUpdateFuture.java:353)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.onPrimaryResponse(GridNearAtomicUpdateFuture.java:467)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateResponse(GridDhtAtomicCache.java:3207)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$500(GridDhtAtomicCache.java:143)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:303)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:298)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1151)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:592)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:393)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:110)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:309)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1909)
> at
>
[jira] [Commented] (IGNITE-16397) Calcite engine. Failed to insert to table with two or more columns in primary keys
[
https://issues.apache.org/jira/browse/IGNITE-16397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488739#comment-17488739
]
Aleksey Plekhanov commented on IGNITE-16397:
[~ivandasch], thanks for the review! Merged to sql-calcite branch.
> Calcite engine. Failed to insert to table with two or more columns in primary
> keys
> --
>
> Key: IGNITE-16397
> URL: https://issues.apache.org/jira/browse/IGNITE-16397
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For example:
> {noformat}
> CREATE TABLE t(id INT, val VARCHAR, PRIMARY KEY(id, val));
> INSERT INTO t(id, val) VALUES (1, 'a');
> {noformat}
> Fails with:
> {noformat}
> Failed processing message [senderId=8aec0b77-e5a2-49b5-8f77-0f0a7771,
> msg=GridNearAtomicUpdateResponse
> [nodeId=235d7fbc-2a05-4d8b-8e37-3dff3980fc76, futId=1, errs=null,
> ret=GridCacheReturn [v=HashMap
> {SQL_PUBLIC_T_a975cf68_1738_43ca_915b_a52e6b89c049_KEY [idHash=1524322354,
> hash=-904731590, VAL=a, ID=1]=CacheInvokeResult [res=1, err=null]},
> cacheObj=null, success=false, invokeRes=true, loc=true, cacheId=-1578586257],
> remapTopVer=null, nearUpdates=null, partId=552, mapping=ArrayList [],
> nodeLeft=false, super=GridCacheIdMessage [cacheId=-1578586257,
> super=GridCacheMessage [msgId=30, depInfo=null,
> lastAffChangedTopVer=AffinityTopologyVersion [topVer=-1, minorTopVer=0],
> err=null, skipPrepare=false
> class org.apache.ignite.binary.BinaryInvalidTypeException:
> SQL_PUBLIC_T_a975cf68_1738_43ca_915b_a52e6b89c049_KEY
> at
> org.apache.ignite.internal.binary.BinaryContext.descriptorForTypeId(BinaryContext.java:719)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize0(BinaryReaderExImpl.java:1772)
> at
> org.apache.ignite.internal.binary.BinaryReaderExImpl.deserialize(BinaryReaderExImpl.java:1731)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.deserializeValue(BinaryObjectImpl.java:826)
> at
> org.apache.ignite.internal.binary.BinaryObjectImpl.value(BinaryObjectImpl.java:156)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:199)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinariesIfNeeded(CacheObjectUtils.java:126)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinary(CacheObjectUtils.java:205)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectUtils.unwrapBinaryIfNeeded(CacheObjectUtils.java:78)
> at
> org.apache.ignite.internal.processors.cache.CacheObjectContext.unwrapBinaryIfNeeded(CacheObjectContext.java:138)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1795)
> at
> org.apache.ignite.internal.processors.cache.GridCacheContext.unwrapBinaryIfNeeded(GridCacheContext.java:1782)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.completeFuture(GridNearAtomicAbstractUpdateFuture.java:353)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicUpdateFuture.onPrimaryResponse(GridNearAtomicUpdateFuture.java:467)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.processNearAtomicUpdateResponse(GridDhtAtomicCache.java:3207)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.access$500(GridDhtAtomicCache.java:143)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:303)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache$6.apply(GridDhtAtomicCache.java:298)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.processMessage(GridCacheIoManager.java:1151)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.onMessage0(GridCacheIoManager.java:592)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:393)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.handleMessage(GridCacheIoManager.java:319)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager.access$100(GridCacheIoManager.java:110)
> at
> org.apache.ignite.internal.processors.cache.GridCacheIoManager$1.onMessage(GridCacheIoManager.java:309)
> at
>
[jira] [Updated] (IGNITE-16119) Caclite engine. Refactor IgniteBuiltInMethod and IgniteMethod classes
[
https://issues.apache.org/jira/browse/IGNITE-16119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16119:
---
Labels: calcite3-required (was: calcite2-required calcite3-required)
> Caclite engine. Refactor IgniteBuiltInMethod and IgniteMethod classes
> -
>
> Key: IGNITE-16119
> URL: https://issues.apache.org/jira/browse/IGNITE-16119
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite3-required
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Looks like {{IgniteBuiltInMethod}} and {{IgniteMethod}} classes have the same
> purpose. We should choose and leave one of them.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16119) Caclite engine. Refactor IgniteBuiltInMethod and IgniteMethod classes
[
https://issues.apache.org/jira/browse/IGNITE-16119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488734#comment-17488734
]
Aleksey Plekhanov commented on IGNITE-16119:
[~ivandasch], thanks for the review! Merged to sql-calcite branch.
> Caclite engine. Refactor IgniteBuiltInMethod and IgniteMethod classes
> -
>
> Key: IGNITE-16119
> URL: https://issues.apache.org/jira/browse/IGNITE-16119
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Looks like {{IgniteBuiltInMethod}} and {{IgniteMethod}} classes have the same
> purpose. We should choose and leave one of them.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16119) Caclite engine. Refactor IgniteBuiltInMethod and IgniteMethod classes
[
https://issues.apache.org/jira/browse/IGNITE-16119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16119:
---
Labels: calcite calcite3-required (was: calcite3-required)
> Caclite engine. Refactor IgniteBuiltInMethod and IgniteMethod classes
> -
>
> Key: IGNITE-16119
> URL: https://issues.apache.org/jira/browse/IGNITE-16119
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite3-required
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Looks like {{IgniteBuiltInMethod}} and {{IgniteMethod}} classes have the same
> purpose. We should choose and leave one of them.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16496) SSLException: closing inbound before receiving peer's close_notify (TLS 1.2)
[
https://issues.apache.org/jira/browse/IGNITE-16496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kukushkin updated IGNITE-16496:
--
Description:
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}}
was:
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}}
> SSLException: closing inbound before receiving peer's close_notify (TLS 1.2)
>
>
> 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
[jira] [Updated] (IGNITE-16496) SSLException: closing inbound before receiving peer's close_notify (TLS 1.2)
[
https://issues.apache.org/jira/browse/IGNITE-16496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kukushkin updated IGNITE-16496:
--
Description:
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}}
was:
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. I guess the right approach to close an SSL
socket is just calling {{Socke#close}}, which should properly wait/send a
{{close_notify}}
> SSLException: closing inbound before receiving peer's close_notify (TLS 1.2)
>
>
> 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
>
[jira] [Updated] (IGNITE-16496) SSLException: closing inbound before receiving peer's close_notify (TLS 1.2)
[
https://issues.apache.org/jira/browse/IGNITE-16496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Kukushkin updated IGNITE-16496:
--
Description:
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. I guess the right approach to close an SSL
socket is just calling {{Socke#close}}, which should properly wait/send a
{{close_notify}}
was:
Ignite nodes output the warning below on startup when TLS protocol v1.3 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.3 is expecting. I guess the right approach to close an SSL
socket is just calling {{Socke#close}}, which should properly wait/send a
{{close_notify}}
> SSLException: closing inbound before receiving peer's close_notify (TLS 1.2)
>
>
> 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
>
[jira] [Updated] (IGNITE-16496) SSLException: closing inbound before receiving peer's close_notify (TLS 1.2)
[
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
(TLS 1.2) (was: SSLException: closing inbound before receiving peer's
close_notify (TLS 1.3))
> SSLException: closing inbound before receiving peer's close_notify (TLS 1.2)
>
>
> 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.3 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.3 is expecting. 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] [Commented] (IGNITE-16487) Use PATCH HTTP verb instead of PUT for modifying cluster/node configuration
[ https://issues.apache.org/jira/browse/IGNITE-16487?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488728#comment-17488728 ] Roman Puchkovskiy commented on IGNITE-16487: Thanks! > Use PATCH HTTP verb instead of PUT for modifying cluster/node configuration > --- > > Key: IGNITE-16487 > URL: https://issues.apache.org/jira/browse/IGNITE-16487 > Project: Ignite > Issue Type: Improvement > Components: rest >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently, both /management/v1/configuration/node/ and > /management/v1/configuration/cluster/ are bound to PUT for modification of > the configuration. > In RESTful APIs, PUT usually performs a complete replacement of an entity > (see > [https://hub.packtpub.com/what-are-rest-verbs-and-status-codes-tutorial/] ), > but in our case the configuration is actually patched (the client passes a > diff, not the complete configuration). > So it makes sense to use PATCH verb instead of PUT. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16496) SSLException: closing inbound before receiving peer's close_notify (TLS 1.3)
Alexey Kukushkin created IGNITE-16496:
-
Summary: SSLException: closing inbound before receiving peer's
close_notify (TLS 1.3)
Key: IGNITE-16496
URL: https://issues.apache.org/jira/browse/IGNITE-16496
Project: Ignite
Issue Type: Bug
Affects Versions: 2.12
Reporter: Alexey Kukushkin
Ignite nodes output the warning below on startup when TLS protocol v1.3 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.3 is expecting. 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] [Updated] (IGNITE-16487) Use PATCH HTTP verb instead of PUT for modifying cluster/node configuration
[ https://issues.apache.org/jira/browse/IGNITE-16487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-16487: --- Reviewer: Aleksandr Polovtcev > Use PATCH HTTP verb instead of PUT for modifying cluster/node configuration > --- > > Key: IGNITE-16487 > URL: https://issues.apache.org/jira/browse/IGNITE-16487 > Project: Ignite > Issue Type: Improvement > Components: rest >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently, both /management/v1/configuration/node/ and > /management/v1/configuration/cluster/ are bound to PUT for modification of > the configuration. > In RESTful APIs, PUT usually performs a complete replacement of an entity > (see > [https://hub.packtpub.com/what-are-rest-verbs-and-status-codes-tutorial/] ), > but in our case the configuration is actually patched (the client passes a > diff, not the complete configuration). > So it makes sense to use PATCH verb instead of PUT. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16317) Calcite engine. Add KILL QUERY command support
[ https://issues.apache.org/jira/browse/IGNITE-16317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488705#comment-17488705 ] Ivan Daschinsky commented on IGNITE-16317: -- [~alex_pl] Thanks for review, merged > Calcite engine. Add KILL QUERY command support > -- > > Key: IGNITE-16317 > URL: https://issues.apache.org/jira/browse/IGNITE-16317 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Daschinsky >Assignee: Ivan Daschinsky >Priority: Major > Labels: calcite, calcite2-required, calcite3-required > Time Spent: 2h 20m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16495) Make RestModule handlers asynchronous
Aleksandr Polovtcev created IGNITE-16495: Summary: Make RestModule handlers asynchronous Key: IGNITE-16495 URL: https://issues.apache.org/jira/browse/IGNITE-16495 Project: Ignite Issue Type: Task Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev Request handlers in the RestModule are executed in a Netty thread, which may be an issue for long-running request handlers. It should be possible to execute these handlers on other threads. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16492) Add platform schema SQL tests
[ https://issues.apache.org/jira/browse/IGNITE-16492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488670#comment-17488670 ] Pavel Tupitsyn commented on IGNITE-16492: - [~isapego] looks good to me. > Add platform schema SQL tests > - > > Key: IGNITE-16492 > URL: https://issues.apache.org/jira/browse/IGNITE-16492 > Project: Ignite > Issue Type: Improvement > Components: platforms >Affects Versions: 2.11.1 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.12 > > Time Spent: 20m > Remaining Estimate: 0h > > Add schema-related SQL tests for platfroms. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16492) Add platform schema SQL tests
[
https://issues.apache.org/jira/browse/IGNITE-16492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488668#comment-17488668
]
Ignite TC Bot commented on IGNITE-16492:
{panel:title=Branch: [pull/9806/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Windows){color} [[tests
1|https://ci.ignite.apache.org/viewLog.html?buildId=6407572]]
* exe: DataStreamerTestTopologyChange.TestNoCacheNode - Test has low fail rate
in base branch 0,0% and is not flaky
{panel}
{panel:title=Branch: [pull/9806/head] Base: [master] : New Tests
(12)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Platform .NET (Windows){color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=6407572]]
* {color:#013220}exe:
CacheDmlQueriesTestSchema.TestBasicOpsExplicitPublicSchema - PASSED{color}
* {color:#013220}exe: CacheDmlQueriesTestSchema.TestBasicOpsDiffSchemas -
PASSED{color}
* {color:#013220}exe: CacheDmlQueriesTestSchema.TestBasicOpsMixedPublicSchema -
PASSED{color}
* {color:#013220}exe:
CacheDmlQueriesTestSchema.TestBasicOpsImplicitPublicSchema - PASSED{color}
* {color:#013220}exe:
CacheDmlQueriesTestSchema.TestCreateTblsInDiffSchemasForSameCache -
PASSED{color}
* {color:#013220}exe: CacheDmlQueriesTestSchema.TestCreateDropNonExistingSchema
- PASSED{color}
{color:#8b}Platform .NET (Core Linux){color} [[tests
6|https://ci.ignite.apache.org/viewLog.html?buildId=6407570]]
* {color:#013220}dll:
CacheDmlQueriesTestSchema.TestBasicOpsExplicitPublicSchema - PASSED{color}
* {color:#013220}dll: CacheDmlQueriesTestSchema.TestBasicOpsDiffSchemas -
PASSED{color}
* {color:#013220}dll: CacheDmlQueriesTestSchema.TestBasicOpsMixedPublicSchema -
PASSED{color}
* {color:#013220}dll:
CacheDmlQueriesTestSchema.TestBasicOpsImplicitPublicSchema - PASSED{color}
* {color:#013220}dll:
CacheDmlQueriesTestSchema.TestCreateTblsInDiffSchemasForSameCache -
PASSED{color}
* {color:#013220}dll: CacheDmlQueriesTestSchema.TestCreateDropNonExistingSchema
- PASSED{color}
{panel}
[TeamCity *- Run :: .NET*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6407573buildTypeId=IgniteTests24Java8_RunAllNet]
> Add platform schema SQL tests
> -
>
> Key: IGNITE-16492
> URL: https://issues.apache.org/jira/browse/IGNITE-16492
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Affects Versions: 2.11.1
>Reporter: Igor Sapego
>Assignee: Igor Sapego
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Add schema-related SQL tests for platfroms.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16492) Add platform schema SQL tests
[
https://issues.apache.org/jira/browse/IGNITE-16492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17488667#comment-17488667
]
Ignite TC Bot commented on IGNITE-16492:
{panel:title=Branch: [pull/9806/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9806/head] Base: [master] : New Tests
(48)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Platform C++ CMake (Win x64 / Debug){color} [[tests
12|https://ci.ignite.apache.org/viewLog.html?buildId=6407591]]
* {color:#013220}IgniteCoreTest: CacheQuerySchemaTestSuite:
TestBasicOpsImplicitPublicSchema - PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQuerySchemaTestSuite:
TestBasicOpsExplicitPublicSchema - PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQuerySchemaTestSuite:
TestCreateDropNonExistingSchema - PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQuerySchemaTestSuite:
TestBasicOpsMixedPublicSchema - PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQuerySchemaTestSuite:
TestCreateTblsInDiffSchemasForSameCache - PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQuerySchemaTestSuite:
TestBasicOpsDiffSchemas - PASSED{color}
* {color:#013220}IgniteOdbcTest: SchemaTestSuite:
TestBasicOpsImplicitPublicSchema - PASSED{color}
* {color:#013220}IgniteOdbcTest: SchemaTestSuite:
TestBasicOpsExplicitPublicSchema - PASSED{color}
* {color:#013220}IgniteOdbcTest: SchemaTestSuite:
TestCreateDropNonExistingSchema - PASSED{color}
* {color:#013220}IgniteOdbcTest: SchemaTestSuite: TestBasicOpsMixedPublicSchema
- PASSED{color}
* {color:#013220}IgniteOdbcTest: SchemaTestSuite:
TestCreateTblsInDiffSchemasForSameCache - PASSED{color}
... and 1 new tests
{color:#8b}Platform C++ CMake (Win x64 / Release){color} [[tests
12|https://ci.ignite.apache.org/viewLog.html?buildId=6407592]]
* {color:#013220}IgniteCoreTest: CacheQuerySchemaTestSuite:
TestBasicOpsImplicitPublicSchema - PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQuerySchemaTestSuite:
TestBasicOpsExplicitPublicSchema - PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQuerySchemaTestSuite:
TestCreateDropNonExistingSchema - PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQuerySchemaTestSuite:
TestBasicOpsMixedPublicSchema - PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQuerySchemaTestSuite:
TestCreateTblsInDiffSchemasForSameCache - PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQuerySchemaTestSuite:
TestBasicOpsDiffSchemas - PASSED{color}
* {color:#013220}IgniteOdbcTest: SchemaTestSuite:
TestBasicOpsImplicitPublicSchema - PASSED{color}
* {color:#013220}IgniteOdbcTest: SchemaTestSuite:
TestBasicOpsExplicitPublicSchema - PASSED{color}
* {color:#013220}IgniteOdbcTest: SchemaTestSuite:
TestCreateDropNonExistingSchema - PASSED{color}
* {color:#013220}IgniteOdbcTest: SchemaTestSuite: TestBasicOpsMixedPublicSchema
- PASSED{color}
* {color:#013220}IgniteOdbcTest: SchemaTestSuite:
TestCreateTblsInDiffSchemasForSameCache - PASSED{color}
... and 1 new tests
{color:#8b}Platform C++ CMake (Linux Clang){color} [[tests
12|https://ci.ignite.apache.org/viewLog.html?buildId=6407589]]
* {color:#013220}IgniteCoreTest: CacheQuerySchemaTestSuite:
TestBasicOpsImplicitPublicSchema - PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQuerySchemaTestSuite:
TestBasicOpsExplicitPublicSchema - PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQuerySchemaTestSuite:
TestCreateDropNonExistingSchema - PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQuerySchemaTestSuite:
TestBasicOpsMixedPublicSchema - PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQuerySchemaTestSuite:
TestCreateTblsInDiffSchemasForSameCache - PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQuerySchemaTestSuite:
TestBasicOpsDiffSchemas - PASSED{color}
* {color:#013220}IgniteOdbcTest: SchemaTestSuite:
TestBasicOpsImplicitPublicSchema - PASSED{color}
* {color:#013220}IgniteOdbcTest: SchemaTestSuite:
TestBasicOpsExplicitPublicSchema - PASSED{color}
* {color:#013220}IgniteOdbcTest: SchemaTestSuite:
TestCreateDropNonExistingSchema - PASSED{color}
* {color:#013220}IgniteOdbcTest: SchemaTestSuite: TestBasicOpsMixedPublicSchema
- PASSED{color}
* {color:#013220}IgniteOdbcTest: SchemaTestSuite:
TestCreateTblsInDiffSchemasForSameCache - PASSED{color}
... and 1 new tests
{color:#8b}Platform C++ CMake (Linux){color} [[tests
12|https://ci.ignite.apache.org/viewLog.html?buildId=6407590]]
* {color:#013220}IgniteCoreTest: CacheQuerySchemaTestSuite:
TestBasicOpsImplicitPublicSchema - PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQuerySchemaTestSuite:
TestBasicOpsExplicitPublicSchema - PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQuerySchemaTestSuite:
TestCreateDropNonExistingSchema - PASSED{color}
* {color:#013220}IgniteCoreTest: CacheQuerySchemaTestSuite:
TestBasicOpsMixedPublicSchema - PASSED{color}
*
[jira] [Created] (IGNITE-16494) Query engine allows to insert rows with logically equal compound PK
Taras Ledkov created IGNITE-16494:
-
Summary: 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
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)
