[jira] [Commented] (IGNITE-21290) Scan cursors do not close after being fully read in transactions
[ https://issues.apache.org/jira/browse/IGNITE-21290?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17814233#comment-17814233 ] Vladislav Pyatkov commented on IGNITE-21290: Merged 947103e94ed9fca294cf8f088368d63c4a706821 > Scan cursors do not close after being fully read in transactions > > > Key: IGNITE-21290 > URL: https://issues.apache.org/jira/browse/IGNITE-21290 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > Time Spent: 1h 50m > Remaining Estimate: 0h > > h3. Motivation > Open cursors require extra memory on the server side, so they should be > closed as soon as they are no longer used. It is easy to understand on the > coursor owner server when the coursor returns false for the hasNext > invocation. > Despite the fact that all acquired transaction resources should be released > after the transaction finalizes, it would be better to close usles coursorse > faseter. Moreover, the agreement is fit for all types of transactions: RO, > RW, and inplicit. > h3. Implementation notes > When the replica returns a batch, their size can be estimated, and the cursor > can be closed if the size is less than requested. > h3. Definition of done > A cursor is closed on the server side when the client retrieves all data from > it through any type of scan operation. > Moreover, the server-side cursors should be closed in case the cursor > supplier is closing through the API. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21371) Fix ItDmlTest#testMerge
[ https://issues.apache.org/jira/browse/IGNITE-21371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21371: - Reviewer: Alexander Lapin > Fix ItDmlTest#testMerge > --- > > Key: IGNITE-21371 > URL: https://issues.apache.org/jira/browse/IGNITE-21371 > Project: Ignite > Issue Type: Bug >Reporter: Kirill Tkalenko >Assignee: Kirill Sizov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > It was discovered that in > *org.apache.ignite.internal.sql.engine.ItDmlTest#testMerge*, queries *MERGE* > are executed in an implicit transaction that does not decrease the RW > transactions counter in > *org.apache.ignite.internal.index.IndexNodeFinishedRwTransactionsChecker#decrementRwTxCount*, > because of this, tests in which indexes are created can freeze. > If the test is turned on, > *org.apache.ignite.internal.sql.engine.ItDmlTest#rangeReadAndExclusiveInsert* > starts to fail. > h3. What is found out: > For an implicit RW transaction, *txCoordinatorId* may change because of this, > the counter cannot decrease. > This happens because the *org.apache.ignite.internal.tx.TxStateMeta* is > updated in > *org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#processRequest* > and changes *TxStateMeta#txCoordinatorId* to another, even if the > transaction is processed on the node that created it. > Presumably this is due to the fact that fragments of the transaction are > executed on different nodes; perhaps to fix it it will be enough to add > *txCoordinatorId* in the messages. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21371) Fix ItDmlTest#testMerge
[ https://issues.apache.org/jira/browse/IGNITE-21371?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17814254#comment-17814254 ] Alexander Lapin commented on IGNITE-21371: -- [~ksizov] LGTM > Fix ItDmlTest#testMerge > --- > > Key: IGNITE-21371 > URL: https://issues.apache.org/jira/browse/IGNITE-21371 > Project: Ignite > Issue Type: Bug >Reporter: Kirill Tkalenko >Assignee: Kirill Sizov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > It was discovered that in > *org.apache.ignite.internal.sql.engine.ItDmlTest#testMerge*, queries *MERGE* > are executed in an implicit transaction that does not decrease the RW > transactions counter in > *org.apache.ignite.internal.index.IndexNodeFinishedRwTransactionsChecker#decrementRwTxCount*, > because of this, tests in which indexes are created can freeze. > If the test is turned on, > *org.apache.ignite.internal.sql.engine.ItDmlTest#rangeReadAndExclusiveInsert* > starts to fail. > h3. What is found out: > For an implicit RW transaction, *txCoordinatorId* may change because of this, > the counter cannot decrease. > This happens because the *org.apache.ignite.internal.tx.TxStateMeta* is > updated in > *org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#processRequest* > and changes *TxStateMeta#txCoordinatorId* to another, even if the > transaction is processed on the node that created it. > Presumably this is due to the fact that fragments of the transaction are > executed on different nodes; perhaps to fix it it will be enough to add > *txCoordinatorId* in the messages. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21444) Storage Engine TC Green Again Backlog
Vladimir Pligin created IGNITE-21444: Summary: Storage Engine TC Green Again Backlog Key: IGNITE-21444 URL: https://issues.apache.org/jira/browse/IGNITE-21444 Project: Ignite Issue Type: Epic Reporter: Vladimir Pligin Epic to aggregated issues related to TC tests -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21445) IndexQuery ignores pageSize if setLocal=true is set
[ https://issues.apache.org/jira/browse/IGNITE-21445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-21445: Labels: ise (was: ) > IndexQuery ignores pageSize if setLocal=true is set > --- > > Key: IGNITE-21445 > URL: https://issues.apache.org/jira/browse/IGNITE-21445 > Project: Ignite > Issue Type: Bug >Reporter: Maksim Timonin >Priority: Major > Labels: ise > > In 2.14, see GridCacheQueryManager#runQuery:L1323 > If query is local it just collects all possible data. > For ScanQuery this code doesn't work, as it directly uses local > scanQueryIterator that returns entry one by one. > Solution: > # Prepare page for iterating > # Use the same logic as ScanQuery for local queries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21445) IndexQuery ignores pageSize if setLocal=true is set
[ https://issues.apache.org/jira/browse/IGNITE-21445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-21445: Ignite Flags: (was: Docs Required,Release Notes Required) > IndexQuery ignores pageSize if setLocal=true is set > --- > > Key: IGNITE-21445 > URL: https://issues.apache.org/jira/browse/IGNITE-21445 > Project: Ignite > Issue Type: Bug >Reporter: Maksim Timonin >Priority: Major > > In 2.14, see GridCacheQueryManager#runQuery:L1323 > If query is local it just collects all possible data. > For ScanQuery this code doesn't work, as it directly uses local > scanQueryIterator that returns entry one by one. > Solution: > # Prepare page for iterating > # Use the same logic as ScanQuery for local queries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21445) IndexQuery ignores pageSize if setLocal=true is set
Maksim Timonin created IGNITE-21445: --- Summary: IndexQuery ignores pageSize if setLocal=true is set Key: IGNITE-21445 URL: https://issues.apache.org/jira/browse/IGNITE-21445 Project: Ignite Issue Type: Bug Reporter: Maksim Timonin In 2.14, see GridCacheQueryManager#runQuery:L1323 If query is local it just collects all possible data. For ScanQuery this code doesn't work, as it directly uses local scanQueryIterator that returns entry one by one. Solution: # Prepare page for iterating # Use the same logic as ScanQuery for local queries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21445) IndexQuery ignores pageSize if setLocal=true is set
[ https://issues.apache.org/jira/browse/IGNITE-21445?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin updated IGNITE-21445: Affects Version/s: 2.14 > IndexQuery ignores pageSize if setLocal=true is set > --- > > Key: IGNITE-21445 > URL: https://issues.apache.org/jira/browse/IGNITE-21445 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.14 >Reporter: Maksim Timonin >Priority: Major > Labels: ise > > In 2.14, see GridCacheQueryManager#runQuery:L1323 > If query is local it just collects all possible data. > For ScanQuery this code doesn't work, as it directly uses local > scanQueryIterator that returns entry one by one. > Solution: > # Prepare page for iterating > # Use the same logic as ScanQuery for local queries. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21446) Import JVM args from build.gradle for JUnit run configurations
Ivan Bessonov created IGNITE-21446: -- Summary: Import JVM args from build.gradle for JUnit run configurations Key: IGNITE-21446 URL: https://issues.apache.org/jira/browse/IGNITE-21446 Project: Ignite Issue Type: Improvement Reporter: Ivan Bessonov Assignee: Ivan Bessonov Fix For: 3.0.0-beta2 This should help running tests locally with IDEA runner on Java 17 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21446) Import JVM args from build.gradle for JUnit run configurations
[ https://issues.apache.org/jira/browse/IGNITE-21446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-21446: --- Reviewer: Kirill Tkalenko > Import JVM args from build.gradle for JUnit run configurations > -- > > Key: IGNITE-21446 > URL: https://issues.apache.org/jira/browse/IGNITE-21446 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > This should help running tests locally with IDEA runner on Java 17 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21448) Compilation is broken in main
Kirill Sizov created IGNITE-21448:
--
Summary: Compilation is broken in main
Key: IGNITE-21448
URL: https://issues.apache.org/jira/browse/IGNITE-21448
Project: Ignite
Issue Type: Task
Reporter: Kirill Sizov
Compilation is broken after merging IGNITE-21290 right before IGNITE-21371
{noformat}
modules/table/src/test/java/org/apache/ignite/internal/table/distributed/replication/PartitionReplicaListenerTest.java:1894:
error: cannot find symbol
.coordinatorId(localNode.id())
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21447) Compilation is broken in main
Kirill Sizov created IGNITE-21447:
--
Summary: Compilation is broken in main
Key: IGNITE-21447
URL: https://issues.apache.org/jira/browse/IGNITE-21447
Project: Ignite
Issue Type: Task
Reporter: Kirill Sizov
Compilation is broken after merging IGNITE-21290 right before IGNITE-21371
{noformat}
modules/table/src/test/java/org/apache/ignite/internal/table/distributed/replication/PartitionReplicaListenerTest.java:1894:
error: cannot find symbol
.coordinatorId(localNode.id())
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21448) Compilation is broken in main
[
https://issues.apache.org/jira/browse/IGNITE-21448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Sizov reassigned IGNITE-21448:
--
Assignee: Kirill Sizov
> Compilation is broken in main
> -
>
> Key: IGNITE-21448
> URL: https://issues.apache.org/jira/browse/IGNITE-21448
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Sizov
>Assignee: Kirill Sizov
>Priority: Major
> Labels: ignite-3
>
> Compilation is broken after merging IGNITE-21290 right before IGNITE-21371
> {noformat}
> modules/table/src/test/java/org/apache/ignite/internal/table/distributed/replication/PartitionReplicaListenerTest.java:1894:
> error: cannot find symbol
> .coordinatorId(localNode.id())
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21448) Compilation is broken in main
[
https://issues.apache.org/jira/browse/IGNITE-21448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-21448:
Ignite Flags: (was: Docs Required,Release Notes Required)
> Compilation is broken in main
> -
>
> Key: IGNITE-21448
> URL: https://issues.apache.org/jira/browse/IGNITE-21448
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Sizov
>Assignee: Kirill Sizov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Compilation is broken after merging IGNITE-21290 right before IGNITE-21371
> {noformat}
> modules/table/src/test/java/org/apache/ignite/internal/table/distributed/replication/PartitionReplicaListenerTest.java:1894:
> error: cannot find symbol
> .coordinatorId(localNode.id())
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21448) Compilation is broken in main
[
https://issues.apache.org/jira/browse/IGNITE-21448?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Tupitsyn updated IGNITE-21448:
Fix Version/s: 3.0.0-beta2
> Compilation is broken in main
> -
>
> Key: IGNITE-21448
> URL: https://issues.apache.org/jira/browse/IGNITE-21448
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Sizov
>Assignee: Kirill Sizov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Compilation is broken after merging IGNITE-21290 right before IGNITE-21371
> {noformat}
> modules/table/src/test/java/org/apache/ignite/internal/table/distributed/replication/PartitionReplicaListenerTest.java:1894:
> error: cannot find symbol
> .coordinatorId(localNode.id())
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21448) Compilation is broken in main
[
https://issues.apache.org/jira/browse/IGNITE-21448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17814307#comment-17814307
]
Pavel Tupitsyn commented on IGNITE-21448:
-
Merged to main: b23f54f5d54b649ea3053d2f080174dbc5984c04
> Compilation is broken in main
> -
>
> Key: IGNITE-21448
> URL: https://issues.apache.org/jira/browse/IGNITE-21448
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Sizov
>Assignee: Kirill Sizov
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Compilation is broken after merging IGNITE-21290 right before IGNITE-21371
> {noformat}
> modules/table/src/test/java/org/apache/ignite/internal/table/distributed/replication/PartitionReplicaListenerTest.java:1894:
> error: cannot find symbol
> .coordinatorId(localNode.id())
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21435) Sql. Catalog DefaultValue should not depend on Serializable
[
https://issues.apache.org/jira/browse/IGNITE-21435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-21435:
--
Component/s: sql
> Sql. Catalog DefaultValue should not depend on Serializable
> ---
>
> Key: IGNITE-21435
> URL: https://issues.apache.org/jira/browse/IGNITE-21435
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Pavel Pereslegin
>Priority: Major
> Labels: ignite-3
>
> Currently {{ConstantValue}} (inside
> {{org.apache.ignite.internal.catalog.commands.DefaultValue}}) may hold any
> {{Serializable}} object.
> This should be revised to allow custom serialization.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20861) Invoke EntryProcessors on intersected key ranges from different client nodes raises ClassCastException .
[
https://issues.apache.org/jira/browse/IGNITE-20861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17814308#comment-17814308
]
Ignite TC Bot commented on IGNITE-20861:
{panel:title=Branch: [pull/11041/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11041/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7731203&buildTypeId=IgniteTests24Java8_RunAll]
> Invoke EntryProcessors on intersected key ranges from different client nodes
> raises ClassCastException .
>
>
> Key: IGNITE-20861
> URL: https://issues.apache.org/jira/browse/IGNITE-20861
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.15
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Invoke EntryProcessor`s from different client nodes can lead to
> ClassCastException:
>
> {noformat}
> Caused by: java.lang.ClassCastException: class
> org.apache.ignite.tests.p2p.CacheDeploymentTestValue cannot be cast to class
> org.apache.ignite.tests.p2p.CacheDeploymentTestValue
> (org.apache.ignite.tests.p2p.CacheDeploymentTestValue is in unnamed module of
> loader
> org.apache.ignite.internal.managers.deployment.GridDeploymentClassLoader
> @23639a37; org.apache.ignite.tests.p2p.CacheDeploymentTestValue is in unnamed
> module of loader
> org.apache.ignite.internal.managers.deployment.GridDeploymentClassLoader
> @5a2dd3cc)
> at
> org.apache.ignite.tests.p2p.CacheDeploymentEntryProcessorMultipleEnts.process(CacheDeploymentEntryProcessorMultipleEnts.java:38)
> at
> org.apache.ignite.tests.p2p.CacheDeploymentEntryProcessorMultipleEnts.process(CacheDeploymentEntryProcessorMultipleEnts.java:26)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.runEntryProcessor(GridCacheMapEntry.java:6334)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:5650)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:5437)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:4320){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-19082) Describe Catalog operation flow in README and cleanup dead code.
[ https://issues.apache.org/jira/browse/IGNITE-19082?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-19082: --- Description: Let's * ensure Catalog is used by default as a single schema management point by TableManager, IndexManager, SqlSchemaManager, SchemaRegistry. * Describe CatalogService operations in README.md * drop schema related code from configuration. * drop outdated code from TableManager, IndexManager, SqlSchemaManager, SchemaRegistry. * make a PR for merging feature branch to main (if applicable). * ensure there are end-to-end tests for the cases (if applicable) described in CatalogServiceSelfTest. Also drop InternalSchemaTest. * Let’s remove using/keeping schema name instaed of schema id (NewIndexEntry class as example) was: Let's * ensure Catalog is used by default as a single schema management point by TableManager, IndexManager, SqlSchemaManager, SchemaRegistry. * Describe CatalogService operations in README.md * drop schema related code from configuration. * drop outdated code from TableManager, IndexManager, SqlSchemaManager, SchemaRegistry. * make a PR for merging feature branch to main (if applicable). * ensure there are end-to-end tests for the cases (if applicable) described in CatalogServiceSelfTest. Also drop InternalSchemaTest. > Describe Catalog operation flow in README and cleanup dead code. > > > Key: IGNITE-19082 > URL: https://issues.apache.org/jira/browse/IGNITE-19082 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Let's > * ensure Catalog is used by default as a single schema management point by > TableManager, IndexManager, SqlSchemaManager, SchemaRegistry. > * Describe CatalogService operations in README.md > * drop schema related code from configuration. > * drop outdated code from TableManager, IndexManager, SqlSchemaManager, > SchemaRegistry. > * make a PR for merging feature branch to main (if applicable). > * ensure there are end-to-end tests for the cases (if applicable) described > in CatalogServiceSelfTest. Also drop InternalSchemaTest. > * Let’s remove using/keeping schema name instaed of schema id (NewIndexEntry > class as example) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20861) Invoke EntryProcessors on intersected key ranges from different client nodes raises ClassCastException .
[
https://issues.apache.org/jira/browse/IGNITE-20861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17814309#comment-17814309
]
Evgeny Stanilovsky commented on IGNITE-20861:
-
[~vpyatkov][~v.pyatkov] can u make a review ?
> Invoke EntryProcessors on intersected key ranges from different client nodes
> raises ClassCastException .
>
>
> Key: IGNITE-20861
> URL: https://issues.apache.org/jira/browse/IGNITE-20861
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.15
>Reporter: Evgeny Stanilovsky
>Assignee: Evgeny Stanilovsky
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Invoke EntryProcessor`s from different client nodes can lead to
> ClassCastException:
>
> {noformat}
> Caused by: java.lang.ClassCastException: class
> org.apache.ignite.tests.p2p.CacheDeploymentTestValue cannot be cast to class
> org.apache.ignite.tests.p2p.CacheDeploymentTestValue
> (org.apache.ignite.tests.p2p.CacheDeploymentTestValue is in unnamed module of
> loader
> org.apache.ignite.internal.managers.deployment.GridDeploymentClassLoader
> @23639a37; org.apache.ignite.tests.p2p.CacheDeploymentTestValue is in unnamed
> module of loader
> org.apache.ignite.internal.managers.deployment.GridDeploymentClassLoader
> @5a2dd3cc)
> at
> org.apache.ignite.tests.p2p.CacheDeploymentEntryProcessorMultipleEnts.process(CacheDeploymentEntryProcessorMultipleEnts.java:38)
> at
> org.apache.ignite.tests.p2p.CacheDeploymentEntryProcessorMultipleEnts.process(CacheDeploymentEntryProcessorMultipleEnts.java:26)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.runEntryProcessor(GridCacheMapEntry.java:6334)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:5650)
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry$AtomicCacheUpdateClosure.call(GridCacheMapEntry.java:5437)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree$Invoke.invokeClosure(BPlusTree.java:4320){noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (IGNITE-21384) Initialize all rows with new column's default value
[ https://issues.apache.org/jira/browse/IGNITE-21384 ]
Maksim Myskov deleted comment on IGNITE-21384:
was (Author: myskov):
Reopened due to changed circumstances. According to [~slukyanov] , the
performance penalty is not a no-go factor for now. It can be optimized in the
future.
> Initialize all rows with new column's default value
> ---
>
> Key: IGNITE-21384
> URL: https://issues.apache.org/jira/browse/IGNITE-21384
> Project: Ignite
> Issue Type: New Feature
>Reporter: Maksim Myskov
>Priority: Major
> Labels: ignite-3
>
> In case of adding a new column with a default value specified (for example:
> ALTER TABLE ADD COLUMN col INT DEFAULT 10), all existing rows (that were
> added before "alter table") must be initialized with a new value.
> h3. Current behaviour
> The default value of a column is evaluated on read.
> h3. Motivation
> This is a pre-requisite for adding arbitrary expressions as default values.
> Let's imagine a simple case:
> {code:sql}
> ALTER TABLE ADD COLUMN modified TIMESTAMP DEFAULT CURRENT_TIMESTAMP
> {code}
> With the current behavior for all existing rows the value of "modified"
> column will be evaluated on every read.
> Many DBs use the proposed behavior:
> * PostgreSQL
> * CockroachDB
> * Yugabyte
> For example, from PostgreSQL
> [docs|https://www.postgresql.org/docs/current/sql-altertable.html#SQL-ALTERTABLE-NOTES]:
> {noformat}
> Adding a column with a volatile DEFAULT or changing the type of an existing
> column will require the entire table and its indexes to be rewritten.
> {noformat}
> h3. Downsides
> Adding a new column with a default value will be a much more expensive
> operation and can take a significant time on large tables
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] (IGNITE-21384) Initialize all rows with new column's default value
[ https://issues.apache.org/jira/browse/IGNITE-21384 ]
Maksim Myskov deleted comment on IGNITE-21384:
was (Author: myskov):
After a discussion with the team, I'm closing this as non-relevant. There are
ways to achieve this behavior with much less performance penalty.
> Initialize all rows with new column's default value
> ---
>
> Key: IGNITE-21384
> URL: https://issues.apache.org/jira/browse/IGNITE-21384
> Project: Ignite
> Issue Type: New Feature
>Reporter: Maksim Myskov
>Priority: Major
> Labels: ignite-3
>
> In case of adding a new column with a default value specified (for example:
> ALTER TABLE ADD COLUMN col INT DEFAULT 10), all existing rows (that were
> added before "alter table") must be initialized with a new value.
> h3. Current behaviour
> The default value of a column is evaluated on read.
> h3. Motivation
> This is a pre-requisite for adding arbitrary expressions as default values.
> Let's imagine a simple case:
> {code:sql}
> ALTER TABLE ADD COLUMN modified TIMESTAMP DEFAULT CURRENT_TIMESTAMP
> {code}
> With the current behavior for all existing rows the value of "modified"
> column will be evaluated on every read.
> Many DBs use the proposed behavior:
> * PostgreSQL
> * CockroachDB
> * Yugabyte
> For example, from PostgreSQL
> [docs|https://www.postgresql.org/docs/current/sql-altertable.html#SQL-ALTERTABLE-NOTES]:
> {noformat}
> Adding a column with a volatile DEFAULT or changing the type of an existing
> column will require the entire table and its indexes to be rewritten.
> {noformat}
> h3. Downsides
> Adding a new column with a default value will be a much more expensive
> operation and can take a significant time on large tables
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21446) Import JVM args from build.gradle for JUnit run configurations
[ https://issues.apache.org/jira/browse/IGNITE-21446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-21446: --- Ignite Flags: (was: Docs Required,Release Notes Required) > Import JVM args from build.gradle for JUnit run configurations > -- > > Key: IGNITE-21446 > URL: https://issues.apache.org/jira/browse/IGNITE-21446 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > This should help running tests locally with IDEA runner on Java 17 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21401) DataStreamer data removal: improve RW_UPSERT_ALL to support delete
[ https://issues.apache.org/jira/browse/IGNITE-21401?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17814317#comment-17814317 ] Pavel Tupitsyn commented on IGNITE-21401: - Merged to main: bccdb5e4abd6204b9cb52740d0c2e61c546dab2d > DataStreamer data removal: improve RW_UPSERT_ALL to support delete > -- > > Key: IGNITE-21401 > URL: https://issues.apache.org/jira/browse/IGNITE-21401 > Project: Ignite > Issue Type: Improvement > Components: thin client >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: 40m > Remaining Estimate: 0h > > *RW_UPSERT_ALL* implementation in *PartitionReplicaListener* supports inserts > and updates, but not deletes. We can indicate deletes with empty rows (only > key, no value). -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18175) SQL: value out of type bounds is converted into 0 during implicit casting
[
https://issues.apache.org/jira/browse/IGNITE-18175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17814323#comment-17814323
]
Andrey Khitrin commented on IGNITE-18175:
-
In the recent AI3:
{code:sql}
sql-cli> insert into test_e011_SMALLINT (key_field, field1_SMALLINT) values
(1, (select field1 from test_e011_INTEGER_from where key_field=1));
SQL query execution error
SMALLINT out of range
{code}
Consider it as fixed.
> SQL: value out of type bounds is converted into 0 during implicit casting
> -
>
> Key: IGNITE-18175
> URL: https://issues.apache.org/jira/browse/IGNITE-18175
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: calcite2-required, calcite3-required, ignite-3
>
> A simple scenario:
> {code:sql}
> create table test_e011_INTEGER_from (key_field INT PRIMARY KEY, field1
> INTEGER);
> insert into test_e011_INTEGER_from (key_field, field1) values (1,
> -2147483648);
> create table test_e011_SMALLINT (key_field INT PRIMARY KEY, field1_SMALLINT
> SMALLINT);
> insert into test_e011_SMALLINT (key_field, field1_SMALLINT) values (1,
> (select field1 from test_e011_INTEGER_from where key_field=1));
> select * from test_e011_SMALLINT;
> {code}
> I expect it either to return '1, null' (like in postrgres or sqlite3) or to
> raise an error on insert (like in GG8) as value of -2147483648 is out of
> bounds for SMALLINT data type.
> Instead, '1, 0' is stored within test_e011_SMALLINT table and returned from
> select. In other words, -2147483648 was converted into 0. Such behavior seems
> as incorrect.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-18175) SQL: value out of type bounds is converted into 0 during implicit casting
[
https://issues.apache.org/jira/browse/IGNITE-18175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Khitrin resolved IGNITE-18175.
-
Resolution: Fixed
> SQL: value out of type bounds is converted into 0 during implicit casting
> -
>
> Key: IGNITE-18175
> URL: https://issues.apache.org/jira/browse/IGNITE-18175
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: calcite2-required, calcite3-required, ignite-3
>
> A simple scenario:
> {code:sql}
> create table test_e011_INTEGER_from (key_field INT PRIMARY KEY, field1
> INTEGER);
> insert into test_e011_INTEGER_from (key_field, field1) values (1,
> -2147483648);
> create table test_e011_SMALLINT (key_field INT PRIMARY KEY, field1_SMALLINT
> SMALLINT);
> insert into test_e011_SMALLINT (key_field, field1_SMALLINT) values (1,
> (select field1 from test_e011_INTEGER_from where key_field=1));
> select * from test_e011_SMALLINT;
> {code}
> I expect it either to return '1, null' (like in postrgres or sqlite3) or to
> raise an error on insert (like in GG8) as value of -2147483648 is out of
> bounds for SMALLINT data type.
> Instead, '1, 0' is stored within test_e011_SMALLINT table and returned from
> select. In other words, -2147483648 was converted into 0. Such behavior seems
> as incorrect.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21335) C++ 3.0: Implement JobExecutionOptions
[ https://issues.apache.org/jira/browse/IGNITE-21335?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego reassigned IGNITE-21335: Assignee: Igor Sapego > C++ 3.0: Implement JobExecutionOptions > -- > > Key: IGNITE-21335 > URL: https://issues.apache.org/jira/browse/IGNITE-21335 > Project: Ignite > Issue Type: Task > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Dmitry Baranov >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Java part of this changes https://github.com/apache/ignite-3/pull/3050 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21449) Cache dump performance improvement
Yuri Naryshkin created IGNITE-21449: --- Summary: Cache dump performance improvement Key: IGNITE-21449 URL: https://issues.apache.org/jira/browse/IGNITE-21449 Project: Ignite Issue Type: Task Reporter: Yuri Naryshkin Assignee: Yuri Naryshkin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21117) Wait for completion of transactions started before an index drop
[ https://issues.apache.org/jira/browse/IGNITE-21117?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Pligin reassigned IGNITE-21117: Assignee: Aleksandr Polovtcev > Wait for completion of transactions started before an index drop > > > Key: IGNITE-21117 > URL: https://issues.apache.org/jira/browse/IGNITE-21117 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > When an index switches to the STOPPING state, a waiter (IGNITE-21112) should > be started (analogously to the waiter used when waiting in the REGISTERED > state, see IGNITE-21115). > After it finishes waiting, the index should be switched to the READ_ONLY > state. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21446) Import JVM args from build.gradle for JUnit run configurations
[ https://issues.apache.org/jira/browse/IGNITE-21446?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17814332#comment-17814332 ] Kirill Tkalenko commented on IGNITE-21446: -- Looks good. > Import JVM args from build.gradle for JUnit run configurations > -- > > Key: IGNITE-21446 > URL: https://issues.apache.org/jira/browse/IGNITE-21446 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > This should help running tests locally with IDEA runner on Java 17 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21450) Ignite 3 dynamic index optimisations
Vladimir Pligin created IGNITE-21450: Summary: Ignite 3 dynamic index optimisations Key: IGNITE-21450 URL: https://issues.apache.org/jira/browse/IGNITE-21450 Project: Ignite Issue Type: Epic Reporter: Vladimir Pligin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20923) Possible optimization for sending row IDs during index building
[ https://issues.apache.org/jira/browse/IGNITE-20923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Pligin updated IGNITE-20923: - Epic Link: IGNITE-21450 (was: IGNITE-20782) > Possible optimization for sending row IDs during index building > --- > > Key: IGNITE-20923 > URL: https://issues.apache.org/jira/browse/IGNITE-20923 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > > Now, when building an index, we send all row IDs from the row store, starting > from the smallest to the end of the store, and we want to build indexes for > all of them. > I think that we do not need to send all row IDs, but only those in which the > version chains have versions less than or equal to the time the index was > created. Newer ones will be sent in the normal operation of the cluster in > the replication protocol or full rebalancing. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-19717) Get rid of creating indexes at the start of a MvTableStorage
[ https://issues.apache.org/jira/browse/IGNITE-19717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Pligin updated IGNITE-19717: - Epic Link: IGNITE-21450 (was: IGNITE-20782) > Get rid of creating indexes at the start of a MvTableStorage > > > Key: IGNITE-19717 > URL: https://issues.apache.org/jira/browse/IGNITE-19717 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Now, at the start of the *MvTableStorage*, we create indexes, which is not > correct, this should be done by external code that should know about all > indexes. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21368) MVCC code removal from transactional classes
[
https://issues.apache.org/jira/browse/IGNITE-21368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17814337#comment-17814337
]
Ignite TC Bot commented on IGNITE-21368:
{panel:title=Branch: [pull/11203/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11203/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *--> Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7728939&buildTypeId=IgniteTests24Java8_RunAll]
> MVCC code removal from transactional classes
>
>
> Key: IGNITE-21368
> URL: https://issues.apache.org/jira/browse/IGNITE-21368
> Project: Ignite
> Issue Type: Sub-task
> Components: mvcc
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise
> Time Spent: 10m
> Remaining Estimate: 0h
>
> MVCC code have to be removed from {{IgniteInternalTx}} and successors.
> Affected classes are {{GridNearTxLocal}}, {{IgniteTxAdapter}},
> {{IgniteTxLocalAdapter}}, etc. and corresponding code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21368) MVCC code removal from transactional classes
[
https://issues.apache.org/jira/browse/IGNITE-21368?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17814341#comment-17814341
]
Ilya Shishkov commented on IGNITE-21368:
[~av], can you take a look, please?
> MVCC code removal from transactional classes
>
>
> Key: IGNITE-21368
> URL: https://issues.apache.org/jira/browse/IGNITE-21368
> Project: Ignite
> Issue Type: Sub-task
> Components: mvcc
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise
> Time Spent: 20m
> Remaining Estimate: 0h
>
> MVCC code have to be removed from {{IgniteInternalTx}} and successors.
> Affected classes are {{GridNearTxLocal}}, {{IgniteTxAdapter}},
> {{IgniteTxLocalAdapter}}, etc. and corresponding code.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21451) RocksDB: repeat of create table and drop column leads to freeze of client
Igor created IGNITE-21451:
-
Summary: RocksDB: repeat of create table and drop column leads to
freeze of client
Key: IGNITE-21451
URL: https://issues.apache.org/jira/browse/IGNITE-21451
Project: Ignite
Issue Type: Bug
Components: persistence
Affects Versions: 3.0.0-beta1
Environment: 2 nodes cluster running locally.
Reporter: Igor
h3. Steps to reproduce:
Run the next queries in cycle with 50 repeats in single connection:
{code:java}
drop table if exists dropNoMoreIndexedColumn
create zone if not exists "rocksdb" engine rocksdb
create table dropNoMoreIndexedColumn(k1 TIMESTAMP not null, k2 INTEGER not
null, v0 TINYINT not null, v1 SMALLINT not null, v2 INTEGER not null, v3 BIGINT
not null, v4 VARCHAR not null, v5 TIMESTAMP not null, primary key (k1, k2))
with PRIMARY_ZONE='rocksdb'
create index dropNoMoreIndexedColumn_v1idx on dropNoMoreIndexedColumn using
TREE (v1)
drop index dropNoMoreIndexedColumn_v1idx
alter table dropNoMoreIndexedColumn drop column v1 {code}
h3. Expected:
All queries are executed.
h3. Actual:
On repeat 31 the client freeze for infinite amount of time.
h3. Analysis:
The servers contain repeated error in logs:
{code:java}
2024-02-05 13:47:24:812 +0100
[ERROR][%DropColumnsTest_cluster_0%JRaft-FSMCaller-Disruptor-metastorage-_stripe_0-0][WatchProcessor]
Error occurred when notifying safe time advanced callback
java.util.concurrent.CompletionException:
java.lang.UnsupportedOperationException: Update log is not supported in RocksDB
storage.
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
at
java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
at
java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:645)
at
java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
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)
Caused by: java.lang.UnsupportedOperationException: Update log is not supported
in RocksDB storage.
at
org.apache.ignite.internal.storage.rocksdb.RocksDbMvPartitionStorage.trimUpdateLog(RocksDbMvPartitionStorage.java:908)
at
org.apache.ignite.internal.table.distributed.raft.snapshot.outgoing.SnapshotAwarePartitionDataStorage.trimUpdateLog(SnapshotAwarePartitionDataStorage.java:244)
at
org.apache.ignite.internal.table.distributed.gc.GcUpdateHandler.lambda$vacuumBatch$0(GcUpdateHandler.java:81)
at
org.apache.ignite.internal.storage.rocksdb.RocksDbMvPartitionStorage.lambda$runConsistently$2(RocksDbMvPartitionStorage.java:228)
at
org.apache.ignite.internal.storage.rocksdb.RocksDbMvPartitionStorage.busy(RocksDbMvPartitionStorage.java:1431)
at
org.apache.ignite.internal.storage.rocksdb.RocksDbMvPartitionStorage.runConsistently(RocksDbMvPartitionStorage.java:213)
at
org.apache.ignite.internal.table.distributed.raft.snapshot.outgoing.SnapshotAwarePartitionDataStorage.runConsistently(SnapshotAwarePartitionDataStorage.java:80)
at
org.apache.ignite.internal.table.distributed.gc.GcUpdateHandler.vacuumBatch(GcUpdateHandler.java:80)
at
org.apache.ignite.internal.table.distributed.gc.MvGc.lambda$scheduleGcForStorage$7(MvGc.java:242)
at
java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:642)
... 4 more {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21452) improve error handling in SQL module
[ https://issues.apache.org/jira/browse/IGNITE-21452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-21452: --- Description: As of now in case any uexpected error during SQL execution in SQL execution thread pool we can't simple to know the reason due to org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl log such error just on debug level and UncaughtExceptionHandler is not set. Let's fix both of the issues and check similar problem for another thread pools. was: As of now in case any uexpected error during SQL execution in SQL execution thread pool we can't simple to know the reason due to org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl log such error just on debug level and UncaughtExceptionHandler is not set. Let's fix both of the issue and check similar problem for another thread pools. > improve error handling in SQL module > > > Key: IGNITE-21452 > URL: https://issues.apache.org/jira/browse/IGNITE-21452 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > As of now in case any uexpected error during SQL execution in SQL execution > thread pool we can't simple to know the reason due to > org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl log such > error just on debug level and UncaughtExceptionHandler is not set. > Let's fix both of the issues and check similar problem for another thread > pools. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21452) improve error handling in SQL module
Yury Gerzhedovich created IGNITE-21452: -- Summary: improve error handling in SQL module Key: IGNITE-21452 URL: https://issues.apache.org/jira/browse/IGNITE-21452 Project: Ignite Issue Type: Improvement Components: sql Reporter: Yury Gerzhedovich As of now in case any uexpected error during SQL execution in SQL execution thread pool we can't simple to know the reason due to org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl log such error just on debug level and UncaughtExceptionHandler is not set. Let's fix both of the issue and check similar problem for another thread pools. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21449) Cache dump performance improvement
[ https://issues.apache.org/jira/browse/IGNITE-21449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yuri Naryshkin updated IGNITE-21449: Labels: ise (was: ) > Cache dump performance improvement > -- > > Key: IGNITE-21449 > URL: https://issues.apache.org/jira/browse/IGNITE-21449 > Project: Ignite > Issue Type: Task >Reporter: Yuri Naryshkin >Assignee: Yuri Naryshkin >Priority: Major > Labels: ise > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21451) RocksDB: repeat of create table and drop column leads to freeze of client
[
https://issues.apache.org/jira/browse/IGNITE-21451?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor updated IGNITE-21451:
--
Description:
h3. Steps to reproduce:
Run the next queries in cycle with 50 repeats in single connection:
{code:java}
drop table if exists dropNoMoreIndexedColumn
create zone if not exists "rocksdb" engine rocksdb
create table dropNoMoreIndexedColumn(k1 TIMESTAMP not null, k2 INTEGER not
null, v0 TINYINT not null, v1 SMALLINT not null, v2 INTEGER not null, v3 BIGINT
not null, v4 VARCHAR not null, v5 TIMESTAMP not null, primary key (k1, k2))
with PRIMARY_ZONE='rocksdb'
create index dropNoMoreIndexedColumn_v1idx on dropNoMoreIndexedColumn using
TREE (v1)
drop index dropNoMoreIndexedColumn_v1idx
alter table dropNoMoreIndexedColumn drop column v1 {code}
h3. Expected:
All queries are executed.
h3. Actual:
On repeat 31 the client freeze for infinite amount of time.
h3. Analysis:
With storages aimem and aipersist the issue is not happen.
The servers contain repeated error in logs:
{code:java}
2024-02-05 13:47:24:812 +0100
[ERROR][%DropColumnsTest_cluster_0%JRaft-FSMCaller-Disruptor-metastorage-_stripe_0-0][WatchProcessor]
Error occurred when notifying safe time advanced callback
java.util.concurrent.CompletionException:
java.lang.UnsupportedOperationException: Update log is not supported in RocksDB
storage.
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
at
java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
at
java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:645)
at
java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
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)
Caused by: java.lang.UnsupportedOperationException: Update log is not supported
in RocksDB storage.
at
org.apache.ignite.internal.storage.rocksdb.RocksDbMvPartitionStorage.trimUpdateLog(RocksDbMvPartitionStorage.java:908)
at
org.apache.ignite.internal.table.distributed.raft.snapshot.outgoing.SnapshotAwarePartitionDataStorage.trimUpdateLog(SnapshotAwarePartitionDataStorage.java:244)
at
org.apache.ignite.internal.table.distributed.gc.GcUpdateHandler.lambda$vacuumBatch$0(GcUpdateHandler.java:81)
at
org.apache.ignite.internal.storage.rocksdb.RocksDbMvPartitionStorage.lambda$runConsistently$2(RocksDbMvPartitionStorage.java:228)
at
org.apache.ignite.internal.storage.rocksdb.RocksDbMvPartitionStorage.busy(RocksDbMvPartitionStorage.java:1431)
at
org.apache.ignite.internal.storage.rocksdb.RocksDbMvPartitionStorage.runConsistently(RocksDbMvPartitionStorage.java:213)
at
org.apache.ignite.internal.table.distributed.raft.snapshot.outgoing.SnapshotAwarePartitionDataStorage.runConsistently(SnapshotAwarePartitionDataStorage.java:80)
at
org.apache.ignite.internal.table.distributed.gc.GcUpdateHandler.vacuumBatch(GcUpdateHandler.java:80)
at
org.apache.ignite.internal.table.distributed.gc.MvGc.lambda$scheduleGcForStorage$7(MvGc.java:242)
at
java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:642)
... 4 more {code}
was:
h3. Steps to reproduce:
Run the next queries in cycle with 50 repeats in single connection:
{code:java}
drop table if exists dropNoMoreIndexedColumn
create zone if not exists "rocksdb" engine rocksdb
create table dropNoMoreIndexedColumn(k1 TIMESTAMP not null, k2 INTEGER not
null, v0 TINYINT not null, v1 SMALLINT not null, v2 INTEGER not null, v3 BIGINT
not null, v4 VARCHAR not null, v5 TIMESTAMP not null, primary key (k1, k2))
with PRIMARY_ZONE='rocksdb'
create index dropNoMoreIndexedColumn_v1idx on dropNoMoreIndexedColumn using
TREE (v1)
drop index dropNoMoreIndexedColumn_v1idx
alter table dropNoMoreIndexedColumn drop column v1 {code}
h3. Expected:
All queries are executed.
h3. Actual:
On repeat 31 the client freeze for infinite amount of time.
h3. Analysis:
The servers contain repeated error in logs:
{code:java}
2024-02-05 13:47:24:812 +0100
[ERROR][%DropColumnsTest_cluster_0%JRaft-FSMCaller-Disruptor-metastorage-_stripe_0-0][WatchProcessor]
Error occurred when notifying safe time advanced callback
java.util.concurrent.CompletionException:
java.lang.UnsupportedOperationException: Update log is not supported in RocksDB
storage.
at
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
at
java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
at
java.base/java.util.concurrent.CompletableFuture$UniApply.tryFire(CompletableFuture.java:645)
at
java.base/java.util.concurrent.CompletableFuture$Completion.run(Completabl
[jira] [Created] (IGNITE-21453) Fix force index hint test
Vadim Pakhnushev created IGNITE-21453: - Summary: Fix force index hint test Key: IGNITE-21453 URL: https://issues.apache.org/jira/browse/IGNITE-21453 Project: Ignite Issue Type: Bug Components: sql Reporter: Vadim Pakhnushev Test in the ForceIndexHintPlannerTest that verify a particular type of relational operator doesn't work after the merge, apparently the planner finds cheaper index scan instead of the table scan. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21453) Fix force index hint test
[ https://issues.apache.org/jira/browse/IGNITE-21453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vadim Pakhnushev updated IGNITE-21453: -- Description: Test in the ForceIndexHintPlannerTest that verify a particular type of relational operator doesn't always work, apparently the planner finds cheaper index scan instead of the table scan. (was: Test in the ForceIndexHintPlannerTest that verify a particular type of relational operator doesn't work after the merge, apparently the planner finds cheaper index scan instead of the table scan.) > Fix force index hint test > - > > Key: IGNITE-21453 > URL: https://issues.apache.org/jira/browse/IGNITE-21453 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Vadim Pakhnushev >Priority: Major > Labels: ignite-3 > > Test in the ForceIndexHintPlannerTest that verify a particular type of > relational operator doesn't always work, apparently the planner finds cheaper > index scan instead of the table scan. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-19150) Implement proper destruction of indexes
[ https://issues.apache.org/jira/browse/IGNITE-19150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov resolved IGNITE-19150. --- Resolution: Duplicate > Implement proper destruction of indexes > --- > > Key: IGNITE-19150 > URL: https://issues.apache.org/jira/browse/IGNITE-19150 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > At the moment, we do not honestly destroy indexes anywhere in the core code, > we simply remove them from the collection of indexes when inserting data. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21252) Partition RAFT client must use pending and stable assignments as a list of peers during rebalance
[ https://issues.apache.org/jira/browse/IGNITE-21252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17814371#comment-17814371 ] Alexander Lapin commented on IGNITE-21252: -- [~maliev] LGTM, Thanks! > Partition RAFT client must use pending and stable assignments as a list of > peers during rebalance > - > > Key: IGNITE-21252 > URL: https://issues.apache.org/jira/browse/IGNITE-21252 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > *Motivation* > According to > [comment|https://issues.apache.org/jira/browse/IGNITE-18991?focusedCommentId=17806657&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-17806657] > during the ongoing rebalance we need to use the sum of pending+stable > assignments as a list of peers for partition raft clients. > This strategy will protect us in the case, when some tables of zone are > already rebalanced and should use new stables, but others are still have > ongoing rebalance. > *Definition of done* > - On the rebalance start all RAFT clients for all table partition from this > zone updates to the clients with pending+stable peers > - When rebalance is done, RAFT clients switched to the stable assignments only -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21442) DefaultMessagingServiceTest.sendMessagesTwoChannels() hangs
[
https://issues.apache.org/jira/browse/IGNITE-21442?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy updated IGNITE-21442:
---
Description:
The test lacks {{release.set(true)}} if an exception is thrown, so a failure of
the test makes everything hang.
Also, the test does not close Netty threads.
> DefaultMessagingServiceTest.sendMessagesTwoChannels() hangs
> ---
>
> Key: IGNITE-21442
> URL: https://issues.apache.org/jira/browse/IGNITE-21442
> Project: Ignite
> Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The test lacks {{release.set(true)}} if an exception is thrown, so a failure
> of the test makes everything hang.
> Also, the test does not close Netty threads.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21413) .NET: Thin 3.0: Add tags to metrics
[ https://issues.apache.org/jira/browse/IGNITE-21413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-21413: Description: Add tags (= labels in Prometheus = attributes/dimensions in OpenTelemetry) to the metrics in .NET client. This will allow the user to monitor entities separately, such as different client instances, streamers, etc. https://learn.microsoft.com/en-us/dotnet/core/diagnostics/metrics-instrumentation#multi-dimensional-metrics Pay attention to performance - large amount of tag combinations can be problematic: https://learn.microsoft.com/en-us/dotnet/core/diagnostics/metrics-instrumentation#best-practices-4 was: Add tags (= labels in Prometheus = attributes/dimensions in OpenTelemetry) to the metrics in .NET client. This will allow the user to monitor entities separately, such as different client instances, streamers, etc. https://learn.microsoft.com/en-us/dotnet/core/diagnostics/metrics-instrumentation#multi-dimensional-metrics > .NET: Thin 3.0: Add tags to metrics > --- > > Key: IGNITE-21413 > URL: https://issues.apache.org/jira/browse/IGNITE-21413 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-beta2 > > > Add tags (= labels in Prometheus = attributes/dimensions in OpenTelemetry) to > the metrics in .NET client. > This will allow the user to monitor entities separately, such as different > client instances, streamers, etc. > https://learn.microsoft.com/en-us/dotnet/core/diagnostics/metrics-instrumentation#multi-dimensional-metrics > Pay attention to performance - large amount of tag combinations can be > problematic: > https://learn.microsoft.com/en-us/dotnet/core/diagnostics/metrics-instrumentation#best-practices-4 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21454) Remove redundant base classes for integration tests
Aleksandr Polovtcev created IGNITE-21454: Summary: Remove redundant base classes for integration tests Key: IGNITE-21454 URL: https://issues.apache.org/jira/browse/IGNITE-21454 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18166) SQL: LIKE predicate is not supported for BINARY data
[
https://issues.apache.org/jira/browse/IGNITE-18166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrey Khitrin updated IGNITE-18166:
Description:
A 'T022' feature in SQL standard allows to use LIKE predicate for BINARY data.
Unfortunately, it is not supported in AI3 beta1:
{code:sql}
create table tmp_table_binary (key_field INT PRIMARY KEY,field1 BINARY);
INSERT INTO tmp_table_binary (key_field, field1) values(1, x'00ffaa');
INSERT INTO tmp_table_binary (key_field, field1) values(2, x'ffcc');
select * from tmp_table_binary where field1 like '%ff%'; --
expected to return both rows
select * from tmp_table_binary where field1 like '_f%'; --
expected to return 'ffcc'
select * from tmp_table_binary where field1 like '_fc_'; --
expected to return 'ffcc'
{code}
Instead of returning data, all queries show the following error:
{code:java}
Error: Exception while executing query [query=select * from tmp_table_binary
where field1 like '%ff%']. Error message:From line 1, column 38 to line 1,
column 55: Cannot apply 'LIKE' to arguments of type 'LIKE(,
)'. Supported form(s): 'LIKE(, , )'
(state=5,code=0)
java.sql.SQLException: Exception while executing query [query=select * from
tmp_table_binary where field1 like '%ff%']. Error message:From line 1, column
38 to line 1, column 55: Cannot apply 'LIKE' to arguments of type
'LIKE(, )'. Supported form(s): 'LIKE(, ,
)'
at
org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
at
org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:148)
at
org.apache.ignite.internal.jdbc.JdbcStatement.execute(JdbcStatement.java:341)
...
{code}
was:
A 'T022' feature in SQL standard allows to use LIKE predicate for BINARY data.
Unfortunately, it is not supported in AI3 beta1:
{code:sql}
create table tmp_table_binary (key_field INT PRIMARY KEY,field1 BINARY);
INSERT INTO tmp_table_binary (key_field, field1) values(1, '00ffaa');
INSERT INTO tmp_table_binary (key_field, field1) values(2, 'ffcc');
select * from tmp_table_binary where field1 like '%ff%'; --
expected to return both rows
select * from tmp_table_binary where field1 like '_f%'; --
expected to return 'ffcc'
select * from tmp_table_binary where field1 like '_fc_'; --
expected to return 'ffcc'
{code}
Instead of returning data, all queries show the following error:
{code:java}
Error: Exception while executing query [query=select * from tmp_table_binary
where field1 like '%ff%']. Error message:From line 1, column 38 to line 1,
column 55: Cannot apply 'LIKE' to arguments of type 'LIKE(,
)'. Supported form(s): 'LIKE(, , )'
(state=5,code=0)
java.sql.SQLException: Exception while executing query [query=select * from
tmp_table_binary where field1 like '%ff%']. Error message:From line 1, column
38 to line 1, column 55: Cannot apply 'LIKE' to arguments of type
'LIKE(, )'. Supported form(s): 'LIKE(, ,
)'
at
org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
at
org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:148)
at
org.apache.ignite.internal.jdbc.JdbcStatement.execute(JdbcStatement.java:341)
...
{code}
> SQL: LIKE predicate is not supported for BINARY data
>
>
> Key: IGNITE-18166
> URL: https://issues.apache.org/jira/browse/IGNITE-18166
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required, ignite-3
>
> A 'T022' feature in SQL standard allows to use LIKE predicate for BINARY
> data. Unfortunately, it is not supported in AI3 beta1:
> {code:sql}
> create table tmp_table_binary (key_field INT PRIMARY KEY,field1 BINARY);
> INSERT INTO tmp_table_binary (key_field, field1) values(1, x'00ffaa');
> INSERT INTO tmp_table_binary (key_field, field1) values(2, x'ffcc');
> select * from tmp_table_binary where field1 like '%ff%'; --
> expected to return both rows
> select * from tmp_table_binary where field1 like '_f%'; --
> expected to return 'ffcc'
> select * from tmp_table_binary where field1 like '_fc_'; --
> expected to return 'ffcc'
> {code}
> Instead of returning data, all queries show the following error:
> {code:java}
> Error: Exception while executing query [query=select * from tmp_table_binary
> where field1 like '%ff%']. Error message:From line 1, column 38 to line 1,
> column 55: Cannot apply 'LIKE' to arguments of type 'LIKE(,
> )'. Supported form(s): 'LIKE(, , )'
> (state=500
[jira] [Created] (IGNITE-21455) ItTableScanTest#testCompositeScanRequest is flaky
Vladislav Pyatkov created IGNITE-21455:
--
Summary: ItTableScanTest#testCompositeScanRequest is flaky
Key: IGNITE-21455
URL: https://issues.apache.org/jira/browse/IGNITE-21455
Project: Ignite
Issue Type: Bug
Reporter: Vladislav Pyatkov
h3. Motivation
There is an exception:
{noformat}
org.opentest4j.AssertionFailedError: expected: <0> but was: <1>
at
app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
at
app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
at app//org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
at app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:528)
at
app//org.apache.ignite.internal.table.ItTableScanTest.checkCursorsAreClosed(ItTableScanTest.java:150)
at
java.base@11.0.17/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
at
java.base@11.0.17/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
at
java.base@11.0.17/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
at
java.base@11.0.17/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
at
java.base@11.0.17/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
at
java.base@11.0.17/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
at
java.base@11.0.17/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
at
java.base@11.0.17/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at
java.base@11.0.17/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
at
app//org.apache.ignite.internal.table.ItTableScanTest.testCompositeScanRequest(ItTableScanTest.java:760)
{noformat}
h3. Implementation notes
The test became flaky after IGNITE-21290. The reason is that the cursors of the
scan operations are closed asynchronously, but the test checks that they are
closed immediately after the Subscription#cancel() method is invoked.
If the test takes several milliseconds, the cursors will be clearly closed.
{code}
waitForCondition(() -> storage.pendingCursors() == 0, 10_000)
{code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21346) Removal of GridCacheMapEntryEx#mvcc* and IgniteCacheOffheapManager#mvcc* methods
[ https://issues.apache.org/jira/browse/IGNITE-21346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov updated IGNITE-21346: --- Description: Remove all MVCC code from (was: Remove o.a.i.internal.processors.cache.mvcc.txlog.TxState (as a continuation of the IGNITE-21130)) > Removal of GridCacheMapEntryEx#mvcc* and IgniteCacheOffheapManager#mvcc* > methods > > > Key: IGNITE-21346 > URL: https://issues.apache.org/jira/browse/IGNITE-21346 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Ilya Shishkov >Assignee: Ilya Shishkov >Priority: Minor > Labels: ise > > Remove all MVCC code from -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21346) Removal of GridCacheMapEntryEx#mvcc* and IgniteCacheOffheapManager#mvcc* methods
[ https://issues.apache.org/jira/browse/IGNITE-21346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov updated IGNITE-21346: --- Description: Remove all MVCC code from GridCacheMapEntryEx and IgniteCacheOffheapManager and their succesors. (was: Remove all MVCC code from ) > Removal of GridCacheMapEntryEx#mvcc* and IgniteCacheOffheapManager#mvcc* > methods > > > Key: IGNITE-21346 > URL: https://issues.apache.org/jira/browse/IGNITE-21346 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Ilya Shishkov >Assignee: Ilya Shishkov >Priority: Minor > Labels: ise > > Remove all MVCC code from GridCacheMapEntryEx and IgniteCacheOffheapManager > and their succesors. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21455) ItTableScanTest#testCompositeScanRequest is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov reassigned IGNITE-21455:
--
Assignee: Vladislav Pyatkov
> ItTableScanTest#testCompositeScanRequest is flaky
> -
>
> Key: IGNITE-21455
> URL: https://issues.apache.org/jira/browse/IGNITE-21455
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Motivation
> There is an exception:
> {noformat}
> org.opentest4j.AssertionFailedError: expected: <0> but was: <1>
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at
> app//org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
> at
> app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
> at
> app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
> at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:528)
> at
> app//org.apache.ignite.internal.table.ItTableScanTest.checkCursorsAreClosed(ItTableScanTest.java:150)
> at
> java.base@11.0.17/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.base@11.0.17/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
> at
> java.base@11.0.17/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at
> java.base@11.0.17/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at
> java.base@11.0.17/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> at
> java.base@11.0.17/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.base@11.0.17/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.base@11.0.17/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base@11.0.17/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
> at
> app//org.apache.ignite.internal.table.ItTableScanTest.testCompositeScanRequest(ItTableScanTest.java:760)
> {noformat}
> h3. Implementation notes
> The test became flaky after IGNITE-21290. The reason is that the cursors of
> the scan operations are closed asynchronously, but the test checks that they
> are closed immediately after the Subscription#cancel() method is invoked.
> If the test takes several milliseconds, the cursors will be clearly closed.
> {code}
> waitForCondition(() -> storage.pendingCursors() == 0, 10_000)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21346) Removal of MVCC code from GridCacheMapEntryEx and IgniteCacheOffheapManager
[ https://issues.apache.org/jira/browse/IGNITE-21346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ilya Shishkov updated IGNITE-21346: --- Summary: Removal of MVCC code from GridCacheMapEntryEx and IgniteCacheOffheapManager (was: Removal of GridCacheMapEntryEx#mvcc* and IgniteCacheOffheapManager#mvcc* methods) > Removal of MVCC code from GridCacheMapEntryEx and IgniteCacheOffheapManager > --- > > Key: IGNITE-21346 > URL: https://issues.apache.org/jira/browse/IGNITE-21346 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Ilya Shishkov >Assignee: Ilya Shishkov >Priority: Minor > Labels: ise > > Remove all MVCC code from GridCacheMapEntryEx and IgniteCacheOffheapManager > and their succesors. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21455) ItTableScanTest#testCompositeScanRequest is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21455?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17814431#comment-17814431
]
Vladislav Pyatkov commented on IGNITE-21455:
Merge 07b16467a6a548f83ba09f686d77bcc845b0681b
> ItTableScanTest#testCompositeScanRequest is flaky
> -
>
> Key: IGNITE-21455
> URL: https://issues.apache.org/jira/browse/IGNITE-21455
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h3. Motivation
> There is an exception:
> {noformat}
> org.opentest4j.AssertionFailedError: expected: <0> but was: <1>
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at
> app//org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
> at
> app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
> at
> app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
> at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:528)
> at
> app//org.apache.ignite.internal.table.ItTableScanTest.checkCursorsAreClosed(ItTableScanTest.java:150)
> at
> java.base@11.0.17/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.base@11.0.17/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
> at
> java.base@11.0.17/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at
> java.base@11.0.17/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at
> java.base@11.0.17/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> at
> java.base@11.0.17/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.base@11.0.17/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.base@11.0.17/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base@11.0.17/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
> at
> app//org.apache.ignite.internal.table.ItTableScanTest.testCompositeScanRequest(ItTableScanTest.java:760)
> {noformat}
> h3. Implementation notes
> The test became flaky after IGNITE-21290. The reason is that the cursors of
> the scan operations are closed asynchronously, but the test checks that they
> are closed immediately after the Subscription#cancel() method is invoked.
> If the test takes several milliseconds, the cursors will be clearly closed.
> {code}
> waitForCondition(() -> storage.pendingCursors() == 0, 10_000)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21429) Prevent stuck-in-the-wires RW transaction operations from executing in a PartitionReplicaListener
[ https://issues.apache.org/jira/browse/IGNITE-21429?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17814453#comment-17814453 ] Roman Puchkovskiy commented on IGNITE-21429: The patch looks good to me > Prevent stuck-in-the-wires RW transaction operations from executing in a > PartitionReplicaListener > - > > Key: IGNITE-21429 > URL: https://issues.apache.org/jira/browse/IGNITE-21429 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 20m > Remaining Estimate: 0h > > It is necessary to prevent read-write transaction operations stuck “in the > wire” that will appear after the start building index in > *org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener*. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21385) Remove dataStorage and dataregion params from the zone and table params
[ https://issues.apache.org/jira/browse/IGNITE-21385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-21385: Description: After migration to storage profiles approach we don't need anymore: - Data storage params in the zone descriptor and ddl - ENGINE param in the zone ddl - DATAREGION in the zone ddl - All connected validators and engine data storage configurations was: After migration to storage profiles approach we don't need anymore: - data storage params in the zone descriptor and ddl - ENGINE param in the zone ddl - DATAREGION in the zone ddl - all connected validators and engine configurations > Remove dataStorage and dataregion params from the zone and table params > --- > > Key: IGNITE-21385 > URL: https://issues.apache.org/jira/browse/IGNITE-21385 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > After migration to storage profiles approach we don't need anymore: > - Data storage params in the zone descriptor and ddl > - ENGINE param in the zone ddl > - DATAREGION in the zone ddl > - All connected validators and engine data storage configurations -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21385) Remove dataStorage and dataregion params from the zone and table params
[ https://issues.apache.org/jira/browse/IGNITE-21385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-21385: Description: After migration to storage profiles approach we don't need anymore: - data storage params in the zone descriptor and ddl - ENGINE param in the zone ddl - DATAREGION in the zone ddl - all connected validators and engine configurations was: After migration to storage profiles approach we don't need anymore: - data storage params in the zone descriptor and ddl - ENGINE param in the zone ddl - DATAREGION in the table ddl - all connected validators and engine configurations > Remove dataStorage and dataregion params from the zone and table params > --- > > Key: IGNITE-21385 > URL: https://issues.apache.org/jira/browse/IGNITE-21385 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > After migration to storage profiles approach we don't need anymore: > - data storage params in the zone descriptor and ddl > - ENGINE param in the zone ddl > - DATAREGION in the zone ddl > - all connected validators and engine configurations -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21456) Use StopNodeFailureHandler instead of NoOpFailureHandler by default
Vyacheslav Koptilin created IGNITE-21456: Summary: Use StopNodeFailureHandler instead of NoOpFailureHandler by default Key: IGNITE-21456 URL: https://issues.apache.org/jira/browse/IGNITE-21456 Project: Ignite Issue Type: Improvement Reporter: Vyacheslav Koptilin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18879) Leaseholder candidates balancing
[
https://issues.apache.org/jira/browse/IGNITE-18879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17814618#comment-17814618
]
yexiaowei commented on IGNITE-18879:
Can your PD refer to TIDB's approach, where nodes send heartbeats to PD
leaders, collect enough information for routing or scheduling based on load
machine performance, such as assignments adjustment and primary transfer.
> Leaseholder candidates balancing
>
>
> Key: IGNITE-18879
> URL: https://issues.apache.org/jira/browse/IGNITE-18879
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> Primary replicas (leaseholders) should be evenly distributed over cluster to
> balance the transactional load between nodes. As the placement driver assigns
> primary replicas, balancing the primary replicas is also it's responsibility.
> Naive implementation of balancing should choose a node as leaseholder
> candidate in a way to save even lease distribution over all nodes. In real
> cluster, it may take into account slow nodes, hot table records, etc. If
> lease candidate declines LeaseGrantMessage from placement driver, the
> balancer should make decision to choose another candidate for given primary
> replica or enforce the previously chosen. So the balancing algorith should be
> pluggable, so that we could have ability to improve/replace/compare it with
> others.
> *Definition of done*
> Introduced interface for lease candidates balancer, and a simple
> implementation sustaining even lease distribution, which is used by placement
> driver by default. No public or internal configuration needed on this stage.
> *Implementation notes*
> Lease candidates balancer should have at least 2 methods:
> - {_}get(group, ignoredNodes){_}: returns candidate for the given group, a
> node from ignoredNodes set can't be chosen as a candidate
> - {_}considerRedirectProposal(group, candidate, proposedCandidate){_}:
> processes redirect proposal for given group provided by given candidate
> (previously chosen using _get_ method), proposedCandidate is the alternative
> candidate. Returns candidate that should be enforced by placement driver.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20241) C++ 3.0: Reload schema when unmapped Tuple field is detected
[ https://issues.apache.org/jira/browse/IGNITE-20241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17814620#comment-17814620 ] Pavel Tupitsyn commented on IGNITE-20241: - [~isapego] looks good to me. > C++ 3.0: Reload schema when unmapped Tuple field is detected > > > Key: IGNITE-20241 > URL: https://issues.apache.org/jira/browse/IGNITE-20241 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Affects Versions: 3.0.0-beta1 >Reporter: Pavel Tupitsyn >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > See parent epic. Unmapped columns are not allowed; however, we must ensure > that the validation is performed against the latest schema, not the cached > one. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21455) ItTableScanTest#testCompositeScanRequest is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-21455:
-
Epic Link: IGNITE-21389
> ItTableScanTest#testCompositeScanRequest is flaky
> -
>
> Key: IGNITE-21455
> URL: https://issues.apache.org/jira/browse/IGNITE-21455
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h3. Motivation
> There is an exception:
> {noformat}
> org.opentest4j.AssertionFailedError: expected: <0> but was: <1>
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at
> app//org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
> at
> app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
> at
> app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
> at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:528)
> at
> app//org.apache.ignite.internal.table.ItTableScanTest.checkCursorsAreClosed(ItTableScanTest.java:150)
> at
> java.base@11.0.17/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.base@11.0.17/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
> at
> java.base@11.0.17/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at
> java.base@11.0.17/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at
> java.base@11.0.17/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> at
> java.base@11.0.17/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.base@11.0.17/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.base@11.0.17/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base@11.0.17/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
> at
> app//org.apache.ignite.internal.table.ItTableScanTest.testCompositeScanRequest(ItTableScanTest.java:760)
> {noformat}
> h3. Implementation notes
> The test became flaky after IGNITE-21290. The reason is that the cursors of
> the scan operations are closed asynchronously, but the test checks that they
> are closed immediately after the Subscription#cancel() method is invoked.
> If the test takes several milliseconds, the cursors will be clearly closed.
> {code}
> waitForCondition(() -> storage.pendingCursors() == 0, 10_000)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21455) ItTableScanTest#testCompositeScanRequest is flaky
[
https://issues.apache.org/jira/browse/IGNITE-21455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-21455:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> ItTableScanTest#testCompositeScanRequest is flaky
> -
>
> Key: IGNITE-21455
> URL: https://issues.apache.org/jira/browse/IGNITE-21455
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> h3. Motivation
> There is an exception:
> {noformat}
> org.opentest4j.AssertionFailedError: expected: <0> but was: <1>
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151)
> at
> app//org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132)
> at
> app//org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197)
> at
> app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:150)
> at
> app//org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:145)
> at app//org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:528)
> at
> app//org.apache.ignite.internal.table.ItTableScanTest.checkCursorsAreClosed(ItTableScanTest.java:150)
> at
> java.base@11.0.17/java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:183)
> at
> java.base@11.0.17/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:177)
> at
> java.base@11.0.17/java.util.Spliterators$ArraySpliterator.forEachRemaining(Spliterators.java:948)
> at
> java.base@11.0.17/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at
> java.base@11.0.17/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> at
> java.base@11.0.17/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:150)
> at
> java.base@11.0.17/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:173)
> at
> java.base@11.0.17/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base@11.0.17/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:497)
> at
> app//org.apache.ignite.internal.table.ItTableScanTest.testCompositeScanRequest(ItTableScanTest.java:760)
> {noformat}
> h3. Implementation notes
> The test became flaky after IGNITE-21290. The reason is that the cursors of
> the scan operations are closed asynchronously, but the test checks that they
> are closed immediately after the Subscription#cancel() method is invoked.
> If the test takes several milliseconds, the cursors will be clearly closed.
> {code}
> waitForCondition(() -> storage.pendingCursors() == 0, 10_000)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-20452) Integrate failure handler processor into Ignite components
[ https://issues.apache.org/jira/browse/IGNITE-20452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-20452: - Summary: Integrate failure handler processor into Ignite components (was: Integrate failure handler processor into all components) > Integrate failure handler processor into Ignite components > -- > > Key: IGNITE-20452 > URL: https://issues.apache.org/jira/browse/IGNITE-20452 > Project: Ignite > Issue Type: Improvement >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > The failure processor IGNITE-20447 should be propagated into all Ignite > components. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20452) Integrate failure handler processor into Ignite components
[ https://issues.apache.org/jira/browse/IGNITE-20452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-20452: - Fix Version/s: 3.0.0-beta2 > Integrate failure handler processor into Ignite components > -- > > Key: IGNITE-20452 > URL: https://issues.apache.org/jira/browse/IGNITE-20452 > Project: Ignite > Issue Type: Improvement >Reporter: Vyacheslav Koptilin >Assignee: Vyacheslav Koptilin >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > The failure processor IGNITE-20447 should be propagated into all Ignite > components. -- This message was sent by Atlassian Jira (v8.20.10#820010)
