[jira] [Updated] (IGNITE-21227) Monitor network critical threads for being blocked
[ https://issues.apache.org/jira/browse/IGNITE-21227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-21227: --- Description: If a netty thread or an inbound thread gets blocked, this might cause a node freeze. We need to monitor such situations to: # Have ability to see such blockages in logs # See the thread dump corresponding to the blockage moment to make it possible diagnose the root cause of the blockage There is a mechanism in AI2 that allows doing so, and it's (at least partially) ported to AI3, it is about Ignitethreads and IgniteWorkers. Netty and inbound threads are currently not using the IgniteWorkers mechanism. We need to either use it or adapt them to include them in this monitoring. > Monitor network critical threads for being blocked > -- > > Key: IGNITE-21227 > URL: https://issues.apache.org/jira/browse/IGNITE-21227 > Project: Ignite > Issue Type: Improvement >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > If a netty thread or an inbound thread gets blocked, this might cause a node > freeze. We need to monitor such situations to: > # Have ability to see such blockages in logs > # See the thread dump corresponding to the blockage moment to make it > possible diagnose the root cause of the blockage > There is a mechanism in AI2 that allows doing so, and it's (at least > partially) ported to AI3, it is about Ignitethreads and IgniteWorkers. > Netty and inbound threads are currently not using the IgniteWorkers > mechanism. We need to either use it or adapt them to include them in this > monitoring. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21227) Monitor network critical threads for being blocked
Roman Puchkovskiy created IGNITE-21227: -- Summary: Monitor network critical threads for being blocked Key: IGNITE-21227 URL: https://issues.apache.org/jira/browse/IGNITE-21227 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-20051) Add startup recovery to SchemaManager
[
https://issues.apache.org/jira/browse/IGNITE-20051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov resolved IGNITE-20051.
Resolution: Fixed
> Add startup recovery to SchemaManager
> -
>
> Key: IGNITE-20051
> URL: https://issues.apache.org/jira/browse/IGNITE-20051
> Project: Ignite
> Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Currently, {{SchemaManager}} does not implement a proper recovery procedure
> at start. It needs a way to get all tables from the CatalogService (including
> the dropped ones). Also, it must make sure that versions of the tables that
> were missed due to being offline are added to the schemas storage as a result
> of recovery.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21226) NPE throws from MessageServiceImpl if service already stopped but incoming message still processed
Evgeny Stanilovsky created IGNITE-21226:
---
Summary: NPE throws from MessageServiceImpl if service already
stopped but incoming message still processed
Key: IGNITE-21226
URL: https://issues.apache.org/jira/browse/IGNITE-21226
Project: Ignite
Issue Type: Bug
Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Evgeny Stanilovsky
Assignee: Evgeny Stanilovsky
MessageServiceImpl can throw NPE if it was closed but incoming message need to
be processed.
{noformat}
at java.base@11.0.17/java.util.Objects.requireNonNull(Objects.java:246)
at
app//org.apache.ignite.internal.sql.engine.message.MessageServiceImpl.onMessageInternal(MessageServiceImpl.java:135)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17615) Close local cursors on primary replica expiration
[
https://issues.apache.org/jira/browse/IGNITE-17615?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov reassigned IGNITE-17615:
--
Assignee: Vladislav Pyatkov
> Close local cursors on primary replica expiration
> -
>
> Key: IGNITE-17615
> URL: https://issues.apache.org/jira/browse/IGNITE-17615
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Uttsel
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Motivation
> According to our tx protocol, it’s impossible to commit a transaction if any
> of the enlisted primary replicas have expired. It also means that there’s no
> sense in preserving tx related volatile state such as locks and cursors. Pay
> attention, that it’s still useful to preserve txnState in the
> txnStateLocalMap because it will ease write intent resolution procedure.
> Locks release on primary replica expiration was already implemented, so this
> ticket is only about closing cursors on primary expiration.
> h3. Definition of Done
> * On primary replica expiration all RW-scoped cursors are closed.
> h3. Implementation Notes
> 1.In
> `org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#onPrimaryExpired`
> we release all tx locks
> {code:java}
> futs.add(allOf(txFuts).whenComplete((unused, throwable) ->
> releaseTxLocks(txId)));
> {code}
> Seems reasonable to reuse same event to close the cursors. Worth mentioning
> that given action should be asynchronous. I believe that we may do the
> cursors close in partition striped pool. See StripedThreadPoolExecutor for
> more details. Another option here is to introduce special dedicated cleanup
> thread and use it instead. That will be a part of TX Resourse Cleanup design.
> 2. So, that was about when to close, let’s clarify what to close. Seems that
> it’s trivial. We have
> `org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#cursors`
> right in partition replica listeners. We even have corresponding helper
> method
> `org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#closeAllTransactionCursors`
>
> All in all, seems that it's required to substitute
>
> {code:java}
> futs.add(allOf(txFuts).whenComplete((unused, throwable) ->
> releaseTxLocks(txId)));{code}
> with
> {code:java}
> futs.add(allOf(txFuts).whenComplete((unused, throwable)
> -> {
> releaseTxLocks(txId);
> try {
> closeAllTransactionCursors(txId);
> } catch (Exception e) {
> LOG.warn("Unable to close cursor on primary
> replica expiration", e);
> }
> }));{code}
> Tests are trickey though.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20918) Leases expire after a node has been restarted
[
https://issues.apache.org/jira/browse/IGNITE-20918?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804863#comment-17804863
]
Vladislav Pyatkov commented on IGNITE-20918:
Loks like it is fixed in IGNITE-20883.
> Leases expire after a node has been restarted
> -
>
> Key: IGNITE-20918
> URL: https://issues.apache.org/jira/browse/IGNITE-20918
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Alexander Lapin
>Priority: Critical
> Labels: ignite-3
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> IGNITE-20910 introduces a test that inserts some data after restarting a
> node. For some reason, after some time, I can see the following messages in
> the log:
> {noformat}
> [2023-11-22T10:00:17,056][INFO
> ][%isnt_tmpar_0%metastorage-watch-executor-3][PartitionReplicaListener]
> Primary replica expired [grp=5_part_19]
> [2023-11-22T10:00:17,057][INFO
> ][%isnt_tmpar_0%metastorage-watch-executor-3][PartitionReplicaListener]
> Primary replica expired [grp=5_part_0]
> [2023-11-22T10:00:17,057][INFO
> ][%isnt_tmpar_0%metastorage-watch-executor-3][PartitionReplicaListener]
> Primary replica expired [grp=5_part_9]
> [2023-11-22T10:00:17,057][INFO
> ][%isnt_tmpar_0%metastorage-watch-executor-3][PartitionReplicaListener]
> Primary replica expired [grp=5_part_10]
> {noformat}
> After that, the test fails with a {{PrimaryReplicaMissException}}. The
> problem here, that it is expected that a single node should never have
> expired leases, they should be prolongated automatically. I think that this
> happens because the initial lease that was issued before the node was
> restarted is still accepted by the node after restart.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17615) Close local cursors on primary replica expiration
[
https://issues.apache.org/jira/browse/IGNITE-17615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804859#comment-17804859
]
Vladislav Pyatkov commented on IGNITE-17615:
I also resolved the ticket IGNITE-20933 at this PR, because it is trivial and
does not deserve a dedicated check.
> Close local cursors on primary replica expiration
> -
>
> Key: IGNITE-17615
> URL: https://issues.apache.org/jira/browse/IGNITE-17615
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergey Uttsel
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Motivation
> According to our tx protocol, it’s impossible to commit a transaction if any
> of the enlisted primary replicas have expired. It also means that there’s no
> sense in preserving tx related volatile state such as locks and cursors. Pay
> attention, that it’s still useful to preserve txnState in the
> txnStateLocalMap because it will ease write intent resolution procedure.
> Locks release on primary replica expiration was already implemented, so this
> ticket is only about closing cursors on primary expiration.
> h3. Definition of Done
> * On primary replica expiration all RW-scoped cursors are closed.
> h3. Implementation Notes
> 1.In
> `org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#onPrimaryExpired`
> we release all tx locks
> {code:java}
> futs.add(allOf(txFuts).whenComplete((unused, throwable) ->
> releaseTxLocks(txId)));
> {code}
> Seems reasonable to reuse same event to close the cursors. Worth mentioning
> that given action should be asynchronous. I believe that we may do the
> cursors close in partition striped pool. See StripedThreadPoolExecutor for
> more details. Another option here is to introduce special dedicated cleanup
> thread and use it instead. That will be a part of TX Resourse Cleanup design.
> 2. So, that was about when to close, let’s clarify what to close. Seems that
> it’s trivial. We have
> `org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#cursors`
> right in partition replica listeners. We even have corresponding helper
> method
> `org.apache.ignite.internal.table.distributed.replicator.PartitionReplicaListener#closeAllTransactionCursors`
>
> All in all, seems that it's required to substitute
>
> {code:java}
> futs.add(allOf(txFuts).whenComplete((unused, throwable) ->
> releaseTxLocks(txId)));{code}
> with
> {code:java}
> futs.add(allOf(txFuts).whenComplete((unused, throwable)
> -> {
> releaseTxLocks(txId);
> try {
> closeAllTransactionCursors(txId);
> } catch (Exception e) {
> LOG.warn("Unable to close cursor on primary
> replica expiration", e);
> }
> }));{code}
> Tests are trickey though.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21225) Redundant lambda object allocation in ClockPageReplacementFlags#setFlag
Aleksey Plekhanov created IGNITE-21225:
--
Summary: Redundant lambda object allocation in
ClockPageReplacementFlags#setFlag
Key: IGNITE-21225
URL: https://issues.apache.org/jira/browse/IGNITE-21225
Project: Ignite
Issue Type: Improvement
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov
Every time we call {{ClockPageReplacementFlags#setFlag/clearFlag}} methods the
new lambda object is created, since lambda is accessing the variable in
enclosing scope. \{{ClockPageReplacementFlags#setFlag}} method called every
time when page is modified, so, it's a relatevily hot method and we should
avoid new object allocation here.
Here is the test to show redundant allocations:
{code:java}
/** */
@Test
public void testAllocation() {
clockFlags = new ClockPageReplacementFlags(MAX_PAGES_CNT, region.address());
int cnt = 1_000_000;
ThreadMXBean bean = (ThreadMXBean)ManagementFactory.getThreadMXBean();
// Warmup.
clockFlags.setFlag(0);
long allocated0 =
bean.getThreadAllocatedBytes(Thread.currentThread().getId());
for (int i = 0; i < cnt; i++)
clockFlags.setFlag(i % MAX_PAGES_CNT);
long allocated1 =
bean.getThreadAllocatedBytes(Thread.currentThread().getId());
assertTrue("Too many bytes allocated: " + (allocated1 - allocated0),
allocated1 - allocated0 < cnt);
} {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21185) In DistributionFunction strings are compared with == instead of equals()
[
https://issues.apache.org/jira/browse/IGNITE-21185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804830#comment-17804830
]
Dmitrii Kriukov commented on IGNITE-21185:
--
PR: https://github.com/apache/ignite/pull/11169
> In DistributionFunction strings are compared with == instead of equals()
>
>
> Key: IGNITE-21185
> URL: https://issues.apache.org/jira/browse/IGNITE-21185
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitrii Kriukov
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Line 157:
> {color:#cc7832}if {color}(f0 == f1 || f0.name() == f1.name())
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21224) Add checks for generated error code files to the sanity tests
Dmitrii Zabotlin created IGNITE-21224:
-
Summary: Add checks for generated error code files to the sanity
tests
Key: IGNITE-21224
URL: https://issues.apache.org/jira/browse/IGNITE-21224
Project: Ignite
Issue Type: Improvement
Reporter: Dmitrii Zabotlin
Assignee: Igor Sapego
We need to check that generated error codes files are not changed during the
build. It means that we have committed proper versions.
Files:
{code:java}
./modules/platforms/cpp/ignite/common/error_codes.h{code}
{code:java}
./modules/platforms/dotnet/Apache.Ignite/ErrorCodes.g.cs {code}
Sanity checks
[link|https://ci.ignite.apache.org/project/ApacheIgnite3xGradle_Test_SanityCheck]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21223) Add xml example WAL Records Compression
[ https://issues.apache.org/jira/browse/IGNITE-21223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Nikolaev updated IGNITE-21223: Labels: ise newbee (was: ise) > Add xml example WAL Records Compression > > > Key: IGNITE-21223 > URL: https://issues.apache.org/jira/browse/IGNITE-21223 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Priority: Major > Labels: ise, newbee > > Add xml example WAL Records Compression > [https://ignite.apache.org/docs/latest/persistence/native-persistence#wal-records-compression] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21223) Add xml example WAL Records Compression
[ https://issues.apache.org/jira/browse/IGNITE-21223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Nikolaev updated IGNITE-21223: Labels: ise (was: ) > Add xml example WAL Records Compression > > > Key: IGNITE-21223 > URL: https://issues.apache.org/jira/browse/IGNITE-21223 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Priority: Major > Labels: ise > > Add xml example WAL Records Compression > [https://ignite.apache.org/docs/latest/persistence/native-persistence#wal-records-compression] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21223) Add xml example WAL Records Compression
Aleksandr Nikolaev created IGNITE-21223: --- Summary: Add xml example WAL Records Compression Key: IGNITE-21223 URL: https://issues.apache.org/jira/browse/IGNITE-21223 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Nikolaev Add xml example WAL Records Compression [https://ignite.apache.org/docs/latest/persistence/native-persistence#wal-records-compression] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21214) Add Catalog API to retrieve a schema by its ID
[
https://issues.apache.org/jira/browse/IGNITE-21214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-21214:
-
Fix Version/s: 3.0.0-beta2
> Add Catalog API to retrieve a schema by its ID
> --
>
> Key: IGNITE-21214
> URL: https://issues.apache.org/jira/browse/IGNITE-21214
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> For some reason, {{CatalogService}} API does not allow searching for schemas
> by their IDs, like any other objects. We should remove this descrepancy.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21216) Do not consider tasks that are not in org.apache.ignite package as system
[ https://issues.apache.org/jira/browse/IGNITE-21216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Petrov reassigned IGNITE-21216: --- Assignee: Mikhail Petrov > Do not consider tasks that are not in org.apache.ignite package as system > - > > Key: IGNITE-21216 > URL: https://issues.apache.org/jira/browse/IGNITE-21216 > Project: Ignite > Issue Type: Bug >Reporter: Mikhail Petrov >Assignee: Mikhail Petrov >Priority: Minor > Time Spent: 10m > Remaining Estimate: 0h > > Check https://github.com/apache/ignite/issues/10907 for more detailed > description of the problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21214) Add Catalog API to retrieve a schema by its ID
[
https://issues.apache.org/jira/browse/IGNITE-21214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804735#comment-17804735
]
Kirill Tkalenko commented on IGNITE-21214:
--
Looks goof
> Add Catalog API to retrieve a schema by its ID
> --
>
> Key: IGNITE-21214
> URL: https://issues.apache.org/jira/browse/IGNITE-21214
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For some reason, {{CatalogService}} API does not allow searching for schemas
> by their IDs, like any other objects. We should remove this descrepancy.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21214) Add Catalog API to retrieve a schema by its ID
[
https://issues.apache.org/jira/browse/IGNITE-21214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21214:
-
Reviewer: Kirill Tkalenko
> Add Catalog API to retrieve a schema by its ID
> --
>
> Key: IGNITE-21214
> URL: https://issues.apache.org/jira/browse/IGNITE-21214
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For some reason, {{CatalogService}} API does not allow searching for schemas
> by their IDs, like any other objects. We should remove this descrepancy.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21222) Update the current year in website
Aleksandr Nikolaev created IGNITE-21222: --- Summary: Update the current year in website Key: IGNITE-21222 URL: https://issues.apache.org/jira/browse/IGNITE-21222 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Nikolaev Assignee: Aleksandr Nikolaev The site [https://ignite.apache.org/] indicates the date of 2023, it is necessary to update to the current -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21218) Design txn resource cleanup
[ https://issues.apache.org/jira/browse/IGNITE-21218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21218: - Summary: Design txn resource cleanup (was: Design txn resourse cleanup) > Design txn resource cleanup > --- > > Key: IGNITE-21218 > URL: https://issues.apache.org/jira/browse/IGNITE-21218 > Project: Ignite > Issue Type: Task >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21221) Txn resource cleanup
[ https://issues.apache.org/jira/browse/IGNITE-21221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21221: - Labels: ignite-3 (was: ) > Txn resource cleanup > > > Key: IGNITE-21221 > URL: https://issues.apache.org/jira/browse/IGNITE-21221 > Project: Ignite > Issue Type: Epic >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21218) Design txn resource cleanup
[ https://issues.apache.org/jira/browse/IGNITE-21218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21218: - Epic Link: IGNITE-21221 > Design txn resource cleanup > --- > > Key: IGNITE-21218 > URL: https://issues.apache.org/jira/browse/IGNITE-21218 > Project: Ignite > Issue Type: Task >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21221) Txn resourse cleanup
[ https://issues.apache.org/jira/browse/IGNITE-21221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21221: - Epic Name: Txn resource cleanup (was: Txn resourse cleanup) > Txn resourse cleanup > > > Key: IGNITE-21221 > URL: https://issues.apache.org/jira/browse/IGNITE-21221 > Project: Ignite > Issue Type: Epic >Reporter: Alexander Lapin >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21222) Update the current year in website
[ https://issues.apache.org/jira/browse/IGNITE-21222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Nikolaev updated IGNITE-21222: Component/s: website > Update the current year in website > -- > > Key: IGNITE-21222 > URL: https://issues.apache.org/jira/browse/IGNITE-21222 > Project: Ignite > Issue Type: Improvement > Components: website >Reporter: Aleksandr Nikolaev >Assignee: Aleksandr Nikolaev >Priority: Major > Labels: ise > > The site [https://ignite.apache.org/] indicates the date of 2023, it is > necessary to update to the current -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21222) Update the current year in website
[ https://issues.apache.org/jira/browse/IGNITE-21222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Nikolaev updated IGNITE-21222: Ignite Flags: (was: Docs Required,Release Notes Required) > Update the current year in website > -- > > Key: IGNITE-21222 > URL: https://issues.apache.org/jira/browse/IGNITE-21222 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Nikolaev >Assignee: Aleksandr Nikolaev >Priority: Major > Labels: ise > > The site [https://ignite.apache.org/] indicates the date of 2023, it is > necessary to update to the current -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21221) Txn resource cleanup
[ https://issues.apache.org/jira/browse/IGNITE-21221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21221: - Summary: Txn resource cleanup (was: Txn resourse cleanup) > Txn resource cleanup > > > Key: IGNITE-21221 > URL: https://issues.apache.org/jira/browse/IGNITE-21221 > Project: Ignite > Issue Type: Epic >Reporter: Alexander Lapin >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21221) Txn resourse cleanup
Alexander Lapin created IGNITE-21221: Summary: Txn resourse cleanup Key: IGNITE-21221 URL: https://issues.apache.org/jira/browse/IGNITE-21221 Project: Ignite Issue Type: Epic Reporter: Alexander Lapin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21221) Txn resourse cleanup
[ https://issues.apache.org/jira/browse/IGNITE-21221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21221: - Ignite Flags: (was: Docs Required,Release Notes Required) > Txn resourse cleanup > > > Key: IGNITE-21221 > URL: https://issues.apache.org/jira/browse/IGNITE-21221 > Project: Ignite > Issue Type: Epic >Reporter: Alexander Lapin >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-20851) Client disconnect and coordinator node shutdown failover
[ https://issues.apache.org/jira/browse/IGNITE-20851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mikhail Pochatkin resolved IGNITE-20851. Assignee: Mikhail Pochatkin Resolution: Won't Fix > Client disconnect and coordinator node shutdown failover > > > Key: IGNITE-20851 > URL: https://issues.apache.org/jira/browse/IGNITE-20851 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Mikhail Pochatkin >Assignee: Mikhail Pochatkin >Priority: Major > Labels: ignite-3 > > h2. Coordinator node shutdown > In the case when the coordinator node is turned off, the execution of the job > will not stop (except for the case where the worker node and the coordinator > node coincide), but in this case the client loses the opportunity to receive > the result of the job execution. > h2. Client disconnect > The current architecture implies that if the connection with the client is > broken, the execution of the job must be canceled, since there is no way to > get the result of the job execution. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21217) Check STMT_VALIDATION error code usage
[ https://issues.apache.org/jira/browse/IGNITE-21217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21217: - Labels: ignite-3 (was: ) > Check STMT_VALIDATION error code usage > -- > > Key: IGNITE-21217 > URL: https://issues.apache.org/jira/browse/IGNITE-21217 > Project: Ignite > Issue Type: Improvement >Reporter: Dmitrii Zabotlin >Assignee: Yury Gerzhedovich >Priority: Major > Labels: ignite-3 > > We throwing STMT_VALIDATION error in many cases now. For example, on > non-existent table drop or non-existent index drop. > Looks like we can be more specific, it will help us to propagate proper error > to the client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21185) In DistributionFunction strings are compared with == instead of equals()
[
https://issues.apache.org/jira/browse/IGNITE-21185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21185:
-
Labels: ignite-3 (was: )
> In DistributionFunction strings are compared with == instead of equals()
>
>
> Key: IGNITE-21185
> URL: https://issues.apache.org/jira/browse/IGNITE-21185
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitrii Kriukov
>Priority: Minor
> Labels: ignite-3
>
> Line 157:
> {color:#cc7832}if {color}(f0 == f1 || f0.name() == f1.name())
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21185) In DistributionFunction strings are compared with == instead of equals()
[
https://issues.apache.org/jira/browse/IGNITE-21185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21185:
-
Labels: (was: ignite-3)
> In DistributionFunction strings are compared with == instead of equals()
>
>
> Key: IGNITE-21185
> URL: https://issues.apache.org/jira/browse/IGNITE-21185
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitrii Kriukov
>Priority: Minor
>
> Line 157:
> {color:#cc7832}if {color}(f0 == f1 || f0.name() == f1.name())
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21211) Catalog service advanced improvements
[ https://issues.apache.org/jira/browse/IGNITE-21211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21211: - Labels: ignite-3 (was: ) > Catalog service advanced improvements > - > > Key: IGNITE-21211 > URL: https://issues.apache.org/jira/browse/IGNITE-21211 > Project: Ignite > Issue Type: Epic >Reporter: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21182) Temporary increase lease interval to eliminate issues related to long watch events processing
[ https://issues.apache.org/jira/browse/IGNITE-21182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21182: - Labels: ignite-3 (was: ) > Temporary increase lease interval to eliminate issues related to long watch > events processing > - > > Key: IGNITE-21182 > URL: https://issues.apache.org/jira/browse/IGNITE-21182 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21177) Replace dynamic properties injection by correct configuration file
[ https://issues.apache.org/jira/browse/IGNITE-21177?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21177: - Labels: ignite-3 (was: ) > Replace dynamic properties injection by correct configuration file > -- > > Key: IGNITE-21177 > URL: https://issues.apache.org/jira/browse/IGNITE-21177 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21174) Transaction enhancements
[ https://issues.apache.org/jira/browse/IGNITE-21174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21174: - Labels: ignite-3 (was: ) > Transaction enhancements > > > Key: IGNITE-21174 > URL: https://issues.apache.org/jira/browse/IGNITE-21174 > Project: Ignite > Issue Type: Epic >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > > Various tx related issues: refactoring, tech dept, enhancements. This epic > doesn't have a corresponding Monday counterpart, it's here in order to > aggregate issues. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21170) Partition divergence on instable topology in replicated cache
[ https://issues.apache.org/jira/browse/IGNITE-21170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-21170: - Summary: Partition divergence on instable topology in replicated cache (was: Partition divergence on instable topology in replicated cahce) > Partition divergence on instable topology in replicated cache > - > > Key: IGNITE-21170 > URL: https://issues.apache.org/jira/browse/IGNITE-21170 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > > The rebalancing topology for a replicated cache can be switched earlier on a > particular node before all nodes rebalance. If the topology is switched on by > the coordinator, it may send a full partition map with the topology, which is > not reached. This finally leads to map invoke operations on a moving > partition and then divergence between replicas. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21167) Sql. Change exception message raised while calling transactions with disabled autoCommit from jdbc
[
https://issues.apache.org/jira/browse/IGNITE-21167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-21167:
-
Labels: ignite-3 (was: )
> Sql. Change exception message raised while calling transactions with disabled
> autoCommit from jdbc
> --
>
> Key: IGNITE-21167
> URL: https://issues.apache.org/jira/browse/IGNITE-21167
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Evgeny Stanilovsky
>Priority: Major
> Labels: ignite-3
>
> After ignite-20661 was implemented, statements like:
> {code:java}
> "START TRANSACTION; SELECT 1; COMMIT;"
> {code}
> will throw non friendly exception like :
> "Transaction control statement cannot be executed within an external
> transaction"
> Need to be changed.
> Discussed in [1]
> [1] https://github.com/apache/ignite-3/pull/2906#discussion_r1420178983
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21220) Worker node recovery
Aleksandr created IGNITE-21220: -- Summary: Worker node recovery Key: IGNITE-21220 URL: https://issues.apache.org/jira/browse/IGNITE-21220 Project: Ignite Issue Type: Improvement Reporter: Aleksandr There is a case when the worker node executing some job has left the logical topology. This node has to identify this situation and stop all running jobs. We must not have the situation when the worker left the topology, the coordinator restarted the job on another node, then the first worker joined the topology and two instances of the job are running on the cluster. Maybe we do not allow this but we have a lack of tests here. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21219) Write memory leak tests
Aleksandr created IGNITE-21219: -- Summary: Write memory leak tests Key: IGNITE-21219 URL: https://issues.apache.org/jira/browse/IGNITE-21219 Project: Ignite Issue Type: Improvement Components: compute Reporter: Aleksandr Compute jobs handling logic is getting harder to track every reference we have. It seems like we can easily introduce a memory leak. I wonder if we have some microbenchmarks that prove the absence of memory leak in the compute component. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21218) Design txn resourse cleanup
[ https://issues.apache.org/jira/browse/IGNITE-21218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21218: - Labels: ignite-3 (was: ) > Design txn resourse cleanup > --- > > Key: IGNITE-21218 > URL: https://issues.apache.org/jira/browse/IGNITE-21218 > Project: Ignite > Issue Type: Task >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21218) Design txn resourse cleanup
[ https://issues.apache.org/jira/browse/IGNITE-21218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin reassigned IGNITE-21218: Assignee: Alexander Lapin > Design txn resourse cleanup > --- > > Key: IGNITE-21218 > URL: https://issues.apache.org/jira/browse/IGNITE-21218 > Project: Ignite > Issue Type: Task >Reporter: Alexander Lapin >Assignee: Alexander Lapin >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21218) Design txn resourse cleanup
[ https://issues.apache.org/jira/browse/IGNITE-21218?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21218: - Ignite Flags: (was: Docs Required,Release Notes Required) > Design txn resourse cleanup > --- > > Key: IGNITE-21218 > URL: https://issues.apache.org/jira/browse/IGNITE-21218 > Project: Ignite > Issue Type: Task >Reporter: Alexander Lapin >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21218) Design txn resourse cleanup
Alexander Lapin created IGNITE-21218: Summary: Design txn resourse cleanup Key: IGNITE-21218 URL: https://issues.apache.org/jira/browse/IGNITE-21218 Project: Ignite Issue Type: Task Reporter: Alexander Lapin -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21055) Sql. ParserService should use SqlNode::unparse instead of SqlNode::toString
[ https://issues.apache.org/jira/browse/IGNITE-21055?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-21055: - Assignee: Maksim Zhuravkov > Sql. ParserService should use SqlNode::unparse instead of SqlNode::toString > --- > > Key: IGNITE-21055 > URL: https://issues.apache.org/jira/browse/IGNITE-21055 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > Problem - SqlNodes may contain sensitive information that can leak into logs > via toString method, in order to avoid such > issues it maybe a good idea to override toString method to remove all > sensitive information for such SQL nodes. > Unfornutently such approach breaks PrepareService, because it builds a copy > for a SQL AST from SQL string created by SqlNode::toString method. > Let's update ParserService to build SQL via unparse method to avoid this > problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21217) Check STMT_VALIDATION error code usage
Dmitrii Zabotlin created IGNITE-21217: - Summary: Check STMT_VALIDATION error code usage Key: IGNITE-21217 URL: https://issues.apache.org/jira/browse/IGNITE-21217 Project: Ignite Issue Type: Improvement Reporter: Dmitrii Zabotlin Assignee: Yury Gerzhedovich We throwing STMT_VALIDATION error in many cases now. For example, on non-existent table drop or non-existent index drop. Looks like we can be more specific, it will help us to propagate proper error to the client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20795) Sql. QuerySplitter does not visit IgniteTableFunctionScan nodes.
[ https://issues.apache.org/jira/browse/IGNITE-20795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Zhuravkov reassigned IGNITE-20795: - Assignee: Maksim Zhuravkov > Sql. QuerySplitter does not visit IgniteTableFunctionScan nodes. > > > Key: IGNITE-20795 > URL: https://issues.apache.org/jira/browse/IGNITE-20795 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Maksim Zhuravkov >Assignee: Maksim Zhuravkov >Priority: Minor > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > > IgniteTableFunctionScan implements SourceAwareIgniteRel but returns hardcoded > sourceId that is equal to -1, because QuerySplitter does not visit nodes of > this type. > Update QuerySpliiter to visit IgniteTableFunctionScan and fix this behaviour. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21036) Add possibility to obtain parameters of already existing zone.
[ https://issues.apache.org/jira/browse/IGNITE-21036?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-21036: Assignee: Mirza Aliev > Add possibility to obtain parameters of already existing zone. > -- > > Key: IGNITE-21036 > URL: https://issues.apache.org/jira/browse/IGNITE-21036 > Project: Ignite > Issue Type: Improvement > Components: sql >Affects Versions: 3.0.0-beta1 >Reporter: Evgeny Stanilovsky >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > > For now it`s possible to create distributed zone with different configurable > parameters, like: > "CREATE ZONE name_of_the_zone WITH partitions=7, DATA_NODES_AUTO_ADJUST=100" > but there is no way to obtain this zone params using public api (views, > jmx?). Seems we need such a functionality. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20894) Add tests for ensuring transactional guarantees
[ https://issues.apache.org/jira/browse/IGNITE-20894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-20894: Assignee: Denis Chudov > Add tests for ensuring transactional guarantees > --- > > Key: IGNITE-20894 > URL: https://issues.apache.org/jira/browse/IGNITE-20894 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0 >Reporter: Alexey Scherbakov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > > h3. Motivation > The first purpose of the transaction flow tests is to preserve consistency in > storage. The reason for this might be partial commits due to executing > commits and rollbacks on one transaction. The second is avoiding redundant or > permanent locks that can originate from an asynchronous operation during a > commit. > h3. Definition of done > Here is a list of tests that should be present: > # Ensure the correctness of the exception and all the transaction's locks are > freed when adding operations to a committed transaction. > # Ensure the correctness of the exception and all the transaction's locks are > freed when adding operations to a rolled-back transaction. > # Test consistency after commit when the transaction is acting asynchronously. > # Test consistency after rollback when the transaction is acting > asynchronously. > # Ensure consistency when a transaction is committed or rolled back from > several threads at the same time. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-21061) Durable cleanup requires additional replication group command
[
https://issues.apache.org/jira/browse/IGNITE-21061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-21061:
Assignee: Kirill Sizov
> Durable cleanup requires additional replication group command
> -
>
> Key: IGNITE-21061
> URL: https://issues.apache.org/jira/browse/IGNITE-21061
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Kirill Sizov
>Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> After locks are released, it is required to write the information to
> transaction persistent storage and replicate it on all commit partition
> replication group nodes. That is performed by the replication command
> ({{MarkLocksReleasedCommand}}). As a result, we have an additional
> replication command for the entire transaction process.
> h3. Implementation notes
> In my opinion, we can resolve this situation in the transaction resolution
> procedure ({{OrphanDetector}}). It just needs to do nothing additional:
> either release the locks by durable finish from the transaction coordinator
> or release them by recovery by {{OrphanDetector}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17666) Scan subscription cancel does not close a server side cursor
[ https://issues.apache.org/jira/browse/IGNITE-17666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-17666: Assignee: Denis Chudov > Scan subscription cancel does not close a server side cursor > > > Key: IGNITE-17666 > URL: https://issues.apache.org/jira/browse/IGNITE-17666 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3 > > h3. Motivation > Read-only transactions start a scan operation and save transaction cursors on > the replica side. The cursors stay on the server until they are closed. > Read-only transactions finish locally and do not notify all replicas of the > transaction. > h3. Definition of done > # Enlist node to RO transaction. > # Prohibit adding operations to the read-only transaction after the > transaction is finished. > # Send the finish transaction request to all enlisted nodes to close cursors. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-20974) It seems a row has been skipped by the removal operation
[
https://issues.apache.org/jira/browse/IGNITE-20974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin reassigned IGNITE-20974:
Assignee: Vladislav Pyatkov
> It seems a row has been skipped by the removal operation
>
>
> Key: IGNITE-20974
> URL: https://issues.apache.org/jira/browse/IGNITE-20974
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: MakeTeamcityGreenAgain, ignite-3
> Attachments: _Integration_Tests_Module_Table_17003.log.zip
>
>
> h3. Motivation
> This issue has happened in TC, but it is very rare, and it is related to a
> multi-node cluster only (TC log was attached). Look at the exception for
> ItTxDistributedTestThreeNodesThreeReplicas.testComplexImplicit:
> {noformat}
> org.opentest4j.AssertionFailedError: expected: but was:
>
> 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.AssertNull.failNotNull(AssertNull.java:50)
> at app//org.junit.jupiter.api.AssertNull.assertNull(AssertNull.java:35)
> at app//org.junit.jupiter.api.AssertNull.assertNull(AssertNull.java:30)
> at app//org.junit.jupiter.api.Assertions.assertNull(Assertions.java:276)
> at
> app//org.apache.ignite.internal.table.TxAbstractTest.doTestComplex(TxAbstractTest.java:1450)
> at
> app//org.apache.ignite.internal.table.TxAbstractTest.testComplexImplicit(TxAbstractTest.java:1354)
> at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base@11.0.17/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base@11.0.17/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base@11.0.17/java.lang.reflect.Method.invoke(Method.java:566)
> {noformat}
> The assertion failed exception is here (in line 6):
> {code:title=TxAbstractTest.java}
> view.deleteAll(tx, keys);
> for (Tuple key : keys) {
> Tuple entry = view.get(tx, key);
> assertNull(entry);
> }
> {code}
> h3. Implementation notes
> Check that the result of the _deleteAll_ operation is an empty collection.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-20364) Design the details how zone partition listeners will support multiple table partitions
[ https://issues.apache.org/jira/browse/IGNITE-20364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin reassigned IGNITE-20364: Assignee: Kirill Gusakov > Design the details how zone partition listeners will support multiple table > partitions > -- > > Key: IGNITE-20364 > URL: https://issues.apache.org/jira/browse/IGNITE-20364 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Assignee: Kirill Gusakov >Priority: Major > Labels: ignite-3 > > *Motivation* > Due to the fact, that the new data layout will be built around the zone-based > partition: one zone partition (one RAFT peer at the node) will store multiple > table partitions (multiple state machines for one RAFT peer). So, we need to > prepare details according for > [document|https://github.com/apache/ignite-3/blob/1abb67c8770179d5d3e295876b73893f3845a08e/modules/distribution-zones/tech-notes/zone-collocation.md#L1] > to clarify implementation details. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21216) Do not consider tasks that are not in org.apache.ignite package as system
Mikhail Petrov created IGNITE-21216: --- Summary: Do not consider tasks that are not in org.apache.ignite package as system Key: IGNITE-21216 URL: https://issues.apache.org/jira/browse/IGNITE-21216 Project: Ignite Issue Type: Bug Reporter: Mikhail Petrov Check https://github.com/apache/ignite/issues/10907 for more detailed description of the problem. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-20993) Make the tables recover on the same assignments on different nodes
[
https://issues.apache.org/jira/browse/IGNITE-20993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-20993:
-
Reviewer: Alexander Lapin
> Make the tables recover on the same assignments on different nodes
> --
>
> Key: IGNITE-20993
> URL: https://issues.apache.org/jira/browse/IGNITE-20993
> Project: Ignite
> Issue Type: Improvement
>Reporter: Denis Chudov
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Motivation*
> Currently the following is possible:
> * node A performs the recovery on revision _x_ and in case of absence of
> stable assignments calculates the assignments from data nodes for this
> revision;
> * node B is doing the same for recovery revision _y_ which is not equal to
> {_}x{_}.
> As a result, they can start partitions for different assignments which are
> not consistent, and this can lead to side effects like unavailability of the
> majority for some partitions, and ambiguous unpredictable assignments will be
> written to meta storate due to the race between these nodes.
> *Definition of done*
> The multiple nodes performing recovery always start partitions for
> assignments calculated for the same revision.
> *Implementation notes*
> The common revision for different nodes in this case can be revision on which
> the table was created, it should be done under IGNITE-21014 .
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-20653) C++ client: support SQL script execution
[ https://issues.apache.org/jira/browse/IGNITE-20653?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804671#comment-17804671 ] Dmitrii Zabotlin commented on IGNITE-20653: --- LGTM > C++ client: support SQL script execution > > > Key: IGNITE-20653 > URL: https://issues.apache.org/jira/browse/IGNITE-20653 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Pavel Pereslegin >Assignee: Igor Sapego >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > support SQL script execution in C++ client -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20360) Implement the set of zone supported storages
[
https://issues.apache.org/jira/browse/IGNITE-20360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804662#comment-17804662
]
Mirza Aliev commented on IGNITE-20360:
--
Merged to feature branch `*storage-profiles-feature`*
> Implement the set of zone supported storages
>
>
> Key: IGNITE-20360
> URL: https://issues.apache.org/jira/browse/IGNITE-20360
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Gusakov
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Motivation*
> According to IGNITE-20357 we need to have an appropriate zone filter, which
> filters the nodes based on their available storages.
> *Example*
> {code}
> create zone z1 with storage_profiles="lru_rocks,*clock_aipersist";
> {code}
> As a result::
> * Zone consists of nodes which supports the *BOTH* storage profiles
> lru_rocks and clock_aipersist
> * Default storage profile for this zone will be clock_aipersist, because it
> is marked with *. It means, that (after the IGNITE-20361) if on table
> creation we will skip the storage profile for table:
> {code}
> create table t1 using zone="z1";
> {code}
> the table t1 will use clock_aipersist storage_profile.
> *Definition of done*
> * Zone has the filters, which can be unambiguously used to check if table
> can be "deployed" in this zone
> *Notes*
> * Avoid filter altering for now (but add the appropriate event types)
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Comment Edited] (IGNITE-20360) Implement the set of zone supported storages
[
https://issues.apache.org/jira/browse/IGNITE-20360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804662#comment-17804662
]
Mirza Aliev edited comment on IGNITE-20360 at 1/9/24 9:52 AM:
--
Merged to feature branch {{{*}storage-profiles-feature}}{*}
was (Author: maliev):
Merged to feature branch `*storage-profiles-feature`*
> Implement the set of zone supported storages
>
>
> Key: IGNITE-20360
> URL: https://issues.apache.org/jira/browse/IGNITE-20360
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Gusakov
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Motivation*
> According to IGNITE-20357 we need to have an appropriate zone filter, which
> filters the nodes based on their available storages.
> *Example*
> {code}
> create zone z1 with storage_profiles="lru_rocks,*clock_aipersist";
> {code}
> As a result::
> * Zone consists of nodes which supports the *BOTH* storage profiles
> lru_rocks and clock_aipersist
> * Default storage profile for this zone will be clock_aipersist, because it
> is marked with *. It means, that (after the IGNITE-20361) if on table
> creation we will skip the storage profile for table:
> {code}
> create table t1 using zone="z1";
> {code}
> the table t1 will use clock_aipersist storage_profile.
> *Definition of done*
> * Zone has the filters, which can be unambiguously used to check if table
> can be "deployed" in this zone
> *Notes*
> * Avoid filter altering for now (but add the appropriate event types)
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-21141) MvccProcessor removal
[ https://issues.apache.org/jira/browse/IGNITE-21141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804658#comment-17804658 ] Ilya Shishkov commented on IGNITE-21141: [~av], thank you a lot for the review! > MvccProcessor removal > - > > Key: IGNITE-21141 > URL: https://issues.apache.org/jira/browse/IGNITE-21141 > Project: Ignite > Issue Type: Sub-task > Components: mvcc >Reporter: Ilya Shishkov >Assignee: Ilya Shishkov >Priority: Minor > Labels: ise > Fix For: 2.17 > > Time Spent: 50m > Remaining Estimate: 0h > > Remove MvccProcessor class. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-20360) Implement the set of zone supported storages
[
https://issues.apache.org/jira/browse/IGNITE-20360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804656#comment-17804656
]
Kirill Gusakov commented on IGNITE-20360:
-
LGTM
> Implement the set of zone supported storages
>
>
> Key: IGNITE-20360
> URL: https://issues.apache.org/jira/browse/IGNITE-20360
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Gusakov
>Assignee: Mirza Aliev
>Priority: Major
> Labels: ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> *Motivation*
> According to IGNITE-20357 we need to have an appropriate zone filter, which
> filters the nodes based on their available storages.
> *Example*
> {code}
> create zone z1 with storage_profiles="lru_rocks,*clock_aipersist";
> {code}
> As a result::
> * Zone consists of nodes which supports the *BOTH* storage profiles
> lru_rocks and clock_aipersist
> * Default storage profile for this zone will be clock_aipersist, because it
> is marked with *. It means, that (after the IGNITE-20361) if on table
> creation we will skip the storage profile for table:
> {code}
> create table t1 using zone="z1";
> {code}
> the table t1 will use clock_aipersist storage_profile.
> *Definition of done*
> * Zone has the filters, which can be unambiguously used to check if table
> can be "deployed" in this zone
> *Notes*
> * Avoid filter altering for now (but add the appropriate event types)
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21163) .NET platform test timeouts
[
https://issues.apache.org/jira/browse/IGNITE-21163?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Steshin reassigned IGNITE-21163:
-
Assignee: Vladimir Steshin
> .NET platform test timeouts
> ---
>
> Key: IGNITE-21163
> URL: https://issues.apache.org/jira/browse/IGNITE-21163
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>
> There are many timeouted test runs in the .NET suite. For example:
> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
> "The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
> {buildId=7678070} has been running for more than 40 minutes. Terminating..."
> Looks like only port 47500 is requested while server node started on another.
> Probably a previous test didn't release the port yet.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21203) flaky org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession
[ https://issues.apache.org/jira/browse/IGNITE-21203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov reassigned IGNITE-21203: - Assignee: Konstantin Orlov > flaky org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession > -- > > Key: IGNITE-21203 > URL: https://issues.apache.org/jira/browse/IGNITE-21203 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > The test > org.apache.ignite.internal.sql.api.ItSqlAsynchronousApiTest.closeSession is > flacky due to org.apache.ignite.internal.sql.api.SessionImpl#close relies on > the fact that the returned CompletableFuture will be complited only after all > resources have been closed. However, > org.apache.ignite.internal.sql.api.SessionImpl#closeAsync returns a always > ready facke CompletableFuture. > The closeInternal() method needs to be slightly reworked to return a real > CompletableFuture and start using the return value. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21209) Do not try handle PrimaryReplicaMissException on transaction operation
[ https://issues.apache.org/jira/browse/IGNITE-21209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804645#comment-17804645 ] Vladislav Pyatkov commented on IGNITE-21209: Meregd 57da4e559cf20e06fcaef419cb7d77822534e3b7 > Do not try handle PrimaryReplicaMissException on transaction operation > -- > > Key: IGNITE-21209 > URL: https://issues.apache.org/jira/browse/IGNITE-21209 > Project: Ignite > Issue Type: Improvement >Reporter: Vladislav Pyatkov >Assignee: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > h3. Motivation > A transaction enlists a primary replica before making an operation request. > But the PrimaryReplicaMissException can be thrown after the request tries to > be sent. This means that any ties to remap the request cannot enlist a new > primary replica, and all this is meaningless. The code, which handles the > PrimaryReplicaMissException, just wastes time. > h3. Definition of done > Do not handle the PrimaryReplicaMissException on any transaction operation > after the primary replica is already enlisted. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-21165) .NET platform test timeouts after ClientServerCompatibilityTest
[
https://issues.apache.org/jira/browse/IGNITE-21165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17804644#comment-17804644
]
Vladimir Steshin commented on IGNITE-21165:
---
[~ptupitsyn], could you take a look please? The timeouts have gone.
> .NET platform test timeouts after ClientServerCompatibilityTest
> ---
>
> Key: IGNITE-21165
> URL: https://issues.apache.org/jira/browse/IGNITE-21165
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladimir Steshin
>Priority: Major
> Labels: ise
> Attachments:
> Ignite_Tests_2.x_JDK_8_11_Platform_.NET_Core_Linux_39429.log.zip
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> There are many timeouted test runs in the .NET suite. Example:
> https://ci2.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformNetCoreLinux/7678070
> {code:java}
> The build Ignite Tests 2.x (JDK 8/11)::Platform .NET (Core Linux) #39429
> {buildId=7678070} has been running for more than 40 minutes. Terminating...
> {code}
> Looks like only port 47500 is requested while server node started on another.
> Probably a previous test didn't release the port yet.
> {code:java}
> Successfully bound communication NIO server to TCP port [port=47101,
> locHost=/127.0.0.1, selectorsCnt=4, selectorSpins=0, pairedConn=false]
> {code}
> {code:java}
> Failed to connect to any address from IP finder (make sure IP finder
> addresses are correct and firewalls are disabled on all host machines):
> [/127.0.0.1:47500]
> {code}
> It looks like this issue happens on JDK8 only. And only on Linux.
> _ClientServerCompatibilityTest_ starts a server node with _Runner.java_,
> _PlatformProcessUtils#startProcess()_ and stops with
> _PlatformProcessUtils#stopProcess()_. On Windows, additional
> {code:java}
> serverProc.KillProcessTree();
> {code}
> is applied.
> We should wait until _java.lang.Process_ completely stops.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-21066) Create job priority change API
[ https://issues.apache.org/jira/browse/IGNITE-21066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Baranov reassigned IGNITE-21066: --- Assignee: Dmitry Baranov > Create job priority change API > -- > > Key: IGNITE-21066 > URL: https://issues.apache.org/jira/browse/IGNITE-21066 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Mikhail Pochatkin >Assignee: Dmitry Baranov >Priority: Major > Labels: ignite-3 > > Once a job has been accepted for execution and is in the queue, we should be > able to dynamically change its priority in order to move it up or down in the > execution queue. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-20988) Ignite can't execute tasks - "Topology projection is empty"
[
https://issues.apache.org/jira/browse/IGNITE-20988?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikita Amelchev resolved IGNITE-20988.
--
Resolution: Won't Fix
> Ignite can't execute tasks - "Topology projection is empty"
> ---
>
> Key: IGNITE-20988
> URL: https://issues.apache.org/jira/browse/IGNITE-20988
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.16
>Reporter: Valery Shorin
>Assignee: Nikita Amelchev
>Priority: Critical
> Labels: ise
> Attachments: image-2023-11-28-16-52-32-145.png
>
>
> On our Ignite cluster logs are flooded by the following exceptions:
> {code:java}
> 2023-11-28 16:39:54.253 [INFO
> ][db-checkpoint-thread-#92][org.apache.ignite.internal.processors.cache.persistence.checkpoint.Checkpointer]
> Skipping checkpoint (no pages were modified) [checkpointBeforeLockTime=6ms,
> checkpointLockWait=0ms, checkpointListenersExecuteTime=5ms,
> checkpointLockHoldTime=6ms, reason='timeout']
> 2023-11-28 16:40:18.905 [WARN
> ][client-connector-#83][org.apache.ignite.internal.processors.odbc.ClientListenerNioListener]
> Failed to process client request
> [req=o.a.i.i.processors.platform.client.compute.ClientExecuteTaskRequest@33b4781e,
> msg=Topology projection is empty.]
> org.apache.ignite.internal.processors.platform.client.IgniteClientException:
> Topology projection is empty.
> at
> org.apache.ignite.internal.processors.platform.client.compute.ClientComputeTask.execute(ClientComputeTask.java:117)
> ~[ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.platform.client.compute.ClientExecuteTaskRequest.process(ClientExecuteTaskRequest.java:89)
> ~[ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.platform.client.ClientRequestHandler.handle(ClientRequestHandler.java:101)
> ~[ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:211)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:57)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterChain$TailFilter.onMessageReceived(GridNioFilterChain.java:279)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.util.nio.GridNioFilterAdapter.proceedMessageReceived(GridNioFilterAdapter.java:109)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.util.nio.GridNioAsyncNotifyFilter$3.body(GridNioAsyncNotifyFilter.java:97)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.util.worker.GridWorkerPool$1.run(GridWorkerPool.java:70)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
> [?:?]
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
> [?:?]
> at java.lang.Thread.run(Thread.java:834) [?:?]
> 2023-11-28 16:40:48.895 [WARN
> ][client-connector-#82][org.apache.ignite.internal.processors.odbc.ClientListenerNioListener]
> Failed to process client request
> [req=o.a.i.i.processors.platform.client.compute.ClientExecuteTaskRequest@aa13d84,
> msg=Topology projection is empty.]
> org.apache.ignite.internal.processors.platform.client.IgniteClientException:
> Topology projection is empty.
> at
> org.apache.ignite.internal.processors.platform.client.compute.ClientComputeTask.execute(ClientComputeTask.java:117)
> ~[ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.platform.client.compute.ClientExecuteTaskRequest.process(ClientExecuteTaskRequest.java:89)
> ~[ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.platform.client.ClientRequestHandler.handle(ClientRequestHandler.java:101)
> ~[ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:211)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
> org.apache.ignite.internal.processors.odbc.ClientListenerNioListener.onMessage(ClientListenerNioListener.java:57)
> [ignite-core-16.0.0-SNAPSHOT.jar:16.0.0-SNAPSHOT]
> at
>
[jira] [Updated] (IGNITE-21215) Catalog API should allow renaming tables and indices
[
https://issues.apache.org/jira/browse/IGNITE-21215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21215:
-
Description:
Implementation details:
# Add Catalog commands for renaming a table and an index;
# Add corresponding {{UpdateEntry}} implementations;
# Add events and event types, if needed.
> Catalog API should allow renaming tables and indices
>
>
> Key: IGNITE-21215
> URL: https://issues.apache.org/jira/browse/IGNITE-21215
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> Implementation details:
> # Add Catalog commands for renaming a table and an index;
> # Add corresponding {{UpdateEntry}} implementations;
> # Add events and event types, if needed.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21215) Catalog API should allow renaming tables and indices
[ https://issues.apache.org/jira/browse/IGNITE-21215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21215: - Labels: ignite-3 (was: ) > Catalog API should allow renaming tables and indices > > > Key: IGNITE-21215 > URL: https://issues.apache.org/jira/browse/IGNITE-21215 > 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-21215) Catalog API should allow renaming tables and indices
[ https://issues.apache.org/jira/browse/IGNITE-21215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev updated IGNITE-21215: - Ignite Flags: (was: Docs Required,Release Notes Required) > Catalog API should allow renaming tables and indices > > > Key: IGNITE-21215 > URL: https://issues.apache.org/jira/browse/IGNITE-21215 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-21215) Catalog API should allow renaming tables and indices
Aleksandr Polovtcev created IGNITE-21215: Summary: Catalog API should allow renaming tables and indices Key: IGNITE-21215 URL: https://issues.apache.org/jira/browse/IGNITE-21215 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-21214) Add Catalog API to retrieve a schema by its ID
[
https://issues.apache.org/jira/browse/IGNITE-21214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21214:
-
Labels: ignite-3 (was: )
> Add Catalog API to retrieve a schema by its ID
> --
>
> Key: IGNITE-21214
> URL: https://issues.apache.org/jira/browse/IGNITE-21214
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
> Labels: ignite-3
>
> For some reason, {{CatalogService}} API does not allow searching for schemas
> by their IDs, like any other objects. We should remove this descrepancy.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-21214) Add Catalog API to retrieve a schema by its ID
[
https://issues.apache.org/jira/browse/IGNITE-21214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksandr Polovtcev updated IGNITE-21214:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Add Catalog API to retrieve a schema by its ID
> --
>
> Key: IGNITE-21214
> URL: https://issues.apache.org/jira/browse/IGNITE-21214
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Blocker
>
> For some reason, {{CatalogService}} API does not allow searching for schemas
> by their IDs, like any other objects. We should remove this descrepancy.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-21214) Add Catalog API to retrieve a schema by its ID
Aleksandr Polovtcev created IGNITE-21214:
Summary: Add Catalog API to retrieve a schema by its ID
Key: IGNITE-21214
URL: https://issues.apache.org/jira/browse/IGNITE-21214
Project: Ignite
Issue Type: Improvement
Reporter: Aleksandr Polovtcev
Assignee: Aleksandr Polovtcev
For some reason, {{CatalogService}} API does not allow searching for schemas by
their IDs, like any other objects. We should remove this descrepancy.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
