[jira] [Updated] (IGNITE-14184) API for off-line update of configuration
[ https://issues.apache.org/jira/browse/IGNITE-14184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-14184: --- Parent: (was: IGNITE-13511) Issue Type: Improvement (was: Sub-task) > API for off-line update of configuration > > > Key: IGNITE-14184 > URL: https://issues.apache.org/jira/browse/IGNITE-14184 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Chugunov >Priority: Major > Labels: iep-55 > > Tools like new CLI may include ability to view/change existing configuration > without starting Ignite nodes. > This may also be useful in Ignite version upgrade scenarios. > Configuration module should support this case with all validations and other > functionality. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13842) Creating the new configuration on old cluster
[ https://issues.apache.org/jira/browse/IGNITE-13842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-13842: --- Parent: (was: IGNITE-13511) Issue Type: Improvement (was: Sub-task) > Creating the new configuration on old cluster > - > > Key: IGNITE-13842 > URL: https://issues.apache.org/jira/browse/IGNITE-13842 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Kalashnikov >Priority: Major > Labels: iep-55 > > Do we need the ability to create a new configuration/property on the working > cluster? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13843) Wrapper/Converter for primitive configuration
[ https://issues.apache.org/jira/browse/IGNITE-13843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-13843: --- Parent: (was: IGNITE-13511) Issue Type: Improvement (was: Sub-task) > Wrapper/Converter for primitive configuration > -- > > Key: IGNITE-13843 > URL: https://issues.apache.org/jira/browse/IGNITE-13843 > Project: Ignite > Issue Type: Improvement >Reporter: Anton Kalashnikov >Priority: Major > Labels: iep-55 > > Do we need the ability to use complex type such InternetAddress as wrapper of > some string property? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14645) Support polymorphic configuration nodes.
[
https://issues.apache.org/jira/browse/IGNITE-14645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-14645:
---
Parent: (was: IGNITE-13511)
Issue Type: Improvement (was: Sub-task)
> Support polymorphic configuration nodes.
>
>
> Key: IGNITE-14645
> URL: https://issues.apache.org/jira/browse/IGNITE-14645
> Project: Ignite
> Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: iep-55, ignite-3
>
> NOTE: description might not be finished.
> h3. Problem
> Currently configuration schema structure is very restricted and doesn't allow
> any variations in it. This approach comes with a set of problems.
> # How do you properly configure {{IpFinder}}? For each type of finder you
> only need a few properties.
> # How do you configure SQL indexes? Pretty much the same problem.
> h3. Interface
> For the solution we need to expand abilities of configuration schemas. I
> propose the following option:
> {code:java}
> // Configuration schema that contains polymorphic field.
> @Config
> class TableConfigurationSchema {
> @NamedConfigValue
> public IndexConfigurationSchema indexes;
> }
> // Base class for polymorphic value. Explicitly has all subclasses
> // in its description to simplify incremental code generation.
> //TODO: Maybe we cab avoid this part by using "originating elements" in
> annotation processing,
> // we'll check that during POC phase.
> @PolymorphicConfig(impl = {
> HashIndexConfigurationSchema.class,
> TreeIndexConfigurationSchema.class,
> })
> class IndexConfigurationSchema {
> // This annotation shows that current field defines implementation.
> // Specific values are present in implementations declarations.
> @Id
> @Immutable
> @Value
> public String type;
> }
> // One of implementations for index. Id value is defined in annotation.
> @PolymorphicInstance(id = "hash")
> public static class HashIndexConfigurationSchema extends
> IndexConfigurationSchema {
> @Immutable
> @Value
> public String column;
> }
> // Other implementation for index.
> @PolymorphicInstance(id = "tree")
> public static class TreeIndexConfigurationSchema extends
> IndexConfigurationSchema {
> @Immutable
> @Value
> public String[] columns;
> }
> {code}
> h3. Generated API
> We need to tweak API a little bit. I'd love to see as few changes as
> possible, so my vision is something like this:
> {code:java}
> TableConfiguration tableCfg = ...;
> tableCfg.indexes().create("hashIndexName", index ->
> // Id sets up automatically by the call.
> index.asHashIndex().changeColumn("columnName")
> ).get();
> tableCfg.indexes().update("hashIndexName", index ->
> // Any cast is allowed to do in change request.
> // But this update will fail during processing.
> index.asTreeIndex().changeColumns("a", "b")
> );
> IndexConfiguration indexCfg = tableCfg.indexes().get("hashIndexName");
> // This must be an instance of "HashIndexConfiguration".
> HashIndexConfiguration hashCfg = (HashIndexConfiguration)indexCfg;
> // This must be instance of HashIndexView,
> IndexView indexView = indexCfg.value();
> // Maybe this is redundant, I don't know.
> assert indexView.isHashIndex();
> // Returns the same object with a safe cast.
> // Maybe this is redundant as well and regular cast would be enough.
> HashIndexView hashView = indexView.asHashIndex();{code}
> h3. Implementation Notes
> There are quite a few places that need to be tweaked here. First of all,
> let's examine {{ConfigurationImpl}} classes:
>
> {code:java}
> // Let's assume for a moment that "index" is not a named list, this is more
> convenient for current example.
> final class TableConfigurationImpl extends DynamicConfiguration TableChange> implements TableConfiguration {
> // Polymorphic fields won't be final anymore.
> private IndexConfigurationImpl index;
> public TableConfigurationImpl(List prefix, String key, RootKey ?> rootKey, ConfigurationChanger changer) {
> super(prefix, key, rootKey, changer);
> // No more "add" method invocations. "members" becomes mutable
> collections.
> // There's no point in making specific code generation for the
> situation when it's static.
> }
> @Override public final IndexConfiguration index() {
> // It's important to note that we can't just read field content
> because its type might have been changed.
> // This scenario was impossible before polymorphic types.
> refreshValue();
> return index;
> }
> @Override protected final synchronized void beforeRefreshValue(IndexView
> newValue) {
> // New value must be reinstantiated if its type changed.
> }
> @Override public Ma
[jira] [Updated] (IGNITE-13738) Document the new configuration format
[ https://issues.apache.org/jira/browse/IGNITE-13738?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-13738: --- Parent: (was: IGNITE-13511) Issue Type: Task (was: Sub-task) > Document the new configuration format > - > > Key: IGNITE-13738 > URL: https://issues.apache.org/jira/browse/IGNITE-13738 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Valentin Kulichenko >Assignee: Nikita Safonov >Priority: Major > Labels: iep-55, ignite-3 > > IEP: > [https://cwiki.apache.org/confluence/display/IGNITE/IEP-55+Unified+Configuration] > Need to create a documentation page describing formats supported by the new > configuration engine (HOCON, Properties, JSON) and the currently available > parameters. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15047) Support internal/private properties in configuration framework
[
https://issues.apache.org/jira/browse/IGNITE-15047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-15047:
---
Description:
In order to provide consistent update of configuration and metastorage metadata
we should have configuration values that are hidden form the user.
Requirements are:
* these configuration values should be available from internal code only
* they should not be accessible in JSON or any other configuration view
representation
* they can't be updated via CLI's HOCON update requests or any other public
API calls
One possible solution is to have configuration schema extensions, registered in
"internal" modules - they'll lead to generation of extended VIEW and CHANGE
interfaces. All extra fields from these schemas will be marked as internal by
configuration framework, technically it is possible.
h3. API notes
I think it would be convenient to have explicit internal configuration
extensions like these:
{code:java}
@InternalConfigurationExtension
public class ExtendedConfigurationSchema extends PublicConfigurationSchema {
// fields
}{code}
There has to be some "extension descriptor", like a "RootKey", that should be
passed into configuration manager constructor (or registered in it by some
other means before component's start). It should have at least the information
about the schema that it extends.
Following restriction has to be applied:
* There cannot be multiple extensions for the same schema. It is possible to
avoid this restriction but it would lead to unnecessary complications (like in
polymorphic schemas, that would probably complicate such approach even more:
IGNITE-14645).
There's also no point in having extension in the same module. Maybe we should
validate this fact.
Every {{FooConfiguration}} object must in fact be an instance of
{{InternalFooConfiguration}} as well. Same applies to {{*View}} and {{*Change}}
interfaces. There's no way that it's possible to design API where its user
won't have to perform explicit type casts, so this solution looks fine.
h3. Implementation notes
First of all, annotation processor will be expanded. I suppose that
{{@InternalConfigurationExtension}} will be the only addition to public
configuration-api module, everything else will be hidden in implementation
packages.
Traversal / construction API will be expanded as well. I guess that adding a
{{internal}} flag to a bunch of method will be enough. Having two sets of
methods for {{all}} and {{public}} would just be too much.
After these methods are changed, {{ConfigurationAsmGenerator}} and a lot of
their usages will have to be fixed. I suspect that most changes will be here
and in tests.
was:
In order to provide consistent update of configuration and metastorage metadata
we should have configuration values that are hidden form the user.
Requirements are:
* these configuration values should be available from internal code only
* they should not be accessible in JSON or any other configuration view
representation
* they can't be updated via CLI's HOCON update requests or any other public
API calls
One possible solution is to have configuration schema extensions, registered in
"internal" modules - they'll lead to generation of extended VIEW and CHANGE
interfaces. All extra fields from these schemas will be marked as internal by
configuration framework, technically it is possible.
h3. API notes
> Support internal/private properties in configuration framework
> --
>
> Key: IGNITE-15047
> URL: https://issues.apache.org/jira/browse/IGNITE-15047
> Project: Ignite
> Issue Type: Task
>Reporter: Ivan Bessonov
>Priority: Major
> Labels: iep-55, ignite-3
>
> In order to provide consistent update of configuration and metastorage
> metadata we should have configuration values that are hidden form the user.
> Requirements are:
> * these configuration values should be available from internal code only
> * they should not be accessible in JSON or any other configuration view
> representation
> * they can't be updated via CLI's HOCON update requests or any other public
> API calls
> One possible solution is to have configuration schema extensions, registered
> in "internal" modules - they'll lead to generation of extended VIEW and
> CHANGE interfaces. All extra fields from these schemas will be marked as
> internal by configuration framework, technically it is possible.
> h3. API notes
> I think it would be convenient to have explicit internal configuration
> extensions like these:
> {code:java}
> @InternalConfigurationExtension
> public class ExtendedConfigurationSchema extends PublicConfigurationSchema {
> // fields
> }{code}
> There has to be some "extension descriptor", like a "RootKey", that sh
[jira] [Updated] (IGNITE-15286) Code style improvement.
[
https://issues.apache.org/jira/browse/IGNITE-15286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-15286:
---
Ignite Flags: (was: Docs Required,Release Notes Required)
> Code style improvement.
> ---
>
> Key: IGNITE-15286
> URL: https://issues.apache.org/jira/browse/IGNITE-15286
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Mashenkov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> We have a requirement to the imports order in our code-style guide,
> but checkstyle plugin has no rules configured.
> Let's turn on these checks with the code below..
> Also, let's add Idea codestyle config to the project as it is in Ignite 2.
> {code:java}
>
>
>
> value="STANDARD_JAVA_PACKAGE###SPECIAL_IMPORTS###THIRD_PARTY_PACKAGE###STATIC"/>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-15286) Code style improvement.
[
https://issues.apache.org/jira/browse/IGNITE-15286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov reassigned IGNITE-15286:
--
Assignee: Ivan Bessonov
> Code style improvement.
> ---
>
> Key: IGNITE-15286
> URL: https://issues.apache.org/jira/browse/IGNITE-15286
> Project: Ignite
> Issue Type: Improvement
>Reporter: Andrey Mashenkov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> We have a requirement to the imports order in our code-style guide,
> but checkstyle plugin has no rules configured.
> Let's turn on these checks with the code below..
> Also, let's add Idea codestyle config to the project as it is in Ignite 2.
> {code:java}
>
>
>
> value="STANDARD_JAVA_PACKAGE###SPECIAL_IMPORTS###THIRD_PARTY_PACKAGE###STATIC"/>
>
>
>
>
>
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15047) Support internal/private properties in configuration framework
[ https://issues.apache.org/jira/browse/IGNITE-15047?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-15047: --- Description: In order to provide consistent update of configuration and metastorage metadata we should have configuration values that are hidden form the user. Requirements are: * these configuration values should be available from internal code only * they should not be accessible in JSON or any other configuration view representation * they can't be updated via CLI's HOCON update requests or any other public API calls One possible solution is to have configuration schema extensions, registered in "internal" modules - they'll lead to generation of extended VIEW and CHANGE interfaces. All extra fields from these schemas will be marked as internal by configuration framework, technically it is possible. h3. API notes was: In order to provide consistent update of configuration and metastorage metadata we should have configuration values that are hidden form the user. Requirements are: * these configuration values should be available from internal code only * they should not be accessible in JSON or any other configuration view representation * they can't be updated via CLI's HOCON update requests or any other public API calls One possible solution is to have configuration schema extensions, registered in "internal" modules - they'll lead to generation of extended VIEW and CHANGE interfaces. All extra fields from these schemas will be marked as internal by configuration framework, technically it is possible. > Support internal/private properties in configuration framework > -- > > Key: IGNITE-15047 > URL: https://issues.apache.org/jira/browse/IGNITE-15047 > Project: Ignite > Issue Type: Task >Reporter: Ivan Bessonov >Priority: Major > Labels: iep-55, ignite-3 > > In order to provide consistent update of configuration and metastorage > metadata we should have configuration values that are hidden form the user. > Requirements are: > * these configuration values should be available from internal code only > * they should not be accessible in JSON or any other configuration view > representation > * they can't be updated via CLI's HOCON update requests or any other public > API calls > One possible solution is to have configuration schema extensions, registered > in "internal" modules - they'll lead to generation of extended VIEW and > CHANGE interfaces. All extra fields from these schemas will be marked as > internal by configuration framework, technically it is possible. > h3. API notes > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15193) Some notifications are lost in configuration listeners.
[
https://issues.apache.org/jira/browse/IGNITE-15193?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17397189#comment-17397189
]
Ivan Bessonov commented on IGNITE-15193:
Merged to main branch
> Some notifications are lost in configuration listeners.
> ---
>
> Key: IGNITE-15193
> URL: https://issues.apache.org/jira/browse/IGNITE-15193
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha2
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: iep-55, ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> Consider following test: ConfigurationListenerTest#dataRace()
> {code:java}
> /** */
> @Test
> public void dataRace() throws Exception {
> configuration.change(parent -> parent.changeElements(elements ->
> elements.create("name", e -> {}))
> ).get(1, SECONDS);
> List log = new CopyOnWriteArrayList<>();
> configuration.elements().get("name").listen(ctx -> {
> assertNull(ctx.newValue());
> log.add("deleted");
> return completedFuture(null);
> });
> configuration.change(parent -> parent.changeElements(elements ->
> elements.delete("name"))
> ).get(1, SECONDS);
> assertEquals(List.of("deleted"), log);
> }
> {code}
> It fails due to wrong configuration access in ConfigurationNotificationsUtil.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15174) Fix javadoc in Network module.
[
https://issues.apache.org/jira/browse/IGNITE-15174?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-15174:
---
Reviewer: Ivan Bessonov
> Fix javadoc in Network module.
> --
>
> Key: IGNITE-15174
> URL: https://issues.apache.org/jira/browse/IGNITE-15174
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Mashenkov
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Let's fix Javadoc styles regarding the policy.
> Startpoint is to remove modules from excludes
> {noformat}
> ./check-rules/checkstyle-disabled-modules.xml
> {noformat}
> and run
> {code:java}
> mvn clean checkstyle:checkstyle-aggregate -P javadoc-public-api
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15275) Server handshake process is incorrect
[ https://issues.apache.org/jira/browse/IGNITE-15275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-15275: --- Affects Version/s: 3.0.0-alpha2 > Server handshake process is incorrect > - > > Key: IGNITE-15275 > URL: https://issues.apache.org/jira/browse/IGNITE-15275 > Project: Ignite > Issue Type: Bug > Components: networking >Affects Versions: 3.0.0-alpha2 >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Labels: iep-67, ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 0.5h > Remaining Estimate: 0h > > At this moment, NettyServer uses one handshake manager for all incoming > connections which can result in the following: the first message from the > server to a client can be sent to a different node than expected. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15275) Server handshake process is incorrect
[ https://issues.apache.org/jira/browse/IGNITE-15275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-15275: --- Labels: iep-67 ignite-3 (was: ignite-3) > Server handshake process is incorrect > - > > Key: IGNITE-15275 > URL: https://issues.apache.org/jira/browse/IGNITE-15275 > Project: Ignite > Issue Type: Bug > Components: networking >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Labels: iep-67, ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 0.5h > Remaining Estimate: 0h > > At this moment, NettyServer uses one handshake manager for all incoming > connections which can result in the following: the first message from the > server to a client can be sent to a different node than expected. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15275) Server handshake process is incorrect
[ https://issues.apache.org/jira/browse/IGNITE-15275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-15275: --- Ignite Flags: (was: Docs Required,Release Notes Required) > Server handshake process is incorrect > - > > Key: IGNITE-15275 > URL: https://issues.apache.org/jira/browse/IGNITE-15275 > Project: Ignite > Issue Type: Bug > Components: networking >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 0.5h > Remaining Estimate: 0h > > At this moment, NettyServer uses one handshake manager for all incoming > connections which can result in the following: the first message from the > server to a client can be sent to a different node than expected. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15275) Server handshake process is incorrect
[ https://issues.apache.org/jira/browse/IGNITE-15275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-15275: --- Component/s: networking > Server handshake process is incorrect > - > > Key: IGNITE-15275 > URL: https://issues.apache.org/jira/browse/IGNITE-15275 > Project: Ignite > Issue Type: Bug > Components: networking >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Labels: ignite-3 > Time Spent: 20m > Remaining Estimate: 0h > > At this moment, NettyServer uses one handshake manager for all incoming > connections which can result in the following: the first message from the > server to a client can be sent to a different node than expected. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15275) Server handshake process is incorrect
[ https://issues.apache.org/jira/browse/IGNITE-15275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-15275: --- Fix Version/s: 3.0.0-alpha3 > Server handshake process is incorrect > - > > Key: IGNITE-15275 > URL: https://issues.apache.org/jira/browse/IGNITE-15275 > Project: Ignite > Issue Type: Bug > Components: networking >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 0.5h > Remaining Estimate: 0h > > At this moment, NettyServer uses one handshake manager for all incoming > connections which can result in the following: the first message from the > server to a client can be sent to a different node than expected. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15275) Server handshake process is incorrect
[ https://issues.apache.org/jira/browse/IGNITE-15275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-15275: --- Reviewer: Aleksandr Polovtcev > Server handshake process is incorrect > - > > Key: IGNITE-15275 > URL: https://issues.apache.org/jira/browse/IGNITE-15275 > Project: Ignite > Issue Type: Bug > Components: networking >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 0.5h > Remaining Estimate: 0h > > At this moment, NettyServer uses one handshake manager for all incoming > connections which can result in the following: the first message from the > server to a client can be sent to a different node than expected. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15285) Properly split two ConfigurationManager instances
Ivan Bessonov created IGNITE-15285:
--
Summary: Properly split two ConfigurationManager instances
Key: IGNITE-15285
URL: https://issues.apache.org/jira/browse/IGNITE-15285
Project: Ignite
Issue Type: Improvement
Affects Versions: 3.0.0-alpha2
Reporter: Ivan Bessonov
Assignee: Kirill Tkalenko
Fix For: 3.0.0-alpha3
Currently you can see "WARNING: Configuration listener has already been set."
message on node start. That's not good, it means that one of configuration
managers reuses the same storages and it doesn't work. It's a bad design and
leads to weird bugs and unpredictable system behavior.
The reason is this line of code:
{code:java}
cfgStorages.add(new DistributedConfigurationStorage(metaStorageMgr, vaultMgr));
{code}
What's need to be done is changing ConfigurationManager constructor so that it
only takes one storage, not the list. Such decision will lead to two major
consequences:
* REST module will have to deal with two ConfigurationManager instances. It's
challenging to understand in advance the exact instance that it should use.
Valid behavior should be discussed during implementation.
* Classes like ConfigurationRegistry and ConfigurationChanger operate with
collections of storages. They should be refactored.
Validators instances will probably be duplicated in both managers. It's hard to
avoid duplication if we don't have ConfigurationManagerFactory or something,
but having factory to create two well know instances is an overkill. Anyway,
some approaches for deduplication should be discussed during implementation as
well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14790) Replace a storage map in RAFT partition listener to the persistence storage
[
https://issues.apache.org/jira/browse/IGNITE-14790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-14790:
---
Ignite Flags: (was: Docs Required,Release Notes Required)
> Replace a storage map in RAFT partition listener to the persistence storage
> ---
>
> Key: IGNITE-14790
> URL: https://issues.apache.org/jira/browse/IGNITE-14790
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Semyon Danilov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> The map is using as a temporary solution until storage will be implemented.
> Here we need to implement the RAFT listener through the persistent layer:
> {code:java}
> /**
> * Storage.
> * This is a temporary solution, it will apply until persistence layer
> would not be implemented.
> * TODO: Replace in the future.
> */
> private ConcurrentHashMap storage = new
> ConcurrentHashMap<>();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14790) Replace a storage map in RAFT partition listener to the persistence storage
[
https://issues.apache.org/jira/browse/IGNITE-14790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-14790:
---
Labels: ignite-3 (was: )
> Replace a storage map in RAFT partition listener to the persistence storage
> ---
>
> Key: IGNITE-14790
> URL: https://issues.apache.org/jira/browse/IGNITE-14790
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Semyon Danilov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 2.5h
> Remaining Estimate: 0h
>
> The map is using as a temporary solution until storage will be implemented.
> Here we need to implement the RAFT listener through the persistent layer:
> {code:java}
> /**
> * Storage.
> * This is a temporary solution, it will apply until persistence layer
> would not be implemented.
> * TODO: Replace in the future.
> */
> private ConcurrentHashMap storage = new
> ConcurrentHashMap<>();
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15158) Integration Tests logs are too big
[ https://issues.apache.org/jira/browse/IGNITE-15158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-15158: --- Fix Version/s: 3.0.0-alpha3 > Integration Tests logs are too big > -- > > Key: IGNITE-15158 > URL: https://issues.apache.org/jira/browse/IGNITE-15158 > Project: Ignite > Issue Type: Improvement >Affects Versions: 3.0.0-alpha2 >Reporter: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > > Logs for integration tests exceed 60 Mb already, this is not ok. It's > impossible to attach full build log to the Jira issue for further > investigation, for example. > > Link to the suite: > https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_IntegrationTests?branch=%3Cdefault%3E&buildTypeTab=overview&mode=builds#all-projects -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15273) Triple flushing of meta information at the checkpoint
[ https://issues.apache.org/jira/browse/IGNITE-15273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17396466#comment-17396466 ] Ivan Bessonov commented on IGNITE-15273: [~ktkale...@gridgain.com] thank you for the fix, I'll merge it! > Triple flushing of meta information at the checkpoint > - > > Key: IGNITE-15273 > URL: https://issues.apache.org/jira/browse/IGNITE-15273 > Project: Ignite > Issue Type: Bug > Components: persistence >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.12 > > Time Spent: 10m > Remaining Estimate: 0h > > At the moment, I found that at the checkpoint, the meta information is > flushed three times, which is redundant and will not give a performance gain. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14956) Implement and check scenarios for startup configuration
[
https://issues.apache.org/jira/browse/IGNITE-14956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17396448#comment-17396448
]
Ivan Bessonov commented on IGNITE-14956:
Looks good now, thank you everyone!
> Implement and check scenarios for startup configuration
> ---
>
> Key: IGNITE-14956
> URL: https://issues.apache.org/jira/browse/IGNITE-14956
> Project: Ignite
> Issue Type: Sub-task
>Affects Versions: 3.0.0-alpha3
>Reporter: Aleksandr Polovtcev
>Assignee: Vladislav Pyatkov
>Priority: Minor
> Labels: ignite-3
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> Let's rename Vault's {{bootstrapped}} method to {{bootstrappedWithPDS}} or
> rename to {{initialized()}} and change the logic in the following way:
> * returns true if was deployed atop PDS with some configuration included;
> * returns true if it was bootstrapped with user bootstrap configuration;
> * returns true if there was no user bootstrap configuration and the default
> one was used.
> Seems that the second option is better.
> *UPD:*
> After talking about initial configuration, we made a decision to change the
> term a bootstrap configuration to a startup configuration.
> The startup configuration will be able to be provided each time when the node
> starts.
> When the startup configuration was presented, it overwrites stored state if
> it existed (restart scenario), otherwise it applied with defaults (first
> start).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15269) Get rid of JSON code in configuration module
Ivan Bessonov created IGNITE-15269: -- Summary: Get rid of JSON code in configuration module Key: IGNITE-15269 URL: https://issues.apache.org/jira/browse/IGNITE-15269 Project: Ignite Issue Type: Improvement Affects Versions: 3.0.0-alpha2 Reporter: Ivan Bessonov Fix For: 3.0.0-alpha3 Right now we have a duplicated logic in configuration framework for HOCON and JSON text representations. Given that HOCON is the extension of JSON format, it can both parse and produce valid JSON representation. This means that classes like JsonConfigurationVisitor and others are not required anymore and can be deleted. There's only one problem here: REST code that uses JSON conversion is not covered with tests. We have to be sure that it won't be broken after the change. Maybe write our own tests. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-13837) Configuration initialization
[ https://issues.apache.org/jira/browse/IGNITE-13837?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov resolved IGNITE-13837. Resolution: Duplicate Replaced by other issues with more specific descriptions that are already in process or even completed. > Configuration initialization > > > Key: IGNITE-13837 > URL: https://issues.apache.org/jira/browse/IGNITE-13837 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Kalashnikov >Assignee: Ivan Bessonov >Priority: Major > Labels: iep-55 > Time Spent: 0.5h > Remaining Estimate: 0h > > It needs to think how the first initialization of node/cluster should look > like. What is the format of initial properties(json/hocon etc.)? How should > they be handled? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Resolved] (IGNITE-14118) Add converter of key-value configuration to traversable tree
[ https://issues.apache.org/jira/browse/IGNITE-14118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov resolved IGNITE-14118. Resolution: Duplicate Already done > Add converter of key-value configuration to traversable tree > > > Key: IGNITE-14118 > URL: https://issues.apache.org/jira/browse/IGNITE-14118 > Project: Ignite > Issue Type: Sub-task >Reporter: Semyon Danilov >Priority: Major > Labels: iep-55, ignite-3 > > We need to convert Map to TraversableTreeNode. > Also, don't forget to update ConfigurationChanger to initialize tree with > converted data from storage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14118) Add converter of key-value configuration to traversable tree
[ https://issues.apache.org/jira/browse/IGNITE-14118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-14118: --- Ignite Flags: (was: Docs Required,Release Notes Required) > Add converter of key-value configuration to traversable tree > > > Key: IGNITE-14118 > URL: https://issues.apache.org/jira/browse/IGNITE-14118 > Project: Ignite > Issue Type: Sub-task >Reporter: Semyon Danilov >Priority: Major > Labels: iep-55, ignite-3 > > We need to convert Map to TraversableTreeNode. > Also, don't forget to update ConfigurationChanger to initialize tree with > converted data from storage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14118) Add converter of key-value configuration to traversable tree
[ https://issues.apache.org/jira/browse/IGNITE-14118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-14118: --- Labels: iep-55 ignite-3 (was: iep-55) > Add converter of key-value configuration to traversable tree > > > Key: IGNITE-14118 > URL: https://issues.apache.org/jira/browse/IGNITE-14118 > Project: Ignite > Issue Type: Sub-task >Reporter: Semyon Danilov >Priority: Major > Labels: iep-55, ignite-3 > > We need to convert Map to TraversableTreeNode. > Also, don't forget to update ConfigurationChanger to initialize tree with > converted data from storage. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15264) DistributedConfigurationStorage violates MetaStorageManager watch contract
[
https://issues.apache.org/jira/browse/IGNITE-15264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-15264:
---
Summary: DistributedConfigurationStorage violates MetaStorageManager watch
contract (was: DistributedConfigurationStorage violates MetaStorage watch
contract)
> DistributedConfigurationStorage violates MetaStorageManager watch contract
> --
>
> Key: IGNITE-15264
> URL: https://issues.apache.org/jira/browse/IGNITE-15264
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha2
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: iep-55, ignite-3
> Fix For: 3.0.0-alpha3
>
>
> There are a few issues with the {{DistributedConfigurationStorage}} and
> related classes:
> * {{MetaStorageManager#DISTRIBUTED_PREFIX}} is located in the wrong class;
> * {{MetaStorageManager#APPLIED_REV}} constant should be changed;
> * {{DistributedConfigurationStorage#MASTER_KEY}} is confused with
> {{APPLIED_REV}} in some places, so
> {{DistributedConfigurationStorage#readAll}} returns god knows what;
> * watch callback in
> {{DistributedConfigurationStorage#registerConfigurationListener}} returns
> from {{onUpdate}} before notifications are processed.
> {{DistributedConfigurationStorage#notifyApplied}} doesn't work properly as
> well.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15264) DistributedConfigurationStorage violates MetaStorage watch contract
Ivan Bessonov created IGNITE-15264:
--
Summary: DistributedConfigurationStorage violates MetaStorage
watch contract
Key: IGNITE-15264
URL: https://issues.apache.org/jira/browse/IGNITE-15264
Project: Ignite
Issue Type: Bug
Affects Versions: 3.0.0-alpha2
Reporter: Ivan Bessonov
Assignee: Ivan Bessonov
Fix For: 3.0.0-alpha3
There are a few issues with the {{DistributedConfigurationStorage}} and related
classes:
* {{MetaStorageManager#DISTRIBUTED_PREFIX}} is located in the wrong class;
* {{MetaStorageManager#APPLIED_REV}} constant should be changed;
* {{DistributedConfigurationStorage#MASTER_KEY}} is confused with
{{APPLIED_REV}} in some places, so {{DistributedConfigurationStorage#readAll}}
returns god knows what;
* watch callback in
{{DistributedConfigurationStorage#registerConfigurationListener}} returns from
{{onUpdate}} before notifications are processed.
{{DistributedConfigurationStorage#notifyApplied}} doesn't work properly as well.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15262) Remove duplicated TestConfigurationStorage classes
[ https://issues.apache.org/jira/browse/IGNITE-15262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-15262: --- Fix Version/s: 3.0.0-alpha3 > Remove duplicated TestConfigurationStorage classes > -- > > Key: IGNITE-15262 > URL: https://issues.apache.org/jira/browse/IGNITE-15262 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: iep-55, ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently there are 6 classes called TestConfgurationStorage and they mostly > duplicate each other. We have to leave just one of them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15262) Remove duplicated TestConfigurationStorage classes
[ https://issues.apache.org/jira/browse/IGNITE-15262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-15262: --- Affects Version/s: 3.0.0-alpha2 > Remove duplicated TestConfigurationStorage classes > -- > > Key: IGNITE-15262 > URL: https://issues.apache.org/jira/browse/IGNITE-15262 > Project: Ignite > Issue Type: Improvement >Affects Versions: 3.0.0-alpha2 >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: iep-55, ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently there are 6 classes called TestConfgurationStorage and they mostly > duplicate each other. We have to leave just one of them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15262) Remove duplicated TestConfigurationStorage classes
Ivan Bessonov created IGNITE-15262: -- Summary: Remove duplicated TestConfigurationStorage classes Key: IGNITE-15262 URL: https://issues.apache.org/jira/browse/IGNITE-15262 Project: Ignite Issue Type: Improvement Reporter: Ivan Bessonov Assignee: Ivan Bessonov Currently there are 6 classes called TestConfgurationStorage and they mostly duplicate each other. We have to leave just one of them. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15257) ITNodeTest.testNodeTaskOverload is flaky
Ivan Bessonov created IGNITE-15257:
--
Summary: ITNodeTest.testNodeTaskOverload is flaky
Key: IGNITE-15257
URL: https://issues.apache.org/jira/browse/IGNITE-15257
Project: Ignite
Issue Type: Bug
Affects Versions: 3.0.0-alpha2
Reporter: Ivan Bessonov
Fix For: 3.0.0-alpha3
Test failed locally:
{code:java}
Aug 05, 2021 10:02:29 AM org.apache.ignite.lang.IgniteLogger logInternalAug 05,
2021 10:02:29 AM org.apache.ignite.lang.IgniteLogger logInternalINFO:
>>> Start test method: testNodeTaskOverload()Aug 05, 2021 10:02:29
AM org.apache.ignite.lang.IgniteLogger logInternalINFO: Connection created
[address=/0:0:0:0:0:0:0:0:5003]Aug 05, 2021 10:02:29 AM
org.apache.ignite.lang.IgniteLogger logInternalINFO: Node joined: ClusterNode
[id=5f83a413-f3b0-406f-93fd-74ecc2ee1370, name=127.0.1.1:5003,
address=127.0.1.1:5003]Aug 05, 2021 10:02:29 AM
org.apache.ignite.lang.IgniteLogger logInternalINFO: Topology snapshot
[nodes=1] ^-- ClusterNode [id=5f83a413-f3b0-406f-93fd-74ecc2ee1370,
name=127.0.1.1:5003, address=127.0.1.1:5003]Aug 05, 2021 10:02:30 AM
org.apache.ignite.lang.IgniteLogger logInternalINFO: Starts FSMCaller
successfully.Aug 05, 2021 10:02:30 AM org.apache.ignite.lang.IgniteLogger
logInternalWARNING: No data for snapshot reader
target/work/ITNodeTest/testNodeTaskOverload_1628146949951/snapshot.Aug 05, 2021
10:02:30 AM org.apache.ignite.lang.IgniteLogger logInternalINFO: Node
init, term=0, lastLogId=LogId [index=0, term=0],
conf=127.0.1.1:5003, oldConf=.Aug 05, 2021 10:02:30 AM
org.apache.ignite.lang.IgniteLogger logInternalINFO: Node
start vote and grant vote self, term=0.Aug 05, 2021
10:02:30 AM org.apache.ignite.lang.IgniteLogger logInternalINFO: Save raft
meta, path=target/work/ITNodeTest/testNodeTaskOverload_1628146949951/meta,
term=1, votedFor=127.0.1.1:5003, cost time=7 msAug 05, 2021 10:02:30 AM
org.apache.ignite.lang.IgniteLogger logInternalINFO: Node
become leader of group, term=1, conf=127.0.1.1:5003,
oldConf=.Aug 05, 2021 10:02:30 AM org.apache.ignite.lang.IgniteLogger
logInternalINFO: Start the RaftGroupService successfully
Aug 05, 2021 10:02:30 AM
org.apache.ignite.lang.IgniteLogger logInternalWARNING: Node
applyQueue is overload.Status[EBUSY<1009>: Node is
busy, has too many tasks.]Aug 05, 2021 10:02:30 AM
org.apache.ignite.lang.IgniteLogger logInternalINFO: onLeaderStart: term=1.Aug
05, 2021 10:02:30 AM org.apache.ignite.lang.IgniteLogger logInternalSEVERE:
Node append [2, 2] failed, status=Status[EIO<1014>:
Corrupted LogStorage].Aug 05, 2021 10:02:30 AM
org.apache.ignite.lang.IgniteLogger logInternalSEVERE: Encountered an
error=Status[EBUSY<1009>: LogManager is busy, disk queue overload.] on
StateMachine org.apache.ignite.raft.jraft.core.MockStateMachine, it's highly
recommended to implement this method as raft stops working since some error
occurs, you should figure out the cause and repair or remove this node.Error
[type=ERROR_TYPE_LOG, status=Status[EBUSY<1009>: LogManager is busy, disk queue
overload.]] at
org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.reportError(LogManagerImpl.java:577)Status[EBUSY<1009>:
Node is busy, has too many tasks.] at
org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.appendEntries(LogManagerImpl.java:332)
at
org.apache.ignite.raft.jraft.core.NodeImpl.executeApplyingTasks(NodeImpl.java:1371)
at
org.apache.ignite.raft.jraft.core.NodeImpl$LogEntryAndClosureHandler.onEvent(NodeImpl.java:292)
at
org.apache.ignite.raft.jraft.core.NodeImpl$LogEntryAndClosureHandler.onEvent(NodeImpl.java:275)
at
org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:214)
at
org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:179)
at com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:137) at
java.base/java.lang.Thread.run(Thread.java:829)
Aug 05, 2021 10:02:30 AM org.apache.ignite.lang.IgniteLogger
logInternalWARNING: Node got error: Error
[type=ERROR_TYPE_LOG, status=Status[EBUSY<1009>: LogManager is busy, disk queue
overload.]].Aug 05, 2021 10:02:30 AM org.apache.ignite.lang.IgniteLogger
warnWARNING: FSMCaller already in error status, ignore new errorError
[type=ERROR_TYPE_LOG, status=Status[EBUSY<1009>: LogManager is busy, disk queue
overload.]] at
org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.reportError(LogManagerImpl.java:577)
at
org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.appendEntries(LogManagerImpl.java:332)
at
org.apache.ignite.raft.jraft.core.NodeImpl.executeApplyingTasks(NodeImpl.java:1371)
at
org.apache.ignite.raft.jraft.core.NodeImpl$LogEntryAndClosureHandler.onEvent(NodeImpl.java:292)
at
org.apache.ignite.raft.jraft.core.NodeImpl$LogEntryAndClosureHandler.onEvent(NodeImpl.java:275)
at
org.apac
[jira] [Commented] (IGNITE-15246) Error when starting a node when exceeding the DataStorageConfiguration#getMaxWalArchiveSize
[ https://issues.apache.org/jira/browse/IGNITE-15246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17393637#comment-17393637 ] Ivan Bessonov commented on IGNITE-15246: [~ktkale...@gridgain.com] thank you for the improvement! I will merge it > Error when starting a node when exceeding the > DataStorageConfiguration#getMaxWalArchiveSize > --- > > Key: IGNITE-15246 > URL: https://issues.apache.org/jira/browse/IGNITE-15246 > Project: Ignite > Issue Type: Bug > Components: persistence >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.12 > > Time Spent: 10m > Remaining Estimate: 0h > > If the node starts with exceeding the > *DataStorageConfiguration#getMaxWalArchiveSize*, then during the recovery > phase of logical records there will be a segment reservation error, which > will not allow the node to start. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15243) Return the IGNITE_THRESHOLD_WAL_ARCHIVE_SIZE_PERCENTAGE and deprecate it
[ https://issues.apache.org/jira/browse/IGNITE-15243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17393267#comment-17393267 ] Ivan Bessonov commented on IGNITE-15243: [~ktkale...@gridgain.com] thank you for the contribution! Code looks good > Return the IGNITE_THRESHOLD_WAL_ARCHIVE_SIZE_PERCENTAGE and deprecate it > > > Key: IGNITE-15243 > URL: https://issues.apache.org/jira/browse/IGNITE-15243 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.12 > > Time Spent: 10m > Remaining Estimate: 0h > > For backward compatibility, return the > *IGNITE_THRESHOLD_WAL_ARCHIVE_SIZE_PERCENTAGE* and deprecate it, with the > following logic: > * If the user himself set the *DataStorageConfiguration#minWalArchiveSize*, > we take it; > * if *IGNITE_THRESHOLD_WAL_ARCHIVE_SIZE_PERCENTAGE* is set, we take it (with > standard checks for > 0 and < *DataStorageConfiguration#maxWalArchiveSize*); > * Otherwise, we take default > (*DataStorageConfiguration#HALF_MAX_WAL_ARCHIVE_SIZE*). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15193) Some notifications are lost in configuration listeners.
[
https://issues.apache.org/jira/browse/IGNITE-15193?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-15193:
---
Affects Version/s: 3.0.0-alpha2
> Some notifications are lost in configuration listeners.
> ---
>
> Key: IGNITE-15193
> URL: https://issues.apache.org/jira/browse/IGNITE-15193
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha2
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: iep-55, ignite-3
> Fix For: 3.0.0-alpha3
>
>
> Consider following test: ConfigurationListenerTest#dataRace()
> {code:java}
> /** */
> @Test
> public void dataRace() throws Exception {
> configuration.change(parent -> parent.changeElements(elements ->
> elements.create("name", e -> {}))
> ).get(1, SECONDS);
> List log = new CopyOnWriteArrayList<>();
> configuration.elements().get("name").listen(ctx -> {
> assertNull(ctx.newValue());
> log.add("deleted");
> return completedFuture(null);
> });
> configuration.change(parent -> parent.changeElements(elements ->
> elements.delete("name"))
> ).get(1, SECONDS);
> assertEquals(List.of("deleted"), log);
> }
> {code}
> It fails due to wrong configuration access in ConfigurationNotificationsUtil.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15098) testChangePeersChaosWithoutSnapshot is flaky
[ https://issues.apache.org/jira/browse/IGNITE-15098?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17391421#comment-17391421 ] Ivan Bessonov commented on IGNITE-15098: Failed during local build: [ERROR] org.apache.ignite.raft.jraft.core.ITNodeTest.testChangePeersChaosWithoutSnapshot Time elapsed: 14.722 s <<< FAILURE![ERROR] org.apache.ignite.raft.jraft.core.ITNodeTest.testChangePeersChaosWithoutSnapshot Time elapsed: 14.722 s <<< FAILURE!org.opentest4j.AssertionFailedError: expected: but was: at org.apache.ignite.raft.jraft.core.ITNodeTest.testChangePeersChaosWithoutSnapshot(ITNodeTest.java:3169) > testChangePeersChaosWithoutSnapshot is flaky > > > Key: IGNITE-15098 > URL: https://issues.apache.org/jira/browse/IGNITE-15098 > Project: Ignite > Issue Type: Task >Reporter: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > > https://ci.ignite.apache.org/viewLog.html?buildId=6079968&tab=buildResultsDiv&buildTypeId=ignite3_Test_IntegrationTests_IntegrationTests > org.opentest4j.AssertionFailedError: expected: but was: > at > org.apache.ignite.raft.jraft.core.ITNodeTest.testChangePeersChaosWithoutSnapshot(ITNodeTest.java:3174) > // assertTrue(done.await().isOk()); -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15213) StreamCorruptedException when running a node with an existing PDS
[
https://issues.apache.org/jira/browse/IGNITE-15213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-15213:
---
Labels: ignite-3 (was: )
> StreamCorruptedException when running a node with an existing PDS
> -
>
> Key: IGNITE-15213
> URL: https://issues.apache.org/jira/browse/IGNITE-15213
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When running an Ignite node with an existing PDS folder, the following
> exception is printed in the logs during configuration startup:
>
> {code:java}
> WARNING: Could not deserialize an object
> java.io.StreamCorruptedException: invalid stream header:
> at
> java.base/java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:940)
> at
> java.base/java.io.ObjectInputStream.(ObjectInputStream.java:379)
> at
> org.apache.ignite.internal.util.ByteUtils.fromBytes(ByteUtils.java:138)
> at
> org.apache.ignite.internal.storage.DistributedConfigurationStorage.readAll(DistributedConfigurationStorage.java:116)
> at
> org.apache.ignite.internal.configuration.ConfigurationChanger.register(ConfigurationChanger.java:193)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> at
> org.apache.ignite.internal.configuration.ConfigurationRegistry.start(ConfigurationRegistry.java:121)
> at
> org.apache.ignite.internal.configuration.ConfigurationManager.start(ConfigurationManager.java:73)
> at
> org.apache.ignite.internal.app.IgnitionImpl.doStartComponent(IgnitionImpl.java:418)
> at
> org.apache.ignite.internal.app.IgnitionImpl.doStart(IgnitionImpl.java:279)
> at
> org.apache.ignite.internal.app.IgnitionImpl.start(IgnitionImpl.java:133)
> at org.apache.ignite.app.IgnitionManager.start(IgnitionManager.java:64)
> at
> org.apache.ignite.example.table.KeyValueBinaryViewExample.main(KeyValueBinaryViewExample.java:46)
> {code}
> This error happens due to a bug in the {{DistributedConfigurationStorage}}:
> {{MASTER_KEY}}, that is used to store the configuration version, also happens
> to be the same as the key prefix in the metastore. This leads to confusion,
> for example, it is accidentally included in the data read from the vault in
> the {{readAll}} method, which leads to de-serialization errors.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15213) StreamCorruptedException when running a node with an existing PDS
[
https://issues.apache.org/jira/browse/IGNITE-15213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-15213:
---
Affects Version/s: 3.0.0-alpha2
> StreamCorruptedException when running a node with an existing PDS
> -
>
> Key: IGNITE-15213
> URL: https://issues.apache.org/jira/browse/IGNITE-15213
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha2
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> When running an Ignite node with an existing PDS folder, the following
> exception is printed in the logs during configuration startup:
>
> {code:java}
> WARNING: Could not deserialize an object
> java.io.StreamCorruptedException: invalid stream header:
> at
> java.base/java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:940)
> at
> java.base/java.io.ObjectInputStream.(ObjectInputStream.java:379)
> at
> org.apache.ignite.internal.util.ByteUtils.fromBytes(ByteUtils.java:138)
> at
> org.apache.ignite.internal.storage.DistributedConfigurationStorage.readAll(DistributedConfigurationStorage.java:116)
> at
> org.apache.ignite.internal.configuration.ConfigurationChanger.register(ConfigurationChanger.java:193)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> at
> org.apache.ignite.internal.configuration.ConfigurationRegistry.start(ConfigurationRegistry.java:121)
> at
> org.apache.ignite.internal.configuration.ConfigurationManager.start(ConfigurationManager.java:73)
> at
> org.apache.ignite.internal.app.IgnitionImpl.doStartComponent(IgnitionImpl.java:418)
> at
> org.apache.ignite.internal.app.IgnitionImpl.doStart(IgnitionImpl.java:279)
> at
> org.apache.ignite.internal.app.IgnitionImpl.start(IgnitionImpl.java:133)
> at org.apache.ignite.app.IgnitionManager.start(IgnitionManager.java:64)
> at
> org.apache.ignite.example.table.KeyValueBinaryViewExample.main(KeyValueBinaryViewExample.java:46)
> {code}
> This error happens due to a bug in the {{DistributedConfigurationStorage}}:
> {{MASTER_KEY}}, that is used to store the configuration version, also happens
> to be the same as the key prefix in the metastore. This leads to confusion,
> for example, it is accidentally included in the data read from the vault in
> the {{readAll}} method, which leads to de-serialization errors.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15213) StreamCorruptedException when running a node with an existing PDS
[
https://issues.apache.org/jira/browse/IGNITE-15213?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17390647#comment-17390647
]
Ivan Bessonov commented on IGNITE-15213:
Looks good, thank you for the contribution!
> StreamCorruptedException when running a node with an existing PDS
> -
>
> Key: IGNITE-15213
> URL: https://issues.apache.org/jira/browse/IGNITE-15213
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Fix For: 3.0.0-alpha3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> When running an Ignite node with an existing PDS folder, the following
> exception is printed in the logs during configuration startup:
>
> {code:java}
> WARNING: Could not deserialize an object
> java.io.StreamCorruptedException: invalid stream header:
> at
> java.base/java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:940)
> at
> java.base/java.io.ObjectInputStream.(ObjectInputStream.java:379)
> at
> org.apache.ignite.internal.util.ByteUtils.fromBytes(ByteUtils.java:138)
> at
> org.apache.ignite.internal.storage.DistributedConfigurationStorage.readAll(DistributedConfigurationStorage.java:116)
> at
> org.apache.ignite.internal.configuration.ConfigurationChanger.register(ConfigurationChanger.java:193)
> at java.base/java.util.ArrayList.forEach(ArrayList.java:1541)
> at
> org.apache.ignite.internal.configuration.ConfigurationRegistry.start(ConfigurationRegistry.java:121)
> at
> org.apache.ignite.internal.configuration.ConfigurationManager.start(ConfigurationManager.java:73)
> at
> org.apache.ignite.internal.app.IgnitionImpl.doStartComponent(IgnitionImpl.java:418)
> at
> org.apache.ignite.internal.app.IgnitionImpl.doStart(IgnitionImpl.java:279)
> at
> org.apache.ignite.internal.app.IgnitionImpl.start(IgnitionImpl.java:133)
> at org.apache.ignite.app.IgnitionManager.start(IgnitionManager.java:64)
> at
> org.apache.ignite.example.table.KeyValueBinaryViewExample.main(KeyValueBinaryViewExample.java:46)
> {code}
> This error happens due to a bug in the {{DistributedConfigurationStorage}}:
> {{MASTER_KEY}}, that is used to store the configuration version, also happens
> to be the same as the key prefix in the metastore. This leads to confusion,
> for example, it is accidentally included in the data read from the vault in
> the {{readAll}} method, which leads to de-serialization errors.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15202) ITNodeTest.readCommittedUserLog is flaky
[
https://issues.apache.org/jira/browse/IGNITE-15202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-15202:
---
Description:
[https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_IntegrationTests/6106062]
{code:java}
java.lang.IllegalStateException: No user log between index:1 and
last_applied_index:1
at
org.apache.ignite.raft.jraft.core.ITNodeTest.readCommittedUserLog(ITNodeTest.java:2728)
{code}
was:https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_IntegrationTests/6106062
> ITNodeTest.readCommittedUserLog is flaky
>
>
> Key: IGNITE-15202
> URL: https://issues.apache.org/jira/browse/IGNITE-15202
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 3.0.0-alpha2
>Reporter: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
> Attachments: ITNodeTest.readCommittedUserLog.log
>
>
> [https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_IntegrationTests/6106062]
> {code:java}
> java.lang.IllegalStateException: No user log between index:1 and
> last_applied_index:1
> at
> org.apache.ignite.raft.jraft.core.ITNodeTest.readCommittedUserLog(ITNodeTest.java:2728)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15202) ITNodeTest.readCommittedUserLog is flaky
[ https://issues.apache.org/jira/browse/IGNITE-15202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-15202: --- Description: https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_IntegrationTests/6106062 (was: [https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_RunAllTests/6106064?buildTab=dependencies&mode=list&state=failed&expandedTest=build%3A%28id%3A6106062%29%2Cid%3A184567#6106062|https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_IntegrationTests/6106062]) > ITNodeTest.readCommittedUserLog is flaky > > > Key: IGNITE-15202 > URL: https://issues.apache.org/jira/browse/IGNITE-15202 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-alpha2 >Reporter: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Attachments: ITNodeTest.readCommittedUserLog.log > > > https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_IntegrationTests/6106062 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15202) ITNodeTest.readCommittedUserLog is flaky
Ivan Bessonov created IGNITE-15202: -- Summary: ITNodeTest.readCommittedUserLog is flaky Key: IGNITE-15202 URL: https://issues.apache.org/jira/browse/IGNITE-15202 Project: Ignite Issue Type: Bug Affects Versions: 3.0.0-alpha2 Reporter: Ivan Bessonov Attachments: ITNodeTest.readCommittedUserLog.log [https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_RunAllTests/6106064?buildTab=dependencies&mode=list&state=failed&expandedTest=build%3A%28id%3A6106062%29%2Cid%3A184567#6106062|https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_IntegrationTests/6106062] -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15202) ITNodeTest.readCommittedUserLog is flaky
[ https://issues.apache.org/jira/browse/IGNITE-15202?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-15202: --- Attachment: ITNodeTest.readCommittedUserLog.log > ITNodeTest.readCommittedUserLog is flaky > > > Key: IGNITE-15202 > URL: https://issues.apache.org/jira/browse/IGNITE-15202 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-alpha2 >Reporter: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Attachments: ITNodeTest.readCommittedUserLog.log > > > https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_IntegrationTests/6106062 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15026) Remove storage of physical page ids in a DurableBackgroundCleanupIndexTreeTask
[
https://issues.apache.org/jira/browse/IGNITE-15026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17388096#comment-17388096
]
Ivan Bessonov commented on IGNITE-15026:
Merged to master branch. Thank you for the contribution!
> Remove storage of physical page ids in a DurableBackgroundCleanupIndexTreeTask
> --
>
> Key: IGNITE-15026
> URL: https://issues.apache.org/jira/browse/IGNITE-15026
> Project: Ignite
> Issue Type: Improvement
> Components: persistence, sql
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> DurableBackgroundCleanupIndexTreeTask does one bad thing - it stores page id
> into a logical metastorage record. BUT, there are no guarantees that this
> page exists in current checkpoint state on the storage device.
> Imagine that someone waits for checkpoint, then before the next checkpoint
> they create SQL index, then drop it and end the process with "kill -9".
> There's a chance that something like this could happen by accident.
> Then page id in DurableBackgroundCleanupIndexTreeTask will either point to a
> nonexistent page (trace 1) or to the existing page that has nothing to do
> with meta tree (trace 2).
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 4937
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.getStore(FilePageStoreManager.java:1085)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageReadWriteManagerImpl.read(PageReadWriteManagerImpl.java:65)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:510)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:871)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:697)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:686)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:185)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.acquirePage(BPlusTree.java:6061)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.destroyDownPages(BPlusTree.java:2607)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.destroy(BPlusTree.java:2555)
> at
> org.apache.ignite.internal.processors.query.h2.DurableBackgroundCleanupIndexTreeTask.execute(DurableBackgroundCleanupIndexTreeTask.java:231)
> at
> org.apache.ignite.internal.processors.localtask.DurableBackgroundTasksProcessor$1.body(DurableBackgroundTasksProcessor.java:121)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> {noformat}
> 4d11-9351-08a40b89548c
> java.lang.IllegalStateException: Failed to get page IO instance (page content
> is corrupted)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.io.IOVersions.forVersion(IOVersions.java:84)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.io.IOVersions.forPage(IOVersions.java:96)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2Tree.getMetaInfo(H2Tree.java:508)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2Tree.(H2Tree.java:240)
> at
> org.apache.ignite.internal.processors.query.h2.DurableBackgroundCleanupIndexTreeTask$H2TreeToDestroy.(DurableBackgroundCleanupIndexTreeTask.java:359)
> at
> org.apache.ignite.internal.processors.query.h2.DurableBackgroundCleanupIndexTreeTask.execute(DurableBackgroundCleanupIndexTreeTask.java:208)
> at
> org.apache.ignite.internal.processors.localtask.DurableBackgroundTasksProcessor$1.body(DurableBackgroundTasksProcessor.java:121)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15026) Remove storage of physical page ids in a DurableBackgroundCleanupIndexTreeTask
[
https://issues.apache.org/jira/browse/IGNITE-15026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-15026:
---
Release Note: Fixed possible failure of background cleanup of dropped SQL
indexes. (was: Fix background cleanup of SQL indexes.)
> Remove storage of physical page ids in a DurableBackgroundCleanupIndexTreeTask
> --
>
> Key: IGNITE-15026
> URL: https://issues.apache.org/jira/browse/IGNITE-15026
> Project: Ignite
> Issue Type: Improvement
> Components: persistence, sql
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> DurableBackgroundCleanupIndexTreeTask does one bad thing - it stores page id
> into a logical metastorage record. BUT, there are no guarantees that this
> page exists in current checkpoint state on the storage device.
> Imagine that someone waits for checkpoint, then before the next checkpoint
> they create SQL index, then drop it and end the process with "kill -9".
> There's a chance that something like this could happen by accident.
> Then page id in DurableBackgroundCleanupIndexTreeTask will either point to a
> nonexistent page (trace 1) or to the existing page that has nothing to do
> with meta tree (trace 2).
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 4937
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.getStore(FilePageStoreManager.java:1085)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageReadWriteManagerImpl.read(PageReadWriteManagerImpl.java:65)
> at
> org.apache.ignite.internal.processors.cache.persistence.file.FilePageStoreManager.read(FilePageStoreManager.java:510)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:871)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:697)
> at
> org.apache.ignite.internal.processors.cache.persistence.pagemem.PageMemoryImpl.acquirePage(PageMemoryImpl.java:686)
> at
> org.apache.ignite.internal.processors.cache.persistence.DataStructure.acquirePage(DataStructure.java:185)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.acquirePage(BPlusTree.java:6061)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.destroyDownPages(BPlusTree.java:2607)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.destroy(BPlusTree.java:2555)
> at
> org.apache.ignite.internal.processors.query.h2.DurableBackgroundCleanupIndexTreeTask.execute(DurableBackgroundCleanupIndexTreeTask.java:231)
> at
> org.apache.ignite.internal.processors.localtask.DurableBackgroundTasksProcessor$1.body(DurableBackgroundTasksProcessor.java:121)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> {noformat}
> 4d11-9351-08a40b89548c
> java.lang.IllegalStateException: Failed to get page IO instance (page content
> is corrupted)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.io.IOVersions.forVersion(IOVersions.java:84)
> at
> org.apache.ignite.internal.processors.cache.persistence.tree.io.IOVersions.forPage(IOVersions.java:96)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2Tree.getMetaInfo(H2Tree.java:508)
> at
> org.apache.ignite.internal.processors.query.h2.database.H2Tree.(H2Tree.java:240)
> at
> org.apache.ignite.internal.processors.query.h2.DurableBackgroundCleanupIndexTreeTask$H2TreeToDestroy.(DurableBackgroundCleanupIndexTreeTask.java:359)
> at
> org.apache.ignite.internal.processors.query.h2.DurableBackgroundCleanupIndexTreeTask.execute(DurableBackgroundCleanupIndexTreeTask.java:208)
> at
> org.apache.ignite.internal.processors.localtask.DurableBackgroundTasksProcessor$1.body(DurableBackgroundTasksProcessor.java:121)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:119)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15168) Investigate local dependency purge for always clean build
[ https://issues.apache.org/jira/browse/IGNITE-15168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-15168: --- Labels: ignite-3 (was: ) > Investigate local dependency purge for always clean build > - > > Key: IGNITE-15168 > URL: https://issues.apache.org/jira/browse/IGNITE-15168 > Project: Ignite > Issue Type: Improvement >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 0.5h > Remaining Estimate: 0h > > This plugin > [https://maven.apache.org/plugins/maven-dependency-plugin/purge-local-repository-mojo.html] > can remove internal module dependency artifacts from local repository in > order to use local resolution scope each time the project is being built, > thus, providing clean build without additional artifacts resolution or > downloading. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15168) Investigate local dependency purge for always clean build
[ https://issues.apache.org/jira/browse/IGNITE-15168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-15168: --- Ignite Flags: (was: Docs Required,Release Notes Required) > Investigate local dependency purge for always clean build > - > > Key: IGNITE-15168 > URL: https://issues.apache.org/jira/browse/IGNITE-15168 > Project: Ignite > Issue Type: Improvement >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > Fix For: 3.0.0-alpha3 > > Time Spent: 0.5h > Remaining Estimate: 0h > > This plugin > [https://maven.apache.org/plugins/maven-dependency-plugin/purge-local-repository-mojo.html] > can remove internal module dependency artifacts from local repository in > order to use local resolution scope each time the project is being built, > thus, providing clean build without additional artifacts resolution or > downloading. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15193) Some notifications are lost in configuration listeners.
Ivan Bessonov created IGNITE-15193:
--
Summary: Some notifications are lost in configuration listeners.
Key: IGNITE-15193
URL: https://issues.apache.org/jira/browse/IGNITE-15193
Project: Ignite
Issue Type: Bug
Reporter: Ivan Bessonov
Assignee: Ivan Bessonov
Fix For: 3.0.0-alpha3
Consider following test: ConfigurationListenerTest#dataRace()
{code:java}
/** */
@Test
public void dataRace() throws Exception {
configuration.change(parent -> parent.changeElements(elements ->
elements.create("name", e -> {}))
).get(1, SECONDS);
List log = new CopyOnWriteArrayList<>();
configuration.elements().get("name").listen(ctx -> {
assertNull(ctx.newValue());
log.add("deleted");
return completedFuture(null);
});
configuration.change(parent -> parent.changeElements(elements ->
elements.delete("name"))
).get(1, SECONDS);
assertEquals(List.of("deleted"), log);
}
{code}
It fails due to wrong configuration access in ConfigurationNotificationsUtil.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-15166) Support renaming in named list configuration elements
[
https://issues.apache.org/jira/browse/IGNITE-15166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov reassigned IGNITE-15166:
--
Assignee: Ivan Bessonov
> Support renaming in named list configuration elements
> -
>
> Key: IGNITE-15166
> URL: https://issues.apache.org/jira/browse/IGNITE-15166
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 3.0.0-alpha2
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: iep-55, ignite-3
>
> h3. Motivation
> Current NamedListChange API does not allow you to perform rename operation.
> Best that you can do is to manually copy the required element and then delete
> the original. This is bad for several reasons:
> * inconvenient both in Java API and CLI tool;
> * results in "onDelete" and "onCreate" events, which is probably not what
> people want.
> There must be a way to rename elements in Java API at least so that "ALTER
> ..." DDL command could be properly implemented.
> h3. Java API
> {{NamedListChange}} is a right place to add "rename" method. It should have
> two parameters and following restrictions:
> * "old" and "new" names are not null;
> * element with "old" name must exist;
> * element with "new" name must not exist.
> New method must be added {{to ConfigurationNamedListListener}}, named
> "onRename". It should have "onUpdate" semantics, but with two new parameters:
> "oldKey" and "newKey". Names are a subject to change.
> h3. CLI
> -This is a little less obvious since HOCON/JSON describe data, not
> operations. We already have specific syntax for "delete" operation. I suggest
> making "rename" look similar:-
> {code:java}
> root.namedList {
> oldName = newName
> }{code}
> -In short, now we can assign 3 things to the element:-
> * -regular composite object with its inner values;-
> * -"null" for deletion;-
> * -"String" for renaming.-
> HOCON/JSON format will have no alterations for this feature. DDL commands are
> to be used for these operations instead.
> h3. Implementation hints
> This will be similar to how we store ordering of named list elements. But
> this time we have to assign each element a unique identifier. This can be a
> String or a number. Laziest solution is to use UUID with hyphens removed from
> it. That'll do it.
> NamedListNode object will store these ids. In short, following algorithms
> will have to be altered:
> * conversion of update tree to the flat map - this one should be easy;
> * applying the flat map to the tree - a bit trickier. Matching from ids to
> keys will be required, we have to make sure that it won't cost too much;
> * matching old list with a new one to properly invoke listeners - should be
> partially solved by the code from the issue above, but still, might be tricky
> as well.
> -HOCON / JSON "parsers" will have to be altered as well to support "rename"
> operation. That should be easy.-
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15178) Add validation of MessageGroup IDs
[
https://issues.apache.org/jira/browse/IGNITE-15178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17386149#comment-17386149
]
Ivan Bessonov commented on IGNITE-15178:
Looks good, thank you for the contribution. Merged to main branch.
> Add validation of MessageGroup IDs
> --
>
> Key: IGNITE-15178
> URL: https://issues.apache.org/jira/browse/IGNITE-15178
> Project: Ignite
> Issue Type: Task
> Components: networking
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: iep-67, ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently message groups IDs are simply {{short}} values that are manually
> assigned to every module. This can lead to ID clashes which will lead to
> message handlers being invoked unexpectedly.
> We should find a way to validate group IDs across all modules. One way is to
> check that message group classes are the same when a handler is registered in
> the {{MessagingService}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15178) Add validation of MessageGroup IDs
[
https://issues.apache.org/jira/browse/IGNITE-15178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-15178:
---
Labels: iep-67 ignite-3 (was: ignite-3)
> Add validation of MessageGroup IDs
> --
>
> Key: IGNITE-15178
> URL: https://issues.apache.org/jira/browse/IGNITE-15178
> Project: Ignite
> Issue Type: Task
> Components: networking
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: iep-67, ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently message groups IDs are simply {{short}} values that are manually
> assigned to every module. This can lead to ID clashes which will lead to
> message handlers being invoked unexpectedly.
> We should find a way to validate group IDs across all modules. One way is to
> check that message group classes are the same when a handler is registered in
> the {{MessagingService}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15178) Add validation of MessageGroup IDs
[
https://issues.apache.org/jira/browse/IGNITE-15178?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-15178:
---
Labels: ignite-3 (was: )
> Add validation of MessageGroup IDs
> --
>
> Key: IGNITE-15178
> URL: https://issues.apache.org/jira/browse/IGNITE-15178
> Project: Ignite
> Issue Type: Task
> Components: networking
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Currently message groups IDs are simply {{short}} values that are manually
> assigned to every module. This can lead to ID clashes which will lead to
> message handlers being invoked unexpectedly.
> We should find a way to validate group IDs across all modules. One way is to
> check that message group classes are the same when a handler is registered in
> the {{MessagingService}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15149) Fix javadoc in Configuration module.
[
https://issues.apache.org/jira/browse/IGNITE-15149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-15149:
---
Reviewer: Aleksandr Polovtcev (was: Andrey Mashenkov)
> Fix javadoc in Configuration module.
>
>
> Key: IGNITE-15149
> URL: https://issues.apache.org/jira/browse/IGNITE-15149
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Mashenkov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Let's fix Javadoc styles regarding the policy.
> Startpoint is to remove modules from excludes
> {noformat}
> ./check-rules/checkstyle-disabled-modules.xml
> {noformat}
> and run
> {code:java}
> mvn clean checkstyle:checkstyle-aggregate -P javadoc-public-api
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-15149) Fix javadoc in Configuration module.
[
https://issues.apache.org/jira/browse/IGNITE-15149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov reassigned IGNITE-15149:
--
Assignee: Ivan Bessonov
> Fix javadoc in Configuration module.
>
>
> Key: IGNITE-15149
> URL: https://issues.apache.org/jira/browse/IGNITE-15149
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Mashenkov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> Let's fix Javadoc styles regarding the policy.
> Startpoint is to remove modules from excludes
> {noformat}
> ./check-rules/checkstyle-disabled-modules.xml
> {noformat}
> and run
> {code:java}
> mvn clean checkstyle:checkstyle-aggregate -P javadoc-public-api
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Resolved] (IGNITE-15172) Fix javadocs for configuration-api module
[ https://issues.apache.org/jira/browse/IGNITE-15172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov resolved IGNITE-15172. Resolution: Duplicate https://issues.apache.org/jira/browse/IGNITE-15149 > Fix javadocs for configuration-api module > - > > Key: IGNITE-15172 > URL: https://issues.apache.org/jira/browse/IGNITE-15172 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: iep-55, ignite-3 > Fix For: 3.0.0-alpha3 > > > Module has to be removed from exclusion list and fixed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15152) Fix javadoc in Api and Core modules.
[
https://issues.apache.org/jira/browse/IGNITE-15152?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17385381#comment-17385381
]
Ivan Bessonov commented on IGNITE-15152:
[~amashenkov] looks good, please proceed with merge!
> Fix javadoc in Api and Core modules.
>
>
> Key: IGNITE-15152
> URL: https://issues.apache.org/jira/browse/IGNITE-15152
> Project: Ignite
> Issue Type: Bug
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> Let's fix Javadoc styles regarding the policy.
> Startpoint is to remove modules from excludes and run
> {code:java}
> mvn clean checkstyle:checkstyle-aggregate -P javadoc-public-api
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15172) Fix javadocs for configuration-api module
Ivan Bessonov created IGNITE-15172: -- Summary: Fix javadocs for configuration-api module Key: IGNITE-15172 URL: https://issues.apache.org/jira/browse/IGNITE-15172 Project: Ignite Issue Type: Improvement Reporter: Ivan Bessonov Assignee: Ivan Bessonov Fix For: 3.0.0-alpha3 Module has to be removed from exclusion list and fixed. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15166) Support renaming in named list configuration elements
[
https://issues.apache.org/jira/browse/IGNITE-15166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-15166:
---
Description:
h3. Motivation
Current NamedListChange API does not allow you to perform rename operation.
Best that you can do is to manually copy the required element and then delete
the original. This is bad for several reasons:
* inconvenient both in Java API and CLI tool;
* results in "onDelete" and "onCreate" events, which is probably not what
people want.
There must be a way to rename elements in Java API at least so that "ALTER ..."
DDL command could be properly implemented.
h3. Java API
{{NamedListChange}} is a right place to add "rename" method. It should have two
parameters and following restrictions:
* "old" and "new" names are not null;
* element with "old" name must exist;
* element with "new" name must not exist.
New method must be added {{to ConfigurationNamedListListener}}, named
"onRename". It should have "onUpdate" semantics, but with two new parameters:
"oldKey" and "newKey". Names are a subject to change.
h3. CLI
-This is a little less obvious since HOCON/JSON describe data, not operations.
We already have specific syntax for "delete" operation. I suggest making
"rename" look similar:-
{code:java}
root.namedList {
oldName = newName
}{code}
-In short, now we can assign 3 things to the element:-
* -regular composite object with its inner values;-
* -"null" for deletion;-
* -"String" for renaming.-
HOCON/JSON format will have no alterations for this feature. DDL commands are
to be used for these operations instead.
h3. Implementation hints
This will be similar to how we store ordering of named list elements. But this
time we have to assign each element a unique identifier. This can be a String
or a number. Laziest solution is to use UUID with hyphens removed from it.
That'll do it.
NamedListNode object will store these ids. In short, following algorithms will
have to be altered:
* conversion of update tree to the flat map - this one should be easy;
* applying the flat map to the tree - a bit trickier. Matching from ids to
keys will be required, we have to make sure that it won't cost too much;
* matching old list with a new one to properly invoke listeners - should be
partially solved by the code from the issue above, but still, might be tricky
as well.
-HOCON / JSON "parsers" will have to be altered as well to support "rename"
operation. That should be easy.-
was:
h3. Motivation
Current NamedListChange API does not allow you to perform rename operation.
Best that you can do is to manually copy the required element and then delete
the original. This is bad for several reasons:
* inconvenient both in Java API and CLI tool;
* results in "onDelete" and "onCreate" events, which is probably not what
people want.
There must be a way to rename elements in Java API at least so that "ALTER ..."
DDL command could be properly implemented.
h3. Java API
{{NamedListChange}} is a right place to add "rename" method. It should have two
parameters and following restrictions:
* "old" and "new" names are not null;
* element with "old" name must exist;
* element with "new" name must not exist.
New method must be added {{to ConfigurationNamedListListener}}, named
"onRename". It should have "onUpdate" semantics, but with two new parameters:
"oldKey" and "newKey". Names are a subject to change.
h3. CLI
-This is a little less obvious since HOCON/JSON describe data, not operations.
We already have specific syntax for "delete" operation. I suggest making
"rename" look similar:-
{code:java}
root.namedList {
oldName = newName
}{code}
-In short, now we can assign 3 things to the element:-
* -regular composite object with its inner values;-
* -"null" for deletion;-
* -"String" for renaming.-
HOCON/JSON format will have no alterations for this feature. DDL commands are
to be used for these operations instead.
h3. Implementation hints
This will be similar to how we store ordering of named list elements. But this
time we have to assign each element a unique identifier. This can be a String
or a number. Laziest solution is to use UUID with hyphens removed from it.
That'll do it.
NamedListNode object will store these ids. In short, following algorithms will
have to be altered:
* conversion of update tree to the flat map - this one should be easy;
* applying the flat map to the tree - a bit trickier. Matching from ids to
keys will be required, we have to make sure that it won't cost too much;
* matching old list with a new one to properly invoke listeners - should be
partially solved by the code from the issue above, but still, might be tricky
as well.
HOCON / JSON "parsers" will have to be altered as well to support "rename"
operation. That should be easy.
> Support renaming in named list configuration elements
> --
[jira] [Updated] (IGNITE-15166) Support renaming in named list configuration elements
[
https://issues.apache.org/jira/browse/IGNITE-15166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-15166:
---
Description:
h3. Motivation
Current NamedListChange API does not allow you to perform rename operation.
Best that you can do is to manually copy the required element and then delete
the original. This is bad for several reasons:
* inconvenient both in Java API and CLI tool;
* results in "onDelete" and "onCreate" events, which is probably not what
people want.
There must be a way to rename elements in Java API at least so that "ALTER ..."
DDL command could be properly implemented.
h3. Java API
{{NamedListChange}} is a right place to add "rename" method. It should have two
parameters and following restrictions:
* "old" and "new" names are not null;
* element with "old" name must exist;
* element with "new" name must not exist.
New method must be added {{to ConfigurationNamedListListener}}, named
"onRename". It should have "onUpdate" semantics, but with two new parameters:
"oldKey" and "newKey". Names are a subject to change.
h3. CLI
-This is a little less obvious since HOCON/JSON describe data, not operations.
We already have specific syntax for "delete" operation. I suggest making
"rename" look similar:-
{code:java}
root.namedList {
oldName = newName
}{code}
-In short, now we can assign 3 things to the element:-
* -regular composite object with its inner values;-
* -"null" for deletion;-
* -"String" for renaming.-
HOCON/JSON format will have no alterations for this feature. DDL commands are
to be used for these operations instead.
h3. Implementation hints
This will be similar to how we store ordering of named list elements. But this
time we have to assign each element a unique identifier. This can be a String
or a number. Laziest solution is to use UUID with hyphens removed from it.
That'll do it.
NamedListNode object will store these ids. In short, following algorithms will
have to be altered:
* conversion of update tree to the flat map - this one should be easy;
* applying the flat map to the tree - a bit trickier. Matching from ids to
keys will be required, we have to make sure that it won't cost too much;
* matching old list with a new one to properly invoke listeners - should be
partially solved by the code from the issue above, but still, might be tricky
as well.
HOCON / JSON "parsers" will have to be altered as well to support "rename"
operation. That should be easy.
was:
h3. Motivation
Current NamedListChange API does not allow you to perform rename operation.
Best that you can do is to manually copy the required element and then delete
the original. This is bad for several reasons:
* inconvenient both in Java API and CLI tool;
* results in "onDelete" and "onCreate" events, which is probably not what
people want.
There must be a way to rename elements in Java API at least so that "ALTER ..."
DDL command could be properly implemented.
h3. Java API
{{NamedListChange}} is a right place to add "rename" method. It should have two
parameters and following restrictions:
* "old" and "new" names are not null;
* element with "old" name must exist;
* element with "new" name must not exist.
New method must be added {{to ConfigurationNamedListListener}}, named
"onRename". It should have "onUpdate" semantics, but with two new parameters:
"oldKey" and "newKey". Names are a subject to change.
h3. CLI
This is a little less obvious since HOCON/JSON describe data, not operations.
We already have specific syntax for "delete" operation. I suggest making
"rename" look similar:
{code:java}
root.namedList {
oldName = newName
}{code}
In short, now we can assign 3 things to the element:
* regular composite object with its inner values;
* "null" for deletion;
* "String" for renaming.
h3. Implementation hints
This will be similar to how we store ordering of named list elements. But this
time we have to assign each element a unique identifier. This can be a String
or a number. Laziest solution is to use UUID with hyphens removed from it.
That'll do it.
NamedListNode object will store these ids. In short, following algorithms will
have to be altered:
* conversion of update tree to the flat map - this one should be easy;
* applying the flat map to the tree - a bit trickier. Matching from ids to
keys will be required, we have to make sure that it won't cost too much;
* matching old list with a new one to properly invoke listeners - should be
partially solved by the code from the issue above, but still, might be tricky
as well.
HOCON / JSON "parsers" will have to be altered as well to support "rename"
operation. That should be easy.
> Support renaming in named list configuration elements
> -
>
> Key: IGNITE-15166
> URL: https://issues.apache.org/jira/browse/IGNIT
[jira] [Created] (IGNITE-15166) Support renaming in named list configuration elements
Ivan Bessonov created IGNITE-15166:
--
Summary: Support renaming in named list configuration elements
Key: IGNITE-15166
URL: https://issues.apache.org/jira/browse/IGNITE-15166
Project: Ignite
Issue Type: Improvement
Affects Versions: 3.0.0-alpha2
Reporter: Ivan Bessonov
h3. Motivation
Current NamedListChange API does not allow you to perform rename operation.
Best that you can do is to manually copy the required element and then delete
the original. This is bad for several reasons:
* inconvenient both in Java API and CLI tool;
* results in "onDelete" and "onCreate" events, which is probably not what
people want.
There must be a way to rename elements in Java API at least so that "ALTER ..."
DDL command could be properly implemented.
h3. Java API
{{NamedListChange}} is a right place to add "rename" method. It should have two
parameters and following restrictions:
* "old" and "new" names are not null;
* element with "old" name must exist;
* element with "new" name must not exist.
New method must be added {{to ConfigurationNamedListListener}}, named
"onRename". It should have "onUpdate" semantics, but with two new parameters:
"oldKey" and "newKey". Names are a subject to change.
h3. CLI
This is a little less obvious since HOCON/JSON describe data, not operations.
We already have specific syntax for "delete" operation. I suggest making
"rename" look similar:
{code:java}
root.namedList {
oldName = newName
}{code}
In short, now we can assign 3 things to the element:
* regular composite object with its inner values;
* "null" for deletion;
* "String" for renaming.
h3. Implementation hints
This will be similar to how we store ordering of named list elements. But this
time we have to assign each element a unique identifier. This can be a String
or a number. Laziest solution is to use UUID with hyphens removed from it.
That'll do it.
NamedListNode object will store these ids. In short, following algorithms will
have to be altered:
* conversion of update tree to the flat map - this one should be easy;
* applying the flat map to the tree - a bit trickier. Matching from ids to
keys will be required, we have to make sure that it won't cost too much;
* matching old list with a new one to properly invoke listeners - should be
partially solved by the code from the issue above, but still, might be tricky
as well.
HOCON / JSON "parsers" will have to be altered as well to support "rename"
operation. That should be easy.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15165) Fix maven build when maven.test.skip is set
[ https://issues.apache.org/jira/browse/IGNITE-15165?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-15165: --- Ignite Flags: (was: Docs Required,Release Notes Required) > Fix maven build when maven.test.skip is set > --- > > Key: IGNITE-15165 > URL: https://issues.apache.org/jira/browse/IGNITE-15165 > Project: Ignite > Issue Type: Bug >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 20m > Remaining Estimate: 0h > > `mvn clean install -DskipTests -Dmaven.test.skip=true` has stopped working > after IGNITE-14983 because ignite-network both depends on a test-jar of the > ignite-core module and builds its own test-jar. This leads to maven requiring > a test scope resolution which is not possible due to the fact that test-jars > are not actually getting built with maven.test.skip set to true -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14983) Provide an ability to register NetworkMessageHandler for particular message group
[
https://issues.apache.org/jira/browse/IGNITE-14983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17384061#comment-17384061
]
Ivan Bessonov commented on IGNITE-14983:
Looks good, thank you for the contribution!
> Provide an ability to register NetworkMessageHandler for particular message
> group
> -
>
> Key: IGNITE-14983
> URL: https://issues.apache.org/jira/browse/IGNITE-14983
> Project: Ignite
> Issue Type: Improvement
> Components: networking
>Reporter: Konstantin Orlov
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: iep-66, ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Currently messaging service allows to register a general message handler only
> which will be invoked for every message received.
> {code:java}
> /**
> * Registers a handler for network message events.
> *
> * @param handler Message handler.
> */
> void addMessageHandler(NetworkMessageHandler handler);
> {code}
> It would be great to have an ability to register handler for particular
> message group in order to reduce the amount of unnecessary handlers'
> invocations.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Assigned] (IGNITE-14924) Implement HoconConfigurationSource
[ https://issues.apache.org/jira/browse/IGNITE-14924?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov reassigned IGNITE-14924: -- Assignee: Ivan Bessonov > Implement HoconConfigurationSource > -- > > Key: IGNITE-14924 > URL: https://issues.apache.org/jira/browse/IGNITE-14924 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Assignee: Ivan Bessonov >Priority: Major > Labels: iep-55, ignite-3 > > According to > [IEP-55|https://cwiki.apache.org/confluence/display/IGNITE/IEP-55+Unified+Configuration] > we must support HOCON format as the main format for configuration files. But > now we support only json configs by our configuration framework and forced to > convert hocon to json before. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15158) Integration Tests logs are too big
Ivan Bessonov created IGNITE-15158: -- Summary: Integration Tests logs are too big Key: IGNITE-15158 URL: https://issues.apache.org/jira/browse/IGNITE-15158 Project: Ignite Issue Type: Improvement Affects Versions: 3.0.0-alpha2 Reporter: Ivan Bessonov Logs for integration tests exceed 60 Mb already, this is not ok. It's impossible to attach full build log to the Jira issue for further investigation, for example. Link to the suite: https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_IntegrationTests?branch=%3Cdefault%3E&buildTypeTab=overview&mode=builds#all-projects -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15157) ITCliServiceTest.testAddPeerRemovePeer is flaky
[
https://issues.apache.org/jira/browse/IGNITE-15157?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-15157:
---
Description:
[https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_IntegrationTests/6094143]
{code:java}
[09:50:48]W: [Step 2/2] [ERROR]
org.apache.ignite.raft.jraft.core.ITCliServiceTest.testAddPeerRemovePeer Time
elapsed: 22.237 s <<< FAILURE![09:50:48]W: [Step 2/2] [ERROR]
org.apache.ignite.raft.jraft.core.ITCliServiceTest.testAddPeerRemovePeer Time
elapsed: 22.237 s <<< FAILURE![09:50:48] : [Step 2/2]
org.opentest4j.AssertionFailedError: expected: but was:
[09:50:48] : [Step 2/2] at
org.apache.ignite.raft.jraft.core.ITCliServiceTest.testAddPeerRemovePeer(ITCliServiceTest.java:273)
{code}
was:https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_IntegrationTests/6094143
> ITCliServiceTest.testAddPeerRemovePeer is flaky
> ---
>
> Key: IGNITE-15157
> URL: https://issues.apache.org/jira/browse/IGNITE-15157
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> [https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_IntegrationTests/6094143]
> {code:java}
> [09:50:48]W: [Step 2/2] [ERROR]
> org.apache.ignite.raft.jraft.core.ITCliServiceTest.testAddPeerRemovePeer
> Time elapsed: 22.237 s <<< FAILURE![09:50:48]W: [Step 2/2] [ERROR]
> org.apache.ignite.raft.jraft.core.ITCliServiceTest.testAddPeerRemovePeer
> Time elapsed: 22.237 s <<< FAILURE![09:50:48] : [Step 2/2]
> org.opentest4j.AssertionFailedError: expected: but was:
> [09:50:48] : [Step 2/2] at
> org.apache.ignite.raft.jraft.core.ITCliServiceTest.testAddPeerRemovePeer(ITCliServiceTest.java:273)
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15156) ITJRaftCounterServerTest.testFollowerCatchUpFromSnapshot2 is flaky
[
https://issues.apache.org/jira/browse/IGNITE-15156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-15156:
---
Description:
[https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_IntegrationTests/6092693]
{code:java}
[11:17:18]W: [Step 2/2] [ERROR]
org.apache.ignite.raft.server.ITJRaftCounterServerTest.testFollowerCatchUpFromSnapshot2
Time elapsed: 42.007 s <<< ERROR![11:17:18]W: [Step 2/2] [ERROR]
org.apache.ignite.raft.server.ITJRaftCounterServerTest.testFollowerCatchUpFromSnapshot2
Time elapsed: 42.007 s <<< ERROR![11:17:18] : [Step 2/2]
java.util.concurrent.ExecutionException: java.util.concurrent.TimeoutException:
Did not observe any item or terminal signal within 1ms in
'source(MonoDefer)' (and no fallback has been configured)[11:17:18] : [Step
2/2] at
org.apache.ignite.raft.server.ITJRaftCounterServerTest.applyIncrements(ITJRaftCounterServerTest.java:562)[11:17:18]
: [Step 2/2] at
org.apache.ignite.raft.server.ITJRaftCounterServerTest.doTestFollowerCatchUp(ITJRaftCounterServerTest.java:491)[11:17:18]
: [Step 2/2] at
org.apache.ignite.raft.server.ITJRaftCounterServerTest.testFollowerCatchUpFromSnapshot2(ITJRaftCounterServerTest.java:468)[11:17:18]
: [Step 2/2] Caused by: java.util.concurrent.TimeoutException: Did not
observe any item or terminal signal within 1ms in 'source(MonoDefer)' (and
no fallback has been configured)[11:17:18] : [Step 2/2]
{code}
was:https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_IntegrationTests/6092693
> ITJRaftCounterServerTest.testFollowerCatchUpFromSnapshot2 is flaky
> --
>
> Key: IGNITE-15156
> URL: https://issues.apache.org/jira/browse/IGNITE-15156
> Project: Ignite
> Issue Type: Bug
>Reporter: Ivan Bessonov
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
>
> [https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_IntegrationTests/6092693]
> {code:java}
> [11:17:18]W: [Step 2/2] [ERROR]
> org.apache.ignite.raft.server.ITJRaftCounterServerTest.testFollowerCatchUpFromSnapshot2
> Time elapsed: 42.007 s <<< ERROR![11:17:18]W: [Step 2/2] [ERROR]
> org.apache.ignite.raft.server.ITJRaftCounterServerTest.testFollowerCatchUpFromSnapshot2
> Time elapsed: 42.007 s <<< ERROR![11:17:18] : [Step 2/2]
> java.util.concurrent.ExecutionException:
> java.util.concurrent.TimeoutException: Did not observe any item or terminal
> signal within 1ms in 'source(MonoDefer)' (and no fallback has been
> configured)[11:17:18] : [Step 2/2] at
> org.apache.ignite.raft.server.ITJRaftCounterServerTest.applyIncrements(ITJRaftCounterServerTest.java:562)[11:17:18]
> : [Step 2/2] at
> org.apache.ignite.raft.server.ITJRaftCounterServerTest.doTestFollowerCatchUp(ITJRaftCounterServerTest.java:491)[11:17:18]
> : [Step 2/2] at
> org.apache.ignite.raft.server.ITJRaftCounterServerTest.testFollowerCatchUpFromSnapshot2(ITJRaftCounterServerTest.java:468)[11:17:18]
> : [Step 2/2] Caused by: java.util.concurrent.TimeoutException: Did not
> observe any item or terminal signal within 1ms in 'source(MonoDefer)'
> (and no fallback has been configured)[11:17:18] : [Step 2/2]
> {code}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15157) ITCliServiceTest.testAddPeerRemovePeer is flaky
Ivan Bessonov created IGNITE-15157: -- Summary: ITCliServiceTest.testAddPeerRemovePeer is flaky Key: IGNITE-15157 URL: https://issues.apache.org/jira/browse/IGNITE-15157 Project: Ignite Issue Type: Bug Reporter: Ivan Bessonov Fix For: 3.0.0-alpha3 https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_IntegrationTests/6094143 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (IGNITE-15156) ITJRaftCounterServerTest.testFollowerCatchUpFromSnapshot2 is flaky
Ivan Bessonov created IGNITE-15156: -- Summary: ITJRaftCounterServerTest.testFollowerCatchUpFromSnapshot2 is flaky Key: IGNITE-15156 URL: https://issues.apache.org/jira/browse/IGNITE-15156 Project: Ignite Issue Type: Bug Reporter: Ivan Bessonov Fix For: 3.0.0-alpha3 https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_IntegrationTests_IntegrationTests/6092693 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15130) Network message generator must generate "equals" and "hashCode"
[
https://issues.apache.org/jira/browse/IGNITE-15130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-15130:
---
Labels: iep-66 ignite-3 (was: ignite-3)
> Network message generator must generate "equals" and "hashCode"
> ---
>
> Key: IGNITE-15130
> URL: https://issues.apache.org/jira/browse/IGNITE-15130
> Project: Ignite
> Issue Type: Task
> Components: networking
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: iep-66, ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Network annotation processor must automatically generate {{equals}} and
> {{hashCode}} implementations, because some code (especially in tests) needs
> to compare message contents.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14838) Fix up messaging in jraft.
[ https://issues.apache.org/jira/browse/IGNITE-14838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-14838: --- Component/s: networking > Fix up messaging in jraft. > -- > > Key: IGNITE-14838 > URL: https://issues.apache.org/jira/browse/IGNITE-14838 > Project: Ignite > Issue Type: Task > Components: networking >Reporter: Alexey Scherbakov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: iep-66, ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Currently jraft uses hand coded messages. > This should be cleaned up and switched to generated factories. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14983) Provide an ability to register NetworkMessageHandler for particular message group
[
https://issues.apache.org/jira/browse/IGNITE-14983?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-14983:
---
Labels: iep-66 ignite-3 (was: ignite-3)
> Provide an ability to register NetworkMessageHandler for particular message
> group
> -
>
> Key: IGNITE-14983
> URL: https://issues.apache.org/jira/browse/IGNITE-14983
> Project: Ignite
> Issue Type: Improvement
> Components: networking
>Reporter: Konstantin Orlov
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: iep-66, ignite-3
>
> Currently messaging service allows to register a general message handler only
> which will be invoked for every message received.
> {code:java}
> /**
> * Registers a handler for network message events.
> *
> * @param handler Message handler.
> */
> void addMessageHandler(NetworkMessageHandler handler);
> {code}
> It would be great to have an ability to register handler for particular
> message group in order to reduce the amount of unnecessary handlers'
> invocations.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14838) Fix up messaging in jraft.
[ https://issues.apache.org/jira/browse/IGNITE-14838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-14838: --- Labels: iep-66 ignite-3 (was: ignite-3) > Fix up messaging in jraft. > -- > > Key: IGNITE-14838 > URL: https://issues.apache.org/jira/browse/IGNITE-14838 > Project: Ignite > Issue Type: Task >Reporter: Alexey Scherbakov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: iep-66, ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Currently jraft uses hand coded messages. > This should be cleaned up and switched to generated factories. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14838) Fix up messaging in jraft.
[ https://issues.apache.org/jira/browse/IGNITE-14838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17383811#comment-17383811 ] Ivan Bessonov commented on IGNITE-14838: Looks good, thank you for the improvement! > Fix up messaging in jraft. > -- > > Key: IGNITE-14838 > URL: https://issues.apache.org/jira/browse/IGNITE-14838 > Project: Ignite > Issue Type: Task >Reporter: Alexey Scherbakov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Currently jraft uses hand coded messages. > This should be cleaned up and switched to generated factories. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14838) Fix up messaging in jraft.
[ https://issues.apache.org/jira/browse/IGNITE-14838?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-14838: --- Release Note: (was: Looks good, thank you for the improvement!) > Fix up messaging in jraft. > -- > > Key: IGNITE-14838 > URL: https://issues.apache.org/jira/browse/IGNITE-14838 > Project: Ignite > Issue Type: Task >Reporter: Alexey Scherbakov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 2h 40m > Remaining Estimate: 0h > > Currently jraft uses hand coded messages. > This should be cleaned up and switched to generated factories. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15105) Reduce number of messages for "Blocked system-critical thread" errors
[ https://issues.apache.org/jira/browse/IGNITE-15105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17379778#comment-17379778 ] Ivan Bessonov commented on IGNITE-15105: Mistakenly committed with "GG-30086 Reduce number of messages for "Blocked system-critical thread"" commit message. There's no point of reverting it at this point because this won't give us clean commit history. My bad. > Reduce number of messages for "Blocked system-critical thread" errors > - > > Key: IGNITE-15105 > URL: https://issues.apache.org/jira/browse/IGNITE-15105 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Fix For: 2.12 > > Time Spent: 20m > Remaining Estimate: 0h > > Now, we're printing a lot of messages for these errors, each of them has > thousands of lines, because it prints locks and/or threads. It overwrites > everything else in logs and makes troubleshooting impossible. > This behavior was analyzed on 2.8.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14748) Ordered @NamedConfigValue
[
https://issues.apache.org/jira/browse/IGNITE-14748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-14748:
---
Ignite Flags: (was: Docs Required,Release Notes Required)
> Ordered @NamedConfigValue
> -
>
> Key: IGNITE-14748
> URL: https://issues.apache.org/jira/browse/IGNITE-14748
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Alexander Belyak
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: iep-55, ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Implement some order for @NamedConfigValue fields.
> Imagine that we have some
>
> {code:java}
> @Config
> public class PKIndexConfigurationSchema {
> @Value
> String type;
> @NamedConfigValue
> IndexColumnConfigurationSchema columns.
>
> {code}
> and
>
> {code:java}
> @Config
> public class IndexColumnConfigurationSchema {
> @Value
> String name;
> @Value
> boolean asc;
> @Value
> boolean affinityCol;
> }
> {code}
>
> For now we have to use indexes to store such config like:
>
> {noformat}
> "PK":
> "type":"PrimaryKey",
> "columns": {
> "0": {
> "name":"REGION",
> "asc":true,
> "affinity":true
> },
> "1": {
> "name":"COMPANY",
> "asc":true,
> "affinity":false
> }
> }
> {noformat}
>
> because we have to keep it's order.
> But if configuration keep order for @NamedConfigValue it can look like:
>
> {noformat}
> "PK":
> "type":"PrimaryKey",
> "columns": {
> "REGION": {
> "asc":true,
> "affinity":true
> },
> "COMPANY": {
> "asc":true,
> "affinity":false
> }
> }
> {noformat}
> And to allow insert value in the middle it will be nice to have some methods
> like:
> * listChange.create(idx, key, consumer(elementChange))
> or
> * listChange.createAfter(prevKeyOrNull, key, consumer(elementChange))
> in addition to existing:
> * listChange.create(key, consumer(elementChange))
> * listChange.update(key, consumer(elementChange))
> * listChange.delete(key)
> BTW, lets remove listChange.update method.
> h3. Implementation notes
> It would make sense to store order number inside of named list entry. It
> would look like implicit configuration parameter {{}}, for example. This
> value will be recalculated on every update.
> Index will be stored in named list itself, entries will not contain it.
> Reason is simple - named list entries can be used as regular "inner" nodes
> and we can't distinguish one from the another. That's why index is implicit.
> h3. API notes
> I don't get why we need to remove update method. It would be helpful to
> update their semantics, like "create" would throw "AlreadyExistsException" or
> something, update would do similar thing with "KeyNotFound"...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14748) Ordered @NamedConfigValue
[
https://issues.apache.org/jira/browse/IGNITE-14748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-14748:
---
Labels: iep-55 ignite-3 (was: iep-55)
> Ordered @NamedConfigValue
> -
>
> Key: IGNITE-14748
> URL: https://issues.apache.org/jira/browse/IGNITE-14748
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Alexander Belyak
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: iep-55, ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Implement some order for @NamedConfigValue fields.
> Imagine that we have some
>
> {code:java}
> @Config
> public class PKIndexConfigurationSchema {
> @Value
> String type;
> @NamedConfigValue
> IndexColumnConfigurationSchema columns.
>
> {code}
> and
>
> {code:java}
> @Config
> public class IndexColumnConfigurationSchema {
> @Value
> String name;
> @Value
> boolean asc;
> @Value
> boolean affinityCol;
> }
> {code}
>
> For now we have to use indexes to store such config like:
>
> {noformat}
> "PK":
> "type":"PrimaryKey",
> "columns": {
> "0": {
> "name":"REGION",
> "asc":true,
> "affinity":true
> },
> "1": {
> "name":"COMPANY",
> "asc":true,
> "affinity":false
> }
> }
> {noformat}
>
> because we have to keep it's order.
> But if configuration keep order for @NamedConfigValue it can look like:
>
> {noformat}
> "PK":
> "type":"PrimaryKey",
> "columns": {
> "REGION": {
> "asc":true,
> "affinity":true
> },
> "COMPANY": {
> "asc":true,
> "affinity":false
> }
> }
> {noformat}
> And to allow insert value in the middle it will be nice to have some methods
> like:
> * listChange.create(idx, key, consumer(elementChange))
> or
> * listChange.createAfter(prevKeyOrNull, key, consumer(elementChange))
> in addition to existing:
> * listChange.create(key, consumer(elementChange))
> * listChange.update(key, consumer(elementChange))
> * listChange.delete(key)
> BTW, lets remove listChange.update method.
> h3. Implementation notes
> It would make sense to store order number inside of named list entry. It
> would look like implicit configuration parameter {{}}, for example. This
> value will be recalculated on every update.
> Index will be stored in named list itself, entries will not contain it.
> Reason is simple - named list entries can be used as regular "inner" nodes
> and we can't distinguish one from the another. That's why index is implicit.
> h3. API notes
> I don't get why we need to remove update method. It would be helpful to
> update their semantics, like "create" would throw "AlreadyExistsException" or
> something, update would do similar thing with "KeyNotFound"...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14748) Ordered @NamedConfigValue
[
https://issues.apache.org/jira/browse/IGNITE-14748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-14748:
---
Fix Version/s: 3.0.0-alpha3
> Ordered @NamedConfigValue
> -
>
> Key: IGNITE-14748
> URL: https://issues.apache.org/jira/browse/IGNITE-14748
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Alexander Belyak
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: iep-55, ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Implement some order for @NamedConfigValue fields.
> Imagine that we have some
>
> {code:java}
> @Config
> public class PKIndexConfigurationSchema {
> @Value
> String type;
> @NamedConfigValue
> IndexColumnConfigurationSchema columns.
>
> {code}
> and
>
> {code:java}
> @Config
> public class IndexColumnConfigurationSchema {
> @Value
> String name;
> @Value
> boolean asc;
> @Value
> boolean affinityCol;
> }
> {code}
>
> For now we have to use indexes to store such config like:
>
> {noformat}
> "PK":
> "type":"PrimaryKey",
> "columns": {
> "0": {
> "name":"REGION",
> "asc":true,
> "affinity":true
> },
> "1": {
> "name":"COMPANY",
> "asc":true,
> "affinity":false
> }
> }
> {noformat}
>
> because we have to keep it's order.
> But if configuration keep order for @NamedConfigValue it can look like:
>
> {noformat}
> "PK":
> "type":"PrimaryKey",
> "columns": {
> "REGION": {
> "asc":true,
> "affinity":true
> },
> "COMPANY": {
> "asc":true,
> "affinity":false
> }
> }
> {noformat}
> And to allow insert value in the middle it will be nice to have some methods
> like:
> * listChange.create(idx, key, consumer(elementChange))
> or
> * listChange.createAfter(prevKeyOrNull, key, consumer(elementChange))
> in addition to existing:
> * listChange.create(key, consumer(elementChange))
> * listChange.update(key, consumer(elementChange))
> * listChange.delete(key)
> BTW, lets remove listChange.update method.
> h3. Implementation notes
> It would make sense to store order number inside of named list entry. It
> would look like implicit configuration parameter {{}}, for example. This
> value will be recalculated on every update.
> Index will be stored in named list itself, entries will not contain it.
> Reason is simple - named list entries can be used as regular "inner" nodes
> and we can't distinguish one from the another. That's why index is implicit.
> h3. API notes
> I don't get why we need to remove update method. It would be helpful to
> update their semantics, like "create" would throw "AlreadyExistsException" or
> something, update would do similar thing with "KeyNotFound"...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15105) Reduce number of messages for "Blocked system-critical thread" errors
[ https://issues.apache.org/jira/browse/IGNITE-15105?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17379653#comment-17379653 ] Ivan Bessonov commented on IGNITE-15105: [~apolovtcev] thank you for the contribution! Code looks good, I'll merge it > Reduce number of messages for "Blocked system-critical thread" errors > - > > Key: IGNITE-15105 > URL: https://issues.apache.org/jira/browse/IGNITE-15105 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Major > Fix For: 2.12 > > Time Spent: 10m > Remaining Estimate: 0h > > Now, we're printing a lot of messages for these errors, each of them has > thousands of lines, because it prints locks and/or threads. It overwrites > everything else in logs and makes troubleshooting impossible. > This behavior was analyzed on 2.8.0 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-15050) Add rename index tree to drop index
[ https://issues.apache.org/jira/browse/IGNITE-15050?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17379634#comment-17379634 ] Ivan Bessonov commented on IGNITE-15050: [~ktkale...@gridgain.com] thank you for the contribution, looking forward for the IGNITE-15026 fix. > Add rename index tree to drop index > --- > > Key: IGNITE-15050 > URL: https://issues.apache.org/jira/browse/IGNITE-15050 > Project: Ignite > Issue Type: Improvement > Components: persistence, sql >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Fix For: 2.12 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > To implement the removal of indices in the > *DurableBackgroundCleanupIndexTreeTask* (IGNITE-15026), at the beginning we > need to rename the index tree, this is not yet available. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15044) Node work directory.
[ https://issues.apache.org/jira/browse/IGNITE-15044?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-15044: --- Ignite Flags: (was: Docs Required,Release Notes Required) > Node work directory. > > > Key: IGNITE-15044 > URL: https://issues.apache.org/jira/browse/IGNITE-15044 > Project: Ignite > Issue Type: Improvement > Components: persistence >Reporter: Andrey Mashenkov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 1h > Remaining Estimate: 0h > > Since Vault become persistent, tests create vault files in a module > high-level directory. > This directory is not ignored by git, which may lead to unwanted data in git > repo, > and maybe some other unexpected things. > Let's > * introduce a working directory for nodes where all node files will be stored. > * add workdir to gitignore > We can use Ignite-2 approach for now and improve later in a separate ticket > if there are issues we want to resolve. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (IGNITE-14748) Ordered @NamedConfigValue
[
https://issues.apache.org/jira/browse/IGNITE-14748?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov reassigned IGNITE-14748:
--
Assignee: Ivan Bessonov
> Ordered @NamedConfigValue
> -
>
> Key: IGNITE-14748
> URL: https://issues.apache.org/jira/browse/IGNITE-14748
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Alexander Belyak
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: iep-55
>
> Implement some order for @NamedConfigValue fields.
> Imagine that we have some
>
> {code:java}
> @Config
> public class PKIndexConfigurationSchema {
> @Value
> String type;
> @NamedConfigValue
> IndexColumnConfigurationSchema columns.
>
> {code}
> and
>
> {code:java}
> @Config
> public class IndexColumnConfigurationSchema {
> @Value
> String name;
> @Value
> boolean asc;
> @Value
> boolean affinityCol;
> }
> {code}
>
> For now we have to use indexes to store such config like:
>
> {noformat}
> "PK":
> "type":"PrimaryKey",
> "columns": {
> "0": {
> "name":"REGION",
> "asc":true,
> "affinity":true
> },
> "1": {
> "name":"COMPANY",
> "asc":true,
> "affinity":false
> }
> }
> {noformat}
>
> because we have to keep it's order.
> But if configuration keep order for @NamedConfigValue it can look like:
>
> {noformat}
> "PK":
> "type":"PrimaryKey",
> "columns": {
> "REGION": {
> "asc":true,
> "affinity":true
> },
> "COMPANY": {
> "asc":true,
> "affinity":false
> }
> }
> {noformat}
> And to allow insert value in the middle it will be nice to have some methods
> like:
> * listChange.create(idx, key, consumer(elementChange))
> or
> * listChange.createAfter(prevKeyOrNull, key, consumer(elementChange))
> in addition to existing:
> * listChange.create(key, consumer(elementChange))
> * listChange.update(key, consumer(elementChange))
> * listChange.delete(key)
> BTW, lets remove listChange.update method.
> h3. Implementation notes
> It would make sense to store order number inside of named list entry. It
> would look like implicit configuration parameter {{}}, for example. This
> value will be recalculated on every update.
> Index will be stored in named list itself, entries will not contain it.
> Reason is simple - named list entries can be used as regular "inner" nodes
> and we can't distinguish one from the another. That's why index is implicit.
> h3. API notes
> I don't get why we need to remove update method. It would be helpful to
> update their semantics, like "create" would throw "AlreadyExistsException" or
> something, update would do similar thing with "KeyNotFound"...
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15018) Add support for message inheritance for @Transferable
[
https://issues.apache.org/jira/browse/IGNITE-15018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-15018:
---
Ignite Flags: (was: Docs Required,Release Notes Required)
> Add support for message inheritance for @Transferable
> -
>
> Key: IGNITE-15018
> URL: https://issues.apache.org/jira/browse/IGNITE-15018
> Project: Ignite
> Issue Type: Task
> Components: networking
>Affects Versions: 3.0.0-alpha3
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{@Transferable}} annotation should support message inheritance: it can be
> placed on an interface that extends another interface that declares some
> message fields. These fields should be present in the generated
> implementations.
> For example:
> {code:java}
> interface A extends NetworkMessage {
> int a();
> }
> @Transferable
> interface B extends A {
> int b();
> }
> {code}
> The "{{a}}" field must be present in the generated implementation for {{B}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15018) Add support for message inheritance for @Transferable
[
https://issues.apache.org/jira/browse/IGNITE-15018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17373375#comment-17373375
]
Ivan Bessonov commented on IGNITE-15018:
Looks good, thank you for the contribution!
> Add support for message inheritance for @Transferable
> -
>
> Key: IGNITE-15018
> URL: https://issues.apache.org/jira/browse/IGNITE-15018
> Project: Ignite
> Issue Type: Task
> Components: networking
>Affects Versions: 3.0.0-alpha3
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Minor
> Labels: ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> {{@Transferable}} annotation should support message inheritance: it can be
> placed on an interface that extends another interface that declares some
> message fields. These fields should be present in the generated
> implementations.
> For example:
> {code:java}
> interface A extends NetworkMessage {
> int a();
> }
> @Transferable
> interface B extends A {
> int b();
> }
> {code}
> The "{{a}}" field must be present in the generated implementation for {{B}}.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15047) Support internal/private properties in configuration framework
Ivan Bessonov created IGNITE-15047: -- Summary: Support internal/private properties in configuration framework Key: IGNITE-15047 URL: https://issues.apache.org/jira/browse/IGNITE-15047 Project: Ignite Issue Type: Sub-task Reporter: Ivan Bessonov In order to provide consistent update of configuration and metastorage metadata we should have configuration values that are hidden form the user. Requirements are: * these configuration values should be available from internal code only * they should not be accessible in JSON or any other configuration view representation * they can't be updated via CLI's HOCON update requests or any other public API calls One possible solution is to have configuration schema extensions, registered in "internal" modules - they'll lead to generation of extended VIEW and CHANGE interfaces. All extra fields from these schemas will be marked as internal by configuration framework, technically it is possible. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14645) Support polymorphic configuration nodes.
[
https://issues.apache.org/jira/browse/IGNITE-14645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-14645:
---
Labels: iep-55 ignite-3 (was: iep-55)
> Support polymorphic configuration nodes.
>
>
> Key: IGNITE-14645
> URL: https://issues.apache.org/jira/browse/IGNITE-14645
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
> Labels: iep-55, ignite-3
>
> NOTE: description might not be finished.
> h3. Problem
> Currently configuration schema structure is very restricted and doesn't allow
> any variations in it. This approach comes with a set of problems.
> # How do you properly configure {{IpFinder}}? For each type of finder you
> only need a few properties.
> # How do you configure SQL indexes? Pretty much the same problem.
> h3. Interface
> For the solution we need to expand abilities of configuration schemas. I
> propose the following option:
> {code:java}
> // Configuration schema that contains polymorphic field.
> @Config
> class TableConfigurationSchema {
> @NamedConfigValue
> public IndexConfigurationSchema indexes;
> }
> // Base class for polymorphic value. Explicitly has all subclasses
> // in its description to simplify incremental code generation.
> //TODO: Maybe we cab avoid this part by using "originating elements" in
> annotation processing,
> // we'll check that during POC phase.
> @PolymorphicConfig(impl = {
> HashIndexConfigurationSchema.class,
> TreeIndexConfigurationSchema.class,
> })
> class IndexConfigurationSchema {
> // This annotation shows that current field defines implementation.
> // Specific values are present in implementations declarations.
> @Id
> @Immutable
> @Value
> public String type;
> }
> // One of implementations for index. Id value is defined in annotation.
> @PolymorphicInstance(id = "hash")
> public static class HashIndexConfigurationSchema extends
> IndexConfigurationSchema {
> @Immutable
> @Value
> public String column;
> }
> // Other implementation for index.
> @PolymorphicInstance(id = "tree")
> public static class TreeIndexConfigurationSchema extends
> IndexConfigurationSchema {
> @Immutable
> @Value
> public String[] columns;
> }
> {code}
> h3. Generated API
> We need to tweak API a little bit. I'd love to see as few changes as
> possible, so my vision is something like this:
> {code:java}
> TableConfiguration tableCfg = ...;
> tableCfg.indexes().create("hashIndexName", index ->
> // Id sets up automatically by the call.
> index.asHashIndex().changeColumn("columnName")
> ).get();
> tableCfg.indexes().update("hashIndexName", index ->
> // Any cast is allowed to do in change request.
> // But this update will fail during processing.
> index.asTreeIndex().changeColumns("a", "b")
> );
> IndexConfiguration indexCfg = tableCfg.indexes().get("hashIndexName");
> // This must be an instance of "HashIndexConfiguration".
> HashIndexConfiguration hashCfg = (HashIndexConfiguration)indexCfg;
> // This must be instance of HashIndexView,
> IndexView indexView = indexCfg.value();
> // Maybe this is redundant, I don't know.
> assert indexView.isHashIndex();
> // Returns the same object with a safe cast.
> // Maybe this is redundant as well and regular cast would be enough.
> HashIndexView hashView = indexView.asHashIndex();{code}
> h3. Implementation Notes
> There are quite a few places that need to be tweaked here. First of all,
> let's examine {{ConfigurationImpl}} classes:
>
> {code:java}
> // Let's assume for a moment that "index" is not a named list, this is more
> convenient for current example.
> final class TableConfigurationImpl extends DynamicConfiguration TableChange> implements TableConfiguration {
> // Polymorphic fields won't be final anymore.
> private IndexConfigurationImpl index;
> public TableConfigurationImpl(List prefix, String key, RootKey ?> rootKey, ConfigurationChanger changer) {
> super(prefix, key, rootKey, changer);
> // No more "add" method invocations. "members" becomes mutable
> collections.
> // There's no point in making specific code generation for the
> situation when it's static.
> }
> @Override public final IndexConfiguration index() {
> // It's important to note that we can't just read field content
> because its type might have been changed.
> // This scenario was impossible before polymorphic types.
> refreshValue();
> return index;
> }
> @Override protected final synchronized void beforeRefreshValue(IndexView
> newValue) {
> // New value must be reinstantiated if its type changed.
> }
> @Override public Map> members() {
> refreshValue();
>
[jira] [Updated] (IGNITE-15017) Contention in lock on Compound future
[
https://issues.apache.org/jira/browse/IGNITE-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Bessonov updated IGNITE-15017:
---
Ignite Flags: (was: Docs Required,Release Notes Required)
> Contention in lock on Compound future
> -
>
> Key: IGNITE-15017
> URL: https://issues.apache.org/jira/browse/IGNITE-15017
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Fix For: 2.12
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> During analyze of JFR I noticed that the threads waiting long time on getting
> compounds on the future.
> It happened on an exclusive checkpoint phase and have a negative impact to
> transactions (they increased to a hundred milliseconds).
> This stack held the checkpoint workers:
> {noformat}
> org.apache.ignite.internal.util.future.GridCompoundFuture.futuresCount()
> line: 3582 0,036 272 938 246
>org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete()
> line: 2822 0,036 272 938 246
>
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(IgniteInternalFuture)
> line: 142 2 0,036 272 938 246
>
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(Object) line:
> 43 2 0,036 272 938 246
>
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(IgniteInClosure)
> line: 4072 0,036 272 938 246
>
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(Object)
> line: 355 2 0,036 272 938 246
>
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter$Node)
> line: 343 2 0,036 272 938 246
>
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(Object,
> Throwable, boolean) line: 5202 0,036 272 938 246
>
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(Object,
> Throwable) line: 498 2 0,036 272 938 246
>
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone() line: 464
> 2 0,036 272 938 246
>
> org.apache.ignite.internal.util.IgniteUtils.lambda$wrapIgniteFuture$3(Runnable,
> GridFutureAdapter) line: 11730 2 0,036 272 938 246
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker)
> line: 1149 2 0,036 272 938 246
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run() line: 6242
> 0,036 272 938 246
>java.lang.Thread.run() line: 748
> 2 0,036 272 938 246
> {noformat}
> You can see that the method {{checkComplete}} was freezed on 272 938 246
> microseconds in two times invocations.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (IGNITE-15017) Contention in lock on Compound future
[
https://issues.apache.org/jira/browse/IGNITE-15017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17371192#comment-17371192
]
Ivan Bessonov commented on IGNITE-15017:
[~v.pyatkov] sure, code looks good, I'll merge it
> Contention in lock on Compound future
> -
>
> Key: IGNITE-15017
> URL: https://issues.apache.org/jira/browse/IGNITE-15017
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> During analyze of JFR I noticed that the threads waiting long time on getting
> compounds on the future.
> It happened on an exclusive checkpoint phase and have a negative impact to
> transactions (they increased to a hundred milliseconds).
> This stack held the checkpoint workers:
> {noformat}
> org.apache.ignite.internal.util.future.GridCompoundFuture.futuresCount()
> line: 3582 0,036 272 938 246
>org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete()
> line: 2822 0,036 272 938 246
>
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(IgniteInternalFuture)
> line: 142 2 0,036 272 938 246
>
> org.apache.ignite.internal.util.future.GridCompoundFuture.apply(Object) line:
> 43 2 0,036 272 938 246
>
> org.apache.ignite.internal.util.future.GridFutureAdapter.notifyListener(IgniteInClosure)
> line: 4072 0,036 272 938 246
>
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblock(Object)
> line: 355 2 0,036 272 938 246
>
> org.apache.ignite.internal.util.future.GridFutureAdapter.unblockAll(GridFutureAdapter$Node)
> line: 343 2 0,036 272 938 246
>
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(Object,
> Throwable, boolean) line: 5202 0,036 272 938 246
>
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(Object,
> Throwable) line: 498 2 0,036 272 938 246
>
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone() line: 464
> 2 0,036 272 938 246
>
> org.apache.ignite.internal.util.IgniteUtils.lambda$wrapIgniteFuture$3(Runnable,
> GridFutureAdapter) line: 11730 2 0,036 272 938 246
>
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor$Worker)
> line: 1149 2 0,036 272 938 246
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run() line: 6242
> 0,036 272 938 246
>java.lang.Thread.run() line: 748
> 2 0,036 272 938 246
> {noformat}
> You can see that the method {{checkComplete}} was freezed on 272 938 246
> microseconds in two times invocations.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-15021) Apache Rat plugin does not check full text license
[ https://issues.apache.org/jira/browse/IGNITE-15021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-15021: --- Reviewer: Semyon Danilov > Apache Rat plugin does not check full text license > -- > > Key: IGNITE-15021 > URL: https://issues.apache.org/jira/browse/IGNITE-15021 > Project: Ignite > Issue Type: Bug >Reporter: Peter Ivanov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently, Apache Rat plugin configuration matches not full text of license > from settings, but overall AL2.0 license header. Thus, some files missed > check. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15021) Apache Rat plugin does not check full text license
[ https://issues.apache.org/jira/browse/IGNITE-15021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-15021: --- Fix Version/s: 3.0.0-alpha3 > Apache Rat plugin does not check full text license > -- > > Key: IGNITE-15021 > URL: https://issues.apache.org/jira/browse/IGNITE-15021 > Project: Ignite > Issue Type: Bug >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 10m > Remaining Estimate: 0h > > Currently, Apache Rat plugin configuration matches not full text of license > from settings, but overall AL2.0 license header. Thus, some files missed > check. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15021) Apache Rat plugin does not check full text license
[ https://issues.apache.org/jira/browse/IGNITE-15021?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-15021: --- Labels: ignite-3 (was: ) > Apache Rat plugin does not check full text license > -- > > Key: IGNITE-15021 > URL: https://issues.apache.org/jira/browse/IGNITE-15021 > Project: Ignite > Issue Type: Bug >Reporter: Peter Ivanov >Assignee: Peter Ivanov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > Currently, Apache Rat plugin configuration matches not full text of license > from settings, but overall AL2.0 license header. Thus, some files missed > check. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (IGNITE-14408) Vault based on custom persistent storage
[
https://issues.apache.org/jira/browse/IGNITE-14408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17370571#comment-17370571
]
Ivan Bessonov commented on IGNITE-14408:
[~apolovtcev] you have my approve as well, thank you for the contribution.
> Vault based on custom persistent storage
> -
>
> Key: IGNITE-14408
> URL: https://issues.apache.org/jira/browse/IGNITE-14408
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Vyacheslav Koptilin
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: iep-74, ignite-3
> Fix For: 3.0.0-alpha3
>
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> Implement the {{VaultService}} using the RocksDB as the underlying persistent
> storage.
>
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Created] (IGNITE-15019) ITNodeTest.testFollowerStartStopFollowing is flaky
Ivan Bessonov created IGNITE-15019:
--
Summary: ITNodeTest.testFollowerStartStopFollowing is flaky
Key: IGNITE-15019
URL: https://issues.apache.org/jira/browse/IGNITE-15019
Project: Ignite
Issue Type: Bug
Affects Versions: 3.0.0-alpha2
Reporter: Ivan Bessonov
{code:java}
[ERROR]
org.apache.ignite.raft.jraft.core.ITNodeTest.testFollowerStartStopFollowing
Time elapsed: 1.557 s <<< FAILURE!
org.opentest4j.AssertionFailedError: expected: <2> but was: <3>
at
org.apache.ignite.raft.jraft.core.ITNodeTest.testFollowerStartStopFollowing(ITNodeTest.java:2686)
{code}
This is all I have from logs. Must be a race somewhere
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (IGNITE-14094) Configuration storage interface
[ https://issues.apache.org/jira/browse/IGNITE-14094?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-14094: --- Labels: iep-55 (was: ) > Configuration storage interface > --- > > Key: IGNITE-14094 > URL: https://issues.apache.org/jira/browse/IGNITE-14094 > Project: Ignite > Issue Type: Sub-task >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Labels: iep-55 > Fix For: 3.0.0-alpha2 > > Time Spent: 2h > Remaining Estimate: 0h > > Create configuration storage interface with its probable "metastorage" > implementation in mind (meaning string keys and primitive values). Support > write retries (based on versioning). -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14121) Implement ability to generate configuration trees from arbitrary sources
[ https://issues.apache.org/jira/browse/IGNITE-14121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-14121: --- Labels: iep-55 (was: ) > Implement ability to generate configuration trees from arbitrary sources > > > Key: IGNITE-14121 > URL: https://issues.apache.org/jira/browse/IGNITE-14121 > Project: Ignite > Issue Type: Sub-task >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: iep-55 > Fix For: 3.0.0-alpha2 > > Time Spent: 20m > Remaining Estimate: 0h > > Prototype is already present here: > [https://github.com/apache/ignite-3/pull/34/files] > Now we need to adapt it to current configuration code and implement automatic > generation of construction method's implementations. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-13842) Creating the new configuration on old cluster
[ https://issues.apache.org/jira/browse/IGNITE-13842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-13842: --- Labels: iep-55 (was: ) > Creating the new configuration on old cluster > - > > Key: IGNITE-13842 > URL: https://issues.apache.org/jira/browse/IGNITE-13842 > Project: Ignite > Issue Type: Sub-task >Reporter: Anton Kalashnikov >Priority: Major > Labels: iep-55 > > Do we need the ability to create a new configuration/property on the working > cluster? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14791) Support byte[] configuration values
[ https://issues.apache.org/jira/browse/IGNITE-14791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-14791: --- Labels: iep-55 ignite-3 (was: ignite-3) > Support byte[] configuration values > --- > > Key: IGNITE-14791 > URL: https://issues.apache.org/jira/browse/IGNITE-14791 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 3.0.0-alpha2 >Reporter: Ivan Bessonov >Assignee: Aleksandr Polovtcev >Priority: Major > Labels: iep-55, ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 1h > Remaining Estimate: 0h > > Right now "smallest" array type that we have is int[], it may not be > convenient for some use-cases. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-14657) Add README.md to configuration module
[ https://issues.apache.org/jira/browse/IGNITE-14657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-14657: --- Labels: iep-55 (was: ) > Add README.md to configuration module > - > > Key: IGNITE-14657 > URL: https://issues.apache.org/jira/browse/IGNITE-14657 > Project: Ignite > Issue Type: Sub-task >Affects Versions: 3.0.0-alpha1 >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: iep-55 > Fix For: 3.0.0-alpha2 > > Time Spent: 50m > Remaining Estimate: 0h > > Add README.md to configuration module -- This message was sent by Atlassian Jira (v8.3.4#803005)
