[jira] [Updated] (IGNITE-17595) Add test for required constructors in public exception types
[ https://issues.apache.org/jira/browse/IGNITE-17595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-17595: Summary: Add test for required constructors in public exception types (was: Add a test to check required constructor presence in all public exception types) > Add test for required constructors in public exception types > > > Key: IGNITE-17595 > URL: https://issues.apache.org/jira/browse/IGNITE-17595 > Project: Ignite > Issue Type: Task >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > > *IgniteException#wrap* throws "IgniteException-derived class does not have > required constructor" when a constructor with expected signature "UUID > traceId, int code, String message, Throwable cause" is not present. > We should catch those issues early. Write a test to scan all jars/classes and > check constructors. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17595) Add test for required constructors in public exception types
[ https://issues.apache.org/jira/browse/IGNITE-17595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-17595: Description: *IgniteException#wrap* throws "IgniteException-derived class does not have required constructor" when a constructor with expected signature "UUID traceId, int code, String message, Throwable cause" is not present. We should catch those issues early. Write a test to scan all jars/classes and check constructors. See https://www.archunit.org/ was: *IgniteException#wrap* throws "IgniteException-derived class does not have required constructor" when a constructor with expected signature "UUID traceId, int code, String message, Throwable cause" is not present. We should catch those issues early. Write a test to scan all jars/classes and check constructors. > Add test for required constructors in public exception types > > > Key: IGNITE-17595 > URL: https://issues.apache.org/jira/browse/IGNITE-17595 > Project: Ignite > Issue Type: Task >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > > *IgniteException#wrap* throws "IgniteException-derived class does not have > required constructor" when a constructor with expected signature "UUID > traceId, int code, String message, Throwable cause" is not present. > We should catch those issues early. Write a test to scan all jars/classes and > check constructors. See https://www.archunit.org/ -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-14726) [Log4j2] Omitted start character [ in default log pattern
[
https://issues.apache.org/jira/browse/IGNITE-14726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexey Gidaspov reassigned IGNITE-14726:
Assignee: Alexey Gidaspov
> [Log4j2] Omitted start character [ in default log pattern
> -
>
> Key: IGNITE-14726
> URL: https://issues.apache.org/jira/browse/IGNITE-14726
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
>Reporter: Fedor Malchikov
>Assignee: Alexey Gidaspov
>Priority: Major
> Labels: newbie
>
> {code:java}.withPattern("%d{ISO8601}][%-5p][%t][%c{1}] %m%n"){code}
> should be:
> {code:java}.withPattern("[%d{ISO8601}][%-5p][%t][%c{1}] %m%n"){code}
> code:
> https://github.com/apache/ignite/blob/master/modules/log4j2/src/main/java/org/apache/ignite/logger/log4j2/Log4J2Logger.java#L363
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17618) Update Ignite dependency: Jackson Databind
Aleksandr created IGNITE-17618: -- Summary: Update Ignite dependency: Jackson Databind Key: IGNITE-17618 URL: https://issues.apache.org/jira/browse/IGNITE-17618 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Assignee: Aleksandr Update dependency: jackson 2.12.4 to 2.12.7 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17431) Sql. Index support by optimizer
[
https://issues.apache.org/jira/browse/IGNITE-17431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17599592#comment-17599592
]
Konstantin Orlov commented on IGNITE-17431:
---
[~amashenkov], the patch looks good in general. I've fixed a few minor things
and merged this to main.
Thanks for contribution!
> Sql. Index support by optimizer
> ---
>
> Key: IGNITE-17431
> URL: https://issues.apache.org/jira/browse/IGNITE-17431
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We need to integrate indexes into optimisation framework. This includes
> following parts:
> - Integration of indexes into sql schema management: we need to provide a way
> to discover indexes during optimising phase (see {{ExposeIndexRule}})
> - Integration of indexes into execution: need to provide an execution node to
> convert IndexScan to (see {{LogicalRelImplementor#visit(IgniteIndexScan)}})
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17617) Snapshot status command fails if cluster has a client node.
[
https://issues.apache.org/jira/browse/IGNITE-17617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-17617:
--
Summary: Snapshot status command fails if cluster has a client node. (was:
Fix NPE in the snapshot restore status command on client nodes and
non-persistent cluster.)
> Snapshot status command fails if cluster has a client node.
> ---
>
> Key: IGNITE-17617
> URL: https://issues.apache.org/jira/browse/IGNITE-17617
> Project: Ignite
> Issue Type: Bug
>Reporter: Nikita Amelchev
>Assignee: Nikita Amelchev
>Priority: Minor
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> NPE example:
> {noformat}
> Caused by: java.lang.NullPointerException
> at
> org.apache.ignite.internal.visor.snapshot.VisorSnapshotStatusTask$VisorSnapshotStatusJob.run(VisorSnapshotStatusTask.java:133)
> at
> org.apache.ignite.internal.visor.snapshot.VisorSnapshotStatusTask$VisorSnapshotStatusJob.run(VisorSnapshotStatusTask.java:95)
> at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17617) Fix NPE in the snapshot restore status command on client nodes and non-persistent cluster.
Nikita Amelchev created IGNITE-17617:
Summary: Fix NPE in the snapshot restore status command on client
nodes and non-persistent cluster.
Key: IGNITE-17617
URL: https://issues.apache.org/jira/browse/IGNITE-17617
Project: Ignite
Issue Type: Bug
Reporter: Nikita Amelchev
Assignee: Nikita Amelchev
Fix For: 2.14
NPE example:
{noformat}
Caused by: java.lang.NullPointerException
at
org.apache.ignite.internal.visor.snapshot.VisorSnapshotStatusTask$VisorSnapshotStatusJob.run(VisorSnapshotStatusTask.java:133)
at
org.apache.ignite.internal.visor.snapshot.VisorSnapshotStatusTask$VisorSnapshotStatusJob.run(VisorSnapshotStatusTask.java:95)
at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17579) TxStateStorage management
[
https://issues.apache.org/jira/browse/IGNITE-17579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17579:
-
Description:
h3. Motivation
Currently TxStateStorage is instantiated every time on PartitionListener
instantiation, probably with incorrect storage path, that actually means that
separate rocks instances will be also instantiated, that leads us to the
unfortunate conclusion of inefficient cursors usage and whole set of excessive
resource utilization.
{code:java}
new PartitionListener(
partitionStorage,
// TODO: https://issues.apache.org/jira/browse/IGNITE-17579
TxStateStorage management.
new TxStateRocksDbStorage(Paths.get("tx_state_storage" + tblId +
partId)),
txManager,
new ConcurrentHashMap<>()
){code}
All in all, instead of new TxStateRocksDbStorage() proper storage factory
should be used like it's done for MVPartitionStorage.
h3. Definition of Done
* Proper usage of storage factory for TxStateStorage is expected, meaning that
same amount of resources is used for TxnStateStorage as for MVPartitionStorage.
h3. Implementation Notes
* It's required to add new
{code:java}
TxnStateTableStorage txnStateStorage();{code}
method to InternalTable.
* Add new interface TxnStateTableStorage with following methods
{code:java}
public interface TxnStateTableStorage {
TxnStateStorage getOrCreateTxnStateStorage(int partitionId) throws
StorageException;
@Nullable
TxnStateStorage getTxnStateStorage(int partitionId);
CompletableFuture destroyTxnStateStorage(int partitionId) throws
StorageException;
TableConfiguration configuration();
void start() throws StorageException;
void stop() throws StorageException;
void destroy() throws StorageException;
}{code}
Not sure whether we need TableConfiguration configuration(); methods, let's
check it during implementation.
* Add RocksDb implementation of aforementioned interface similar to
RocksDbTableStorage
* Implement new RocksDbTxnStateStorageEngine similar to RocksDbStorageEngine
that'll be used in order to create TxnStateTableStorage
* Update direct TxnStateStorage instantiations with proper storage
instantiation pipeline.
* It's not clear what DataStorageConfiguration to use, let's check this during
implementation.
was:
h3. Motivation
Currently TxStateStorage is instantiated every time on PartitionListener
instantiation, probably with incorrect storage path, that actually means that
separate rocks instances will be also instantiated, that leads us to the
unfortunate conclusion of inefficient cursors usage and whole set of excessive
resource utilization.
{code:java}
new PartitionListener(
partitionStorage,
// TODO: https://issues.apache.org/jira/browse/IGNITE-17579
TxStateStorage management.
new TxStateRocksDbStorage(Paths.get("tx_state_storage" + tblId +
partId)),
txManager,
new ConcurrentHashMap<>()
){code}
All in all, instead of new TxStateRocksDbStorage() proper storage factory
should be used like it's done for MVPartitionStorage.
h3. Definition of Done
* Proper usage of storage factory for TxStateStorage is expected, meaning that
same amount of resources is used for TxnStateStorage as for MVPartitionStorage.
h3. Implementation Notes
* It's required to add new
{code:java}
TxnStateTableStorage txnStateStorage();{code}
method to InternalTable.
* Add new interface TxnStateTableStorage with following methods
{code:java}
public interface TxnStateTableStorage {
TxnStateStorage getOrCreateTxnStateStorage(int partitionId) throws
StorageException;
@Nullable
TxnStateStorage getTxnStateStorage(int partitionId);
CompletableFuture destroyTxnStateStorage(int partitionId) throws
StorageException;
TableConfiguration configuration();
void start() throws StorageException;
void stop() throws StorageException;
void destroy() throws StorageException;
}{code}
Not sure whether we need TableConfiguration configuration(); methods, let's
check it during implementation.
* Add RocksDb implementation of aforementioned interface similar to
RocksDbTableStorage
* Implement new RocksDbTxnStateStorageEngine similar to RocksDbStorageEngine
that'll be used in order to create TxnStateTableStorage
* Update direct TxnStateStorage instantiations with proper storage
instantiation pipeline.
* It's not clear what DataStorageConfiguration to use, let's check this during
implementation.
> TxStateStorage management
> -
>
> Key: IGNITE-17579
> URL: https://issues.apache.org/jira/browse/IGNITE-17579
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3, transaction3_rw
>
> h3. Motivation
> Currently TxStateStorage is
[jira] [Updated] (IGNITE-17579) TxStateStorage management
[
https://issues.apache.org/jira/browse/IGNITE-17579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17579:
-
Description:
h3. Motivation
Currently TxStateStorage is instantiated every time on PartitionListener
instantiation, probably with incorrect storage path, that actually means that
separate rocks instances will be also instantiated, that leads us to the
unfortunate conclusion of inefficient cursors usage and whole set of excessive
resource utilization.
{code:java}
new PartitionListener(
partitionStorage,
// TODO: https://issues.apache.org/jira/browse/IGNITE-17579
TxStateStorage management.
new TxStateRocksDbStorage(Paths.get("tx_state_storage" + tblId +
partId)),
txManager,
new ConcurrentHashMap<>()
){code}
All in all, instead of new TxStateRocksDbStorage() proper storage factory
should be used like it's done for MVPartitionStorage.
h3. Definition of Done
* Proper usage of storage factory for TxStateStorage is expected, meaning that
same amount of resources is used for TxnStateStorage as for MVPartitionStorage.
h3. Implementation Notes
* It's required to add new
{code:java}
TxnStateTableStorage txnStateStorage();{code}
method to InternalTable.
* Add new interface TxnStateTableStorage with following methods
{code:java}
public interface TxnStateTableStorage {
TxnStateStorage getOrCreateTxnStateStorage(int partitionId) throws
StorageException;
@Nullable
TxnStateStorage getTxnStateStorage(int partitionId);
CompletableFuture destroyTxnStateStorage(int partitionId) throws
StorageException;
TableConfiguration configuration();
void start() throws StorageException;
void stop() throws StorageException;
void destroy() throws StorageException;
}{code}
Not sure whether we need TableConfiguration configuration(); methods, let's
check it during implementation.
* Add RocksDb implementation of aforementioned interface similar to
RocksDbTableStorage
* Implement new RocksDbTxnStateStorageEngine similar to RocksDbStorageEngine
that'll be used in order to create TxnStateTableStorage
* Update direct TxnStateStorage instantiations with proper storage
instantiation pipeline.
* It's not clear what DataStorageConfiguration to use, let's check this during
implementation.
was:
h3. Motivation
Currently TxStateStorage is instantiated every time on PartitionListener
instantiation, probably with incorrect storage path, that actually means that
separate rocks instances will be also instantiated, that leads us to the
unfortunate conclusion of inefficient cursors usage and whole set of excessive
resource utilization.
{code:java}
new PartitionListener(
partitionStorage,
// TODO: https://issues.apache.org/jira/browse/IGNITE-17579
TxStateStorage management.
new TxStateRocksDbStorage(Paths.get("tx_state_storage" + tblId +
partId)),
txManager,
new ConcurrentHashMap<>()
){code}
{{{}{}}}All in all, instead of new TxStateRocksDbStorage() proper storage
factory should be used like it's done for MVPartitionStorage.
h3. Definition of Done
* Proper usage of storage factory for TxStateStorage is expected, meaning that
same amount of resources is used for TxnStateStorage as for MVPartitionStorage.
h3. Implementation Notes
* It's required to add new
{code:java}
TxnStateTableStorage txnStateStorage();{code}
method to InternalTable.
* Add new interface TxnStateTableStorage with following methods
{code:java}
public interface TxnStateTableStorage {
TxnStateStorage getOrCreateTxnStateStorage(int partitionId) throws
StorageException;
@Nullable
TxnStateStorage getTxnStateStorage(int partitionId);
CompletableFuture destroyTxnStateStorage(int partitionId) throws
StorageException;
TableConfiguration configuration();
void start() throws StorageException;
void stop() throws StorageException;
void destroy() throws StorageException;
}{code}
Not sure whether we need TableConfiguration configuration(); methods, let's
check it during implementation.
* Add RocksDb implementation of aforementioned interface similar to
RocksDbTableStorage
* Implement new RocksDbTxnStateStorageEngine similar to RocksDbStorageEngine
that'll be used in order to create TxnStateTableStorage
* Update direct TxnStateStorage instantiations with proper storage
instantiation pipeline.
* It's not clear what DataStorageConfiguration to use, let's check this during
implementation.
> TxStateStorage management
> -
>
> Key: IGNITE-17579
> URL: https://issues.apache.org/jira/browse/IGNITE-17579
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3, transaction3_rw
>
> h3. Motivation
> Currently TxStateStorage
[jira] [Updated] (IGNITE-17579) TxStateStorage management
[
https://issues.apache.org/jira/browse/IGNITE-17579?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-17579:
-
Description:
h3. Motivation
Currently TxStateStorage is instantiated every time on PartitionListener
instantiation, probably with incorrect storage path, that actually means that
separate rocks instances will be also instantiated, that leads us to the
unfortunate conclusion of inefficient cursors usage and whole set of excessive
resource utilization.
{code:java}
new PartitionListener(
partitionStorage,
// TODO: https://issues.apache.org/jira/browse/IGNITE-17579
TxStateStorage management.
new TxStateRocksDbStorage(Paths.get("tx_state_storage" + tblId +
partId)),
txManager,
new ConcurrentHashMap<>()
){code}
{{{}{}}}All in all, instead of new TxStateRocksDbStorage() proper storage
factory should be used like it's done for MVPartitionStorage.
h3. Definition of Done
* Proper usage of storage factory for TxStateStorage is expected, meaning that
same amount of resources is used for TxnStateStorage as for MVPartitionStorage.
h3. Implementation Notes
* It's required to add new
{code:java}
TxnStateTableStorage txnStateStorage();{code}
method to InternalTable.
* Add new interface TxnStateTableStorage with following methods
{code:java}
public interface TxnStateTableStorage {
TxnStateStorage getOrCreateTxnStateStorage(int partitionId) throws
StorageException;
@Nullable
TxnStateStorage getTxnStateStorage(int partitionId);
CompletableFuture destroyTxnStateStorage(int partitionId) throws
StorageException;
TableConfiguration configuration();
void start() throws StorageException;
void stop() throws StorageException;
void destroy() throws StorageException;
}{code}
Not sure whether we need TableConfiguration configuration(); methods, let's
check it during implementation.
* Add RocksDb implementation of aforementioned interface similar to
RocksDbTableStorage
* Implement new RocksDbTxnStateStorageEngine similar to RocksDbStorageEngine
that'll be used in order to create TxnStateTableStorage
* Update direct TxnStateStorage instantiations with proper storage
instantiation pipeline.
* It's not clear what DataStorageConfiguration to use, let's check this during
implementation.
was:{color:#3c4043}In order to persist txnState RocksDb based TxnStateStorage
was introduced. However it's required to properly manage it: effectively create
and start like it's done for data storage, etc.{color}
> TxStateStorage management
> -
>
> Key: IGNITE-17579
> URL: https://issues.apache.org/jira/browse/IGNITE-17579
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Priority: Major
> Labels: ignite-3, transaction3_rw
>
> h3. Motivation
> Currently TxStateStorage is instantiated every time on PartitionListener
> instantiation, probably with incorrect storage path, that actually means that
> separate rocks instances will be also instantiated, that leads us to the
> unfortunate conclusion of inefficient cursors usage and whole set of
> excessive resource utilization.
>
> {code:java}
> new PartitionListener(
> partitionStorage,
> // TODO: https://issues.apache.org/jira/browse/IGNITE-17579
> TxStateStorage management.
> new TxStateRocksDbStorage(Paths.get("tx_state_storage" + tblId +
> partId)),
> txManager,
> new ConcurrentHashMap<>()
> ){code}
> {{{}{}}}All in all, instead of new TxStateRocksDbStorage() proper storage
> factory should be used like it's done for MVPartitionStorage.
> h3. Definition of Done
> * Proper usage of storage factory for TxStateStorage is expected, meaning
> that same amount of resources is used for TxnStateStorage as for
> MVPartitionStorage.
> h3. Implementation Notes
> * It's required to add new
> {code:java}
> TxnStateTableStorage txnStateStorage();{code}
> method to InternalTable.
> * Add new interface TxnStateTableStorage with following methods
> {code:java}
> public interface TxnStateTableStorage {
> TxnStateStorage getOrCreateTxnStateStorage(int partitionId) throws
> StorageException;
> @Nullable
> TxnStateStorage getTxnStateStorage(int partitionId);
> CompletableFuture destroyTxnStateStorage(int partitionId) throws
> StorageException;
> TableConfiguration configuration();
> void start() throws StorageException;
> void stop() throws StorageException;
> void destroy() throws StorageException;
> }{code}
> Not sure whether we need TableConfiguration configuration(); methods, let's
> check it during implementation.
> * Add RocksDb implementation of aforementioned interface similar to
> RocksDbTableStorage
> * Implement new RocksDbTxnStateStorageEngine similar to
[jira] [Assigned] (IGNITE-15425) Calcite engine. Add native support for SEARCH/SARG operator
[
https://issues.apache.org/jira/browse/IGNITE-15425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-15425:
--
Assignee: Aleksey Plekhanov
> Calcite engine. Add native support for SEARCH/SARG operator
> ---
>
> Key: IGNITE-15425
> URL: https://issues.apache.org/jira/browse/IGNITE-15425
> Project: Ignite
> Issue Type: Improvement
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
>
> Currently, Calcite compose some field conditions to {{SEARCH/SARG}} operator
> (for example: {{field IN (scalar)}}, {{field <> ...}}, {{field = value1 OR
> field = value2}}, etc). This operator is not supported natively by Ignite
> Calcite engine and converted back to original expression using
> {{RexUtil.expandSearch}} method on the {{RexToLixTranslator}} phase.
> Such behavior forces Ignite to use full table scan instead of indexes in
> some cases. For example, if {{field}} is indexed, with {{field IN (1, 2)}}
> condition usually is much faster to scan index for 2 values, then full scan
> table and filter out results. For {{OR}} operator {{OrToUnion}} rule can't be
> applied and there will be full table scan again.
> We should support index traversing using SEARCH/SARG operator.
> Alternatively we can convert {{SEARCH/SARG}} to {{UNIONs}} (similarly to
> {{OrToUnion}} rule), but this approach will extend plan search space a lot.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Reopened] (IGNITE-15862) Fix kubernetes ConfigMap docs on site
[ https://issues.apache.org/jira/browse/IGNITE-15862?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dmitry Pavlov reopened IGNITE-15862: I forgot to cherry pick commit to ignite-2.14. reopening > Fix kubernetes ConfigMap docs on site > - > > Key: IGNITE-15862 > URL: https://issues.apache.org/jira/browse/IGNITE-15862 > Project: Ignite > Issue Type: Improvement > Components: documentation >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Minor > Fix For: 2.14 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > There is an error in the configuration file on the site > node-configuration.xml for ConfigMap in the installation instructions in > kubernetes: > > > although if you follow the instructions, the following values should be > namespace =ignite and serviceName=ignite-service > [https://ignite.apache.org/docs/latest/installation/kubernetes/gke-deployment.html] > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-17222) Need to propagate HLC with transaction protocol events
[ https://issues.apache.org/jira/browse/IGNITE-17222?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17599449#comment-17599449 ] Alexander Lapin commented on IGNITE-17222: -- [~Sergey Uttsel] LGTM to feature branch > Need to propagate HLC with transaction protocol events > -- > > Key: IGNITE-17222 > URL: https://issues.apache.org/jira/browse/IGNITE-17222 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3, transaction3_ro > > One of source of HLC sync is a transaction protocol. Each ReplicaRequest и > ReplicaResponse should carry the sender’s HLC and updates receiver HLC > according to rules. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17222) Need to propagate HLC with transaction protocol events
[ https://issues.apache.org/jira/browse/IGNITE-17222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-17222: - Reviewer: Alexander Lapin > Need to propagate HLC with transaction protocol events > -- > > Key: IGNITE-17222 > URL: https://issues.apache.org/jira/browse/IGNITE-17222 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3, transaction3_ro > > One of source of HLC sync is a transaction protocol. Each ReplicaRequest и > ReplicaResponse should carry the sender’s HLC and updates receiver HLC > according to rules. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-12455) Calcite integration. Partition pruning.
[ https://issues.apache.org/jira/browse/IGNITE-12455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky updated IGNITE-12455: - Priority: Major (was: Minor) > Calcite integration. Partition pruning. > --- > > Key: IGNITE-12455 > URL: https://issues.apache.org/jira/browse/IGNITE-12455 > Project: Ignite > Issue Type: Improvement >Reporter: Igor Seliverstov >Assignee: Ivan Daschinsky >Priority: Major > Labels: calcite2-required, calcite3-required > > In scope of fragment info calculation we're able to prune partitions on the > basis of filter condition, query parameters, affinity and tables distribution. > This optimization may dramatically reduce query execution time/needed > resources. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-12455) Calcite integration. Partition pruning.
[ https://issues.apache.org/jira/browse/IGNITE-12455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Daschinsky reassigned IGNITE-12455: Assignee: Ivan Daschinsky > Calcite integration. Partition pruning. > --- > > Key: IGNITE-12455 > URL: https://issues.apache.org/jira/browse/IGNITE-12455 > Project: Ignite > Issue Type: Improvement >Reporter: Igor Seliverstov >Assignee: Ivan Daschinsky >Priority: Minor > Labels: calcite2-required, calcite3-required > > In scope of fragment info calculation we're able to prune partitions on the > basis of filter condition, query parameters, affinity and tables distribution. > This optimization may dramatically reduce query execution time/needed > resources. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-16550) Redesign SchemaRegistry to use causality tokens
[
https://issues.apache.org/jira/browse/IGNITE-16550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-16550:
-
Ignite Flags: (was: Docs Required,Release Notes Required)
> Redesign SchemaRegistry to use causality tokens
> ---
>
> Key: IGNITE-16550
> URL: https://issues.apache.org/jira/browse/IGNITE-16550
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Denis Chudov
>Priority: Major
> Labels: ignite-3
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> SchemaRegistry designed before the causality logic aspired(IGNITE-16391), by
> the reason all method do not apply a token and work synchronously.
> After the redesign part of the methods should be removed
> (SchemaRegistry#lastSchemaVersion, SchemaRegistry#waitLatestSchema), others
> should entirely depend on causality.
> Possibly the new methods will return futures.
> UPD:
> It was decided that in the current ticket it's worth to decouple Schema logic
> from the {{TableManager}} and create a new manager called {{SchemaManager}},
> so we can integrate causality tokens logic to the {{SchemaManager}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17561) SQLException: Hexadecimal string with odd number of characters
[
https://issues.apache.org/jira/browse/IGNITE-17561?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17599383#comment-17599383
]
Dren commented on IGNITE-17561:
---
Hi [~jooger]
A few more updates:
# the issue occurs only on SQL tables that have PK with more than one column
# the issue occurs only when using one of these columns (that are part of PK)
in WHERE part of query
# we are not using cache API for managing data in SQL tables
# we have tried rebuilding indexes with control utility as described in docs,
rebuilding finished OK (command exists properly and log shows "Finished indexes
rebuilding" entries), but it did not solve the problem
# we have stumbled across this Jira issue:
https://issues.apache.org/jira/browse/IGNITE-11252 that suggests deleting
index.bin files for affected caches/tables. Following this procedure finally
solved the problem
Also, it is possible for us to provide you with our sample data if you would
like to reproduce it yourself. We were able to reproduce it by ourselves by
repeating all upgrade steps.
> SQLException: Hexadecimal string with odd number of characters
> --
>
> Key: IGNITE-17561
> URL: https://issues.apache.org/jira/browse/IGNITE-17561
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.13
> Environment: Ignite 2.13.0
>Reporter: Dren
>Priority: Critical
> Attachments: CREATE_TABLE_STAT_ENRICH_PROCESSOR.sql, Ignite_log.txt,
> data_sample_in_table.jpg, error_sql1.jpg, ok_sql2.jpg
>
>
> After in place upgrade from 2.7.6 to 2.13.0 SQL failed with error.
> {code:java}
> //
> Caused by: org.h2.jdbc.JdbcSQLException: Hexadecimal string with odd number
> of characters: "2022-08-22 10:30:58.938" [90003-197]
> at
> org.h2.message.DbException.getJdbcSQLException(DbException.java:357)
> ... 57 more {code}
> After creation of new table with same columns and same data SQL return result
> without error.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17616) Check the replica is a primary before processing ReadWriteReplicaRequest, TxFinishReplicaRequest and TxCleanupReplicaRequest
[ https://issues.apache.org/jira/browse/IGNITE-17616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel updated IGNITE-17616: --- Description: Now we check that the replica is a primary on all of ReplicaRequest. But we need to check it only for ReadWriteReplicaRequest, because ReadOnlyReplicaRequest can be handled on non primary replica. Also after https://issues.apache.org/jira/browse/IGNITE-16882 was implemented we need to check that the replica is a primary before processing TxFinishReplicaRequest and TxCleanupReplicaRequest. was: Now we check that the replica is a primary on all of ReplicaRequest. But we need to check it only for ReadWriteReplicaRequest, because ReadOnlyReplicaRequest can be handled on non primary replica. Also after https://issues.apache.org/jira/browse/IGNITE-16882 was implemented we need to check that the replica is a primary before processing TxFinishReplicaRequest и TxCleanupReplicaRequest. > Check the replica is a primary before processing ReadWriteReplicaRequest, > TxFinishReplicaRequest and TxCleanupReplicaRequest > > > Key: IGNITE-17616 > URL: https://issues.apache.org/jira/browse/IGNITE-17616 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3, transaction3_rw > > Now we check that the replica is a primary on all of ReplicaRequest. But we > need to check it only for ReadWriteReplicaRequest, because > ReadOnlyReplicaRequest can be handled on non primary replica. > Also after https://issues.apache.org/jira/browse/IGNITE-16882 was implemented > we need to check that the replica is a primary before processing > TxFinishReplicaRequest and TxCleanupReplicaRequest. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17616) Check the replica is a primary before processing ReadWriteReplicaRequest, TxFinishReplicaRequest и TxCleanupReplicaRequest
[ https://issues.apache.org/jira/browse/IGNITE-17616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel updated IGNITE-17616: --- Summary: Check the replica is a primary before processing ReadWriteReplicaRequest, TxFinishReplicaRequest и TxCleanupReplicaRequest (was: Check the replica is a primary before processing TxFinishReplicaRequest и TxCleanupReplicaRequest) > Check the replica is a primary before processing ReadWriteReplicaRequest, > TxFinishReplicaRequest и TxCleanupReplicaRequest > -- > > Key: IGNITE-17616 > URL: https://issues.apache.org/jira/browse/IGNITE-17616 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3, transaction3_rw > > Now we check that the replica is a primary on all of ReplicaRequest. But we > need to check it only for ReadWriteReplicaRequest, because > ReadOnlyReplicaRequest can be handled on non primary replica. > Also after https://issues.apache.org/jira/browse/IGNITE-16882 was implemented > we need to check that the replica is a primary before processing > TxFinishReplicaRequest и TxCleanupReplicaRequest. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17616) Check the replica is a primary before processing ReadWriteReplicaRequest, TxFinishReplicaRequest and TxCleanupReplicaRequest
[ https://issues.apache.org/jira/browse/IGNITE-17616?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel updated IGNITE-17616: --- Summary: Check the replica is a primary before processing ReadWriteReplicaRequest, TxFinishReplicaRequest and TxCleanupReplicaRequest (was: Check the replica is a primary before processing ReadWriteReplicaRequest, TxFinishReplicaRequest и TxCleanupReplicaRequest) > Check the replica is a primary before processing ReadWriteReplicaRequest, > TxFinishReplicaRequest and TxCleanupReplicaRequest > > > Key: IGNITE-17616 > URL: https://issues.apache.org/jira/browse/IGNITE-17616 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3, transaction3_rw > > Now we check that the replica is a primary on all of ReplicaRequest. But we > need to check it only for ReadWriteReplicaRequest, because > ReadOnlyReplicaRequest can be handled on non primary replica. > Also after https://issues.apache.org/jira/browse/IGNITE-16882 was implemented > we need to check that the replica is a primary before processing > TxFinishReplicaRequest и TxCleanupReplicaRequest. > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17616) Check the replica is a primary before processing TxFinishReplicaRequest и TxCleanupReplicaRequest
Sergey Uttsel created IGNITE-17616: -- Summary: Check the replica is a primary before processing TxFinishReplicaRequest и TxCleanupReplicaRequest Key: IGNITE-17616 URL: https://issues.apache.org/jira/browse/IGNITE-17616 Project: Ignite Issue Type: Improvement Reporter: Sergey Uttsel Assignee: Sergey Uttsel Now we check that the replica is a primary on all of ReplicaRequest. But we need to check it only for ReadWriteReplicaRequest, because ReadOnlyReplicaRequest can be handled on non primary replica. Also after https://issues.apache.org/jira/browse/IGNITE-16882 was implemented we need to check that the replica is a primary before processing TxFinishReplicaRequest и TxCleanupReplicaRequest. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15516) Add DistributedProcess chaining
[
https://issues.apache.org/jira/browse/IGNITE-15516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-15516:
-
Labels: ise (was: )
> Add DistributedProcess chaining
> ---
>
> Key: IGNITE-15516
> URL: https://issues.apache.org/jira/browse/IGNITE-15516
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maxim Muzafarov
>Priority: Major
> Labels: ise
>
> The Ignite's {{DistributedProcess}} is a cluster-wide process that
> accumulates single nodes results to finish itself. The process has of the
> following phases:
> - The initial request starts the process via discovery.
> - The coordinator accumulates all single nodes results and finish process.
> The finished message sends via discory to each node.
> To run a distributed processes afther the desired distributed process is
> finished you need to call 'start' of the next distributed process on
> coordinator. This lead to the creation of boilerplate code each time you need
> to run next.
> It is necessary to configure such thing at the processes initialization.
> {{prepareSomethingDistribProc.thenRun(rollbackDistribProc)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-15516) Add DistributedProcess chaining
[
https://issues.apache.org/jira/browse/IGNITE-15516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov reassigned IGNITE-15516:
Assignee: Maxim Muzafarov
> Add DistributedProcess chaining
> ---
>
> Key: IGNITE-15516
> URL: https://issues.apache.org/jira/browse/IGNITE-15516
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: ise
> Fix For: 2.15
>
>
> The Ignite's {{DistributedProcess}} is a cluster-wide process that
> accumulates single nodes results to finish itself. The process has of the
> following phases:
> - The initial request starts the process via discovery.
> - The coordinator accumulates all single nodes results and finish process.
> The finished message sends via discory to each node.
> To run a distributed processes afther the desired distributed process is
> finished you need to call 'start' of the next distributed process on
> coordinator. This lead to the creation of boilerplate code each time you need
> to run next.
> It is necessary to configure such thing at the processes initialization.
> {{prepareSomethingDistribProc.thenRun(rollbackDistribProc)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15516) Add DistributedProcess chaining
[
https://issues.apache.org/jira/browse/IGNITE-15516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maxim Muzafarov updated IGNITE-15516:
-
Fix Version/s: 2.15
> Add DistributedProcess chaining
> ---
>
> Key: IGNITE-15516
> URL: https://issues.apache.org/jira/browse/IGNITE-15516
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maxim Muzafarov
>Priority: Major
> Labels: ise
> Fix For: 2.15
>
>
> The Ignite's {{DistributedProcess}} is a cluster-wide process that
> accumulates single nodes results to finish itself. The process has of the
> following phases:
> - The initial request starts the process via discovery.
> - The coordinator accumulates all single nodes results and finish process.
> The finished message sends via discory to each node.
> To run a distributed processes afther the desired distributed process is
> finished you need to call 'start' of the next distributed process on
> coordinator. This lead to the creation of boilerplate code each time you need
> to run next.
> It is necessary to configure such thing at the processes initialization.
> {{prepareSomethingDistribProc.thenRun(rollbackDistribProc)}}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-15556) Drop SchemaBuilder API.
[ https://issues.apache.org/jira/browse/IGNITE-15556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-15556: --- Summary: Drop SchemaBuilder API. (was: Drop SchemaBuilder public API.) > Drop SchemaBuilder API. > --- > > Key: IGNITE-15556 > URL: https://issues.apache.org/jira/browse/IGNITE-15556 > Project: Ignite > Issue Type: Task >Reporter: Andrey Mashenkov >Priority: Major > Labels: UX, ignite-3, tech-debt > > Drop SchemaBuilders public API as schema manupulation will be available only > via SQL -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15556) Drop SchemaBuilder API.
[ https://issues.apache.org/jira/browse/IGNITE-15556?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yury Gerzhedovich updated IGNITE-15556: --- Description: Drop SchemaBuilders API as schema manupulation will be available only via SQL (was: Drop SchemaBuilders public API as schema manupulation will be available only via SQL) > Drop SchemaBuilder API. > --- > > Key: IGNITE-15556 > URL: https://issues.apache.org/jira/browse/IGNITE-15556 > Project: Ignite > Issue Type: Task >Reporter: Andrey Mashenkov >Priority: Major > Labels: UX, ignite-3, tech-debt > > Drop SchemaBuilders API as schema manupulation will be available only via SQL -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17597) Calcite engine. Indexes for table can't be used after columns added or dropped
[
https://issues.apache.org/jira/browse/IGNITE-17597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-17597:
---
Release Note: Calcite engine: Fixed indexes registration after add/drop
column
> Calcite engine. Indexes for table can't be used after columns added or dropped
> --
>
> Key: IGNITE-17597
> URL: https://issues.apache.org/jira/browse/IGNITE-17597
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Blocker
> Labels: calcite, calcite3-required
> Fix For: 2.14
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We recreate tables, but not copy indexes in schema change listener
> (\{{SchemaHolderImpl#onColumnsAdded}}, \{{SchemaHolderImpl#onColumnsDropped}})
> Reproducer:
>
> {code:java}
> public void testIndexAfterColumnsChange() {
> sql("create table t(id int)");
> sql("create index t_idx on t(id)");
> for (int i = 0; i < 100; i++)
> sql("insert into t values (?)", i);
> assertQuery("select * from t where id = 0")
> .matches(QueryChecker.containsIndexScan("PUBLIC", "T", "T_IDX"))
> .check();
> sql("alter table t add column new_col int");
> assertQuery("select * from t where id = 0")
> .matches(QueryChecker.containsIndexScan("PUBLIC", "T", "T_IDX"))
> .check();
> } {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17597) Calcite engine. Indexes for table can't be used after columns added or dropped
[
https://issues.apache.org/jira/browse/IGNITE-17597?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-17597:
---
Labels: calcite calcite3-required (was: calcite calcite2-required
calcite3-required)
> Calcite engine. Indexes for table can't be used after columns added or dropped
> --
>
> Key: IGNITE-17597
> URL: https://issues.apache.org/jira/browse/IGNITE-17597
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Blocker
> Labels: calcite, calcite3-required
> Fix For: 2.14
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> We recreate tables, but not copy indexes in schema change listener
> (\{{SchemaHolderImpl#onColumnsAdded}}, \{{SchemaHolderImpl#onColumnsDropped}})
> Reproducer:
>
> {code:java}
> public void testIndexAfterColumnsChange() {
> sql("create table t(id int)");
> sql("create index t_idx on t(id)");
> for (int i = 0; i < 100; i++)
> sql("insert into t values (?)", i);
> assertQuery("select * from t where id = 0")
> .matches(QueryChecker.containsIndexScan("PUBLIC", "T", "T_IDX"))
> .check();
> sql("alter table t add column new_col int");
> assertQuery("select * from t where id = 0")
> .matches(QueryChecker.containsIndexScan("PUBLIC", "T", "T_IDX"))
> .check();
> } {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17597) Calcite engine. Indexes for table can't be used after columns added or dropped
[
https://issues.apache.org/jira/browse/IGNITE-17597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17599312#comment-17599312
]
Ignite TC Bot commented on IGNITE-17597:
{panel:title=Branch: [pull/10233/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10233/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Calcite SQL{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6589049]]
* {color:#013220}IgniteCalciteTestSuite:
TableDdlIntegrationTest.alterTableChangeColumnAndUseIndex - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6589128buildTypeId=IgniteTests24Java8_RunAll]
> Calcite engine. Indexes for table can't be used after columns added or dropped
> --
>
> Key: IGNITE-17597
> URL: https://issues.apache.org/jira/browse/IGNITE-17597
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Blocker
> Labels: calcite, calcite2-required, calcite3-required
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> We recreate tables, but not copy indexes in schema change listener
> (\{{SchemaHolderImpl#onColumnsAdded}}, \{{SchemaHolderImpl#onColumnsDropped}})
> Reproducer:
>
> {code:java}
> public void testIndexAfterColumnsChange() {
> sql("create table t(id int)");
> sql("create index t_idx on t(id)");
> for (int i = 0; i < 100; i++)
> sql("insert into t values (?)", i);
> assertQuery("select * from t where id = 0")
> .matches(QueryChecker.containsIndexScan("PUBLIC", "T", "T_IDX"))
> .check();
> sql("alter table t add column new_col int");
> assertQuery("select * from t where id = 0")
> .matches(QueryChecker.containsIndexScan("PUBLIC", "T", "T_IDX"))
> .check();
> } {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17615) Handling primary replica changes on TxFinishReplicaRequest and TxCleanupReplicaRequest
Sergey Uttsel created IGNITE-17615: -- Summary: Handling primary replica changes on TxFinishReplicaRequest and TxCleanupReplicaRequest Key: IGNITE-17615 URL: https://issues.apache.org/jira/browse/IGNITE-17615 Project: Ignite Issue Type: Improvement Reporter: Sergey Uttsel -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17614) Restore incremental snapshot
Maksim Timonin created IGNITE-17614: --- Summary: Restore incremental snapshot Key: IGNITE-17614 URL: https://issues.apache.org/jira/browse/IGNITE-17614 Project: Ignite Issue Type: New Feature Reporter: Maksim Timonin Assignee: Maksim Timonin Restoring of incremental snapshot is part of restoring full snapshot (SnapshotRestoreProcess) User specifies a name of incremental snapshot to restore (full snapshot name + timestamp suffix). Restoring steps: # Common checks for base full snapshot # Check that all incremental snapshots are present (and WAL segments) # After caches started, a WAL recovery process is started More info: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=211884314 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17613) Create incremental snapshot
Maksim Timonin created IGNITE-17613: --- Summary: Create incremental snapshot Key: IGNITE-17613 URL: https://issues.apache.org/jira/browse/IGNITE-17613 Project: Ignite Issue Type: New Feature Reporter: Maksim Timonin Assignee: Maksim Timonin Incremental snapshot is a lightweight alternative to full snapshot. It bases on the non-blocking Consistent Cut algorithm and provides a collection of WAL segments that hold logical changes since previous snapshot (full or incremental). Incremental snapshot should contain: * compacted WAL segments * meta file with Consistent Cut to restore on Incremental snapshot is stored within full snapshot directory. More info: https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=211884314 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17585) flaky ItCommonApiTest.testSessionExpiration
[
https://issues.apache.org/jira/browse/IGNITE-17585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-17585:
Affects Version/s: 3.0.0-alpha5
> flaky ItCommonApiTest.testSessionExpiration
> ---
>
> Key: IGNITE-17585
> URL: https://issues.apache.org/jira/browse/IGNITE-17585
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Affects Versions: 3.0.0-alpha5
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The test ItCommonApiTest.testSessionExpiration is flaky. Let's fix it.
> https://ci.ignite.apache.org/test/-6167055026598275943?currentProjectId=ignite3_Test_IntegrationTests=%3Cdefault%3E
> {code:java}
> org.apache.ignite.lang.IgniteExceptionorg.apache.ignite.lang.IgniteException:
> IGN-CMN-65535 TraceId:336fba3d-323a-4107-8ec1-a31ecfe6cfec IGN-CMN-65535
> TraceId:336fba3d-323a-4107-8ec1-a31ecfe6cfec IGN-CMN-65535
> TraceId:a7e3c0ff-7642-410c-8caa-8790d6ed7c6f at
> org.apache.ignite.internal.sql.api.ItCommonApiTest.testSessionExpiration(ItCommonApiTest.java:68)Caused
> by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:336fba3d-323a-4107-8ec1-a31ecfe6cfec IGN-CMN-65535
> TraceId:a7e3c0ff-7642-410c-8caa-8790d6ed7c6fCaused by:
> org.apache.ignite.internal.sql.engine.exec.ExecutionCancelledException:
> IGN-CMN-65535 TraceId:a7e3c0ff-7642-410c-8caa-8790d6ed7c6f {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17585) flaky ItCommonApiTest.testSessionExpiration
[
https://issues.apache.org/jira/browse/IGNITE-17585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-17585:
Ignite Flags: (was: Docs Required,Release Notes Required)
> flaky ItCommonApiTest.testSessionExpiration
> ---
>
> Key: IGNITE-17585
> URL: https://issues.apache.org/jira/browse/IGNITE-17585
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The test ItCommonApiTest.testSessionExpiration is flaky. Let's fix it.
> https://ci.ignite.apache.org/test/-6167055026598275943?currentProjectId=ignite3_Test_IntegrationTests=%3Cdefault%3E
> {code:java}
> org.apache.ignite.lang.IgniteExceptionorg.apache.ignite.lang.IgniteException:
> IGN-CMN-65535 TraceId:336fba3d-323a-4107-8ec1-a31ecfe6cfec IGN-CMN-65535
> TraceId:336fba3d-323a-4107-8ec1-a31ecfe6cfec IGN-CMN-65535
> TraceId:a7e3c0ff-7642-410c-8caa-8790d6ed7c6f at
> org.apache.ignite.internal.sql.api.ItCommonApiTest.testSessionExpiration(ItCommonApiTest.java:68)Caused
> by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:336fba3d-323a-4107-8ec1-a31ecfe6cfec IGN-CMN-65535
> TraceId:a7e3c0ff-7642-410c-8caa-8790d6ed7c6fCaused by:
> org.apache.ignite.internal.sql.engine.exec.ExecutionCancelledException:
> IGN-CMN-65535 TraceId:a7e3c0ff-7642-410c-8caa-8790d6ed7c6f {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17585) flaky ItCommonApiTest.testSessionExpiration
[
https://issues.apache.org/jira/browse/IGNITE-17585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-17585:
Fix Version/s: 3.0.0-alpha6
> flaky ItCommonApiTest.testSessionExpiration
> ---
>
> Key: IGNITE-17585
> URL: https://issues.apache.org/jira/browse/IGNITE-17585
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> The test ItCommonApiTest.testSessionExpiration is flaky. Let's fix it.
> https://ci.ignite.apache.org/test/-6167055026598275943?currentProjectId=ignite3_Test_IntegrationTests=%3Cdefault%3E
> {code:java}
> org.apache.ignite.lang.IgniteExceptionorg.apache.ignite.lang.IgniteException:
> IGN-CMN-65535 TraceId:336fba3d-323a-4107-8ec1-a31ecfe6cfec IGN-CMN-65535
> TraceId:336fba3d-323a-4107-8ec1-a31ecfe6cfec IGN-CMN-65535
> TraceId:a7e3c0ff-7642-410c-8caa-8790d6ed7c6f at
> org.apache.ignite.internal.sql.api.ItCommonApiTest.testSessionExpiration(ItCommonApiTest.java:68)Caused
> by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535
> TraceId:336fba3d-323a-4107-8ec1-a31ecfe6cfec IGN-CMN-65535
> TraceId:a7e3c0ff-7642-410c-8caa-8790d6ed7c6fCaused by:
> org.apache.ignite.internal.sql.engine.exec.ExecutionCancelledException:
> IGN-CMN-65535 TraceId:a7e3c0ff-7642-410c-8caa-8790d6ed7c6f {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
