[jira] [Commented] (IGNITE-21817) CriteriaException must keep error code for mapping from SqlException
[
https://issues.apache.org/jira/browse/IGNITE-21817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17829760#comment-17829760
]
Roman Puchkovskiy commented on IGNITE-21817:
The patch looks good to me
> CriteriaException must keep error code for mapping from SqlException
> -
>
> Key: IGNITE-21817
> URL: https://issues.apache.org/jira/browse/IGNITE-21817
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Novikov
>Assignee: Andrey Novikov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Current implementation of
> CriteriaExceptionMapperUtil#mapToPublicCriteriaException
> {code:java}
> public static Throwable mapToPublicCriteriaException(Throwable origin) {
> Throwable e = mapToPublicException(origin);
> if (e instanceof Error) {
> return e;
> }
> if (e instanceof CriteriaException) {
> return e;
> }
> if (e instanceof SqlException) {
> return new CriteriaException(INTERNAL_ERR, e);
> }
> ...{code}
> It looks like we doesn't need to map all SqlException to CriteriaException
> with errorCode = INTERNAL_ERR
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21612) Send LWM of sender on full state transfer
[ https://issues.apache.org/jira/browse/IGNITE-21612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-21612: - Fix Version/s: 3.0.0-beta2 > Send LWM of sender on full state transfer > - > > Key: IGNITE-21612 > URL: https://issues.apache.org/jira/browse/IGNITE-21612 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > For consistency, we need to get a LWM on a full state transfer and apply it > locally (if it hasn't reached it, of course). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21612) Send LWM of sender on full state transfer
[ https://issues.apache.org/jira/browse/IGNITE-21612?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko reassigned IGNITE-21612: Assignee: Kirill Tkalenko > Send LWM of sender on full state transfer > - > > Key: IGNITE-21612 > URL: https://issues.apache.org/jira/browse/IGNITE-21612 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > For consistency, we need to get a LWM on a full state transfer and apply it > locally (if it hasn't reached it, of course). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21826) MvccCoordinator removal
[
https://issues.apache.org/jira/browse/IGNITE-21826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov reassigned IGNITE-21826:
--
Assignee: (was: Ilya Shishkov)
> MvccCoordinator removal
> ---
>
> Key: IGNITE-21826
> URL: https://issues.apache.org/jira/browse/IGNITE-21826
> Project: Ignite
> Issue Type: Sub-task
> Components: mvcc
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: ise
>
> * SQL commands should be removed:
> * {{BEGIN [TRANSACTION]}} -> {{SqlBeginTransactionCommand}}
> * {{COMMIT [TRANSACTION]}} -> {{SqlCommitTransactionCommand}}
> * {{ROLLBACK [TRANSACTION]}} -> {{SqlRollbackTransactionCommand}}
> * {{SELECT FOR UPDATE}}
> * etc.
> All corresponding parsing code should be removed too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21826) MvccCoordinator removal
[
https://issues.apache.org/jira/browse/IGNITE-21826?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-21826:
---
Description: MvccCoordinator class and corresponding code have to be
removed. (was: * SQL commands should be removed:
* {{BEGIN [TRANSACTION]}} -> {{SqlBeginTransactionCommand}}
* {{COMMIT [TRANSACTION]}} -> {{SqlCommitTransactionCommand}}
* {{ROLLBACK [TRANSACTION]}} -> {{SqlRollbackTransactionCommand}}
* {{SELECT FOR UPDATE}}
* etc.
All corresponding parsing code should be removed too.)
> MvccCoordinator removal
> ---
>
> Key: IGNITE-21826
> URL: https://issues.apache.org/jira/browse/IGNITE-21826
> Project: Ignite
> Issue Type: Sub-task
> Components: mvcc
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: ise
>
> MvccCoordinator class and corresponding code have to be removed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21826) MvccCoordinator removal
Ilya Shishkov created IGNITE-21826:
--
Summary: MvccCoordinator removal
Key: IGNITE-21826
URL: https://issues.apache.org/jira/browse/IGNITE-21826
Project: Ignite
Issue Type: Sub-task
Components: mvcc
Reporter: Ilya Shishkov
Assignee: Ilya Shishkov
* SQL commands should be removed:
* {{BEGIN [TRANSACTION]}} -> {{SqlBeginTransactionCommand}}
* {{COMMIT [TRANSACTION]}} -> {{SqlCommitTransactionCommand}}
* {{ROLLBACK [TRANSACTION]}} -> {{SqlRollbackTransactionCommand}}
* {{SELECT FOR UPDATE}}
* etc.
All corresponding parsing code should be removed too.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21145) MvccDataInnerIO removal
[ https://issues.apache.org/jira/browse/IGNITE-21145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-21145: Description: Delete all classes from: 1) org/apache/ignite/internal/processors/cache/tree/mvcc/data * MvccCacheIdAwareDataInnerIO * MvccCacheIdAwareDataLeafIO * MvccDataInnerIO * MvccDataLeafIO * MvccDataRow * MvccUpdateDataRow * MvccUpdateResult * ResultType 2) org/apache/ignite/internal/processors/cache/tree/mvcc/search * MvccDataPageClosure * MvccFirstRowTreeClosure * MvccLinkAwareSearchRow * MvccMaxSearchRow * MvccMinSearchRow * MvccSearchRow * MvccSnapshotSearchRow * MvccTreeClosure was: Delete all classes from org/apache/ignite/internal/processors/cache/tree/mvcc/data: * MvccCacheIdAwareDataInnerIO * MvccCacheIdAwareDataLeafIO * MvccDataInnerIO * MvccDataLeafIO * MvccDataRow * MvccUpdateDataRow * MvccUpdateResult * ResultType > MvccDataInnerIO removal > --- > > Key: IGNITE-21145 > URL: https://issues.apache.org/jira/browse/IGNITE-21145 > Project: Ignite > Issue Type: Sub-task >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > > Delete all classes from: > 1) org/apache/ignite/internal/processors/cache/tree/mvcc/data > * MvccCacheIdAwareDataInnerIO > * MvccCacheIdAwareDataLeafIO > * MvccDataInnerIO > * MvccDataLeafIO > * MvccDataRow > * MvccUpdateDataRow > * MvccUpdateResult > * ResultType > 2) org/apache/ignite/internal/processors/cache/tree/mvcc/search > * MvccDataPageClosure > * MvccFirstRowTreeClosure > * MvccLinkAwareSearchRow > * MvccMaxSearchRow > * MvccMinSearchRow > * MvccSearchRow > * MvccSnapshotSearchRow > * MvccTreeClosure -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21815) Make client handler to not use Session
[
https://issues.apache.org/jira/browse/IGNITE-21815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17829599#comment-17829599
]
Pavel Tupitsyn commented on IGNITE-21815:
-
Merged to main: cbc84ebce03c7554d8b9e09699f4884033ccaac1
> Make client handler to not use Session
> --
>
> Key: IGNITE-21815
> URL: https://issues.apache.org/jira/browse/IGNITE-21815
> Project: Ignite
> Issue Type: Improvement
> Components: thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Konstantin Orlov
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> At the moment, client handler uses {{Session}} object from public API.
> Although this is not a big deal by itself, the fact that handler injects
> client-specific {{IgniteTransactionsImpl}} to the session makes it not simply
> `removing Session` task, but also adds additional complexity to propagation
> of {{IgniteTransactions}} to sql engine.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (IGNITE-21639) Server after kill does not start and stuck on election
[ https://issues.apache.org/jira/browse/IGNITE-21639 ]
Igor deleted comment on IGNITE-21639:
---
was (Author: JIRAUSER299771):
The run with logs
https://ggtc.gridgain.com/buildConfiguration/Qa_PocTesterAwsBuildTypeAI3/10704411?hideTestsFromDependencies=false&hideProblemsFromDependencies=false&expandBuildDeploymentsSection=false&expandBuildChangesSection=true
> Server after kill does not start and stuck on election
> ---
>
> Key: IGNITE-21639
> URL: https://issues.apache.org/jira/browse/IGNITE-21639
> Project: Ignite
> Issue Type: Improvement
> Components: general, networking, platforms
>Affects Versions: 3.0.0-beta1
>Reporter: Igor
>Priority: Major
> Labels: ignite-3
> Attachments:
> poc-tester-SERVER-192.168.1.117-id-0-2024-02-29-22-56-11-client.log.0
>
>
> *Steps to reproduce:*
> # Start the 3 nodes cluster on different machine each (not in docker).
> # Insert about 500 000 rows across 500 tables. Replication is 3.
> # Kill one node.
> # Start killed node.
> *Expected:*
> The node is started, joined to the cluster and works normally.
> Actual:
> The node stucks on starting with repeating messages like this:
> {code:java}
> 2024-02-29 23:06:21:261 +0300
> [INFO][%poc-tester-SERVER-192.168.1.117-id-0%JRaft-ElectionTimer-18][NodeImpl]
> Unsuccessful election round number 128
> 2024-02-29 23:06:21:261 +0300
> [INFO][%poc-tester-SERVER-192.168.1.117-id-0%JRaft-ElectionTimer-18][NodeImpl]
> Node <154_part_24/poc-tester-SERVER-192.168.1.117-id-0> term 3 start
> preVote.
> 2024-02-29 23:06:21:282 +0300
> [ERROR][%poc-tester-SERVER-192.168.1.117-id-0%JRaft-FSMCaller-Disruptor_stripe_5-0][StripedDisruptor]
> Handle disruptor event error
> [name=%poc-tester-SERVER-192.168.1.117-id-0%JRaft-FSMCaller-Disruptor-,
> event=org.apache.ignite.raft.jraft.core.FSMCallerImpl$ApplyTask@efb699b,
> hasHandler=false]
> java.lang.AssertionError: Safe time reordering detected
> [current=112016525904248838, proposed=112016523364991002]
> at
> org.apache.ignite.internal.table.distributed.raft.PartitionListener.lambda$onWrite$1(PartitionListener.java:169)
> at java.base/java.util.Iterator.forEachRemaining(Iterator.java:133)
> at
> org.apache.ignite.internal.table.distributed.raft.PartitionListener.onWrite(PartitionListener.java:159)
> at
> org.apache.ignite.internal.raft.server.impl.JraftServerImpl$DelegatingStateMachine.onApply(JraftServerImpl.java:674)
> at
> org.apache.ignite.raft.jraft.core.FSMCallerImpl.doApplyTasks(FSMCallerImpl.java:557)
> at
> org.apache.ignite.raft.jraft.core.FSMCallerImpl.doCommitted(FSMCallerImpl.java:525)
> at
> org.apache.ignite.raft.jraft.core.FSMCallerImpl.runApplyTask(FSMCallerImpl.java:444)
> at
> org.apache.ignite.raft.jraft.core.FSMCallerImpl$ApplyTaskHandler.onEvent(FSMCallerImpl.java:136)
> at
> org.apache.ignite.raft.jraft.core.FSMCallerImpl$ApplyTaskHandler.onEvent(FSMCallerImpl.java:130)
> at
> org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:266)
> at
> org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:231)
> at
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:137)
> at java.base/java.lang.Thread.run(Thread.java:829){code}
>
> [^poc-tester-SERVER-192.168.1.117-id-0-2024-02-29-22-56-11-client.log.0]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21793) Fix inconsistencies in table view APIs
[ https://issues.apache.org/jira/browse/IGNITE-21793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-21793: --- Assignee: Pavel Tupitsyn > Fix inconsistencies in table view APIs > -- > > Key: IGNITE-21793 > URL: https://issues.apache.org/jira/browse/IGNITE-21793 > Project: Ignite > Issue Type: Improvement >Affects Versions: 3.0 >Reporter: Alexey Scherbakov >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > > # *getOrDefault* accepts nullables after IGNITE-20524, but its semantics is > to ensure null safety. It should not accept or nulls (*getNullable* methods > exist to deal with nulls) > # *getNullable* family of methods throws exceptions from tuple-based views > (*ClientKeyValueBinaryView*, *KeyValueBinaryViewImpl*), but it should work > same as equivalent getters to ensure view equivalence. > # *getAndReplaceAsync* has nullable key and value, but actual implementations > (client and embedded) disallow nulls. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21793) Fix inconsistencies in table view APIs
[ https://issues.apache.org/jira/browse/IGNITE-21793?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21793: Description: # *getOrDefault* accepts nullables after IGNITE-20524, but its semantics is to ensure null safety. It should not accept or nulls (*getNullable* methods exist to deal with nulls) # *getNullable* family of methods throws exceptions from tuple-based views (*ClientKeyValueBinaryView*, *KeyValueBinaryViewImpl*), but it should work same as equivalent getters to ensure view equivalence. # *getAndReplaceAsync* has nullable key and value, but actual implementations (client and embedded) disallow nulls. was: # *getOrDefault* accepts nullables after IGNITE-20524, but its semantics is to ensure null safety. It should not accept or nulls (*getNullable* methods exist to deal with nulls) # *getNullable* family of methods throws exceptions from tuple-based views (*ClientKeyValueBinaryView*, *KeyValueBinaryViewImpl*), but it should work same as equivalent getters to ensure view equivalence. > Fix inconsistencies in table view APIs > -- > > Key: IGNITE-21793 > URL: https://issues.apache.org/jira/browse/IGNITE-21793 > Project: Ignite > Issue Type: Improvement >Affects Versions: 3.0 >Reporter: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > > # *getOrDefault* accepts nullables after IGNITE-20524, but its semantics is > to ensure null safety. It should not accept or nulls (*getNullable* methods > exist to deal with nulls) > # *getNullable* family of methods throws exceptions from tuple-based views > (*ClientKeyValueBinaryView*, *KeyValueBinaryViewImpl*), but it should work > same as equivalent getters to ensure view equivalence. > # *getAndReplaceAsync* has nullable key and value, but actual implementations > (client and embedded) disallow nulls. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-18159) Implement splitting of an Ignite node hosting a learner and a follower from the same Raft group
[
https://issues.apache.org/jira/browse/IGNITE-18159?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev resolved IGNITE-18159.
--
Resolution: Won't Fix
> Implement splitting of an Ignite node hosting a learner and a follower from
> the same Raft group
> ---
>
> Key: IGNITE-18159
> URL: https://issues.apache.org/jira/browse/IGNITE-18159
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> As described in IGNITE-18070, we need to implement one of the scenarios that
> will allow us to have a single Ignite node hosting a follower and a learner
> from the same Raft group. This ticket focuses on a case when a node gets
> "split", that is, when after calculating the assignments, a follower (or a
> learner) gets moved to a different Ignite node.
> The algorithm looks like the following: after stable assignments have been
> changes, we simply destroy the follower's (or learner's, whichever gets
> moved) storage data (looks like a good place for that would be inside the
> {{metaStorageMgr.registerWatchByPrefix(ByteArray.fromString(STABLE_ASSIGNMENTS_PREFIX)}}
> listener in the {{TableManager}}) on the node that gets "split" . The other
> node should simply start the corresponding Raft service as usual, its data
> would be transferred by Raft replication.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21521) Wrong update order in upsertAll and DataStreamer for a new key
[
https://issues.apache.org/jira/browse/IGNITE-21521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17829590#comment-17829590
]
Pavel Tupitsyn commented on IGNITE-21521:
-
Merged to main: c3de575204337dc1c2dbf6609012a1fb86ff3d1a
> Wrong update order in upsertAll and DataStreamer for a new key
> --
>
> Key: IGNITE-21521
> URL: https://issues.apache.org/jira/browse/IGNITE-21521
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Add the following test to *ItInternalTableTest* to reproduce:
> {code:java}
> @Test
> public void upsertAllOrderTest() {
> RecordView view = table.recordView();
> InternalTable internalTable = ((TableViewInternal)
> table).internalTable();
> List rows = new ArrayList<>();
> int count = 100;
> int lastId = count - 1;
> long id = 12345;
> for (int i = 0; i < count; i++) {
> rows.add(createKeyValueRow(id, i, "row-" + i));
> }
> internalTable.upsertAll(rows, null).join();
> Tuple res = view.get(null, Tuple.create().set("key", id));
> assertEquals(lastId, res.intValue("valInt"));
> assertEquals("row-" + lastId, res.stringValue("valStr"));
> }
> {code}
> As a user, I expect to observe the last value for the given key. Instead,
> there is a random value.
> This is caused by *PartitionReplicaListener* - when there is no row with
> specified key, we generate a new random *RowId*:
> {code:java}
> RowId rowId0 = insert ? new RowId(partId(), UUID.randomUUID()) : rowId
> {code}
> Then this row id is stored in a hash set, which results in a random update
> order. The same applies to the *DataStreamer*, which goes through
> *InternalTableImpl.updateAll*.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18617) Clear rw tx context and cleanup ready futures on tx finish
[ https://issues.apache.org/jira/browse/IGNITE-18617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-18617: - Reviewer: Alexander Lapin > Clear rw tx context and cleanup ready futures on tx finish > -- > > Key: IGNITE-18617 > URL: https://issues.apache.org/jira/browse/IGNITE-18617 > Project: Ignite > Issue Type: Improvement >Reporter: Denis Chudov >Assignee: Kirill Sizov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > The map PartitionReplicaListener#txCleanupReadyFutures is not completely > cleared on tx finish. There should be no mapping once TX is closed. > Also the coordinator should clear TX Context (inflights, enlistments) when > the corresponding transaction is finished. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21575) Destroy index storages on rebalance
[ https://issues.apache.org/jira/browse/IGNITE-21575?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev resolved IGNITE-21575. -- Resolution: Invalid > Destroy index storages on rebalance > --- > > Key: IGNITE-21575 > URL: https://issues.apache.org/jira/browse/IGNITE-21575 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21575) Destroy index storages on rebalance
[ https://issues.apache.org/jira/browse/IGNITE-21575?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17829588#comment-17829588 ] Aleksandr Polovtcev commented on IGNITE-21575: -- Originally this ticket was intended to check that index storages are destroyed when a node is no longer present for a partition's assignments. Looks like this has already been implemented in IGNITE-18160. > Destroy index storages on rebalance > --- > > Key: IGNITE-21575 > URL: https://issues.apache.org/jira/browse/IGNITE-21575 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21825) Extract code common for all index storages
[ https://issues.apache.org/jira/browse/IGNITE-21825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-21825: --- Description: At least, now different implementations of IndexStorage have their own implementations of busy() methods, which are basically duplicates. We need to get rid of this duplication. > Extract code common for all index storages > -- > > Key: IGNITE-21825 > URL: https://issues.apache.org/jira/browse/IGNITE-21825 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > > At least, now different implementations of IndexStorage have their own > implementations of busy() methods, which are basically duplicates. We need to > get rid of this duplication. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21825) Extract code common for all index storages
Roman Puchkovskiy created IGNITE-21825: -- Summary: Extract code common for all index storages Key: IGNITE-21825 URL: https://issues.apache.org/jira/browse/IGNITE-21825 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20142) Introduce changes for JDK17 tests run
[ https://issues.apache.org/jira/browse/IGNITE-20142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-20142: - Labels: ignite-3 ise (was: ise) > Introduce changes for JDK17 tests run > - > > Key: IGNITE-20142 > URL: https://issues.apache.org/jira/browse/IGNITE-20142 > Project: Ignite > Issue Type: Improvement >Reporter: Petr Ivanov >Assignee: Petr Ivanov >Priority: Major > Labels: ignite-3, ise > Fix For: 2.16 > > Time Spent: 10m > Remaining Estimate: 0h > > Introduce several changes and extend current WAs for ability to run tests > under JDK17. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21823) fix log message pageSize
[ https://issues.apache.org/jira/browse/IGNITE-21823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrei Nadyktov reassigned IGNITE-21823: Assignee: Andrei Nadyktov > fix log message pageSize > > > Key: IGNITE-21823 > URL: https://issues.apache.org/jira/browse/IGNITE-21823 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Andrei Nadyktov >Priority: Minor > Labels: ise, newbie > Fix For: 2.17 > > > If you do not indicate in the configuration, the size of pageSize, then in > the log we see the message that pageSize = 0 that is not true -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21824) Revert workaround for jline bug
Vadim Pakhnushev created IGNITE-21824: - Summary: Revert workaround for jline bug Key: IGNITE-21824 URL: https://issues.apache.org/jira/browse/IGNITE-21824 Project: Ignite Issue Type: Improvement Components: cli Reporter: Vadim Pakhnushev Assignee: Vadim Pakhnushev When [https://github.com/jline/jline3/issues/956] is fixed, remove workaround added in the IGNITE-21674 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21172) Table operation fails with invalid exception after table drop
[
https://issues.apache.org/jira/browse/IGNITE-21172?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17829549#comment-17829549
]
Andrey Mashenkov commented on IGNITE-21172:
---
Can’t reproduce the original issue. Seems, it was fixed somewhen.
I’ve added a test to ItTablesApiTest suite and fix invalid error code.
> Table operation fails with invalid exception after table drop
> -
>
> Key: IGNITE-21172
> URL: https://issues.apache.org/jira/browse/IGNITE-21172
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Tupitsyn
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Run the following test (add to ItTablesApiTest):
> {code}
> @Test
> public void useAfterDrop() {
> Ignite ignite0 = clusterNodes.get(0);
> Table tbl = createTable(ignite0, TABLE_NAME);
> RecordView view = tbl.recordView();
> sql(ignite0, "DROP TABLE " + TABLE_NAME);
> view.insert(null, Tuple.create().set("key", 1L).set("valInt",
> 1).set("valStr", "1"));
> }
> {code}
> Result:
> {code}
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:2292b265-aa9f-4ba4-a8d0-8ea93a2101ef
> at
> org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.mapToPublicException(IgniteExceptionMapperUtil.java:117)
> at
> org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.lambda$convertToPublicFuture$2(IgniteExceptionMapperUtil.java:132)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:946)
> at
> java.base/java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2272)
> at
> org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.convertToPublicFuture(IgniteExceptionMapperUtil.java:130)
> at
> org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:127)
> at
> org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:102)
> at
> org.apache.ignite.internal.table.RecordBinaryViewImpl.insertAsync(RecordBinaryViewImpl.java:168)
> at
> org.apache.ignite.internal.table.RecordBinaryViewImpl.insert(RecordBinaryViewImpl.java:160)
> at
> org.apache.ignite.internal.table.RecordBinaryViewImpl.insert(RecordBinaryViewImpl.java:47)
> at
> org.apache.ignite.internal.runner.app.ItTablesApiTest.useAfterDrop(ItTablesApiTest.java:164)
> Caused by: java.lang.NullPointerException
> at
> java.base/java.util.concurrent.CompletableFuture.uniApplyNow(CompletableFuture.java:680)
> at
> java.base/java.util.concurrent.CompletableFuture.uniApplyStage(CompletableFuture.java:658)
> at
> java.base/java.util.concurrent.CompletableFuture.thenApply(CompletableFuture.java:2100)
> at
> org.apache.ignite.internal.table.distributed.schema.SchemaVersionsImpl.schemaVersionAt(SchemaVersionsImpl.java:52)
> at
> org.apache.ignite.internal.table.distributed.schema.SchemaVersionsImpl.schemaVersionAtNow(SchemaVersionsImpl.java:68)
> at
> org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:107)
> ... 75 more
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21172) Table operation fails with invalid exception after table drop
[
https://issues.apache.org/jira/browse/IGNITE-21172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-21172:
--
Summary: Table operation fails with invalid exception after table drop
(was: NullPointerException in AbstractTableView.withSchemaSync after table drop)
> Table operation fails with invalid exception after table drop
> -
>
> Key: IGNITE-21172
> URL: https://issues.apache.org/jira/browse/IGNITE-21172
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Tupitsyn
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Run the following test with *disabled assertions* (add to ItTablesApiTest):
> {code}
> @Test
> public void useAfterDrop() {
> Ignite ignite0 = clusterNodes.get(0);
> Table tbl = createTable(ignite0, TABLE_NAME);
> RecordView view = tbl.recordView();
> sql(ignite0, "DROP TABLE " + TABLE_NAME);
> view.insert(null, Tuple.create().set("key", 1L).set("valInt",
> 1).set("valStr", "1"));
> }
> {code}
> Result:
> {code}
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:2292b265-aa9f-4ba4-a8d0-8ea93a2101ef
> at
> org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.mapToPublicException(IgniteExceptionMapperUtil.java:117)
> at
> org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.lambda$convertToPublicFuture$2(IgniteExceptionMapperUtil.java:132)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:946)
> at
> java.base/java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2272)
> at
> org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.convertToPublicFuture(IgniteExceptionMapperUtil.java:130)
> at
> org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:127)
> at
> org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:102)
> at
> org.apache.ignite.internal.table.RecordBinaryViewImpl.insertAsync(RecordBinaryViewImpl.java:168)
> at
> org.apache.ignite.internal.table.RecordBinaryViewImpl.insert(RecordBinaryViewImpl.java:160)
> at
> org.apache.ignite.internal.table.RecordBinaryViewImpl.insert(RecordBinaryViewImpl.java:47)
> at
> org.apache.ignite.internal.runner.app.ItTablesApiTest.useAfterDrop(ItTablesApiTest.java:164)
> Caused by: java.lang.NullPointerException
> at
> java.base/java.util.concurrent.CompletableFuture.uniApplyNow(CompletableFuture.java:680)
> at
> java.base/java.util.concurrent.CompletableFuture.uniApplyStage(CompletableFuture.java:658)
> at
> java.base/java.util.concurrent.CompletableFuture.thenApply(CompletableFuture.java:2100)
> at
> org.apache.ignite.internal.table.distributed.schema.SchemaVersionsImpl.schemaVersionAt(SchemaVersionsImpl.java:52)
> at
> org.apache.ignite.internal.table.distributed.schema.SchemaVersionsImpl.schemaVersionAtNow(SchemaVersionsImpl.java:68)
> at
> org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:107)
> ... 75 more
> {code}
> With enabled assertions there is an unfriendly exception:
> {code}
> org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:f84af536-d752-4887-8096-b15d6e0a0efc No table in the catalog after
> schema sync, table 5, ts HybridTimestamp [physical=2023-12-28 11:20:59:574
> +0200, logical=0, composite=111657304691441664]
> at
> org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.mapToPublicException(IgniteExceptionMapperUtil.java:88)
> at
> org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.lambda$convertToPublicFuture$2(IgniteExceptionMapperUtil.java:132)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
> at
> java.base/java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:946)
> at
> java.base/java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2272)
> at
> org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.convertToPublicFuture(IgniteExceptionMapperUtil.java:130)
> at
> org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:127)
> at
> org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:102)
> at
> org.apache.ignite.internal.table.RecordBinaryViewImpl.insertAsync(RecordBinaryViewImpl.java:168)
> at
> org.apache.ignite.internal.table.RecordBinaryViewIm
[jira] [Updated] (IGNITE-21172) Table operation fails with invalid exception after table drop
[
https://issues.apache.org/jira/browse/IGNITE-21172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Mashenkov updated IGNITE-21172:
--
Description:
Run the following test (add to ItTablesApiTest):
{code}
@Test
public void useAfterDrop() {
Ignite ignite0 = clusterNodes.get(0);
Table tbl = createTable(ignite0, TABLE_NAME);
RecordView view = tbl.recordView();
sql(ignite0, "DROP TABLE " + TABLE_NAME);
view.insert(null, Tuple.create().set("key", 1L).set("valInt",
1).set("valStr", "1"));
}
{code}
Result:
{code}
org.apache.ignite.lang.IgniteException: IGN-CMN-65535
TraceId:2292b265-aa9f-4ba4-a8d0-8ea93a2101ef
at
org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.mapToPublicException(IgniteExceptionMapperUtil.java:117)
at
org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.lambda$convertToPublicFuture$2(IgniteExceptionMapperUtil.java:132)
at
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at
java.base/java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:946)
at
java.base/java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2272)
at
org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.convertToPublicFuture(IgniteExceptionMapperUtil.java:130)
at
org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:127)
at
org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:102)
at
org.apache.ignite.internal.table.RecordBinaryViewImpl.insertAsync(RecordBinaryViewImpl.java:168)
at
org.apache.ignite.internal.table.RecordBinaryViewImpl.insert(RecordBinaryViewImpl.java:160)
at
org.apache.ignite.internal.table.RecordBinaryViewImpl.insert(RecordBinaryViewImpl.java:47)
at
org.apache.ignite.internal.runner.app.ItTablesApiTest.useAfterDrop(ItTablesApiTest.java:164)
Caused by: java.lang.NullPointerException
at
java.base/java.util.concurrent.CompletableFuture.uniApplyNow(CompletableFuture.java:680)
at
java.base/java.util.concurrent.CompletableFuture.uniApplyStage(CompletableFuture.java:658)
at
java.base/java.util.concurrent.CompletableFuture.thenApply(CompletableFuture.java:2100)
at
org.apache.ignite.internal.table.distributed.schema.SchemaVersionsImpl.schemaVersionAt(SchemaVersionsImpl.java:52)
at
org.apache.ignite.internal.table.distributed.schema.SchemaVersionsImpl.schemaVersionAtNow(SchemaVersionsImpl.java:68)
at
org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:107)
... 75 more
{code}
was:
Run the following test with *disabled assertions* (add to ItTablesApiTest):
{code}
@Test
public void useAfterDrop() {
Ignite ignite0 = clusterNodes.get(0);
Table tbl = createTable(ignite0, TABLE_NAME);
RecordView view = tbl.recordView();
sql(ignite0, "DROP TABLE " + TABLE_NAME);
view.insert(null, Tuple.create().set("key", 1L).set("valInt",
1).set("valStr", "1"));
}
{code}
Result:
{code}
org.apache.ignite.lang.IgniteException: IGN-CMN-65535
TraceId:2292b265-aa9f-4ba4-a8d0-8ea93a2101ef
at
org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.mapToPublicException(IgniteExceptionMapperUtil.java:117)
at
org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.lambda$convertToPublicFuture$2(IgniteExceptionMapperUtil.java:132)
at
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at
java.base/java.util.concurrent.CompletableFuture.uniHandleStage(CompletableFuture.java:946)
at
java.base/java.util.concurrent.CompletableFuture.handle(CompletableFuture.java:2272)
at
org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.convertToPublicFuture(IgniteExceptionMapperUtil.java:130)
at
org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:127)
at
org.apache.ignite.internal.table.AbstractTableView.withSchemaSync(AbstractTableView.java:102)
at
org.apache.ignite.internal.table.RecordBinaryViewImpl.insertAsync(RecordBinaryViewImpl.java:168)
at
org.apache.ignite.internal.table.RecordBinaryViewImpl.insert(RecordBinaryViewImpl.java:160)
at
org.apache.ignite.internal.table.RecordBinaryViewImpl.insert(RecordBinaryViewImpl.java:47)
at
org.apache.ignite.internal.runner.app.ItTablesApiTest.useAfterDrop(ItTablesApiTest.java:164)
Caused by: java.lang.NullPointerException
at
java.base/java.util.concurrent.CompletableFuture.uniApplyNow(CompletableFuture.java:680)
at
java.base/java.util.concurrent.CompletableFuture.uniApplyStage(CompletableFuture.java:658)
at
java.base/java.util.concurrent.CompletableFuture.t
[jira] [Commented] (IGNITE-21708) Catalog. CatalogManagerSelfTest::testPkAvailableIndexEvent is flaky.
[ https://issues.apache.org/jira/browse/IGNITE-21708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17829541#comment-17829541 ] Iurii Gerzhedovich commented on IGNITE-21708: - [~amashenkov] LGTM > Catalog. CatalogManagerSelfTest::testPkAvailableIndexEvent is flaky. > > > Key: IGNITE-21708 > URL: https://issues.apache.org/jira/browse/IGNITE-21708 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > testPkAvailableIndexEvent fails at line assertThat(fireEventFuture, > willCompleteSuccessfully()) > Can be easily reproduced by running this test with repeat-until-failure > option in IDE. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21478) OOM crash with unstable topology
[
https://issues.apache.org/jira/browse/IGNITE-21478?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yuri Naryshkin reassigned IGNITE-21478:
---
Assignee: Yuri Naryshkin (was: Mikhail Petrov)
> OOM crash with unstable topology
>
>
> Key: IGNITE-21478
> URL: https://issues.apache.org/jira/browse/IGNITE-21478
> Project: Ignite
> Issue Type: Bug
>Reporter: Luchnikov Alexander
>Assignee: Yuri Naryshkin
>Priority: Minor
> Labels: ise
> Attachments: HistoMinorTop.png, histo.png
>
>
> User cases:
> 1) Frequent entry/exit of a thick client into the topology leads to a crash
> of the server node due to OMM.
> 2) Frequent creation and destroy of caches leads to a server node crash due
> to OOM.
> topVer=20098
> *Real case*
> Part of the log before the OOM crash, pay attention to *topVer=20098*
> {code:java}
> Metrics for local node (to disable set 'metricsLogFrequency' to 0)
> ^-- Node [id=f080abcd, uptime=3 days, 09:00:55.274]
> ^-- Cluster [hosts=4, CPUs=6, servers=2, clients=2, topVer=20098,
> minorTopVer=6]
> ^-- Network [addrs=[192.168.1.2, 127.0.0.1], discoPort=47500,
> commPort=47100]
> ^-- CPU [CPUs=2, curLoad=86.83%, avgLoad=21.9%, GC=23.9%]
> ^-- Heap [used=867MB, free=15.29%, comm=1024MB]
> ^-- Outbound messages queue [size=0]
> ^-- Public thread pool [active=0, idle=7, qSize=0]
> ^-- System thread pool [active=0, idle=8, qSize=0]
> ^-- Striped thread pool [active=0, idle=8, qSize=0]
> {code}
> Histogram from heap-dump after node failed
> !histo.png!
> *MinorTop example*
> {code:java}
> @Test
> public void testMinorVer() throws Exception {
> Ignite server = startGrids(1);
> IgniteEx client = startClientGrid();
> String cacheName = "cacheName";
> for (int i = 0; i < 500; i++) {
> client.getOrCreateCache(cacheName);
> client.destroyCache(cacheName);
> }
> System.err.println("Heap dump time");
> Thread.sleep(100);
> }
> {code}
> {code:java}
> [INFO
> ][exchange-worker-#149%internal.IgniteOomTest%][GridCachePartitionExchangeManager]
> AffinityTopologyVersion [topVer=2, minorTopVer=1000],
> evt=DISCOVERY_CUSTOM_EVT, evtNode=52b4c130-1a01-4858-813a-ebc8a5dabf1e,
> client=true]
> {code}
> !HistoMinorTop.png!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21819) NextRowIdToBuild does not get cleared on rebalance
[
https://issues.apache.org/jira/browse/IGNITE-21819?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17829494#comment-17829494
]
Roman Puchkovskiy commented on IGNITE-21819:
The patch looks good to me
> NextRowIdToBuild does not get cleared on rebalance
> --
>
> Key: IGNITE-21819
> URL: https://issues.apache.org/jira/browse/IGNITE-21819
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> During a rebalance, partition storages and their indexes get cleaned up.
> However, {{nextRowIdToBuild}}-related logic used by all index implementations
> does not take this into account and does not remove the current value as well
> as doesn't reset the cached field. In addition, Page Memory-based index
> storages don't reset their index meta trees and can access destroyed trees
> after a rebalance.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20649) SQL: class cast exception in EXCEPT SELECT with different column types
[
https://issues.apache.org/jira/browse/IGNITE-20649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-20649:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> SQL: class cast exception in EXCEPT SELECT with different column types
> --
>
> Key: IGNITE-20649
> URL: https://issues.apache.org/jira/browse/IGNITE-20649
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3, sql
>
> Steps to reproduce:
> 1. Create two tables, one with `INT` column and one with `NUMERIC`. Add some
> sample data into both.
> {code:sql}
> -- first table
> drop table if exists tmp_table_age_name_wage;
> create table tmp_table_age_name_wage (key_field INT PRIMARY KEY,AGE
> INT,field1 VARCHAR,field2 INT);
> insert into tmp_table_age_name_wage (key_field,AGE,field1,field2) values (1,
> 42,'John',10);
> insert into tmp_table_age_name_wage (key_field,AGE,field1,field2) values (2,
> 43,'Jack',5);
> -- second table
> drop table if exists tmp_table_age_name_wage_2;
> create table tmp_table_age_name_wage_2 (key_field INT PRIMARY KEY,AGE
> DECIMAL,field1 VARCHAR,field2 DECIMAL);
> insert into tmp_table_age_name_wage_2 (key_field,AGE,field1,field2) values
> (1, 42,'John',10);
> {code}
> 2. `UNION SELECT` for columns with different types works fine:
> {code:sql}
> sql-cli> SELECT AGE,field1,field2 FROM tmp_table_age_name_wage UNION SELECT
> AGE,field1,field2 FROM tmp_table_age_name_wage_2;
> ╔═╤╤╗
> ║ AGE │ FIELD1 │ FIELD2 ║
> ╠═╪╪╣
> ║ 42 │ John │ 10 ║
> ╟─┼┼╢
> ║ 42 │ John │ 10 ║
> ╟─┼┼╢
> ║ 43 │ Jack │ 5 ║
> ╚═╧╧╝
> {code}
> 3. Nevertheless, `EXCEPT SELECT` leads to class casting exception:
> {code:sql}
> sql-cli> SELECT AGE,field1,field2 FROM tmp_table_age_name_wage EXCEPT SELECT
> AGE,field1,field2 FROM tmp_table_age_name_wage_2;
> SQL query execution error
> class java.math.BigDecimal cannot be cast to class java.lang.Integer
> (java.math.BigDecimal and java.lang.Integer are in module java.base of loader
> 'bootstrap')
> {code}
> The query above worked in AI3 some time ago (e.g., in 3.0.0-beta1), but not
> now. Looks like a degradation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20649) SQL: class cast exception in EXCEPT SELECT with different column types
[
https://issues.apache.org/jira/browse/IGNITE-20649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin reassigned IGNITE-20649:
-
Assignee: Pavel Pereslegin
> SQL: class cast exception in EXCEPT SELECT with different column types
> --
>
> Key: IGNITE-20649
> URL: https://issues.apache.org/jira/browse/IGNITE-20649
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3, sql
>
> Steps to reproduce:
> 1. Create two tables, one with `INT` column and one with `NUMERIC`. Add some
> sample data into both.
> {code:sql}
> -- first table
> drop table if exists tmp_table_age_name_wage;
> create table tmp_table_age_name_wage (key_field INT PRIMARY KEY,AGE
> INT,field1 VARCHAR,field2 INT);
> insert into tmp_table_age_name_wage (key_field,AGE,field1,field2) values (1,
> 42,'John',10);
> insert into tmp_table_age_name_wage (key_field,AGE,field1,field2) values (2,
> 43,'Jack',5);
> -- second table
> drop table if exists tmp_table_age_name_wage_2;
> create table tmp_table_age_name_wage_2 (key_field INT PRIMARY KEY,AGE
> DECIMAL,field1 VARCHAR,field2 DECIMAL);
> insert into tmp_table_age_name_wage_2 (key_field,AGE,field1,field2) values
> (1, 42,'John',10);
> {code}
> 2. `UNION SELECT` for columns with different types works fine:
> {code:sql}
> sql-cli> SELECT AGE,field1,field2 FROM tmp_table_age_name_wage UNION SELECT
> AGE,field1,field2 FROM tmp_table_age_name_wage_2;
> ╔═╤╤╗
> ║ AGE │ FIELD1 │ FIELD2 ║
> ╠═╪╪╣
> ║ 42 │ John │ 10 ║
> ╟─┼┼╢
> ║ 42 │ John │ 10 ║
> ╟─┼┼╢
> ║ 43 │ Jack │ 5 ║
> ╚═╧╧╝
> {code}
> 3. Nevertheless, `EXCEPT SELECT` leads to class casting exception:
> {code:sql}
> sql-cli> SELECT AGE,field1,field2 FROM tmp_table_age_name_wage EXCEPT SELECT
> AGE,field1,field2 FROM tmp_table_age_name_wage_2;
> SQL query execution error
> class java.math.BigDecimal cannot be cast to class java.lang.Integer
> (java.math.BigDecimal and java.lang.Integer are in module java.base of loader
> 'bootstrap')
> {code}
> The query above worked in AI3 some time ago (e.g., in 3.0.0-beta1), but not
> now. Looks like a degradation.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21823) fix log message pageSize
[ https://issues.apache.org/jira/browse/IGNITE-21823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Nikolaev updated IGNITE-21823: Labels: ise newbie (was: ise) > fix log message pageSize > > > Key: IGNITE-21823 > URL: https://issues.apache.org/jira/browse/IGNITE-21823 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Priority: Minor > Labels: ise, newbie > Fix For: 2.17 > > > If you do not indicate in the configuration, the size of pageSize, then in > the log we see the message that pageSize = 0 that is not true -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21823) fix log message pageSize
[ https://issues.apache.org/jira/browse/IGNITE-21823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Nikolaev updated IGNITE-21823: Description: If you do not indicate in the configuration, the size of pageSize, then in the log we see the message that pageSize = 0 that is not true (was: If you do not indicate in the configuration, the size of pagesize, then in the log we see the message that pageSize = 0 that is not true) > fix log message pageSize > > > Key: IGNITE-21823 > URL: https://issues.apache.org/jira/browse/IGNITE-21823 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Priority: Minor > Labels: ise > Fix For: 2.17 > > > If you do not indicate in the configuration, the size of pageSize, then in > the log we see the message that pageSize = 0 that is not true -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21823) fix log message pageSize
[ https://issues.apache.org/jira/browse/IGNITE-21823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Nikolaev updated IGNITE-21823: Labels: ise (was: ) > fix log message pageSize > > > Key: IGNITE-21823 > URL: https://issues.apache.org/jira/browse/IGNITE-21823 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Priority: Minor > Labels: ise > > If you do not indicate in the configuration, the size of pagesize, then in > the log we see the message that pageSize = 0 that is not true -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21823) fix log message pageSize
Aleksandr Nikolaev created IGNITE-21823: --- Summary: fix log message pageSize Key: IGNITE-21823 URL: https://issues.apache.org/jira/browse/IGNITE-21823 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Nikolaev If you do not indicate in the configuration, the size of pagesize, then in the log we see the message that pageSize = 0 that is not true -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21823) fix log message pageSize
[ https://issues.apache.org/jira/browse/IGNITE-21823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Nikolaev updated IGNITE-21823: Fix Version/s: 2.17 > fix log message pageSize > > > Key: IGNITE-21823 > URL: https://issues.apache.org/jira/browse/IGNITE-21823 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Priority: Minor > Labels: ise > Fix For: 2.17 > > > If you do not indicate in the configuration, the size of pagesize, then in > the log we see the message that pageSize = 0 that is not true -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21145) MvccDataInnerIO removal
[ https://issues.apache.org/jira/browse/IGNITE-21145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-21145: Description: Delete all classes from org/apache/ignite/internal/processors/cache/tree/mvcc/data: * MvccCacheIdAwareDataInnerIO * MvccCacheIdAwareDataLeafIO * MvccDataInnerIO * MvccDataLeafIO * MvccDataRow * MvccUpdateDataRow * MvccUpdateResult * ResultType was: Delete all classes from src/main/java/org/apache/ignite/internal/processors/cache/tree/mvcc/data: * MvccCacheIdAwareDataInnerIO * MvccCacheIdAwareDataLeafIO * MvccDataInnerIO * MvccDataLeafIO * MvccDataRow * MvccUpdateDataRow * MvccUpdateResult * ResultType > MvccDataInnerIO removal > --- > > Key: IGNITE-21145 > URL: https://issues.apache.org/jira/browse/IGNITE-21145 > Project: Ignite > Issue Type: Sub-task >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > > Delete all classes from > org/apache/ignite/internal/processors/cache/tree/mvcc/data: > * MvccCacheIdAwareDataInnerIO > * MvccCacheIdAwareDataLeafIO > * MvccDataInnerIO > * MvccDataLeafIO > * MvccDataRow > * MvccUpdateDataRow > * MvccUpdateResult > * ResultType -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21674) Subcommand completion is broken in CLI
[ https://issues.apache.org/jira/browse/IGNITE-21674?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vadim Pakhnushev reassigned IGNITE-21674: - Assignee: Vadim Pakhnushev > Subcommand completion is broken in CLI > -- > > Key: IGNITE-21674 > URL: https://issues.apache.org/jira/browse/IGNITE-21674 > Project: Ignite > Issue Type: Bug > Components: cli >Reporter: Aleksandr >Assignee: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > > Steps to reproduce: > - build cli from main > - run interactive mode > - (all commands are suggested, it is ok) > - choose "cluster" > - only one subcommand are completed (all cluster * subcommands expected) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21145) MvccDataInnerIO removal
[ https://issues.apache.org/jira/browse/IGNITE-21145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-21145: Description: Delete all classes from src/main/java/org/apache/ignite/internal/processors/cache/tree/mvcc/data: * MvccCacheIdAwareDataInnerIO * MvccCacheIdAwareDataLeafIO * MvccDataInnerIO * MvccDataLeafIO * MvccDataRow * MvccUpdateDataRow * MvccUpdateResult * ResultType was: Remove all classes from src/main/java/org/apache/ignite/internal/processors/cache/tree/mvcc/data: * MvccCacheIdAwareDataInnerIO * MvccCacheIdAwareDataLeafIO * MvccDataInnerIO * MvccDataLeafIO * MvccDataRow * MvccUpdateDataRow * MvccUpdateResult * ResultType > MvccDataInnerIO removal > --- > > Key: IGNITE-21145 > URL: https://issues.apache.org/jira/browse/IGNITE-21145 > Project: Ignite > Issue Type: Sub-task >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > > Delete all classes from > src/main/java/org/apache/ignite/internal/processors/cache/tree/mvcc/data: > * MvccCacheIdAwareDataInnerIO > * MvccCacheIdAwareDataLeafIO > * MvccDataInnerIO > * MvccDataLeafIO > * MvccDataRow > * MvccUpdateDataRow > * MvccUpdateResult > * ResultType -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21330) Sql. Index is not used for IN predicate with column type of UUID
[
https://issues.apache.org/jira/browse/IGNITE-21330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-21330:
--
Description:
See ItUuidIndexTest#testInLookUp, false scan is used in execution although
index is available.
The query is
{code:java}
SELECT *
FROM t
WHERE test_key IN ('--0001--0001'::UUID,
'--0003--0001'::UUID)
ORDER BY id
{code}
and the plan is
{code:java}
IgniteExchange(distribution=[single])
IgniteSort(sort0=[$0], dir0=[ASC])
IgniteTableScan(table=[[PUBLIC, T]], tableId=[6], filters=[OR(=($t1,
CAST(_UTF-8'--0001--0001'):UUID NOT NULL), =($t1,
CAST(_UTF-8'--0003--0001'):UUID NOT NULL))],
requiredColumns=[{0, 1}])
{code}
h4. Update
The issue is raised after rule {{LogicalOrToUnionRule}} has been disabled.
Without this rule, the index was not used, because SARG can only be assembled
from constants, and since there is no UUID literal, we end up with an OR
operator that was not supported when assembling search boundaries for the index.
A solution to the problem of OR operator support is described in the pull
request ([#3407|https://github.com/apache/ignite-3/pull/3407]).
was:
See ItUuidIndexTest#testInLookUp, false scan is used in execution although
index is available.
The query is
{code:java}
SELECT *
FROM t
WHERE test_key IN ('--0001--0001'::UUID,
'--0003--0001'::UUID)
ORDER BY id
{code}
and the plan is
{code:java}
IgniteExchange(distribution=[single])
IgniteSort(sort0=[$0], dir0=[ASC])
IgniteTableScan(table=[[PUBLIC, T]], tableId=[6], filters=[OR(=($t1,
CAST(_UTF-8'--0001--0001'):UUID NOT NULL), =($t1,
CAST(_UTF-8'--0003--0001'):UUID NOT NULL))],
requiredColumns=[{0, 1}])
{code}
h5. Update
The issue is raised after rule {{LogicalOrToUnionRule}} has been disabled.
Without this rule, the index was not used, because SARG can only be assembled
from constants, and since there is no UUID literal, we end up with an OR
operator that was not supported when assembling search boundaries for the index.
A solution to the problem of OR operator support is described in the pull
request ([#3407|https://github.com/apache/ignite-3/pull/3407]).
> Sql. Index is not used for IN predicate with column type of UUID
>
>
> Key: IGNITE-21330
> URL: https://issues.apache.org/jira/browse/IGNITE-21330
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> See ItUuidIndexTest#testInLookUp, false scan is used in execution although
> index is available.
> The query is
> {code:java}
> SELECT *
> FROM t
> WHERE test_key IN ('--0001--0001'::UUID,
> '--0003--0001'::UUID)
> ORDER BY id
> {code}
> and the plan is
> {code:java}
> IgniteExchange(distribution=[single])
> IgniteSort(sort0=[$0], dir0=[ASC])
> IgniteTableScan(table=[[PUBLIC, T]], tableId=[6], filters=[OR(=($t1,
> CAST(_UTF-8'--0001--0001'):UUID NOT NULL), =($t1,
> CAST(_UTF-8'--0003--0001'):UUID NOT NULL))],
> requiredColumns=[{0, 1}])
> {code}
> h4. Update
> The issue is raised after rule {{LogicalOrToUnionRule}} has been disabled.
> Without this rule, the index was not used, because SARG can only be assembled
> from constants, and since there is no UUID literal, we end up with an OR
> operator that was not supported when assembling search boundaries for the
> index.
> A solution to the problem of OR operator support is described in the pull
> request ([#3407|https://github.com/apache/ignite-3/pull/3407]).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21145) MvccDataInnerIO removal
[ https://issues.apache.org/jira/browse/IGNITE-21145?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Julia Bakulina updated IGNITE-21145: Description: Remove all classes from src/main/java/org/apache/ignite/internal/processors/cache/tree/mvcc/data: * MvccCacheIdAwareDataInnerIO * MvccCacheIdAwareDataLeafIO * MvccDataInnerIO * MvccDataLeafIO * MvccDataRow * MvccUpdateDataRow * MvccUpdateResult * ResultType was:Remove MvccDataInnerIO > MvccDataInnerIO removal > --- > > Key: IGNITE-21145 > URL: https://issues.apache.org/jira/browse/IGNITE-21145 > Project: Ignite > Issue Type: Sub-task >Reporter: Julia Bakulina >Assignee: Julia Bakulina >Priority: Minor > Labels: ise > Time Spent: 10m > Remaining Estimate: 0h > > Remove all classes from > src/main/java/org/apache/ignite/internal/processors/cache/tree/mvcc/data: > * MvccCacheIdAwareDataInnerIO > * MvccCacheIdAwareDataLeafIO > * MvccDataInnerIO > * MvccDataLeafIO > * MvccDataRow > * MvccUpdateDataRow > * MvccUpdateResult > * ResultType -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21330) Sql. Index is not used for IN predicate with column type of UUID
[
https://issues.apache.org/jira/browse/IGNITE-21330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-21330:
--
Description:
See ItUuidIndexTest#testInLookUp, false scan is used in execution although
index is available.
The query is
{code:java}
SELECT *
FROM t
WHERE test_key IN ('--0001--0001'::UUID,
'--0003--0001'::UUID)
ORDER BY id
{code}
and the plan is
{code:java}
IgniteExchange(distribution=[single])
IgniteSort(sort0=[$0], dir0=[ASC])
IgniteTableScan(table=[[PUBLIC, T]], tableId=[6], filters=[OR(=($t1,
CAST(_UTF-8'--0001--0001'):UUID NOT NULL), =($t1,
CAST(_UTF-8'--0003--0001'):UUID NOT NULL))],
requiredColumns=[{0, 1}])
{code}
h5. Update
The issue is raised after rule {{LogicalOrToUnionRule}} has been disabled.
Without this rule, the index was not used, because SARG can only be assembled
from constants, and since there is no UUID literal, we end up with an OR
operator that was not supported when assembling search boundaries for the index.
A solution to the problem of OR operator support is described in the pull
request ([#3407|https://github.com/apache/ignite-3/pull/3407]).
was:
See ItUuidIndexTest#testInLookUp, false scan is used in execution although
index is available.
The query is
{code:java}
SELECT *
FROM t
WHERE test_key IN ('--0001--0001'::UUID,
'--0003--0001'::UUID)
ORDER BY id
{code}
and the plan is
{code:java}
IgniteExchange(distribution=[single])
IgniteSort(sort0=[$0], dir0=[ASC])
IgniteTableScan(table=[[PUBLIC, T]], tableId=[6], filters=[OR(=($t1,
CAST(_UTF-8'--0001--0001'):UUID NOT NULL), =($t1,
CAST(_UTF-8'--0003--0001'):UUID NOT NULL))],
requiredColumns=[{0, 1}])
{code}
h5. Update
The issue is raised after rule {{LogicalOrToUnionRule}} has been disabled.
Without this rule, the index was not used, because SARG can only be assembled
from constants, and since there is no UUID literal, we end up with an OR
operator that was not supported when assembling search boundaries for the index.
A solution to the problem of OR operator support is described in the pull
request (#3407).
> Sql. Index is not used for IN predicate with column type of UUID
>
>
> Key: IGNITE-21330
> URL: https://issues.apache.org/jira/browse/IGNITE-21330
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> See ItUuidIndexTest#testInLookUp, false scan is used in execution although
> index is available.
> The query is
> {code:java}
> SELECT *
> FROM t
> WHERE test_key IN ('--0001--0001'::UUID,
> '--0003--0001'::UUID)
> ORDER BY id
> {code}
> and the plan is
> {code:java}
> IgniteExchange(distribution=[single])
> IgniteSort(sort0=[$0], dir0=[ASC])
> IgniteTableScan(table=[[PUBLIC, T]], tableId=[6], filters=[OR(=($t1,
> CAST(_UTF-8'--0001--0001'):UUID NOT NULL), =($t1,
> CAST(_UTF-8'--0003--0001'):UUID NOT NULL))],
> requiredColumns=[{0, 1}])
> {code}
> h5. Update
> The issue is raised after rule {{LogicalOrToUnionRule}} has been disabled.
> Without this rule, the index was not used, because SARG can only be assembled
> from constants, and since there is no UUID literal, we end up with an OR
> operator that was not supported when assembling search boundaries for the
> index.
> A solution to the problem of OR operator support is described in the pull
> request ([#3407|https://github.com/apache/ignite-3/pull/3407]).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21330) Sql. Index is not used for IN predicate with column type of UUID
[
https://issues.apache.org/jira/browse/IGNITE-21330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-21330:
--
Description:
See ItUuidIndexTest#testInLookUp, false scan is used in execution although
index is available.
The query is
{code:java}
SELECT *
FROM t
WHERE test_key IN ('--0001--0001'::UUID,
'--0003--0001'::UUID)
ORDER BY id
{code}
and the plan is
{code:java}
IgniteExchange(distribution=[single])
IgniteSort(sort0=[$0], dir0=[ASC])
IgniteTableScan(table=[[PUBLIC, T]], tableId=[6], filters=[OR(=($t1,
CAST(_UTF-8'--0001--0001'):UUID NOT NULL), =($t1,
CAST(_UTF-8'--0003--0001'):UUID NOT NULL))],
requiredColumns=[{0, 1}])
{code}
h5. Update
The issue is raised after rule {{LogicalOrToUnionRule}} has been disabled.
Without this rule, the index was not used, because SARG can only be assembled
from constants, and since there is no UUID literal, we end up with an OR
operator that was not supported when assembling search boundaries for the index.
A solution to the problem of OR operator support is described in the pull
request (#3407).
was:
See ItUuidIndexTest#testInLookUp, false scan is used in execution although
index is available.
The query is
{code:java}
SELECT *
FROM t
WHERE test_key IN ('--0001--0001'::UUID,
'--0003--0001'::UUID)
ORDER BY id
{code}
and the plan is
{code:java}
IgniteExchange(distribution=[single])
IgniteSort(sort0=[$0], dir0=[ASC])
IgniteTableScan(table=[[PUBLIC, T]], tableId=[6], filters=[OR(=($t1,
CAST(_UTF-8'--0001--0001'):UUID NOT NULL), =($t1,
CAST(_UTF-8'--0003--0001'):UUID NOT NULL))],
requiredColumns=[{0, 1}])
{code}
h5. Update
The issue is raised after rule {{LogicalOrToUnionRule}} has been disabled.
Without this rule, the index was not used, because SARG can only be assembled
from constants, and since there is no UUID literal, we end up with an OR
operator that was not supported when assembling search boundaries for the index.
A solution to the problem of OR operator support is described in the pull
request.
> Sql. Index is not used for IN predicate with column type of UUID
>
>
> Key: IGNITE-21330
> URL: https://issues.apache.org/jira/browse/IGNITE-21330
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> See ItUuidIndexTest#testInLookUp, false scan is used in execution although
> index is available.
> The query is
> {code:java}
> SELECT *
> FROM t
> WHERE test_key IN ('--0001--0001'::UUID,
> '--0003--0001'::UUID)
> ORDER BY id
> {code}
> and the plan is
> {code:java}
> IgniteExchange(distribution=[single])
> IgniteSort(sort0=[$0], dir0=[ASC])
> IgniteTableScan(table=[[PUBLIC, T]], tableId=[6], filters=[OR(=($t1,
> CAST(_UTF-8'--0001--0001'):UUID NOT NULL), =($t1,
> CAST(_UTF-8'--0003--0001'):UUID NOT NULL))],
> requiredColumns=[{0, 1}])
> {code}
> h5. Update
> The issue is raised after rule {{LogicalOrToUnionRule}} has been disabled.
> Without this rule, the index was not used, because SARG can only be assembled
> from constants, and since there is no UUID literal, we end up with an OR
> operator that was not supported when assembling search boundaries for the
> index.
> A solution to the problem of OR operator support is described in the pull
> request (#3407).
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21330) Sql. Index is not used for IN predicate with column type of UUID
[
https://issues.apache.org/jira/browse/IGNITE-21330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-21330:
--
Description:
See ItUuidIndexTest#testInLookUp, false scan is used in execution although
index is available.
The query is
{code:java}
SELECT *
FROM t
WHERE test_key IN ('--0001--0001'::UUID,
'--0003--0001'::UUID)
ORDER BY id
{code}
and the plan is
{code:java}
IgniteExchange(distribution=[single])
IgniteSort(sort0=[$0], dir0=[ASC])
IgniteTableScan(table=[[PUBLIC, T]], tableId=[6], filters=[OR(=($t1,
CAST(_UTF-8'--0001--0001'):UUID NOT NULL), =($t1,
CAST(_UTF-8'--0003--0001'):UUID NOT NULL))],
requiredColumns=[{0, 1}])
{code}
h5. Update
The issue is raised after rule {{LogicalOrToUnionRule}} has been disabled.
Without this rule, the index was not used, because SARG can only be assembled
from constants, and since there is no UUID literal, we end up with an OR
operator that was not supported when assembling search boundaries for the index.
A solution to the problem of OR operator support is described in the pull
request.
was:
See ItUuidIndexTest#testInLookUp, false scan is used in execution although
index is available.
The query is
{code:java}
SELECT *
FROM t
WHERE test_key IN ('--0001--0001'::UUID,
'--0003--0001'::UUID)
ORDER BY id
{code}
and the plan is
{code:java}
IgniteExchange(distribution=[single])
IgniteSort(sort0=[$0], dir0=[ASC])
IgniteTableScan(table=[[PUBLIC, T]], tableId=[6], filters=[OR(=($t1,
CAST(_UTF-8'--0001--0001'):UUID NOT NULL), =($t1,
CAST(_UTF-8'--0003--0001'):UUID NOT NULL))],
requiredColumns=[{0, 1}])
{code}
> Sql. Index is not used for IN predicate with column type of UUID
>
>
> Key: IGNITE-21330
> URL: https://issues.apache.org/jira/browse/IGNITE-21330
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> See ItUuidIndexTest#testInLookUp, false scan is used in execution although
> index is available.
> The query is
> {code:java}
> SELECT *
> FROM t
> WHERE test_key IN ('--0001--0001'::UUID,
> '--0003--0001'::UUID)
> ORDER BY id
> {code}
> and the plan is
> {code:java}
> IgniteExchange(distribution=[single])
> IgniteSort(sort0=[$0], dir0=[ASC])
> IgniteTableScan(table=[[PUBLIC, T]], tableId=[6], filters=[OR(=($t1,
> CAST(_UTF-8'--0001--0001'):UUID NOT NULL), =($t1,
> CAST(_UTF-8'--0003--0001'):UUID NOT NULL))],
> requiredColumns=[{0, 1}])
> {code}
> h5. Update
> The issue is raised after rule {{LogicalOrToUnionRule}} has been disabled.
> Without this rule, the index was not used, because SARG can only be assembled
> from constants, and since there is no UUID literal, we end up with an OR
> operator that was not supported when assembling search boundaries for the
> index.
> A solution to the problem of OR operator support is described in the pull
> request.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Closed] (IGNITE-21644) Deadlock prevention makes Java Async APIs (KV/RV) hard to use
[ https://issues.apache.org/jira/browse/IGNITE-21644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak closed IGNITE-21644. - > Deadlock prevention makes Java Async APIs (KV/RV) hard to use > - > > Key: IGNITE-21644 > URL: https://issues.apache.org/jira/browse/IGNITE-21644 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > # Create table T1 > # Get KeyValue view or Record View > # Make a batch of 100 rows and call CompletableFuture f = > view.putAllAsync(null , batch) or view. > upsertAllAsync(null, batch) > # Make another batch and compose it with the first CompletableFuture with: > f.thenCompose(r -> view.putAllAsync(null, newBatch)); > Expected behavior: batch completed sucessfully. > Actual behavior: Failed to acquire a lock due to a possible deadlock -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Reopened] (IGNITE-21644) Deadlock prevention makes Java Async APIs (KV/RV) hard to use
[ https://issues.apache.org/jira/browse/IGNITE-21644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak reopened IGNITE-21644: --- > Deadlock prevention makes Java Async APIs (KV/RV) hard to use > - > > Key: IGNITE-21644 > URL: https://issues.apache.org/jira/browse/IGNITE-21644 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > # Create table T1 > # Get KeyValue view or Record View > # Make a batch of 100 rows and call CompletableFuture f = > view.putAllAsync(null , batch) or view. > upsertAllAsync(null, batch) > # Make another batch and compose it with the first CompletableFuture with: > f.thenCompose(r -> view.putAllAsync(null, newBatch)); > Expected behavior: batch completed sucessfully. > Actual behavior: Failed to acquire a lock due to a possible deadlock -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21644) Deadlock prevention makes Java Async APIs (KV/RV) hard to use
[ https://issues.apache.org/jira/browse/IGNITE-21644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak resolved IGNITE-21644. --- Resolution: Invalid > Deadlock prevention makes Java Async APIs (KV/RV) hard to use > - > > Key: IGNITE-21644 > URL: https://issues.apache.org/jira/browse/IGNITE-21644 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > # Create table T1 > # Get KeyValue view or Record View > # Make a batch of 100 rows and call CompletableFuture f = > view.putAllAsync(null , batch) or view. > upsertAllAsync(null, batch) > # Make another batch and compose it with the first CompletableFuture with: > f.thenCompose(r -> view.putAllAsync(null, newBatch)); > Expected behavior: batch completed sucessfully. > Actual behavior: Failed to acquire a lock due to a possible deadlock -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21644) Deadlock prevention makes Java Async APIs (KV/RV) hard to use
[ https://issues.apache.org/jira/browse/IGNITE-21644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Belyak resolved IGNITE-21644. --- Resolution: Fixed The problem was that I've use the same Map in two putAllAsync calls. At the time they actually read the map it contains the same keys - the last batch. That’s why we have a deadlock. I’ll close this issue as invalid. Thanks for you time. > Deadlock prevention makes Java Async APIs (KV/RV) hard to use > - > > Key: IGNITE-21644 > URL: https://issues.apache.org/jira/browse/IGNITE-21644 > Project: Ignite > Issue Type: Bug > Components: persistence >Affects Versions: 3.0 >Reporter: Alexander Belyak >Priority: Major > Labels: ignite-3 > > # Create table T1 > # Get KeyValue view or Record View > # Make a batch of 100 rows and call CompletableFuture f = > view.putAllAsync(null , batch) or view. > upsertAllAsync(null, batch) > # Make another batch and compose it with the first CompletableFuture with: > f.thenCompose(r -> view.putAllAsync(null, newBatch)); > Expected behavior: batch completed sucessfully. > Actual behavior: Failed to acquire a lock due to a possible deadlock -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-19809) Make maxClockSkew a cluster-wide configuration property
[ https://issues.apache.org/jira/browse/IGNITE-19809?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy reassigned IGNITE-19809: -- Assignee: Roman Puchkovskiy > Make maxClockSkew a cluster-wide configuration property > --- > > Key: IGNITE-19809 > URL: https://issues.apache.org/jira/browse/IGNITE-19809 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Currently, max clock skew is defined (under the name of CLOCK_SKEW) in > HybridTimestamp class. It should be configurable. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21761) Within commitPartition mark txnState with cleanup replication finished timestamp
[ https://issues.apache.org/jira/browse/IGNITE-21761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Sizov updated IGNITE-21761: --- Description: h3. Motivation Volatile txn state removal is implemented in IGNITE-21759 Worth mentioning that having volatile txnState is mainly an optimization just because it might be lost on node restart. This ticket is about marking txn persistent state as ready for removal. Basically it is ready for removal when the state is either COMMITED or ABORTED and cleanup is fully replicated over majority of all enlisted partitions, including pre-cleanup within primary replica. There are some nuances related to txn recovery case that will be covered in another jiras. h3. Definition of Done * In a durable manner (meaning retry on failure) await cleanup replication over majority of all enlisted partitions along with corresponding pre-cleanup within primary replica. * On cleanup done, compute txnState in txnStateVolatileMap by setting txnState.cleanupCompletionTimestamp to System.currentTimeMillis(). Pay attention that depending on whether given txnState was already removed by TxnResourseVacuumTask or not, it's either an adjusting of an exiting entry in txnStateVolatileMap with timestamp or writing a brand new record. In latter case another iteration of TxnStateCleanupTask will remove newly created entry. Besides that if the volatile state was removed it won't be possible to restore all the meta, which is fine, because all we need is txnId, txnState and System.currentTimeMillies as cleanupReplicationFinished timestamp. * There will be another Jira that will consider such timestamps and remove corresponding states from txnStatePersistentStorage. For now it's out of scope. * There will be another task that will redo the cleanup on node startup in order to restore (or formally re-evaluate) the cleanup replication finished timestamp. For now it's out of scope. was: h3. Motivation Volatile txn state removal is implemented in IGNITE-21759 Worth mentioning that having volatile txnState is mainly an optimization just because it might be lost on node restart. This ticket is about marking txn persistent state as ready for removal. Basically it is ready for removal when the state is either COMMITED or ABORTED and cleanup is fully replicated over majority of all enlisted partitions, including pre-cleanup within primary replica. There are some nuances related to txn recovery case that will be covered in another jiras. h3. Definition of Done * In a durable manner (meaning retry on failure) await cleanup replication over majority of all enlisted partitions along with corresponding pre-cleanup within primary replica. * On cleanup done, compute txnState in txnStateVolatileMap by setting txnState.cleanupCompletionTimestamp to System.currentTimeMillis(). Pay attention that depending on whether given txnState was already removed by TxnResourseVacoomTask or not, it's either an adjusting of an exiting entry in txnStateVolatileMap with timestamp or writing a brand new record. In latter case another iteration of TxnStateCleanupTask will remove newly created entry. Besides that if the volatile state was removed it won't be possible to restore all the meta, which is fine, because all we need is txnId, txnState and System.currentTimeMillies as cleanupReplicationFinished timestamp. * There will be another Jira that will consider such timestamps and remove corresponding states from txnStatePersistentStorage. For now it's out of scope. * There will be another task that will redo the cleanup on node startup in order to restore (or formally re-evaluate) the cleanup replication finished timestamp. For now it's out of scope. > Within commitPartition mark txnState with cleanup replication finished > timestamp > > > Key: IGNITE-21761 > URL: https://issues.apache.org/jira/browse/IGNITE-21761 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Kirill Sizov >Priority: Major > Labels: ignite-3 > > h3. Motivation > Volatile txn state removal is implemented in IGNITE-21759 Worth mentioning > that having volatile txnState is mainly an optimization just because it might > be lost on node restart. > This ticket is about marking txn persistent state as ready for removal. > Basically it is ready for removal when the state is either COMMITED or > ABORTED and cleanup is fully replicated over majority of all enlisted > partitions, including pre-cleanup within primary replica. There are some > nuances related to txn recovery case that will be covered in another jiras. > h3. Definition of Done > * In a durable manner (meaning retry on failure) await cleanup replication > over majority of a
[jira] [Assigned] (IGNITE-21822) Sql. Allow to set time zone on per statement basis
[ https://issues.apache.org/jira/browse/IGNITE-21822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov reassigned IGNITE-21822: - Assignee: Konstantin Orlov > Sql. Allow to set time zone on per statement basis > -- > > Key: IGNITE-21822 > URL: https://issues.apache.org/jira/browse/IGNITE-21822 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > In IGNITE-21551, support for time zone was added to the sql engine. However, > only Session was updated, while Statement was left intact. Let's eliminate > such a discrepancy by providing an ability to set time zone on per statement > basis. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21822) Sql. Allow to set time zone on per statement basis
Konstantin Orlov created IGNITE-21822: - Summary: Sql. Allow to set time zone on per statement basis Key: IGNITE-21822 URL: https://issues.apache.org/jira/browse/IGNITE-21822 Project: Ignite Issue Type: Improvement Components: sql Reporter: Konstantin Orlov In IGNITE-21551, support for time zone was added to the sql engine. However, only Session was updated, while Statement was left intact. Let's eliminate such a discrepancy by providing an ability to set time zone on per statement basis. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21673) Sql. Do not allow duplicate column names in unique column list of a primary key constraint.
[ https://issues.apache.org/jira/browse/IGNITE-21673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Iurii Gerzhedovich reassigned IGNITE-21673: --- Assignee: Iurii Gerzhedovich > Sql. Do not allow duplicate column names in unique column list of a primary > key constraint. > > > Key: IGNITE-21673 > URL: https://issues.apache.org/jira/browse/IGNITE-21673 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Iurii Gerzhedovich >Priority: Minor > Labels: ignite-3 > > SQL standard does not allow to include the same column multiple times in > column list of a primary key. > AI-3 accepts multiple columns with the same name, because it deduplicates > them. Let's update DDL command to catalog command conversion to be consistent > with the standard. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21821) Error: Partition file page store is either not initialized or deleted
[
https://issues.apache.org/jira/browse/IGNITE-21821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iurii Gerzhedovich updated IGNITE-21821:
Priority: Blocker (was: Major)
> Error: Partition file page store is either not initialized or deleted
> -
>
> Key: IGNITE-21821
> URL: https://issues.apache.org/jira/browse/IGNITE-21821
> Project: Ignite
> Issue Type: Improvement
>Reporter: Iurii Gerzhedovich
>Priority: Blocker
> Labels: ignite-3
>
> During looking into log [one of TC
> run|https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7952341?hideTestsFromDependencies=false&hideProblemsFromDependencies=false&expandBuildTestsSection=true&expandCode+Inspection=true&expandBuildProblemsSection=true&expandBuildChangesSection=true&expandBuildDeploymentsSection=false]
> I found Error in log, which looks dangerous
> {code:java}
> ®[2024-03-20T11:15:35,893][ERROR][checkpoint-runner-io0][FailureProcessor]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [], failureCtx=FailureContext
> [type=CRITICAL_ERROR,
> err=org.apache.ignite.internal.lang.IgniteInternalCheckedException:
> IGN-CMN-65535 TraceId:64d96aba-9a18-420d-af54-dd3679466403 Partition file
> page store is either not initialized or deleted: [groupId=81,
> partitionId=19]]]
> org.apache.ignite.internal.lang.IgniteInternalCheckedException: Partition
> file page store is either not initialized or deleted: [groupId=81,
> partitionId=19]
> at
> org.apache.ignite.internal.pagememory.persistence.store.FilePageStoreManager.getStoreWithCheckExists(FilePageStoreManager.java:298)
> ~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.pagememory.persistence.store.FilePageStoreManager.allocatePage(FilePageStoreManager.java:259)
> ~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.pagememory.persistence.PersistentPageMemory.allocatePage(PersistentPageMemory.java:513)
> ~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.pagememory.datastructure.DataStructure.allocatePageNoReuse(DataStructure.java:193)
> ~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.pagememory.datastructure.DataStructure.allocatePage(DataStructure.java:174)
> ~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.pagememory.freelist.PagesList.addStripe(PagesList.java:589)
> ~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.pagememory.freelist.PagesList.getStripeForPut(PagesList.java:711)
> ~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.pagememory.freelist.PagesList.put(PagesList.java:815)
> ~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.pagememory.freelist.PagesList$PutBucket.run(PagesList.java:173)
> ~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.pagememory.freelist.PagesList$PutBucket.run(PagesList.java:147)
> ~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.pagememory.util.PageHandler.writePage(PageHandler.java:298)
> ~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.pagememory.datastructure.DataStructure.write(DataStructure.java:296)
> ~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.pagememory.freelist.PagesList.flushBucketsCache(PagesList.java:387)
> ~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.pagememory.freelist.PagesList.saveMetadata(PagesList.java:332)
> ~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.storage.pagememory.mv.RowVersionFreeList.saveMetadata(RowVersionFreeList.java:185)
> ~[ignite-storage-page-memory-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.storage.pagememory.mv.PersistentPageMemoryMvPartitionStorage.lambda$syncMetadataOnCheckpoint$13(PersistentPageMemoryMvPartitionStorage.java:367)
> ~[ignite-storage-page-memory-3.0.0-SNAPSHOT.jar:?]
> at
> org.apache.ignite.internal.pagememory.persistence.checkpoint.AwaitTasksCompletionExecutor.lambda$execute$1(AwaitTasksCompletionExecutor.java:59)
> ~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.base/java.lang.Thread.run(Thread.java:834) [?:?] stderr
> tc:parseServiceMessagesInside,ãÌ7- Ž[’à
> ‰‰[2024-03-20T11:15:35,912][INFO
> ][%sqllogic0%JRaft-FSMCaller-Disruptor_st
[jira] [Created] (IGNITE-21821) Error: Partition file page store is either not initialized or deleted
Iurii Gerzhedovich created IGNITE-21821:
---
Summary: Error: Partition file page store is either not
initialized or deleted
Key: IGNITE-21821
URL: https://issues.apache.org/jira/browse/IGNITE-21821
Project: Ignite
Issue Type: Improvement
Reporter: Iurii Gerzhedovich
During looking into log [one of TC
run|https://ci.ignite.apache.org/buildConfiguration/ApacheIgnite3xGradle_Test_RunAllTests/7952341?hideTestsFromDependencies=false&hideProblemsFromDependencies=false&expandBuildTestsSection=true&expandCode+Inspection=true&expandBuildProblemsSection=true&expandBuildChangesSection=true&expandBuildDeploymentsSection=false]
I found Error in log, which looks dangerous
{code:java}
®[2024-03-20T11:15:35,893][ERROR][checkpoint-runner-io0][FailureProcessor]
Critical system error detected. Will be handled accordingly to configured
handler [hnd=NoOpFailureHandler [], failureCtx=FailureContext
[type=CRITICAL_ERROR,
err=org.apache.ignite.internal.lang.IgniteInternalCheckedException:
IGN-CMN-65535 TraceId:64d96aba-9a18-420d-af54-dd3679466403 Partition file page
store is either not initialized or deleted: [groupId=81, partitionId=19]]]
org.apache.ignite.internal.lang.IgniteInternalCheckedException: Partition file
page store is either not initialized or deleted: [groupId=81, partitionId=19]
at
org.apache.ignite.internal.pagememory.persistence.store.FilePageStoreManager.getStoreWithCheckExists(FilePageStoreManager.java:298)
~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.pagememory.persistence.store.FilePageStoreManager.allocatePage(FilePageStoreManager.java:259)
~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.pagememory.persistence.PersistentPageMemory.allocatePage(PersistentPageMemory.java:513)
~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.pagememory.datastructure.DataStructure.allocatePageNoReuse(DataStructure.java:193)
~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.pagememory.datastructure.DataStructure.allocatePage(DataStructure.java:174)
~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.pagememory.freelist.PagesList.addStripe(PagesList.java:589)
~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.pagememory.freelist.PagesList.getStripeForPut(PagesList.java:711)
~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.pagememory.freelist.PagesList.put(PagesList.java:815)
~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.pagememory.freelist.PagesList$PutBucket.run(PagesList.java:173)
~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.pagememory.freelist.PagesList$PutBucket.run(PagesList.java:147)
~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.pagememory.util.PageHandler.writePage(PageHandler.java:298)
~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.pagememory.datastructure.DataStructure.write(DataStructure.java:296)
~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.pagememory.freelist.PagesList.flushBucketsCache(PagesList.java:387)
~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.pagememory.freelist.PagesList.saveMetadata(PagesList.java:332)
~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.storage.pagememory.mv.RowVersionFreeList.saveMetadata(RowVersionFreeList.java:185)
~[ignite-storage-page-memory-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.storage.pagememory.mv.PersistentPageMemoryMvPartitionStorage.lambda$syncMetadataOnCheckpoint$13(PersistentPageMemoryMvPartitionStorage.java:367)
~[ignite-storage-page-memory-3.0.0-SNAPSHOT.jar:?]
at
org.apache.ignite.internal.pagememory.persistence.checkpoint.AwaitTasksCompletionExecutor.lambda$execute$1(AwaitTasksCompletionExecutor.java:59)
~[ignite-page-memory-3.0.0-SNAPSHOT.jar:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
[?:?]
at
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
[?:?]
at java.base/java.lang.Thread.run(Thread.java:834) [?:?] stderr
tc:parseServiceMessagesInside,ãÌ7- Ž[’à
‰‰[2024-03-20T11:15:35,912][INFO
][%sqllogic0%JRaft-FSMCaller-Disruptor_stripe_8-0][StateMachineAdapter]
onLeaderStart: term=1.
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
