[jira] [Updated] (IGNITE-17199) Improve the usability of the abstract configuration interface
[
https://issues.apache.org/jira/browse/IGNITE-17199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17199:
-
Description:
*Problem*
Consider an example of generating configuration interfaces (**Configuration*)
for an abstract configuration.
Configuration schemas:
{code:java}
@AbstractConfiguration
public class BaseConfigurationSchema {
@Value
public int size;
}
@Config
public class VolatileConfigurationSchema extends BaseConfigurationSchema {
@Value
public double evictionThreshold;
}
{code}
Configuration interfaces:
{code:java}
public interface BaseConfiguration extends ConfigurationTree {
ConfigurationValue size();
}
public interface VolatileConfiguration extends BaseConfiguration {
ConfigurationValue size();
}
{code}
This implementation allows us to work with the inheritors of the abstract
configuration as with a regular configuration (as if
*VolatileConfigurationSchema* did not extend *BaseConfigurationSchema*), but
when working with the abstract configuration itself, it creates inconvenience.
For example, to get a view of the abstract configuration, we will need to write
the following code:
{code:java}
BaseConfiguration baseConfig0 = ...;
BaseConfiguration baseConfig1 = ...;
BaseView baseView0 = (BasePageMemoryDataRegionView) baseConfig0.value();
BaseView baseView1 = baseConfig1.value();
{code}
Which is not convenient and I would like us to be able to work in the same way
as with the *VolatileConfiguration*.
*Implementation proposal*
was:
*Problem*
Consider an example of generating configuration interfaces (**Configuration*)
for an abstract configuration.
Configuration schemas:
{code:java}
@AbstractConfiguration
public class BaseConfigurationSchema {
@Value
public int size;
}
@Config
public class VolatileConfigurationSchema extends BaseConfigurationSchema {
@Value
public double evictionThreshold;
}
{code}
Configuration interfaces:
{code:java}
public interface BaseConfiguration extends ConfigurationTree {
ConfigurationValue size();
}
public interface VolatileConfiguration extends BaseConfiguration {
ConfigurationValue size();
}
{code}
This implementation allows us to work with the inheritors of the abstract
configuration as with a regular configuration (as if
*VolatileConfigurationSchema* did not extend *BaseConfigurationSchema*), but
when working with the abstract configuration itself, it creates inconvenience.
For example, to get a view of the abstract configuration, we will need to write
the following code:
{code:java}
BaseConfiguration baseConfig0 = ...;
BaseConfiguration baseConfig1 = ...;
BaseView baseView0 = (BasePageMemoryDataRegionView) baseConfig0.value();
BaseView baseView1 = baseConfig1.value();
{code}
Which is not convenient and I would like us to be able to work in the same way
as with the *VolatileConfiguration*.
*Implementation proposal*
For an abstract configuration schema, generate 2 configuration interfaces, the
first is package private, the second is public.
The abstract configuration and all its inheritors will extend the package's
private interface.
For example:
{code:java}
public interface BaseConfiguration extends ConfigurationTree {
ConfigurationValue size();
}
public interface VolatileConfiguration extends BaseConfiguration {
ConfigurationValue size();
}
{code}
> Improve the usability of the abstract configuration interface
> -
>
> Key: IGNITE-17199
> URL: https://issues.apache.org/jira/browse/IGNITE-17199
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: iep-55, ignite-3
> Fix For: 3.0.0-alpha6
>
>
> *Problem*
> Consider an example of generating configuration interfaces (**Configuration*)
> for an abstract configuration.
> Configuration schemas:
> {code:java}
> @AbstractConfiguration
> public class BaseConfigurationSchema {
> @Value
> public int size;
> }
> @Config
> public class VolatileConfigurationSchema extends BaseConfigurationSchema {
> @Value
> public double evictionThreshold;
> }
> {code}
> Configuration interfaces:
> {code:java}
> public interface BaseConfiguration BaseChange> extends ConfigurationTree {
> ConfigurationValue size();
> }
> public interface VolatileConfiguration extends
> BaseConfiguration {
> ConfigurationValue size();
> }
> {code}
> This implementation allows us to work with the inheritors of the abstract
> configuration as with a regular configuration (as if
> *VolatileConfigurationSchema* did not extend *BaseConfigurationSchema*), but
> when working with the abstract configuration itself, it creates
> inconvenience.
> For example, to get a view of the
[jira] [Updated] (IGNITE-17199) Improve the usability of the abstract configuration interface
[
https://issues.apache.org/jira/browse/IGNITE-17199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17199:
-
Description:
*Problem*
Consider an example of generating configuration interfaces (**Configuration*)
for an abstract configuration.
Configuration schemas:
{code:java}
@AbstractConfiguration
public class BaseConfigurationSchema {
@Value
public int size;
}
@Config
public class VolatileConfigurationSchema extends BaseConfigurationSchema {
@Value
public double evictionThreshold;
}
{code}
Configuration interfaces:
{code:java}
public interface BaseConfiguration extends ConfigurationTree {
ConfigurationValue size();
}
public interface VolatileConfiguration extends BaseConfiguration {
ConfigurationValue size();
}
{code}
This implementation allows us to work with the inheritors of the abstract
configuration as with a regular configuration (as if
*VolatileConfigurationSchema* did not extend *BaseConfigurationSchema*), but
when working with the abstract configuration itself, it creates inconvenience.
For example, to get a view of the abstract configuration, we will need to write
the following code:
{code:java}
BaseConfiguration baseConfig0 = ...;
BaseConfiguration baseConfig1 = ...;
BaseView baseView0 = (BasePageMemoryDataRegionView) baseConfig0.value();
BaseView baseView1 = baseConfig1.value();
{code}
Which is not convenient and I would like us to be able to work in the same way
as with the *VolatileConfiguration*.
*Implementation proposal*
For an abstract configuration schema, generate 2 configuration interfaces, the
first is package private, the second is public.
The abstract configuration and all its inheritors will extend the package's
private interface.
For example:
{code:java}
public interface BaseConfiguration extends ConfigurationTree {
ConfigurationValue size();
}
public interface VolatileConfiguration extends BaseConfiguration {
ConfigurationValue size();
}
{code}
was:
*Problem*
Consider an example of generating configuration interfaces (**Configuration*)
for an abstract configuration.
Configuration schemas:
{code:java}
@AbstractConfiguration
public class BaseConfigurationSchema {
@Value
public int size;
}
@Config
public class VolatileConfigurationSchema extends BaseConfigurationSchema {
@Value
public double evictionThreshold;
}
{code}
Configuration interfaces:
{code:java}
public interface BaseConfiguration extends ConfigurationTree {
ConfigurationValue size();
}
public interface VolatileConfiguration extends BaseConfiguration {
ConfigurationValue size();
}
{code}
This implementation allows us to work with the inheritors of the abstract
configuration as with a regular configuration (as if
*VolatileConfigurationSchema* did not extend *BaseConfigurationSchema*), but
when working with the abstract configuration itself, it creates inconvenience.
For example, to get a view of the abstract configuration, we will need to write
the following code:
{code:java}
BaseConfiguration baseConfig0 = ...;
BaseConfiguration baseConfig1 = ...;
BaseView baseView0 = (BasePageMemoryDataRegionView) baseConfig0.value();
BaseView baseView1 = baseConfig1.value();
{code}
Which is not convenient and I would like us to be able to work in the same way
as with the *VolatileConfiguration*.
*Implementation proposal*
> Improve the usability of the abstract configuration interface
> -
>
> Key: IGNITE-17199
> URL: https://issues.apache.org/jira/browse/IGNITE-17199
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: iep-55, ignite-3
> Fix For: 3.0.0-alpha6
>
>
> *Problem*
> Consider an example of generating configuration interfaces (**Configuration*)
> for an abstract configuration.
> Configuration schemas:
> {code:java}
> @AbstractConfiguration
> public class BaseConfigurationSchema {
> @Value
> public int size;
> }
> @Config
> public class VolatileConfigurationSchema extends BaseConfigurationSchema {
> @Value
> public double evictionThreshold;
> }
> {code}
> Configuration interfaces:
> {code:java}
> public interface BaseConfiguration BaseChange> extends ConfigurationTree {
> ConfigurationValue size();
> }
> public interface VolatileConfiguration extends
> BaseConfiguration {
> ConfigurationValue size();
> }
> {code}
> This implementation allows us to work with the inheritors of the abstract
> configuration as with a regular configuration (as if
> *VolatileConfigurationSchema* did not extend *BaseConfigurationSchema*), but
> when working with the abstract configuration itself, it creates
> inconvenience.
> For example, to get a view of the
[jira] [Updated] (IGNITE-17199) Improve the usability of the abstract configuration interface
[
https://issues.apache.org/jira/browse/IGNITE-17199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17199:
-
Description:
*Problem*
Consider an example of generating configuration interfaces (**Configuration*)
for an abstract configuration.
Configuration schemas:
{code:java}
@AbstractConfiguration
public class BaseConfigurationSchema {
@Value
public int size;
}
@Config
public class VolatileConfigurationSchema extends BaseConfigurationSchema {
@Value
public double evictionThreshold;
}
{code}
Configuration interfaces:
{code:java}
public interface BaseConfiguration extends ConfigurationTree {
ConfigurationValue size();
}
public interface VolatileConfiguration extends BaseConfiguration {
ConfigurationValue size();
}
{code}
This implementation allows us to work with the inheritors of the abstract
configuration as with a regular configuration (as if
*VolatileConfigurationSchema* did not extend *BaseConfigurationSchema*), but
when working with the abstract configuration itself, it creates inconvenience.
For example, to get a view of the abstract configuration, we will need to write
the following code:
{code:java}
BaseConfiguration baseConfig0 = ...;
BaseConfiguration baseConfig1 = ...;
BaseView baseView0 = (BasePageMemoryDataRegionView) baseConfig0.value();
BaseView baseView1 = baseConfig1.value();
{code}
Which is not convenient and I would like us to be able to work in the same way
as with the *VolatileConfiguration*.
*Implementation proposal*
was:
*Problem*
Consider an example of generating configuration interfaces (**Configuration*)
for an abstract configuration.
Configuration schemas:
{code:java}
@AbstractConfiguration
public class BaseConfigurationSchema {
@Value
public int size;
}
@Config
public class VolatileConfigurationSchema extends BaseConfigurationSchema {
@Value
public double evictionThreshold;
}
{code}
Configuration interfaces:
{code:java}
public interface BaseConfiguration extends ConfigurationTree {
ConfigurationValue size();
}
public interface VolatileConfiguration extends BaseConfiguration {
ConfigurationValue size();
}
{code}
This implementation allows us to work with the inheritors of the abstract
configuration as with a regular configuration (as if
*VolatileConfigurationSchema* did not extend *BaseConfigurationSchema*), but
when working with the abstract configuration itself, it creates inconvenience.
For example, to get a view of the abstract configuration, we will need to write
the following code:
{code:java}
BaseConfiguration baseConfig0 = ...;
BaseConfiguration baseConfig1 = ...;
BaseView baseView0 = (BasePageMemoryDataRegionView) baseConfig0.value();
BaseView baseView1 = baseConfig1.value();
{code}
Which is not convenient and I would like us to be able to work in the same way
as with the *VolatileConfiguration*.
> Improve the usability of the abstract configuration interface
> -
>
> Key: IGNITE-17199
> URL: https://issues.apache.org/jira/browse/IGNITE-17199
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: iep-55, ignite-3
> Fix For: 3.0.0-alpha6
>
>
> *Problem*
> Consider an example of generating configuration interfaces (**Configuration*)
> for an abstract configuration.
> Configuration schemas:
> {code:java}
> @AbstractConfiguration
> public class BaseConfigurationSchema {
> @Value
> public int size;
> }
> @Config
> public class VolatileConfigurationSchema extends BaseConfigurationSchema {
> @Value
> public double evictionThreshold;
> }
> {code}
> Configuration interfaces:
> {code:java}
> public interface BaseConfiguration BaseChange> extends ConfigurationTree {
> ConfigurationValue size();
> }
> public interface VolatileConfiguration extends
> BaseConfiguration {
> ConfigurationValue size();
> }
> {code}
> This implementation allows us to work with the inheritors of the abstract
> configuration as with a regular configuration (as if
> *VolatileConfigurationSchema* did not extend *BaseConfigurationSchema*), but
> when working with the abstract configuration itself, it creates
> inconvenience.
> For example, to get a view of the abstract configuration, we will need to
> write the following code:
> {code:java}
> BaseConfiguration baseConfig0 = ...;
> BaseConfiguration baseConfig1 = ...;
>
> BaseView baseView0 = (BasePageMemoryDataRegionView) baseConfig0.value();
> BaseView baseView1 = baseConfig1.value();
> {code}
> Which is not convenient and I would like us to be able to work in the same
> way as with the *VolatileConfiguration*.
> *Implementation proposal*
--
This message was sent by
[jira] [Updated] (IGNITE-17199) Improve the usability of the abstract configuration interface
[
https://issues.apache.org/jira/browse/IGNITE-17199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17199:
-
Description:
*Problem*
Consider an example of generating configuration interfaces (**Configuration*)
for an abstract configuration.
Configuration schemas:
{code:java}
@AbstractConfiguration
public class BaseConfigurationSchema {
@Value
public int size;
}
@Config
public class VolatileConfigurationSchema extends BaseConfigurationSchema {
@Value
public double evictionThreshold;
}
{code}
Configuration interfaces:
{code:java}
public interface BaseConfiguration extends ConfigurationTree {
ConfigurationValue size();
}
public interface VolatileConfiguration extends BaseConfiguration {
ConfigurationValue size();
}
{code}
This implementation allows us to work with the inheritors of the abstract
configuration as with a regular configuration (as if
*VolatileConfigurationSchema* did not extend *BaseConfigurationSchema*), but
when working with the abstract configuration itself, it creates inconvenience.
For example, to get a view of the abstract configuration, we will need to write
the following code:
{code:java}
BaseConfiguration baseConfig0 = ...;
BaseConfiguration baseConfig1 = ...;
BaseView baseView0 = (BasePageMemoryDataRegionView) baseConfig0.value();
BaseView baseView1 = baseConfig1.value();
{code}
Which is not convenient and I would like us to be able to work in the same way
as with the *VolatileConfiguration*.
was:
*Problem*
Consider an example of generating configuration interfaces (**Configuration*)
for an abstract configuration.
Configuration schemas:
{code:java}
@AbstractConfiguration
public class BaseConfigurationSchema {
@Value
public int size;
}
@Config
public class VolatileConfigurationSchema extends BaseConfigurationSchema {
@Value
public double evictionThreshold;
}
{code}
Configuration interfaces:
{code:java}
public interface BaseConfiguration extends ConfigurationTree {
ConfigurationValue size();
}
public interface VolatileConfiguration extends BaseConfiguration {
ConfigurationValue size();
}
{code}
> Improve the usability of the abstract configuration interface
> -
>
> Key: IGNITE-17199
> URL: https://issues.apache.org/jira/browse/IGNITE-17199
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: iep-55, ignite-3
> Fix For: 3.0.0-alpha6
>
>
> *Problem*
> Consider an example of generating configuration interfaces (**Configuration*)
> for an abstract configuration.
> Configuration schemas:
> {code:java}
> @AbstractConfiguration
> public class BaseConfigurationSchema {
> @Value
> public int size;
> }
> @Config
> public class VolatileConfigurationSchema extends BaseConfigurationSchema {
> @Value
> public double evictionThreshold;
> }
> {code}
> Configuration interfaces:
> {code:java}
> public interface BaseConfiguration BaseChange> extends ConfigurationTree {
> ConfigurationValue size();
> }
> public interface VolatileConfiguration extends
> BaseConfiguration {
> ConfigurationValue size();
> }
> {code}
> This implementation allows us to work with the inheritors of the abstract
> configuration as with a regular configuration (as if
> *VolatileConfigurationSchema* did not extend *BaseConfigurationSchema*), but
> when working with the abstract configuration itself, it creates
> inconvenience.
> For example, to get a view of the abstract configuration, we will need to
> write the following code:
> {code:java}
> BaseConfiguration baseConfig0 = ...;
> BaseConfiguration baseConfig1 = ...;
>
> BaseView baseView0 = (BasePageMemoryDataRegionView) baseConfig0.value();
> BaseView baseView1 = baseConfig1.value();
> {code}
> Which is not convenient and I would like us to be able to work in the same
> way as with the *VolatileConfiguration*.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17199) Improve the usability of the abstract configuration interface
[
https://issues.apache.org/jira/browse/IGNITE-17199?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17199:
-
Description:
*Problem*
Consider an example of generating configuration interfaces (**Configuration*)
for an abstract configuration.
Configuration schemas:
{code:java}
@AbstractConfiguration
public class BaseConfigurationSchema {
@Value
public int size;
}
@Config
public class VolatileConfigurationSchema extends BaseConfigurationSchema {
@Value
public double evictionThreshold;
}
{code}
Configuration interfaces:
{code:java}
public interface BaseConfiguration extends ConfigurationTree {
ConfigurationValue size();
}
public interface VolatileConfiguration extends BaseConfiguration {
ConfigurationValue size();
}
{code}
was:
*Problem*
Consider an example of generating configuration interfaces (**Configuration*)
for an abstract configuration.
Configuration schemas:
{code:java}
@AbstractConfiguration
public class BasePageMemoryDataRegionConfigurationSchema {
@Value
public int size;
}
@Config
public class VolatilePageMemoryDataRegionConfigurationSchema extends
BasePageMemoryDataRegionConfigurationSchema {
@Value
public double evictionThreshold;
}
{code}
Configuration interfaces:
{code:java}
public interface BasePageMemoryDataRegionConfiguration
extends ConfigurationTree {
ConfigurationValue size();
}
public interface VolatilePageMemoryDataRegionConfiguration extends
BasePageMemoryDataRegionConfiguration {
ConfigurationValue size();
}
{code}
> Improve the usability of the abstract configuration interface
> -
>
> Key: IGNITE-17199
> URL: https://issues.apache.org/jira/browse/IGNITE-17199
> Project: Ignite
> Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: iep-55, ignite-3
> Fix For: 3.0.0-alpha6
>
>
> *Problem*
> Consider an example of generating configuration interfaces (**Configuration*)
> for an abstract configuration.
> Configuration schemas:
> {code:java}
> @AbstractConfiguration
> public class BaseConfigurationSchema {
> @Value
> public int size;
> }
> @Config
> public class VolatileConfigurationSchema extends BaseConfigurationSchema {
> @Value
> public double evictionThreshold;
> }
> {code}
> Configuration interfaces:
> {code:java}
> public interface BaseConfiguration BaseChange> extends ConfigurationTree {
> ConfigurationValue size();
> }
> public interface VolatileConfiguration extends
> BaseConfiguration {
> ConfigurationValue size();
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Created] (IGNITE-17199) Improve the usability of the abstract configuration interface
Kirill Tkalenko created IGNITE-17199:
Summary: Improve the usability of the abstract configuration
interface
Key: IGNITE-17199
URL: https://issues.apache.org/jira/browse/IGNITE-17199
Project: Ignite
Issue Type: Improvement
Reporter: Kirill Tkalenko
Assignee: Kirill Tkalenko
Fix For: 3.0.0-alpha6
*Problem*
Consider an example of generating configuration interfaces (**Configuration*)
for an abstract configuration.
Configuration schemas:
{code:java}
@AbstractConfiguration
public class BasePageMemoryDataRegionConfigurationSchema {
@Value
public int size;
}
@Config
public class VolatilePageMemoryDataRegionConfigurationSchema extends
BasePageMemoryDataRegionConfigurationSchema {
@Value
public double evictionThreshold;
}
{code}
Configuration interfaces:
{code:java}
public interface BasePageMemoryDataRegionConfiguration
extends ConfigurationTree {
ConfigurationValue size();
}
public interface VolatilePageMemoryDataRegionConfiguration extends
BasePageMemoryDataRegionConfiguration {
ConfigurationValue size();
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Assigned] (IGNITE-17143) Review and rewrite rebalance document according to the last rebalance logic updates
[ https://issues.apache.org/jira/browse/IGNITE-17143?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mirza Aliev reassigned IGNITE-17143: Assignee: Mirza Aliev > Review and rewrite rebalance document according to the last rebalance logic > updates > --- > > Key: IGNITE-17143 > URL: https://issues.apache.org/jira/browse/IGNITE-17143 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Assignee: Mirza Aliev >Priority: Major > Labels: ignite-3 > > Under IGNITE-14209 we made some rebalance protocol updates and it needs to > update the document -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-17142) Docs: Review the AI 3.0.0 Alpha 5 documentation
[ https://issues.apache.org/jira/browse/IGNITE-17142?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17556391#comment-17556391 ] Petr Ivanov commented on IGNITE-17142: -- Merged to main. Thanks for contribution! > Docs: Review the AI 3.0.0 Alpha 5 documentation > --- > > Key: IGNITE-17142 > URL: https://issues.apache.org/jira/browse/IGNITE-17142 > Project: Ignite > Issue Type: Task > Components: documentation >Affects Versions: 3.0.0-alpha5 >Reporter: Nikita A. Safonov >Assignee: Nikita A. Safonov >Priority: Major > Labels: documentation, ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > We need to check the new sections throughout the documentation. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (IGNITE-17089) Validate "node" option in "node config show" cmd
[
https://issues.apache.org/jira/browse/IGNITE-17089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vadim Pakhnushev resolved IGNITE-17089.
---
Resolution: Won't Fix
> Validate "node" option in "node config show" cmd
>
>
> Key: IGNITE-17089
> URL: https://issues.apache.org/jira/browse/IGNITE-17089
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr
>Priority: Major
> Labels: ignite-3, ignite-3-cli-tool
>
> Now {{ignite config show does not validate the passed node}} option. Add
> tests for this and impement the validation.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-15655) Random tests fail due to TimeoutException while waiting for a response
[
https://issues.apache.org/jira/browse/IGNITE-15655?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-15655:
-
Fix Version/s: 3.0.0-alpha6
> Random tests fail due to TimeoutException while waiting for a response
> --
>
> Key: IGNITE-15655
> URL: https://issues.apache.org/jira/browse/IGNITE-15655
> Project: Ignite
> Issue Type: Bug
>Reporter: Konstantin Orlov
>Assignee: Vyacheslav Koptilin
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
> Attachments: _Integration_Tests_Integration_Tests_3305.log.zip,
> _Integration_Tests_Integration_Tests_3322.log.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Problem
> Sometimes tests fails on main branch with an abstract "{{Caused by:
> java.util.concurrent.TimeoutException: Did not observe any item or terminal
> signal within 1000ms in 'source(MonoDefer)' (and no fallback has been
> configured)"}} reason.
> Need to investigate and fix the root cause of this fails.
>
> Test
> {{org.apache.ignite.internal.runner.app.ITSchemaChangeKVViewTest.testRenameColumn()}}
> in [^_Integration_Tests_Integration_Tests_3305.log.zip]
> Test
> {{org.apache.ignite.internal.runner.app.ITSchemaChangeKVViewTest.testMergeChangesAddDropAdd()}}
> in [^_Integration_Tests_Integration_Tests_3322.log.zip]
> h3. Upd 1
> Quick research revealed that the main reason for mentioned above
> _TimeoutException_ is a poor consistency of raft timeouts .
> Most of jraft timeouts are based on electionTimeoutMs.
> {code:java}
> // A follower would become a candidate if it doesn't receive any message
> // from the leader in |election_timeout_ms| milliseconds
> // Default: 1000 (1s)
> private int electionTimeoutMs = 1000; // follower to candidate timeout
> {code}
> For example both voteTime and electionTime use exact value of
> getElectionTimeoutMs (1000 ms):
> {code:java}
> String name = "JRaft-VoteTimer-" + suffix;
> this.voteTimer = new RepeatedTimer(name,
> options.getElectionTimeoutMs(), timerFactory.getVoteTimer(name)) {...};
> name = "JRaft-ElectionTimer-" + suffix;
> electionTimer = new RepeatedTimer(name,
> options.getElectionTimeoutMs(), timerFactory.getElectionTimer(name)) {...};
> {code}
> It actually means that Loza#TIMEOUT that was also initially set to 1000 ms
> just won't be enough in some cases. Seems that "operation timeout
> (LOZA#TIMEOUT)" should be an order of magnitude more than election timeout.
> During the implementation of [naive data
> rebalance|https://issues.apache.org/jira/browse/IGNITE-15491] LOZA#TIMEOUT
> was set to 10_000 to satisfy this need. Also a
> [ticket|https://issues.apache.org/jira/browse/IGNITE-15705] for timeouts
> research and consolidation was created.
> So, taking into consideration that raft operation timeout was already
> increased from 1 second to 10 it worth to just enable all tests that were
> disabled under IGNITE-15655 and check whether they are still failing.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-17148) Support for abstract configuration
[
https://issues.apache.org/jira/browse/IGNITE-17148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17556332#comment-17556332
]
Petr Ivanov commented on IGNITE-17148:
--
Merge to main. Thank you for contribution!
> Support for abstract configuration
> --
>
> Key: IGNITE-17148
> URL: https://issues.apache.org/jira/browse/IGNITE-17148
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: iep-55, ignite-3
> Fix For: 3.0.0-alpha6
>
> Time Spent: 10h 40m
> Remaining Estimate: 0h
>
> *NOTE*
> Description may not be complete.
> *Problem*
> We need the ability to create a basic configuration schema so that we can
> define a common configuration schema and inherit from it with additional
> configuration added.
> Let's look at an example:
> We need to create two configuration schemes for the PageMemory based storage
> engine, they should have a common property "page size in bytes" and then they
> should be different, let's sketch an example scheme.
> {code:java}
> public class BasePageMemoryStorageEngineConfigurationSchema {
> @Value(hasDefault = true)
> public int pageSize = 16 * 1024;
> }
> @ConfigurationRoot(rootName = "in-memory-page-memory", type = DISTRIBUTED)
> public class VolatilePageMemoryStorageEngineConfigurationSchema extends
> BasePageMemoryStorageEngineConfigurationSchema{
> @ConfigValue
> public VolatilePageMemoryDataRegionConfigurationSchema defaultRegion;
> @NamedConfigValue
> public VolatilePageMemoryDataRegionConfigurationSchema regions;
> }
> @ConfigurationRoot(rootName = "persistent-page-memory", type = DISTRIBUTED)
> public class PersistentPageMemoryStorageEngineConfigurationSchema extends
> BasePageMemoryStorageEngineConfigurationSchema{
> @ConfigValue
> public PersistentPageMemoryDataRegionConfigurationSchema defaultRegion;
> @NamedConfigValue
> public PersistentPageMemoryDataRegionConfigurationSchema regions;
> @ConfigValue
> public PageMemoryCheckpointConfigurationSchema checkpoint;
> }{code}
> How can we implement this at the moment:
> * internal extension of the configuration: then the user will not be able to
> see and change it - not suitable;
> * polymorphic configuration:
> ** by design, we cannot create root config schemas for polymorphic config or
> instances;
> ** by design, we can change the type of polymorphic configuration to any
> instance, we do not fix its type, which does not suit us;
> ** by design, we cannot expose a polymorphic instance as a configuration
> schema property;
> ** hocon will display the type of polymorphic configuration, which is not
> necessary in this case and will look a little strange.
> The possible options do not suit us, so I propose to add another solution.
> *Proposal*
> Add an abstract configuration schema from which we can inherit, add
> properties, but only its heirs could be used as properties of other
> configurations schemas or configuration roots. Unlike a polymorphic
> configuration, it will not store and display the type in hocon, and the type
> cannot be changed.
> The abstract configuration schema from which will be inherited will contain
> the annotation {*}@AbstractConfiguration{*}, and any successor must extend it
> and contain *@Config* or {*}@ConfigurationRoot{*}, consider examples:
> {code:java}
> @AbstractConfiguration
> public class BasePageMemoryStorageEngineConfigurationSchema {
> @Value(hasDefault = true)
> public int pageSize = 16 * 1024;
> }
> @ConfigurationRoot(rootName = "in-memory-page-memory", type = DISTRIBUTED)
> public class VolatilePageMemoryStorageEngineConfigurationSchema extends
> BasePageMemoryStorageEngineConfigurationSchema{
> @ConfigValue
> public VolatilePageMemoryDataRegionConfigurationSchema defaultRegion;
> @NamedConfigValue
> public VolatilePageMemoryDataRegionConfigurationSchema regions;
> }
> @Config
> public class PersistentPageMemoryStorageEngineConfigurationSchema extends
> BasePageMemoryStorageEngineConfigurationSchema{
> @ConfigValue
> public PersistentPageMemoryDataRegionConfigurationSchema defaultRegion;
> @NamedConfigValue
> public PersistentPageMemoryDataRegionConfigurationSchema regions;
> @ConfigValue
> public PageMemoryCheckpointConfigurationSchema checkpoint;
> }{code}
> *Implementation notes*
> # Add annotation
> *org.apache.ignite.configuration.annotation.AbstractConfiguration*;
> # Add processing to
> *org.apache.ignite.internal.configuration.processor.Processor*;
> # Add processing to
> *org.apache.ignite.internal.configuration.asm.ConfigurationAsmGenerator*;
> # Cover with tests.
> *Further development*
> * Consider the possibility and necessity of crossing with the
[jira] [Resolved] (IGNITE-15306) Change ignite cli command to support separate config commands for node/cluster
[ https://issues.apache.org/jira/browse/IGNITE-15306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vadim Pakhnushev resolved IGNITE-15306. --- Resolution: Fixed > Change ignite cli command to support separate config commands for node/cluster > -- > > Key: IGNITE-15306 > URL: https://issues.apache.org/jira/browse/IGNITE-15306 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-15655) Random tests fail due to TimeoutException while waiting for a response
[
https://issues.apache.org/jira/browse/IGNITE-15655?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17556324#comment-17556324
]
Vyacheslav Koptilin commented on IGNITE-15655:
--
Looks like we can unmute SQL tests based on test branch (which includes all SQL
related fixes)
https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_ModuleRunner?branch=%3Cdefault%3E=builds
> Random tests fail due to TimeoutException while waiting for a response
> --
>
> Key: IGNITE-15655
> URL: https://issues.apache.org/jira/browse/IGNITE-15655
> Project: Ignite
> Issue Type: Bug
>Reporter: Konstantin Orlov
>Assignee: Vyacheslav Koptilin
>Priority: Blocker
> Labels: ignite-3
> Attachments: _Integration_Tests_Integration_Tests_3305.log.zip,
> _Integration_Tests_Integration_Tests_3322.log.zip
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> h3. Problem
> Sometimes tests fails on main branch with an abstract "{{Caused by:
> java.util.concurrent.TimeoutException: Did not observe any item or terminal
> signal within 1000ms in 'source(MonoDefer)' (and no fallback has been
> configured)"}} reason.
> Need to investigate and fix the root cause of this fails.
>
> Test
> {{org.apache.ignite.internal.runner.app.ITSchemaChangeKVViewTest.testRenameColumn()}}
> in [^_Integration_Tests_Integration_Tests_3305.log.zip]
> Test
> {{org.apache.ignite.internal.runner.app.ITSchemaChangeKVViewTest.testMergeChangesAddDropAdd()}}
> in [^_Integration_Tests_Integration_Tests_3322.log.zip]
> h3. Upd 1
> Quick research revealed that the main reason for mentioned above
> _TimeoutException_ is a poor consistency of raft timeouts .
> Most of jraft timeouts are based on electionTimeoutMs.
> {code:java}
> // A follower would become a candidate if it doesn't receive any message
> // from the leader in |election_timeout_ms| milliseconds
> // Default: 1000 (1s)
> private int electionTimeoutMs = 1000; // follower to candidate timeout
> {code}
> For example both voteTime and electionTime use exact value of
> getElectionTimeoutMs (1000 ms):
> {code:java}
> String name = "JRaft-VoteTimer-" + suffix;
> this.voteTimer = new RepeatedTimer(name,
> options.getElectionTimeoutMs(), timerFactory.getVoteTimer(name)) {...};
> name = "JRaft-ElectionTimer-" + suffix;
> electionTimer = new RepeatedTimer(name,
> options.getElectionTimeoutMs(), timerFactory.getElectionTimer(name)) {...};
> {code}
> It actually means that Loza#TIMEOUT that was also initially set to 1000 ms
> just won't be enough in some cases. Seems that "operation timeout
> (LOZA#TIMEOUT)" should be an order of magnitude more than election timeout.
> During the implementation of [naive data
> rebalance|https://issues.apache.org/jira/browse/IGNITE-15491] LOZA#TIMEOUT
> was set to 10_000 to satisfy this need. Also a
> [ticket|https://issues.apache.org/jira/browse/IGNITE-15705] for timeouts
> research and consolidation was created.
> So, taking into consideration that raft operation timeout was already
> increased from 1 second to 10 it worth to just enable all tests that were
> disabled under IGNITE-15655 and check whether they are still failing.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17148) Support for abstract configuration
[
https://issues.apache.org/jira/browse/IGNITE-17148?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko updated IGNITE-17148:
-
Reviewer: Aleksandr Polovtcev
> Support for abstract configuration
> --
>
> Key: IGNITE-17148
> URL: https://issues.apache.org/jira/browse/IGNITE-17148
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: iep-55, ignite-3
> Fix For: 3.0.0-alpha6
>
> Time Spent: 10.5h
> Remaining Estimate: 0h
>
> *NOTE*
> Description may not be complete.
> *Problem*
> We need the ability to create a basic configuration schema so that we can
> define a common configuration schema and inherit from it with additional
> configuration added.
> Let's look at an example:
> We need to create two configuration schemes for the PageMemory based storage
> engine, they should have a common property "page size in bytes" and then they
> should be different, let's sketch an example scheme.
> {code:java}
> public class BasePageMemoryStorageEngineConfigurationSchema {
> @Value(hasDefault = true)
> public int pageSize = 16 * 1024;
> }
> @ConfigurationRoot(rootName = "in-memory-page-memory", type = DISTRIBUTED)
> public class VolatilePageMemoryStorageEngineConfigurationSchema extends
> BasePageMemoryStorageEngineConfigurationSchema{
> @ConfigValue
> public VolatilePageMemoryDataRegionConfigurationSchema defaultRegion;
> @NamedConfigValue
> public VolatilePageMemoryDataRegionConfigurationSchema regions;
> }
> @ConfigurationRoot(rootName = "persistent-page-memory", type = DISTRIBUTED)
> public class PersistentPageMemoryStorageEngineConfigurationSchema extends
> BasePageMemoryStorageEngineConfigurationSchema{
> @ConfigValue
> public PersistentPageMemoryDataRegionConfigurationSchema defaultRegion;
> @NamedConfigValue
> public PersistentPageMemoryDataRegionConfigurationSchema regions;
> @ConfigValue
> public PageMemoryCheckpointConfigurationSchema checkpoint;
> }{code}
> How can we implement this at the moment:
> * internal extension of the configuration: then the user will not be able to
> see and change it - not suitable;
> * polymorphic configuration:
> ** by design, we cannot create root config schemas for polymorphic config or
> instances;
> ** by design, we can change the type of polymorphic configuration to any
> instance, we do not fix its type, which does not suit us;
> ** by design, we cannot expose a polymorphic instance as a configuration
> schema property;
> ** hocon will display the type of polymorphic configuration, which is not
> necessary in this case and will look a little strange.
> The possible options do not suit us, so I propose to add another solution.
> *Proposal*
> Add an abstract configuration schema from which we can inherit, add
> properties, but only its heirs could be used as properties of other
> configurations schemas or configuration roots. Unlike a polymorphic
> configuration, it will not store and display the type in hocon, and the type
> cannot be changed.
> The abstract configuration schema from which will be inherited will contain
> the annotation {*}@AbstractConfiguration{*}, and any successor must extend it
> and contain *@Config* or {*}@ConfigurationRoot{*}, consider examples:
> {code:java}
> @AbstractConfiguration
> public class BasePageMemoryStorageEngineConfigurationSchema {
> @Value(hasDefault = true)
> public int pageSize = 16 * 1024;
> }
> @ConfigurationRoot(rootName = "in-memory-page-memory", type = DISTRIBUTED)
> public class VolatilePageMemoryStorageEngineConfigurationSchema extends
> BasePageMemoryStorageEngineConfigurationSchema{
> @ConfigValue
> public VolatilePageMemoryDataRegionConfigurationSchema defaultRegion;
> @NamedConfigValue
> public VolatilePageMemoryDataRegionConfigurationSchema regions;
> }
> @Config
> public class PersistentPageMemoryStorageEngineConfigurationSchema extends
> BasePageMemoryStorageEngineConfigurationSchema{
> @ConfigValue
> public PersistentPageMemoryDataRegionConfigurationSchema defaultRegion;
> @NamedConfigValue
> public PersistentPageMemoryDataRegionConfigurationSchema regions;
> @ConfigValue
> public PageMemoryCheckpointConfigurationSchema checkpoint;
> }{code}
> *Implementation notes*
> # Add annotation
> *org.apache.ignite.configuration.annotation.AbstractConfiguration*;
> # Add processing to
> *org.apache.ignite.internal.configuration.processor.Processor*;
> # Add processing to
> *org.apache.ignite.internal.configuration.asm.ConfigurationAsmGenerator*;
> # Cover with tests.
> *Further development*
> * Consider the possibility and necessity of crossing with the annotation
> *InternalConfiguration* and
[jira] [Assigned] (IGNITE-16870) Extend Schema with ability to specify function as default value generator
[
https://issues.apache.org/jira/browse/IGNITE-16870?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov reassigned IGNITE-16870:
-
Assignee: Konstantin Orlov
> Extend Schema with ability to specify function as default value generator
> -
>
> Key: IGNITE-16870
> URL: https://issues.apache.org/jira/browse/IGNITE-16870
> Project: Ignite
> Issue Type: New Feature
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
>
> In order to make IGNITE-16860 possible, we need to add an ability to specify
> a function as a default value generator. It worth to note, that a behaviour
> of KV API and SQL should be consistent, thus this feature should be derived
> from a SQL runtime to the common place.
> Within this task we need to extend {{ColumnConfigurationSchema}} in order to
> support several types of default value generators (constant and function for
> now), as well as introduce a new default value supplier for {{{}Column{}}}.
> As a first step, I would propose to support only a few predefined system
> functions. This could be possibly extended to support an arbitrary function
> though.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Commented] (IGNITE-17148) Support for abstract configuration
[
https://issues.apache.org/jira/browse/IGNITE-17148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17556322#comment-17556322
]
Aleksandr Polovtcev commented on IGNITE-17148:
--
Looks wonderful, thank you
> Support for abstract configuration
> --
>
> Key: IGNITE-17148
> URL: https://issues.apache.org/jira/browse/IGNITE-17148
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: iep-55, ignite-3
> Fix For: 3.0.0-alpha6
>
> Time Spent: 10.5h
> Remaining Estimate: 0h
>
> *NOTE*
> Description may not be complete.
> *Problem*
> We need the ability to create a basic configuration schema so that we can
> define a common configuration schema and inherit from it with additional
> configuration added.
> Let's look at an example:
> We need to create two configuration schemes for the PageMemory based storage
> engine, they should have a common property "page size in bytes" and then they
> should be different, let's sketch an example scheme.
> {code:java}
> public class BasePageMemoryStorageEngineConfigurationSchema {
> @Value(hasDefault = true)
> public int pageSize = 16 * 1024;
> }
> @ConfigurationRoot(rootName = "in-memory-page-memory", type = DISTRIBUTED)
> public class VolatilePageMemoryStorageEngineConfigurationSchema extends
> BasePageMemoryStorageEngineConfigurationSchema{
> @ConfigValue
> public VolatilePageMemoryDataRegionConfigurationSchema defaultRegion;
> @NamedConfigValue
> public VolatilePageMemoryDataRegionConfigurationSchema regions;
> }
> @ConfigurationRoot(rootName = "persistent-page-memory", type = DISTRIBUTED)
> public class PersistentPageMemoryStorageEngineConfigurationSchema extends
> BasePageMemoryStorageEngineConfigurationSchema{
> @ConfigValue
> public PersistentPageMemoryDataRegionConfigurationSchema defaultRegion;
> @NamedConfigValue
> public PersistentPageMemoryDataRegionConfigurationSchema regions;
> @ConfigValue
> public PageMemoryCheckpointConfigurationSchema checkpoint;
> }{code}
> How can we implement this at the moment:
> * internal extension of the configuration: then the user will not be able to
> see and change it - not suitable;
> * polymorphic configuration:
> ** by design, we cannot create root config schemas for polymorphic config or
> instances;
> ** by design, we can change the type of polymorphic configuration to any
> instance, we do not fix its type, which does not suit us;
> ** by design, we cannot expose a polymorphic instance as a configuration
> schema property;
> ** hocon will display the type of polymorphic configuration, which is not
> necessary in this case and will look a little strange.
> The possible options do not suit us, so I propose to add another solution.
> *Proposal*
> Add an abstract configuration schema from which we can inherit, add
> properties, but only its heirs could be used as properties of other
> configurations schemas or configuration roots. Unlike a polymorphic
> configuration, it will not store and display the type in hocon, and the type
> cannot be changed.
> The abstract configuration schema from which will be inherited will contain
> the annotation {*}@AbstractConfiguration{*}, and any successor must extend it
> and contain *@Config* or {*}@ConfigurationRoot{*}, consider examples:
> {code:java}
> @AbstractConfiguration
> public class BasePageMemoryStorageEngineConfigurationSchema {
> @Value(hasDefault = true)
> public int pageSize = 16 * 1024;
> }
> @ConfigurationRoot(rootName = "in-memory-page-memory", type = DISTRIBUTED)
> public class VolatilePageMemoryStorageEngineConfigurationSchema extends
> BasePageMemoryStorageEngineConfigurationSchema{
> @ConfigValue
> public VolatilePageMemoryDataRegionConfigurationSchema defaultRegion;
> @NamedConfigValue
> public VolatilePageMemoryDataRegionConfigurationSchema regions;
> }
> @Config
> public class PersistentPageMemoryStorageEngineConfigurationSchema extends
> BasePageMemoryStorageEngineConfigurationSchema{
> @ConfigValue
> public PersistentPageMemoryDataRegionConfigurationSchema defaultRegion;
> @NamedConfigValue
> public PersistentPageMemoryDataRegionConfigurationSchema regions;
> @ConfigValue
> public PageMemoryCheckpointConfigurationSchema checkpoint;
> }{code}
> *Implementation notes*
> # Add annotation
> *org.apache.ignite.configuration.annotation.AbstractConfiguration*;
> # Add processing to
> *org.apache.ignite.internal.configuration.processor.Processor*;
> # Add processing to
> *org.apache.ignite.internal.configuration.asm.ConfigurationAsmGenerator*;
> # Cover with tests.
> *Further development*
> * Consider the possibility and necessity of crossing with the
[jira] [Created] (IGNITE-17198) Prototype of pure in-memory storage (with in-memory RAFT)
Roman Puchkovskiy created IGNITE-17198: -- Summary: Prototype of pure in-memory storage (with in-memory RAFT) Key: IGNITE-17198 URL: https://issues.apache.org/jira/browse/IGNITE-17198 Project: Ignite Issue Type: New Feature Components: persistence Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy Fix For: 3.0.0-alpha6 This is about the simpliest case possible: stable topology, nodes never leave, corner cases are not handled. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (IGNITE-17012) Check if random tests failures because of TimeoutException is still reproducible
[
https://issues.apache.org/jira/browse/IGNITE-17012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17554486#comment-17554486
]
Vyacheslav Koptilin edited comment on IGNITE-17012 at 6/20/22 9:44 AM:
---
Tests cannot be unmuted until the following issues are resolved: IGNITE-17165
IGNITE-17169 IGNITE-17171
was (Author: slava.koptilin):
Test cannot be unmuted until the following issues are resolved: IGNITE-17165
IGNITE-17169 IGNITE-17171
> Check if random tests failures because of TimeoutException is still
> reproducible
> -
>
> Key: IGNITE-17012
> URL: https://issues.apache.org/jira/browse/IGNITE-17012
> Project: Ignite
> Issue Type: Task
>Reporter: Mirza Aliev
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Labels: ignite-3
>
> We have the umbrella ticket IGNITE-15655 where the problem of a random tests
> failures because of {{TimeoutException}} was introduced. A lot of problems
> was found when we investigated the issue, and most of them was fixed, so we
> propose to check if the problem is still reproducible.
> The actions that are proposed to do:
> 1 ) Unmute all tests that were disabled with IGNITE-15655 ticket
> 2) Check if they are reproducible with the same problem
> 3) Create new tickets for all found problems
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-16967) SQL API: Implement server-side query context.
[ https://issues.apache.org/jira/browse/IGNITE-16967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-16967: -- Fix Version/s: 3.0.0-alpha6 > SQL API: Implement server-side query context. > - > > Key: IGNITE-16967 > URL: https://issues.apache.org/jira/browse/IGNITE-16967 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > Time Spent: 20m > Remaining Estimate: 0h > > Implement server-side session management. > Avoid session parameters sending on each query start. > Close session on client disconnect. > Close queries when session has been closed. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17182) Sql. Wrong result of TYPEOF function
[
https://issues.apache.org/jira/browse/IGNITE-17182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-17182:
--
Fix Version/s: 3.0.0-alpha6
> Sql. Wrong result of TYPEOF function
>
>
> Key: IGNITE-17182
> URL: https://issues.apache.org/jira/browse/IGNITE-17182
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Konstantin Orlov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> The result of {{TYPEOF('a'::varchar(1))}} is {{CHAR}} instead of {{VARCHAR}}.
> Looks like the information about actual type is missed after fragment
> deserialisation.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17171) ItIndexSpoolTest fails when the number of rows is greater than 256
[
https://issues.apache.org/jira/browse/IGNITE-17171?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov updated IGNITE-17171:
--
Fix Version/s: 3.0.0-alpha6
> ItIndexSpoolTest fails when the number of rows is greater than 256
> --
>
> Key: IGNITE-17171
> URL: https://issues.apache.org/jira/browse/IGNITE-17171
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Konstantin Orlov
>Priority: Blocker
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> ItIndexSpoolTest fails when the number of table rows is greater than 256
> {noformat}
> java.lang.AssertionError:
> Expected: is <258>
> but: was <256>
>
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
> at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:6)
> at
> org.apache.ignite.internal.sql.engine.ItIndexSpoolTest.test(ItIndexSpoolTest.java:74)
> {noformat}
> Perhaps, batching does not work correctly.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17183) Sql. Test testCurrentDateTimeTimeStamp fails
[ https://issues.apache.org/jira/browse/IGNITE-17183?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov updated IGNITE-17183: -- Fix Version/s: 3.0.0-alpha6 > Sql. Test testCurrentDateTimeTimeStamp fails > > > Key: IGNITE-17183 > URL: https://issues.apache.org/jira/browse/IGNITE-17183 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Konstantin Orlov >Assignee: Konstantin Orlov >Priority: Blocker > Fix For: 3.0.0-alpha6 > > Time Spent: 10m > Remaining Estimate: 0h > > The problem caused by the test itself. Or, to be more precise, in converting > the date value to a string and then comparing. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17048) Some failing tests make other tests fail too
[ https://issues.apache.org/jira/browse/IGNITE-17048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-17048: - Fix Version/s: 3.0.0-alpha6 > Some failing tests make other tests fail too > > > Key: IGNITE-17048 > URL: https://issues.apache.org/jira/browse/IGNITE-17048 > Project: Ignite > Issue Type: Bug >Reporter: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > > Looks like after some tests fail, they do not correctly free the used ports, > because other tests start to fail with a "Failed to start the connection > manager: No available port in range [3346-3346]" message. > This error occurs due to previous test failing to stop a node with > AssertionError "Raft groups are still running > [602f614c-9d19-4467-bcdf-d248d9e3a410_part_1, > 602f614c-9d19-4467-bcdf-d248d9e3a410_part_0, > 602f614c-9d19-4467-bcdf-d248d9e3a410_part_6, > 602f614c-9d19-4467-bcdf-d248d9e3a410_part_4, > 602f614c-9d19-4467-bcdf-d248d9e3a410_part_3, > 602f614c-9d19-4467-bcdf-d248d9e3a410_part_8, > 602f614c-9d19-4467-bcdf-d248d9e3a410_part_7]" > Example of a failed build: > https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_RunAllTests/6583070 > A possible solution might be to create a diagnostics tool that will print the > name of the process that occupies the blocked port. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17197) Change the default storage engine (for tables)
[ https://issues.apache.org/jira/browse/IGNITE-17197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel updated IGNITE-17197: --- Description: Currently the default pagememory storage doesn't support MVCC. So it doesn't fit to the transaction protocol. Only RocksDbTableStorage supports now. So after RocksDbTableStorage was integrated in https://issues.apache.org/jira/browse/IGNITE-16881 the TablesConfigurationSchema#defaultDataStorage was set to "rocksdb" and some tests were disabled. Need to: # implement MvTableStorage and MvPartitionStorage by other storages. # set TablesConfigurationSchema#defaultDataStorage to "pagememory" or other storage. # enable tests marked by "IGNITE-17197" # check other places marked by IGNITE-17197" was: Only RocksDbTableStorage implements MvTableStorage now. So after RocksDbTableStorage was integrated in https://issues.apache.org/jira/browse/IGNITE-16881 the TablesConfigurationSchema#defaultDataStorage was set to "rocksdb" and some tests were disabled. Need to: # implement MvTableStorage and MvPartitionStorage by other storages. # set TablesConfigurationSchema#defaultDataStorage to "pagememory" # enable tests marked by "IGNITE-17197" # check other places marked by IGNITE-17197" Summary: Change the default storage engine (for tables) (was: Page memory storages are disabled now) > Change the default storage engine (for tables) > -- > > Key: IGNITE-17197 > URL: https://issues.apache.org/jira/browse/IGNITE-17197 > Project: Ignite > Issue Type: Task >Reporter: Sergey Uttsel >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > > Currently the default pagememory storage doesn't support MVCC. So it doesn't > fit to the transaction protocol. Only RocksDbTableStorage supports now. So > after RocksDbTableStorage was integrated in > https://issues.apache.org/jira/browse/IGNITE-16881 the > TablesConfigurationSchema#defaultDataStorage was set to "rocksdb" and some > tests were disabled. > Need to: > # implement MvTableStorage and MvPartitionStorage by other storages. > # set TablesConfigurationSchema#defaultDataStorage to "pagememory" or other > storage. > # enable tests marked by "IGNITE-17197" > # check other places marked by IGNITE-17197" -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17197) Page memory storages are disabled now
[ https://issues.apache.org/jira/browse/IGNITE-17197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-17197: - Epic Link: IGNITE-16851 > Page memory storages are disabled now > - > > Key: IGNITE-17197 > URL: https://issues.apache.org/jira/browse/IGNITE-17197 > Project: Ignite > Issue Type: Task >Reporter: Sergey Uttsel >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > > Only RocksDbTableStorage implements MvTableStorage now. So after > RocksDbTableStorage was integrated in > https://issues.apache.org/jira/browse/IGNITE-16881 the > TablesConfigurationSchema#defaultDataStorage was set to "rocksdb" and some > tests were disabled. > Need to: > # implement MvTableStorage and MvPartitionStorage by other storages. > # set TablesConfigurationSchema#defaultDataStorage to "pagememory" > # enable tests marked by "IGNITE-17197" > # check other places marked by IGNITE-17197" -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16881) Integrate MV-storage into current tx implementation
[ https://issues.apache.org/jira/browse/IGNITE-16881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-16881: - Labels: ignite-3 transaction3_rw (was: ignite-3) > Integrate MV-storage into current tx implementation > --- > > Key: IGNITE-16881 > URL: https://issues.apache.org/jira/browse/IGNITE-16881 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3, transaction3_rw > Time Spent: 4h 40m > Remaining Estimate: 0h > > VersionedRowStore contract is replaced with new MV-storage API that should be > used inside tx protocol instead of old VersionedRowStore one. > Tx.Phase1 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16892) Update lock manager in order to soupport S, X and I locks.
[ https://issues.apache.org/jira/browse/IGNITE-16892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-16892: - Labels: ignite-3 transaction3_rw (was: ignite-3) > Update lock manager in order to soupport S, X and I locks. > -- > > Key: IGNITE-16892 > URL: https://issues.apache.org/jira/browse/IGNITE-16892 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3, transaction3_rw > > Tx.Phase1 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16894) Adjust already implemented RW tx protocol in order to match new one
[ https://issues.apache.org/jira/browse/IGNITE-16894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-16894: - Labels: ignite-3 transaction3_rw (was: ignite-3) > Adjust already implemented RW tx protocol in order to match new one > --- > > Key: IGNITE-16894 > URL: https://issues.apache.org/jira/browse/IGNITE-16894 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3, transaction3_rw > > * Tx commit timestamp generation > * Partition enlistment > * Lock acquiring/release > * Intent resolution > * Commit/Abort > * Cleanup > Tx.Phase1 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17197) Page memory storages are disabled now
[ https://issues.apache.org/jira/browse/IGNITE-17197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-17197: - Fix Version/s: 3.0.0-alpha6 > Page memory storages are disabled now > - > > Key: IGNITE-17197 > URL: https://issues.apache.org/jira/browse/IGNITE-17197 > Project: Ignite > Issue Type: Task >Reporter: Sergey Uttsel >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > > Only RocksDbTableStorage implements MvTableStorage now. So after > RocksDbTableStorage was integrated in > https://issues.apache.org/jira/browse/IGNITE-16881 the > TablesConfigurationSchema#defaultDataStorage was set to "rocksdb" and some > tests were disabled. > Need to: > # implement MvTableStorage and MvPartitionStorage by other storages. > # set TablesConfigurationSchema#defaultDataStorage to "pagememory" > # enable tests marked by "IGNITE-17197" > # check other places marked by IGNITE-17197" -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-15931) Implement storage for tx states
[ https://issues.apache.org/jira/browse/IGNITE-15931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-15931: - Labels: ignite-3 transaction3_rw (was: ignite-3) > Implement storage for tx states > --- > > Key: IGNITE-15931 > URL: https://issues.apache.org/jira/browse/IGNITE-15931 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Scherbakov >Priority: Major > Labels: ignite-3, transaction3_rw > > Currently tx states [1] are stored in memory and will be lost on node > failure, but they shouldn't. > Need to store states in the Storage (similar to PartitionStorage). > [1] org.apache.ignite.internal.tx.impl.TxManagerImpl#states > Tx.Phase1 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-15931) Implement storage for tx states
[ https://issues.apache.org/jira/browse/IGNITE-15931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-15931: - Ignite Flags: (was: Docs Required,Release Notes Required) > Implement storage for tx states > --- > > Key: IGNITE-15931 > URL: https://issues.apache.org/jira/browse/IGNITE-15931 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Scherbakov >Priority: Major > Labels: ignite-3, transaction3_rw > > Currently tx states [1] are stored in memory and will be lost on node > failure, but they shouldn't. > Need to store states in the Storage (similar to PartitionStorage). > [1] org.apache.ignite.internal.tx.impl.TxManagerImpl#states > Tx.Phase1 -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-17197) Page memory storages are disabled now
[ https://issues.apache.org/jira/browse/IGNITE-17197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-17197: - Ignite Flags: (was: Docs Required,Release Notes Required) > Page memory storages are disabled now > - > > Key: IGNITE-17197 > URL: https://issues.apache.org/jira/browse/IGNITE-17197 > Project: Ignite > Issue Type: Task >Reporter: Sergey Uttsel >Priority: Major > Labels: ignite-3 > > Only RocksDbTableStorage implements MvTableStorage now. So after > RocksDbTableStorage was integrated in > https://issues.apache.org/jira/browse/IGNITE-16881 the > TablesConfigurationSchema#defaultDataStorage was set to "rocksdb" and some > tests were disabled. > Need to: > # implement MvTableStorage and MvPartitionStorage by other storages. > # set TablesConfigurationSchema#defaultDataStorage to "pagememory" > # enable tests marked by "IGNITE-17197" > # check other places marked by IGNITE-17197" -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16882) Enlist txnState into single parition only
[
https://issues.apache.org/jira/browse/IGNITE-16882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-16882:
-
Labels: ignite-3 transaction3_rw (was: ignite-3)
> Enlist txnState into single parition only
> -
>
> Key: IGNITE-16882
> URL: https://issues.apache.org/jira/browse/IGNITE-16882
> Project: Ignite
> Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
> Labels: ignite-3, transaction3_rw
>
> Currenlly txState(PENDING|ABORTED|COMMITED) is updated within all enlisted
> partitions which is not an atomic solution. According to new tx design it's
> required to replicate tx state with single partition only.
> As a prerequisite persisted replicated TxnStateStore should be introduced
> https://issues.apache.org/jira/browse/IGNITE-15931
> Such introduction will allow to rework existing tx implementaiton in order to
> store txState only within single partition.
> instead of using
> {code:java}
> partId = abs(txId.hashCode() % partCnt) {code}
> we might use any other idempotent funtion, e.g. first partition of first
> enlisted key.
> Tx.Phase1
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Updated] (IGNITE-17197) Page memory storages are disabled now
[ https://issues.apache.org/jira/browse/IGNITE-17197?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Uttsel updated IGNITE-17197: --- Description: Only RocksDbTableStorage implements MvTableStorage now. So after RocksDbTableStorage was integrated in https://issues.apache.org/jira/browse/IGNITE-16881 the TablesConfigurationSchema#defaultDataStorage was set to "rocksdb" and some tests were disabled. Need to: # implement MvTableStorage and MvPartitionStorage by other storages. # set TablesConfigurationSchema#defaultDataStorage to "pagememory" # enable tests marked by "IGNITE-17197" # check other places marked by IGNITE-17197" was: Only RocksDbTableStorage implements MvTableStorage now. So after RocksDbTableStorage was integrated in https://issues.apache.org/jira/browse/IGNITE-16881 the TablesConfigurationSchema#defaultDataStorage was set to "rocksdb" and some tests were disabled. Need to: # implement MvTableStorage and MvPartitionStorage by other storages. # set TablesConfigurationSchema#defaultDataStorage to "pagememory" # enable tests marked by "IGNITE-" # check other places marked by IGNITE- > Page memory storages are disabled now > - > > Key: IGNITE-17197 > URL: https://issues.apache.org/jira/browse/IGNITE-17197 > Project: Ignite > Issue Type: Task >Reporter: Sergey Uttsel >Priority: Major > Labels: ignite-3 > > Only RocksDbTableStorage implements MvTableStorage now. So after > RocksDbTableStorage was integrated in > https://issues.apache.org/jira/browse/IGNITE-16881 the > TablesConfigurationSchema#defaultDataStorage was set to "rocksdb" and some > tests were disabled. > Need to: > # implement MvTableStorage and MvPartitionStorage by other storages. > # set TablesConfigurationSchema#defaultDataStorage to "pagememory" > # enable tests marked by "IGNITE-17197" > # check other places marked by IGNITE-17197" -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-17197) Page memory storages are disabled now
Sergey Uttsel created IGNITE-17197: -- Summary: Page memory storages are disabled now Key: IGNITE-17197 URL: https://issues.apache.org/jira/browse/IGNITE-17197 Project: Ignite Issue Type: Task Reporter: Sergey Uttsel Only RocksDbTableStorage implements MvTableStorage now. So after RocksDbTableStorage was integrated in https://issues.apache.org/jira/browse/IGNITE-16881 the TablesConfigurationSchema#defaultDataStorage was set to "rocksdb" and some tests were disabled. Need to: # implement MvTableStorage and MvPartitionStorage by other storages. # set TablesConfigurationSchema#defaultDataStorage to "pagememory" # enable tests marked by "IGNITE-" # check other places marked by IGNITE- -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (IGNITE-17149) Separation of the PageMemoryStorageEngineConfigurationSchema into in-memory and persistent
[
https://issues.apache.org/jira/browse/IGNITE-17149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kirill Tkalenko reassigned IGNITE-17149:
Assignee: Kirill Tkalenko
> Separation of the PageMemoryStorageEngineConfigurationSchema into in-memory
> and persistent
> --
>
> Key: IGNITE-17149
> URL: https://issues.apache.org/jira/browse/IGNITE-17149
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>
> *Problem*
> At the moment, the
> *org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
> contains configuration for in-memory and persistent
> *org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema*,
> which can be inconvenient for the user for several reasons:
> * *PageMemoryDataRegionConfigurationSchema* contains the configuration for
> in-memory and the persistent case, which can be confusing because it's not
> obvious which properties to set for each;
> * User does not have the ability to set a different size
> *PageMemoryStorageEngineConfigurationSchema#pageSize* for in-memory and the
> persistent case;
> * When creating a table through SQL, it would be more convenient for the
> user to simply specify the engine and use the default region than specify the
> data region, let's look at the examples.
> {code:java}
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
> dataRegion='in-memory'
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE pagememory
> dataRegion='persistnet'{code}
> {code:java}
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
> in-memory-pagememory
> CREATE TABLE user (id INT PRIMARY KEY, name VARCHAR(255)) ENGINE
> persistnet-pagememory
> {code}
> *Implementation proposal*
> Divide by two (in-memory and persistent):
> *
> *org.apache.ignite.internal.pagememory.configuration.schema.PageMemoryDataRegionConfigurationSchema*
> *
> *org.apache.ignite.internal.storage.pagememory.configuration.schema.PageMemoryStorageEngineConfigurationSchema*
> * *org.apache.ignite.internal.storage.pagememory.PageMemoryStorageEngine*
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
[jira] [Resolved] (IGNITE-17164) Absorb RAFT/in-memory/rebalance details
[ https://issues.apache.org/jira/browse/IGNITE-17164?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy resolved IGNITE-17164. Resolution: Done > Absorb RAFT/in-memory/rebalance details > --- > > Key: IGNITE-17164 > URL: https://issues.apache.org/jira/browse/IGNITE-17164 > Project: Ignite > Issue Type: Task > Components: persistence >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > > There is a design described in IGNITE-16668. > To implement the required changes, it is required to read the RAFT paper, see > what problems it can cause for volatile cases and how the proposed design > solves the problems with the rebalance in volatile RAFT cases. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-17196) Implement in-memory raft group reconfiguration on node failure
Roman Puchkovskiy created IGNITE-17196: -- Summary: Implement in-memory raft group reconfiguration on node failure Key: IGNITE-17196 URL: https://issues.apache.org/jira/browse/IGNITE-17196 Project: Ignite Issue Type: Improvement Components: persistence Reporter: Roman Puchkovskiy Fix For: 3.0.0-alpha6 We need to implement design described in IGNITE-16668 -- This message was sent by Atlassian Jira (v8.20.7#820007)
