[jira] [Created] (IGNITE-16809) .NET CancellationToken on Async methods
Jerome Isaac Haltom created IGNITE-16809: Summary: .NET CancellationToken on Async methods Key: IGNITE-16809 URL: https://issues.apache.org/jira/browse/IGNITE-16809 Project: Ignite Issue Type: Improvement Components: thin client Affects Versions: 2.12 Reporter: Jerome Isaac Haltom The .NET ThinClient API has numerous async methods, but none seem to support cancellation. I suspect they could and probably should. Each should accept a CancellationToken parameter. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16592) Add ignite-parent pom and bom to a release lifecycle
[ https://issues.apache.org/jira/browse/IGNITE-16592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-16592: - Release Note: Added ignite-parent pom and bom artifacts to the Ignite release lifecycle (was: Added ignite-parent pom artifacto to the Ignite release lifecycle) > Add ignite-parent pom and bom to a release lifecycle > > > Key: IGNITE-16592 > URL: https://issues.apache.org/jira/browse/IGNITE-16592 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.13 > > Time Spent: 1h > Remaining Estimate: 0h > > Include the ignite-parent pom artefact and ignite-plugin-bom to the Ignite > release lifecycle. This is required to share basic Ignite dependency versions > and configuration properties to the Ignite extensions. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16592) Add ignite-parent pom and bom to a release lifecycle
[ https://issues.apache.org/jira/browse/IGNITE-16592?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-16592: - Release Note: Added ignite-parent pom artifacto to the Ignite release lifecycle > Add ignite-parent pom and bom to a release lifecycle > > > Key: IGNITE-16592 > URL: https://issues.apache.org/jira/browse/IGNITE-16592 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.13 > > Time Spent: 1h > Remaining Estimate: 0h > > Include the ignite-parent pom artefact and ignite-plugin-bom to the Ignite > release lifecycle. This is required to share basic Ignite dependency versions > and configuration properties to the Ignite extensions. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16592) Add ignite-parent pom and bom to a release lifecycle
[ https://issues.apache.org/jira/browse/IGNITE-16592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518433#comment-17518433 ] Maxim Muzafarov commented on IGNITE-16592: -- Merget to the master branch. Will be cherry-picked to 2.13 soon. > Add ignite-parent pom and bom to a release lifecycle > > > Key: IGNITE-16592 > URL: https://issues.apache.org/jira/browse/IGNITE-16592 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.13 > > Time Spent: 1h > Remaining Estimate: 0h > > Include the ignite-parent pom artefact and ignite-plugin-bom to the Ignite > release lifecycle. This is required to share basic Ignite dependency versions > and configuration properties to the Ignite extensions. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16601) The CLI uses a direct java call to run the node ignoring the JAVA_HOME variable.
[ https://issues.apache.org/jira/browse/IGNITE-16601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16601: - Ignite Flags: (was: Release Notes Required) > The CLI uses a direct java call to run the node ignoring the JAVA_HOME > variable. > > > Key: IGNITE-16601 > URL: https://issues.apache.org/jira/browse/IGNITE-16601 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-alpha4 >Reporter: Fedor Malchikov >Priority: Blocker > Labels: ignite-3, ignite-3-cli-tool > > As a result, working on environments where java is not directly installed or > several versions of java are used is significantly complicated. As far as I > know, in version 2, overriding java_home was the main method of switching > between java versions in the system. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16598) CLI ignores an incorrect repository passed via --repo
[ https://issues.apache.org/jira/browse/IGNITE-16598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16598: - Ignite Flags: (was: Docs Required,Release Notes Required) > CLI ignores an incorrect repository passed via --repo > - > > Key: IGNITE-16598 > URL: https://issues.apache.org/jira/browse/IGNITE-16598 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-alpha4 >Reporter: Fedor Malchikov >Priority: Critical > Labels: ignite-3, ignite-3-cli-tool > > prom1se@prom1se-PC276:~/apache/ignite-3/modules/cli/target$ ls ~/temp/test > ls: cannot access '/home/prom1se/temp/test': No such file or directory > prom1se@prom1se-PC276:~/apache/ignite-3/modules/cli/target$ ./ignite init > --repo=file:~/temp/test > Creating directories... Done! > +++ > | Binaries Directory | > /home/prom1se/apache/ignite-3/modules/cli/target/ignite-bin| > +++ > | Work Directory | > /home/prom1se/apache/ignite-3/modules/cli/target/ignite-work | > +++ > | Config Directory | > /home/prom1se/apache/ignite-3/modules/cli/target/ignite-config | > +++ > | Log Directory | > /home/prom1se/apache/ignite-3/modules/cli/target/ignite-log| > +++ > Installing org.apache.ignite:ignite-runner:3.0.0-SNAPSHOT... > |=> > | 6%^C > No errors or warnings, the cli immediately started initialization from the > local maven cache. > It seems to me that this behavior is incorrect, and the utility should stop > working in case of an incorrectly passed repo parameter. Otherwise, the user > may get the wrong version of the product that he expects. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16735) .NET: Thin 3.0: Implement Compute Grid for .NET thin client
[ https://issues.apache.org/jira/browse/IGNITE-16735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-16735: --- Assignee: Pavel Tupitsyn > .NET: Thin 3.0: Implement Compute Grid for .NET thin client > --- > > Key: IGNITE-16735 > URL: https://issues.apache.org/jira/browse/IGNITE-16735 > Project: Ignite > Issue Type: New Feature > Components: compute, thin client >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > Need to implement functionality similiar to Java's > org.apache.ignite.compute.IgniteCompute for .NET thin client. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] (IGNITE-16771) Thin 3.0: Compute cluster awareness
[ https://issues.apache.org/jira/browse/IGNITE-16771 ] Pavel Tupitsyn deleted comment on IGNITE-16771: - was (Author: ptupitsyn): [~isapego] please review. > Thin 3.0: Compute cluster awareness > --- > > Key: IGNITE-16771 > URL: https://issues.apache.org/jira/browse/IGNITE-16771 > Project: Ignite > Issue Type: Improvement > Components: compute, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > Currently, all Compute operations go through the default node. Improve client > compute with cluster awareness: > * Correspond client connections with node id (extend handshake) > * *Compute.Execute*: match specified set of nodes against active connections. > If there are matches, pick random. Otherwise, use default connection and let > the server handle node mapping. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16598) CLI ignores an incorrect repository passed via --repo
[ https://issues.apache.org/jira/browse/IGNITE-16598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16598: - Epic Link: IGNITE-16807 > CLI ignores an incorrect repository passed via --repo > - > > Key: IGNITE-16598 > URL: https://issues.apache.org/jira/browse/IGNITE-16598 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-alpha4 >Reporter: Fedor Malchikov >Priority: Critical > Labels: ignite-3, ignite-3-cli-tool > > prom1se@prom1se-PC276:~/apache/ignite-3/modules/cli/target$ ls ~/temp/test > ls: cannot access '/home/prom1se/temp/test': No such file or directory > prom1se@prom1se-PC276:~/apache/ignite-3/modules/cli/target$ ./ignite init > --repo=file:~/temp/test > Creating directories... Done! > +++ > | Binaries Directory | > /home/prom1se/apache/ignite-3/modules/cli/target/ignite-bin| > +++ > | Work Directory | > /home/prom1se/apache/ignite-3/modules/cli/target/ignite-work | > +++ > | Config Directory | > /home/prom1se/apache/ignite-3/modules/cli/target/ignite-config | > +++ > | Log Directory | > /home/prom1se/apache/ignite-3/modules/cli/target/ignite-log| > +++ > Installing org.apache.ignite:ignite-runner:3.0.0-SNAPSHOT... > |=> > | 6%^C > No errors or warnings, the cli immediately started initialization from the > local maven cache. > It seems to me that this behavior is incorrect, and the utility should stop > working in case of an incorrectly passed repo parameter. Otherwise, the user > may get the wrong version of the product that he expects. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16601) The CLI uses a direct java call to run the node ignoring the JAVA_HOME variable.
[ https://issues.apache.org/jira/browse/IGNITE-16601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16601: - Epic Link: IGNITE-16807 > The CLI uses a direct java call to run the node ignoring the JAVA_HOME > variable. > > > Key: IGNITE-16601 > URL: https://issues.apache.org/jira/browse/IGNITE-16601 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-alpha4 >Reporter: Fedor Malchikov >Priority: Blocker > Labels: ignite-3, ignite-3-cli-tool > > As a result, working on environments where java is not directly installed or > several versions of java are used is significantly complicated. As far as I > know, in version 2, overriding java_home was the main method of switching > between java versions in the system. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16601) The CLI uses a direct java call to run the node ignoring the JAVA_HOME variable.
[ https://issues.apache.org/jira/browse/IGNITE-16601?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16601: - Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > The CLI uses a direct java call to run the node ignoring the JAVA_HOME > variable. > > > Key: IGNITE-16601 > URL: https://issues.apache.org/jira/browse/IGNITE-16601 > Project: Ignite > Issue Type: Bug >Affects Versions: 3.0.0-alpha4 >Reporter: Fedor Malchikov >Priority: Blocker > Labels: ignite-3, ignite-3-cli-tool > > As a result, working on environments where java is not directly installed or > several versions of java are used is significantly complicated. As far as I > know, in version 2, overriding java_home was the main method of switching > between java versions in the system. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16791) Additional source directories in the ingite-tools module not covered by checkstyle rules
[ https://issues.apache.org/jira/browse/IGNITE-16791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov updated IGNITE-16791: - Ignite Flags: (was: Docs Required,Release Notes Required) > Additional source directories in the ingite-tools module not covered by > checkstyle rules > > > Key: IGNITE-16791 > URL: https://issues.apache.org/jira/browse/IGNITE-16791 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > The following directories of the ignite-tools module are not checked by > checkstyle: > > src/main/java8 > > src/main/java11 > > src/main/java15 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16791) Additional source directories in the ingite-tools module not covered by checkstyle rules
[ https://issues.apache.org/jira/browse/IGNITE-16791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518287#comment-17518287 ] Maxim Muzafarov commented on IGNITE-16791: -- Merged to the master branch. > Additional source directories in the ingite-tools module not covered by > checkstyle rules > > > Key: IGNITE-16791 > URL: https://issues.apache.org/jira/browse/IGNITE-16791 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > The following directories of the ignite-tools module are not checked by > checkstyle: > > src/main/java8 > > src/main/java11 > > src/main/java15 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16808) SQL insert fails if it contains OffsetDateTime class value
[
https://issues.apache.org/jira/browse/IGNITE-16808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-16808:
Description:
Reproducer:
{code:java}
/** */
public class OffsetDateTimeIndexTest extends AbstractIndexingCommonTest {
/** */
@Test
public void test() throws Exception {
IgniteEx ignite = startGrids(2);
ignite.createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME)
.setIndexedTypes(String.class, Data.class).setSqlSchema("PUBLIC"));
SqlFieldsQuery qry = new SqlFieldsQuery("INSERT INTO PUBLIC.DATA(_key,
str, offsetDateTime) values(?, ?, ?)").setArgs("0", "0", OffsetDateTime.now());
ignite.context().query().querySqlFields(qry, false).getAll();
}
public static class Data implements Serializable {
/** Serial version UID. */
private static final long serialVersionUID = 1L;
/** */
@QuerySqlField(index = true)
public String str;
/** */
@QuerySqlField(index = true)
public OffsetDateTime offsetDateTime;
}
}
{code}
Exception:
{code:java}
class org.apache.ignite.internal.processors.query.IgniteSQLException: Value
conversion failed [column=OFFSETDATETIME, from=java.time.OffsetDateTime,
to=java.time.OffsetDateTime]
at
org.apache.ignite.internal.processors.query.h2.dml.DmlUtils.convert(DmlUtils.java:157)
at
org.apache.ignite.internal.processors.query.h2.dml.UpdatePlan.processRow(UpdatePlan.java:263)
at
org.apache.ignite.internal.processors.query.h2.dml.DmlUtils.dmlDoInsert(DmlUtils.java:212)
at
org.apache.ignite.internal.processors.query.h2.dml.DmlUtils.processSelectResult(DmlUtils.java:185)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdateNonTransactional(IgniteH2Indexing.java:2902)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdate(IgniteH2Indexing.java:2747)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdateDistributed(IgniteH2Indexing.java:2673)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeDml(IgniteH2Indexing.java:1263)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1185)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:3005)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:2988)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:3650)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$3(GridQueryProcessor.java:3022)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:3094)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2982)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2909)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2882)
at
org.apache.ignite.internal.processors.query.OffsetDateTimeIndexTest.test(OffsetDateTimeIndexTest.java:41)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2431)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to wrap
value[type=24, value=2022-04-06T19:27:05.226+03:00]
at
org.apache.ignite.internal.processors.query.h2.H2Utils.wrap(H2Utils.java:658)
at
org.apache.ignite.internal.processors.query.h2.H2Utils.convert(H2Utils.java:510)
at
org.apache.ignite.internal.processors.query.h2.dml.DmlUtils.convert(DmlUtils.java:146)
... 28 more
{code}
was:
Reproducer:
/** */
public class OffsetDateTimeIndexTest extends AbstractIndexingCommonTest {
/** */
@Test
[jira] [Created] (IGNITE-16808) SQL insert fails if it contains OffsetDateTime class
Mikhail Petrov created IGNITE-16808:
---
Summary: SQL insert fails if it contains OffsetDateTime class
Key: IGNITE-16808
URL: https://issues.apache.org/jira/browse/IGNITE-16808
Project: Ignite
Issue Type: Bug
Reporter: Mikhail Petrov
Reproducer:
/** */
public class OffsetDateTimeIndexTest extends AbstractIndexingCommonTest {
/** */
@Test
public void test() throws Exception {
IgniteEx ignite = startGrids(2);
ignite.createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME)
.setIndexedTypes(String.class, Data.class).setSqlSchema("PUBLIC"));
SqlFieldsQuery qry = new SqlFieldsQuery("INSERT INTO PUBLIC.DATA(_key,
str, offsetDateTime) values(?, ?, ?)").setArgs("0", "0", OffsetDateTime.now());
ignite.context().query().querySqlFields(qry, false).getAll();
}
public static class Data implements Serializable {
/** Serial version UID. */
private static final long serialVersionUID = 1L;
/** */
@QuerySqlField(index = true)
public String str;
/** */
@QuerySqlField(index = true)
public OffsetDateTime offsetDateTime;
}
}
Exception:
{code:java}
class org.apache.ignite.internal.processors.query.IgniteSQLException: Value
conversion failed [column=OFFSETDATETIME, from=java.time.OffsetDateTime,
to=java.time.OffsetDateTime]
at
org.apache.ignite.internal.processors.query.h2.dml.DmlUtils.convert(DmlUtils.java:157)
at
org.apache.ignite.internal.processors.query.h2.dml.UpdatePlan.processRow(UpdatePlan.java:263)
at
org.apache.ignite.internal.processors.query.h2.dml.DmlUtils.dmlDoInsert(DmlUtils.java:212)
at
org.apache.ignite.internal.processors.query.h2.dml.DmlUtils.processSelectResult(DmlUtils.java:185)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdateNonTransactional(IgniteH2Indexing.java:2902)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdate(IgniteH2Indexing.java:2747)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdateDistributed(IgniteH2Indexing.java:2673)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeDml(IgniteH2Indexing.java:1263)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1185)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:3005)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:2988)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:3650)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$3(GridQueryProcessor.java:3022)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:3094)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2982)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2909)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2882)
at
org.apache.ignite.internal.processors.query.OffsetDateTimeIndexTest.test(OffsetDateTimeIndexTest.java:41)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2431)
at java.lang.Thread.run(Thread.java:748)
Caused by: class org.apache.ignite.IgniteCheckedException: Failed to wrap
value[type=24, value=2022-04-06T19:27:05.226+03:00]
at
org.apache.ignite.internal.processors.query.h2.H2Utils.wrap(H2Utils.java:658)
at
org.apache.ignite.internal.processors.query.h2.H2Utils.convert(H2Utils.java:510)
at
org.apache.ignite.internal.processors.query.h2.dml.DmlUtils.convert(DmlUtils.java:146)
... 28 more
{code}
--
This
[jira] [Updated] (IGNITE-16808) SQL insert fails if it contains OffsetDateTime class value
[
https://issues.apache.org/jira/browse/IGNITE-16808?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mikhail Petrov updated IGNITE-16808:
Summary: SQL insert fails if it contains OffsetDateTime class value (was:
SQL insert fails if it contains OffsetDateTime class)
> SQL insert fails if it contains OffsetDateTime class value
> --
>
> Key: IGNITE-16808
> URL: https://issues.apache.org/jira/browse/IGNITE-16808
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Priority: Major
>
> Reproducer:
> /** */
> public class OffsetDateTimeIndexTest extends AbstractIndexingCommonTest {
> /** */
> @Test
> public void test() throws Exception {
> IgniteEx ignite = startGrids(2);
> ignite.createCache(new CacheConfiguration<>(DEFAULT_CACHE_NAME)
> .setIndexedTypes(String.class,
> Data.class).setSqlSchema("PUBLIC"));
> SqlFieldsQuery qry = new SqlFieldsQuery("INSERT INTO
> PUBLIC.DATA(_key, str, offsetDateTime) values(?, ?, ?)").setArgs("0", "0",
> OffsetDateTime.now());
> ignite.context().query().querySqlFields(qry, false).getAll();
> }
> public static class Data implements Serializable {
> /** Serial version UID. */
> private static final long serialVersionUID = 1L;
> /** */
> @QuerySqlField(index = true)
> public String str;
> /** */
> @QuerySqlField(index = true)
> public OffsetDateTime offsetDateTime;
> }
> }
> Exception:
> {code:java}
> class org.apache.ignite.internal.processors.query.IgniteSQLException: Value
> conversion failed [column=OFFSETDATETIME, from=java.time.OffsetDateTime,
> to=java.time.OffsetDateTime]
> at
> org.apache.ignite.internal.processors.query.h2.dml.DmlUtils.convert(DmlUtils.java:157)
> at
> org.apache.ignite.internal.processors.query.h2.dml.UpdatePlan.processRow(UpdatePlan.java:263)
> at
> org.apache.ignite.internal.processors.query.h2.dml.DmlUtils.dmlDoInsert(DmlUtils.java:212)
> at
> org.apache.ignite.internal.processors.query.h2.dml.DmlUtils.processSelectResult(DmlUtils.java:185)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdateNonTransactional(IgniteH2Indexing.java:2902)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdate(IgniteH2Indexing.java:2747)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdateDistributed(IgniteH2Indexing.java:2673)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeDml(IgniteH2Indexing.java:1263)
> at
> org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1185)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:3005)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:2988)
> at
> org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:3650)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$3(GridQueryProcessor.java:3022)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:3094)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2982)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2909)
> at
> org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2882)
> at
> org.apache.ignite.internal.processors.query.OffsetDateTimeIndexTest.test(OffsetDateTimeIndexTest.java:41)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:498)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2431)
> at java.lang.Thread.run(Thread.java:748)
[jira] [Created] (IGNITE-16807) Ignite 3 Command Line Interface
Vyacheslav Koptilin created IGNITE-16807: Summary: Ignite 3 Command Line Interface Key: IGNITE-16807 URL: https://issues.apache.org/jira/browse/IGNITE-16807 Project: Ignite Issue Type: Epic Reporter: Vyacheslav Koptilin Assignee: Vyacheslav Koptilin -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16266) Add unique id for indexes
[ https://issues.apache.org/jira/browse/IGNITE-16266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518277#comment-17518277 ] Andrey Mashenkov commented on IGNITE-16266: --- [~zstan], I've left a comment to the PR. > Add unique id for indexes > - > > Key: IGNITE-16266 > URL: https://issues.apache.org/jira/browse/IGNITE-16266 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3, sql > Fix For: 3.0.0-alpha5 > > Time Spent: 2.5h > Remaining Estimate: 0h > > As of now we address to index by name even internally. It could lead read > another version of index which was dropped and created with another set of > column . Let's introduce unique id (as we already have for tables) which > could be accessed only internally and use as identifier of indexes. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16806) Cache put/SQL table insert fails if SQL index created and LocalDateTime is used as value.
Mikhail Petrov created IGNITE-16806:
---
Summary: Cache put/SQL table insert fails if SQL index created and
LocalDateTime is used as value.
Key: IGNITE-16806
URL: https://issues.apache.org/jira/browse/IGNITE-16806
Project: Ignite
Issue Type: Bug
Reporter: Mikhail Petrov
Reproducer:
{code:java}
/** */
public class LocalDateIndexTest extends AbstractIndexingCommonTest {
/** */
@Test
public void test() throws Exception {
IgniteEx ignite = startGrids(2);
SqlFieldsQuery qry = new SqlFieldsQuery(
"CREATE TABLE DATA (STR VARCHAR PRIMARY KEY, LOCDATETIME TIMESTAMP)
WITH" +
" \"KEY_TYPE=java.lang.String" +
",
VALUE_TYPE=org.apache.ignite.internal.processors.query.LocalDateIndexTest$Data"
+
", CACHE_NAME=" + DEFAULT_CACHE_NAME + "\"");
ignite.context().query().querySqlFields(qry, false).getAll();
qry = new SqlFieldsQuery("CREATE INDEX TEST_IDX ON DATA(LOCDATETIME
DESC);");
ignite.context().query().querySqlFields(qry, false).getAll();
//ignite.cache(DEFAULT_CACHE_NAME).put("0", new Data("0",
LocalDateTime.MAX));
qry = new SqlFieldsQuery("INSERT INTO DATA(_key, str, locDateTime)
values(?, ?, ?)").setArgs("0", "0", LocalDateTime.MAX);
ignite.context().query().querySqlFields(qry, false).getAll();
}
public static class Data implements Serializable {
/** Serial version UID. */
private static final long serialVersionUID = 1L;
/** */
public String str;
/** */
public LocalDateTime locDateTime;
/** */
public Data(String str, LocalDateTime locDateTime) {
this.str = str;
this.locDateTime = locDateTime;
}
}
}
{code}
Exception:
{code:java}
class org.apache.ignite.internal.processors.query.IgniteSQLException: Type for
a column 'LOCDATETIME' is not compatible with index definition. Expected
'Timestamp', actual type 'LocalDateTime'
at
org.apache.ignite.internal.processors.query.QueryTypeDescriptorImpl.validateIndexes(QueryTypeDescriptorImpl.java:735)
at
org.apache.ignite.internal.processors.query.QueryTypeDescriptorImpl.validateKeyAndValue(QueryTypeDescriptorImpl.java:606)
at
org.apache.ignite.internal.processors.query.h2.dml.UpdatePlan.processRow(UpdatePlan.java:295)
at
org.apache.ignite.internal.processors.query.h2.dml.DmlUtils.dmlDoInsert(DmlUtils.java:212)
at
org.apache.ignite.internal.processors.query.h2.dml.DmlUtils.processSelectResult(DmlUtils.java:185)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdateNonTransactional(IgniteH2Indexing.java:2902)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdate(IgniteH2Indexing.java:2747)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeUpdateDistributed(IgniteH2Indexing.java:2673)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.executeDml(IgniteH2Indexing.java:1263)
at
org.apache.ignite.internal.processors.query.h2.IgniteH2Indexing.querySqlFields(IgniteH2Indexing.java:1185)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:3005)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor$2.applyx(GridQueryProcessor.java:2988)
at
org.apache.ignite.internal.util.lang.IgniteOutClosureX.apply(IgniteOutClosureX.java:36)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuery(GridQueryProcessor.java:3650)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.lambda$querySqlFields$3(GridQueryProcessor.java:3022)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.executeQuerySafe(GridQueryProcessor.java:3094)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2982)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2909)
at
org.apache.ignite.internal.processors.query.GridQueryProcessor.querySqlFields(GridQueryProcessor.java:2882)
at
org.apache.ignite.internal.processors.query.LocalDateIndexTest.test(LocalDateIndexTest.java:50)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
[jira] [Assigned] (IGNITE-16550) Redesign SchemaRegistry to use causality tokens
[
https://issues.apache.org/jira/browse/IGNITE-16550?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov reassigned IGNITE-16550:
--
Assignee: Vladislav Pyatkov
> Redesign SchemaRegistry to use causality tokens
> ---
>
> Key: IGNITE-16550
> URL: https://issues.apache.org/jira/browse/IGNITE-16550
> Project: Ignite
> Issue Type: Improvement
>Reporter: Vladislav Pyatkov
>Assignee: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> SchemaRegistry designed before the causality logic aspired(IGNITE-16391), by
> the reason all method do not apply a token and work synchronously.
> After the redesign part of the methods should be removed
> (SchemaRegistry#lastSchemaVersion, SchemaRegistry#waitLatestSchema), others
> should entirely depend on causality.
> Possibly the new methods will return futures.
> UPD:
> It was decided that in the current ticket it's worth to decouple Schema logic
> from the {{TableManager}} and create a new manager called {{SchemaManager}},
> so we can integrate causality tokens logic to the {{SchemaManager}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16799) SQL Calcite: ArrayIndexOutOfBoundsException when serializing MINUS_DATE operation
[
https://issues.apache.org/jira/browse/IGNITE-16799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518212#comment-17518212
]
Aleksey Plekhanov commented on IGNITE-16799:
[~korlov], can you please review the patch?
> SQL Calcite: ArrayIndexOutOfBoundsException when serializing MINUS_DATE
> operation
> --
>
> Key: IGNITE-16799
> URL: https://issues.apache.org/jira/browse/IGNITE-16799
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If you run the following test:
>
> {code:java}
> // ProjectFilterScanMergePlannerTest.java
> @Test
> public void testProjectWithDateMinusExprMerge() throws Exception {
> assertPlan("SELECT (DATE '2021-03-01' - DATE '2021-01-01') months FROM
> tbl WHERE c = 0", publicSchema, isInstanceOf(IgniteTableScan.class)
> .and(scan -> scan.projects() != null)
> .and(scan -> scan.condition() != null)
> .and(scan -> ImmutableBitSet.of(2).equals(scan.requiredColumns()))
> );
> } {code}
> , you will get the following exception:
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 2
> at
> com.google.common.collect.RegularImmutableList.get(RegularImmutableList.java:60)
> at
> org.apache.calcite.rex.RexCallBinding.getOperandType(RexCallBinding.java:149)
> at
> org.apache.calcite.sql.type.OrdinalReturnTypeInference.inferReturnType(OrdinalReturnTypeInference.java:40)
> at
> org.apache.calcite.sql.type.SqlTypeTransformCascade.inferReturnType(SqlTypeTransformCascade.java:58)
> at
> org.apache.calcite.sql.SqlOperator.inferReturnType(SqlOperator.java:537)
> at
> org.apache.calcite.rex.RexBuilder.deriveReturnType(RexBuilder.java:290)
> at
> org.apache.ignite.internal.processors.query.calcite.externalize.RelJson.toRex(RelJson.java:472)
> at
> org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader$RelInputImpl.getExpressionList(RelJsonReader.java:248)
> {noformat}
>
> This caused by definition of the MINUS_DATE operation:
> {code:java}
> public SqlDatetimeSubtractionOperator() {
> super(
> "-",
> SqlKind.MINUS,
> 40,
> true,
> ReturnTypes.ARG2_NULLABLE,
> InferTypes.FIRST_KNOWN, OperandTypes.MINUS_DATE_OPERATOR);
> } {code}
> The return type should be inferred from the 3rd argument, but it appears
> after converting AST -> REX, the resulting expression has 2 arguments only.
> This seems to be a bug in Calcite Framework, but we could avoid this problem
> by serializing the operation type for each operation.
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16799) SQL Calcite: ArrayIndexOutOfBoundsException when serializing MINUS_DATE operation
[
https://issues.apache.org/jira/browse/IGNITE-16799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16799:
---
Labels: calcite calcite2-required calcite3-required (was:
calcite2-required calcite3-required)
> SQL Calcite: ArrayIndexOutOfBoundsException when serializing MINUS_DATE
> operation
> --
>
> Key: IGNITE-16799
> URL: https://issues.apache.org/jira/browse/IGNITE-16799
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If you run the following test:
>
> {code:java}
> // ProjectFilterScanMergePlannerTest.java
> @Test
> public void testProjectWithDateMinusExprMerge() throws Exception {
> assertPlan("SELECT (DATE '2021-03-01' - DATE '2021-01-01') months FROM
> tbl WHERE c = 0", publicSchema, isInstanceOf(IgniteTableScan.class)
> .and(scan -> scan.projects() != null)
> .and(scan -> scan.condition() != null)
> .and(scan -> ImmutableBitSet.of(2).equals(scan.requiredColumns()))
> );
> } {code}
> , you will get the following exception:
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 2
> at
> com.google.common.collect.RegularImmutableList.get(RegularImmutableList.java:60)
> at
> org.apache.calcite.rex.RexCallBinding.getOperandType(RexCallBinding.java:149)
> at
> org.apache.calcite.sql.type.OrdinalReturnTypeInference.inferReturnType(OrdinalReturnTypeInference.java:40)
> at
> org.apache.calcite.sql.type.SqlTypeTransformCascade.inferReturnType(SqlTypeTransformCascade.java:58)
> at
> org.apache.calcite.sql.SqlOperator.inferReturnType(SqlOperator.java:537)
> at
> org.apache.calcite.rex.RexBuilder.deriveReturnType(RexBuilder.java:290)
> at
> org.apache.ignite.internal.processors.query.calcite.externalize.RelJson.toRex(RelJson.java:472)
> at
> org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader$RelInputImpl.getExpressionList(RelJsonReader.java:248)
> {noformat}
>
> This caused by definition of the MINUS_DATE operation:
> {code:java}
> public SqlDatetimeSubtractionOperator() {
> super(
> "-",
> SqlKind.MINUS,
> 40,
> true,
> ReturnTypes.ARG2_NULLABLE,
> InferTypes.FIRST_KNOWN, OperandTypes.MINUS_DATE_OPERATOR);
> } {code}
> The return type should be inferred from the 3rd argument, but it appears
> after converting AST -> REX, the resulting expression has 2 arguments only.
> This seems to be a bug in Calcite Framework, but we could avoid this problem
> by serializing the operation type for each operation.
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16799) SQL Calcite: ArrayIndexOutOfBoundsException when serializing MINUS_DATE operation
[
https://issues.apache.org/jira/browse/IGNITE-16799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov updated IGNITE-16799:
---
Labels: calcite2-required calcite3-required (was: )
> SQL Calcite: ArrayIndexOutOfBoundsException when serializing MINUS_DATE
> operation
> --
>
> Key: IGNITE-16799
> URL: https://issues.apache.org/jira/browse/IGNITE-16799
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite2-required, calcite3-required
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If you run the following test:
>
> {code:java}
> // ProjectFilterScanMergePlannerTest.java
> @Test
> public void testProjectWithDateMinusExprMerge() throws Exception {
> assertPlan("SELECT (DATE '2021-03-01' - DATE '2021-01-01') months FROM
> tbl WHERE c = 0", publicSchema, isInstanceOf(IgniteTableScan.class)
> .and(scan -> scan.projects() != null)
> .and(scan -> scan.condition() != null)
> .and(scan -> ImmutableBitSet.of(2).equals(scan.requiredColumns()))
> );
> } {code}
> , you will get the following exception:
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 2
> at
> com.google.common.collect.RegularImmutableList.get(RegularImmutableList.java:60)
> at
> org.apache.calcite.rex.RexCallBinding.getOperandType(RexCallBinding.java:149)
> at
> org.apache.calcite.sql.type.OrdinalReturnTypeInference.inferReturnType(OrdinalReturnTypeInference.java:40)
> at
> org.apache.calcite.sql.type.SqlTypeTransformCascade.inferReturnType(SqlTypeTransformCascade.java:58)
> at
> org.apache.calcite.sql.SqlOperator.inferReturnType(SqlOperator.java:537)
> at
> org.apache.calcite.rex.RexBuilder.deriveReturnType(RexBuilder.java:290)
> at
> org.apache.ignite.internal.processors.query.calcite.externalize.RelJson.toRex(RelJson.java:472)
> at
> org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader$RelInputImpl.getExpressionList(RelJsonReader.java:248)
> {noformat}
>
> This caused by definition of the MINUS_DATE operation:
> {code:java}
> public SqlDatetimeSubtractionOperator() {
> super(
> "-",
> SqlKind.MINUS,
> 40,
> true,
> ReturnTypes.ARG2_NULLABLE,
> InferTypes.FIRST_KNOWN, OperandTypes.MINUS_DATE_OPERATOR);
> } {code}
> The return type should be inferred from the 3rd argument, but it appears
> after converting AST -> REX, the resulting expression has 2 arguments only.
> This seems to be a bug in Calcite Framework, but we could avoid this problem
> by serializing the operation type for each operation.
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16799) SQL Calcite: ArrayIndexOutOfBoundsException when serializing MINUS_DATE operation
[
https://issues.apache.org/jira/browse/IGNITE-16799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aleksey Plekhanov reassigned IGNITE-16799:
--
Assignee: Aleksey Plekhanov
> SQL Calcite: ArrayIndexOutOfBoundsException when serializing MINUS_DATE
> operation
> --
>
> Key: IGNITE-16799
> URL: https://issues.apache.org/jira/browse/IGNITE-16799
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> If you run the following test:
>
> {code:java}
> // ProjectFilterScanMergePlannerTest.java
> @Test
> public void testProjectWithDateMinusExprMerge() throws Exception {
> assertPlan("SELECT (DATE '2021-03-01' - DATE '2021-01-01') months FROM
> tbl WHERE c = 0", publicSchema, isInstanceOf(IgniteTableScan.class)
> .and(scan -> scan.projects() != null)
> .and(scan -> scan.condition() != null)
> .and(scan -> ImmutableBitSet.of(2).equals(scan.requiredColumns()))
> );
> } {code}
> , you will get the following exception:
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 2
> at
> com.google.common.collect.RegularImmutableList.get(RegularImmutableList.java:60)
> at
> org.apache.calcite.rex.RexCallBinding.getOperandType(RexCallBinding.java:149)
> at
> org.apache.calcite.sql.type.OrdinalReturnTypeInference.inferReturnType(OrdinalReturnTypeInference.java:40)
> at
> org.apache.calcite.sql.type.SqlTypeTransformCascade.inferReturnType(SqlTypeTransformCascade.java:58)
> at
> org.apache.calcite.sql.SqlOperator.inferReturnType(SqlOperator.java:537)
> at
> org.apache.calcite.rex.RexBuilder.deriveReturnType(RexBuilder.java:290)
> at
> org.apache.ignite.internal.processors.query.calcite.externalize.RelJson.toRex(RelJson.java:472)
> at
> org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader$RelInputImpl.getExpressionList(RelJsonReader.java:248)
> {noformat}
>
> This caused by definition of the MINUS_DATE operation:
> {code:java}
> public SqlDatetimeSubtractionOperator() {
> super(
> "-",
> SqlKind.MINUS,
> 40,
> true,
> ReturnTypes.ARG2_NULLABLE,
> InferTypes.FIRST_KNOWN, OperandTypes.MINUS_DATE_OPERATOR);
> } {code}
> The return type should be inferred from the 3rd argument, but it appears
> after converting AST -> REX, the resulting expression has 2 arguments only.
> This seems to be a bug in Calcite Framework, but we could avoid this problem
> by serializing the operation type for each operation.
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16266) Add unique id for indexes
[ https://issues.apache.org/jira/browse/IGNITE-16266?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518147#comment-17518147 ] Konstantin Orlov commented on IGNITE-16266: --- [~zstan] , LGTM! > Add unique id for indexes > - > > Key: IGNITE-16266 > URL: https://issues.apache.org/jira/browse/IGNITE-16266 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3, sql > Fix For: 3.0.0-alpha5 > > Time Spent: 2h 20m > Remaining Estimate: 0h > > As of now we address to index by name even internally. It could lead read > another version of index which was dropped and created with another set of > column . Let's introduce unique id (as we already have for tables) which > could be accessed only internally and use as identifier of indexes. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16800) Support leader changing during rebalance
[ https://issues.apache.org/jira/browse/IGNITE-16800?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16800: - Epic Link: IGNITE-14209 > Support leader changing during rebalance > > > Key: IGNITE-16800 > URL: https://issues.apache.org/jira/browse/IGNITE-16800 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Priority: Major > > We need to start new rebalance, if leader changes during the current (when it > was in the catching up phase) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16362) Local state recovery
[ https://issues.apache.org/jira/browse/IGNITE-16362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16362: - Description: *Local state recovery* is changing local state in a way that every component on the node has its state configured and updated accordingly to cluster-wide configuration, topology, stored data, etc. and all the events that change this state and had already happened in the cluster to the moment in which the node tried to join the cluster. (was: *Local state recovery* is changing local state in a way that every component on the node has its state configured and updated accordingly to cluster-wide configuration, topology, stored data, etc. and all the events that change this state and had already happened in the cluster to the moment in which the node tried to join the cluster. s) > Local state recovery > > > Key: IGNITE-16362 > URL: https://issues.apache.org/jira/browse/IGNITE-16362 > Project: Ignite > Issue Type: Epic >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > *Local state recovery* is changing local state in a way that every component > on the node has its state configured and updated accordingly to cluster-wide > configuration, topology, stored data, etc. and all the events that change > this state and had already happened in the cluster to the moment in which the > node tried to join the cluster. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16362) Local state recovery
[ https://issues.apache.org/jira/browse/IGNITE-16362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16362: - Description: *Local state recovery* is changing local state in a way that every component on the node has its state configured and updated accordingly to cluster-wide configuration, topology, stored data, etc. and all the events that change this state and had already happened in the cluster to the moment in which the node tried to join the cluster. s was:*Local state recovery* is changing local state in a way that every component on the node has its state configured and updated accordingly to cluster-wide configuration, topology, stored data, etc. and all the events that change this state and had already happened in the cluster to the moment in which the node tried to join the cluster. > Local state recovery > > > Key: IGNITE-16362 > URL: https://issues.apache.org/jira/browse/IGNITE-16362 > Project: Ignite > Issue Type: Epic >Reporter: Denis Chudov >Priority: Major > Labels: ignite-3 > > *Local state recovery* is changing local state in a way that every component > on the node has its state configured and updated accordingly to cluster-wide > configuration, topology, stored data, etc. and all the events that change > this state and had already happened in the cluster to the moment in which the > node tried to join the cluster. > s -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16805) Cache Restarts 1 suite hangs
[
https://issues.apache.org/jira/browse/IGNITE-16805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-16805:
--
Description:
Cache Restarts 1 suite hangs on TeamCity due to
GridCacheAbstractNodeRestartSelfTest test
(testRestartWithPutFourNodesOneBackupsOffheapEvict)
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_CacheRestarts1=buildTypeHistoryList_IgniteTests24Java8=%3Cdefault%3E
{noformat}
Thread
[name="test-runner-#376077%near.GridCachePartitionedOptimisticTxNodeRestartTest%",
id=383240, state=WAITING, blockCnt=20, waitCnt=42]
Lock [object=java.lang.Thread@686cf8ad, ownerName=null, ownerId=-1]
at java.base@11.0.8/java.lang.Object.wait(Native Method)
at java.base@11.0.8/java.lang.Thread.join(Thread.java:1305)
at java.base@11.0.8/java.lang.Thread.join(Thread.java:1380)
at
o.a.i.i.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.checkRestartWithTx(GridCacheAbstractNodeRestartSelfTest.java:850)
at
o.a.i.i.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.testRestartWithTxTenNodesTwoBackups(GridCacheAbstractNodeRestartSelfTest.java:543)
at
o.a.i.i.processors.cache.distributed.near.GridCachePartitionedOptimisticTxNodeRestartTest.testRestartWithTxTenNodesTwoBackups(GridCachePartitionedOptimisticTxNodeRestartTest.java:141)
at
java.base@11.0.8/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base@11.0.8/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base@11.0.8/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base@11.0.8/java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
o.a.i.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2431)
at java.base@11.0.8/java.lang.Thread.run(Thread.java:834)
"test-runner-#376077%near.GridCachePartitionedOptimisticTxNodeRestartTest%"
#383240 prio=5 os_prio=0 cpu=649.37ms elapsed=6627.99s tid=0x7f69575ff000
nid=0x6474 waiting on condition [0x7f68edcc2000]
java.lang.Thread.State: WAITING (parking)
at jdk.internal.misc.Unsafe.park(java.base@11.0.8/Native Method)
- parking to wait for <0x87987d88> (a
java.util.concurrent.CountDownLatch$Sync)
at
java.util.concurrent.locks.LockSupport.park(java.base@11.0.8/LockSupport.java:194)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.8/AbstractQueuedSynchronizer.java:885)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(java.base@11.0.8/AbstractQueuedSynchronizer.java:1039)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(java.base@11.0.8/AbstractQueuedSynchronizer.java:1345)
at
java.util.concurrent.CountDownLatch.await(java.base@11.0.8/CountDownLatch.java:232)
at
org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:8106)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.grid(IgnitionEx.java:1657)
at org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1292)
at org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1270)
at org.apache.ignite.Ignition.allGrids(Ignition.java:503)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1563)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1550)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1542)
at
org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.checkRestartWithTx(GridCacheAbstractNodeRestartSelfTest.java:856)
at
org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.testRestartWithTxTenNodesTwoBackups(GridCacheAbstractNodeRestartSelfTest.java:543)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridCachePartitionedOptimisticTxNodeRestartTest.testRestartWithTxTenNodesTwoBackups(GridCachePartitionedOptimisticTxNodeRestartTest.java:141)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.8/Native
Method)
at
[jira] [Commented] (IGNITE-16592) Add ignite-parent pom and bom to a release lifecycle
[
https://issues.apache.org/jira/browse/IGNITE-16592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518123#comment-17518123
]
Ignite TC Bot commented on IGNITE-16592:
{panel:title=Branch: [pull/9942/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6507858]]
{panel}
{panel:title=Branch: [pull/9942/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6507057buildTypeId=IgniteTests24Java8_RunAll]
> Add ignite-parent pom and bom to a release lifecycle
>
>
> Key: IGNITE-16592
> URL: https://issues.apache.org/jira/browse/IGNITE-16592
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Fix For: 2.13
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> Include the ignite-parent pom artefact and ignite-plugin-bom to the Ignite
> release lifecycle. This is required to share basic Ignite dependency versions
> and configuration properties to the Ignite extensions.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16802) Raft log storage creates rocksdb instance per group
[ https://issues.apache.org/jira/browse/IGNITE-16802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr Polovtcev reassigned IGNITE-16802: Assignee: Aleksandr Polovtcev > Raft log storage creates rocksdb instance per group > --- > > Key: IGNITE-16802 > URL: https://issues.apache.org/jira/browse/IGNITE-16802 > Project: Ignite > Issue Type: Bug >Reporter: Semyon Danilov >Assignee: Aleksandr Polovtcev >Priority: Blocker > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > At this moment, every raft group creates RocksDBLogStorage which, in turn, > creates an instance of RocksDB without sharing resources with other log > storages. This inflicts memory overhead and leads to out of memory killer > killing process on TeamCity. > We need to use one rocksdb instance for all log storages -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16802) Raft log storage creates rocksdb instance per group
[ https://issues.apache.org/jira/browse/IGNITE-16802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov reassigned IGNITE-16802: Assignee: (was: Sergey Chugunov) > Raft log storage creates rocksdb instance per group > --- > > Key: IGNITE-16802 > URL: https://issues.apache.org/jira/browse/IGNITE-16802 > Project: Ignite > Issue Type: Bug >Reporter: Semyon Danilov >Priority: Blocker > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > At this moment, every raft group creates RocksDBLogStorage which, in turn, > creates an instance of RocksDB without sharing resources with other log > storages. This inflicts memory overhead and leads to out of memory killer > killing process on TeamCity. > We need to use one rocksdb instance for all log storages -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16802) Raft log storage creates rocksdb instance per group
[ https://issues.apache.org/jira/browse/IGNITE-16802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov reassigned IGNITE-16802: Assignee: Sergey Chugunov > Raft log storage creates rocksdb instance per group > --- > > Key: IGNITE-16802 > URL: https://issues.apache.org/jira/browse/IGNITE-16802 > Project: Ignite > Issue Type: Bug >Reporter: Semyon Danilov >Assignee: Sergey Chugunov >Priority: Blocker > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > At this moment, every raft group creates RocksDBLogStorage which, in turn, > creates an instance of RocksDB without sharing resources with other log > storages. This inflicts memory overhead and leads to out of memory killer > killing process on TeamCity. > We need to use one rocksdb instance for all log storages -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16805) Cache Restarts 1 suite hangs
[
https://issues.apache.org/jira/browse/IGNITE-16805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-16805:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> Cache Restarts 1 suite hangs
>
>
> Key: IGNITE-16805
> URL: https://issues.apache.org/jira/browse/IGNITE-16805
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Minor
>
> Cache Restarts 1 suite hangs on TeamCity
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_CacheRestarts1=buildTypeHistoryList_IgniteTests24Java8=%3Cdefault%3E
> {noformat}
> Thread
> [name="test-runner-#376077%near.GridCachePartitionedOptimisticTxNodeRestartTest%",
> id=383240, state=WAITING, blockCnt=20, waitCnt=42]
> Lock [object=java.lang.Thread@686cf8ad, ownerName=null, ownerId=-1]
> at java.base@11.0.8/java.lang.Object.wait(Native Method)
> at java.base@11.0.8/java.lang.Thread.join(Thread.java:1305)
> at java.base@11.0.8/java.lang.Thread.join(Thread.java:1380)
> at
> o.a.i.i.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.checkRestartWithTx(GridCacheAbstractNodeRestartSelfTest.java:850)
> at
> o.a.i.i.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.testRestartWithTxTenNodesTwoBackups(GridCacheAbstractNodeRestartSelfTest.java:543)
> at
> o.a.i.i.processors.cache.distributed.near.GridCachePartitionedOptimisticTxNodeRestartTest.testRestartWithTxTenNodesTwoBackups(GridCachePartitionedOptimisticTxNodeRestartTest.java:141)
> at
> java.base@11.0.8/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base@11.0.8/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base@11.0.8/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base@11.0.8/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> o.a.i.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2431)
> at java.base@11.0.8/java.lang.Thread.run(Thread.java:834)
>
> "test-runner-#376077%near.GridCachePartitionedOptimisticTxNodeRestartTest%"
> #383240 prio=5 os_prio=0 cpu=649.37ms elapsed=6627.99s tid=0x7f69575ff000
> nid=0x6474 waiting on condition [0x7f68edcc2000]
>java.lang.Thread.State: WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base@11.0.8/Native Method)
> - parking to wait for <0x87987d88> (a
> java.util.concurrent.CountDownLatch$Sync)
> at
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.8/LockSupport.java:194)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.8/AbstractQueuedSynchronizer.java:885)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(java.base@11.0.8/AbstractQueuedSynchronizer.java:1039)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(java.base@11.0.8/AbstractQueuedSynchronizer.java:1345)
> at
> java.util.concurrent.CountDownLatch.await(java.base@11.0.8/CountDownLatch.java:232)
> at
> org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:8106)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.grid(IgnitionEx.java:1657)
> at org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1292)
> at org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1270)
> at org.apache.ignite.Ignition.allGrids(Ignition.java:503)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1563)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1550)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1542)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.checkRestartWithTx(GridCacheAbstractNodeRestartSelfTest.java:856)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.testRestartWithTxTenNodesTwoBackups(GridCacheAbstractNodeRestartSelfTest.java:543)
> at
>
[jira] [Updated] (IGNITE-16805) Cache Restarts 1 suite hangs
[
https://issues.apache.org/jira/browse/IGNITE-16805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-16805:
--
Fix Version/s: 2.14
> Cache Restarts 1 suite hangs
>
>
> Key: IGNITE-16805
> URL: https://issues.apache.org/jira/browse/IGNITE-16805
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Minor
> Fix For: 2.14
>
>
> Cache Restarts 1 suite hangs on TeamCity
> https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_CacheRestarts1=buildTypeHistoryList_IgniteTests24Java8=%3Cdefault%3E
> {noformat}
> Thread
> [name="test-runner-#376077%near.GridCachePartitionedOptimisticTxNodeRestartTest%",
> id=383240, state=WAITING, blockCnt=20, waitCnt=42]
> Lock [object=java.lang.Thread@686cf8ad, ownerName=null, ownerId=-1]
> at java.base@11.0.8/java.lang.Object.wait(Native Method)
> at java.base@11.0.8/java.lang.Thread.join(Thread.java:1305)
> at java.base@11.0.8/java.lang.Thread.join(Thread.java:1380)
> at
> o.a.i.i.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.checkRestartWithTx(GridCacheAbstractNodeRestartSelfTest.java:850)
> at
> o.a.i.i.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.testRestartWithTxTenNodesTwoBackups(GridCacheAbstractNodeRestartSelfTest.java:543)
> at
> o.a.i.i.processors.cache.distributed.near.GridCachePartitionedOptimisticTxNodeRestartTest.testRestartWithTxTenNodesTwoBackups(GridCachePartitionedOptimisticTxNodeRestartTest.java:141)
> at
> java.base@11.0.8/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
> Method)
> at
> java.base@11.0.8/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at
> java.base@11.0.8/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base@11.0.8/java.lang.reflect.Method.invoke(Method.java:566)
> at
> org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at
> org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at
> org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at
> org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at
> o.a.i.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2431)
> at java.base@11.0.8/java.lang.Thread.run(Thread.java:834)
>
> "test-runner-#376077%near.GridCachePartitionedOptimisticTxNodeRestartTest%"
> #383240 prio=5 os_prio=0 cpu=649.37ms elapsed=6627.99s tid=0x7f69575ff000
> nid=0x6474 waiting on condition [0x7f68edcc2000]
>java.lang.Thread.State: WAITING (parking)
> at jdk.internal.misc.Unsafe.park(java.base@11.0.8/Native Method)
> - parking to wait for <0x87987d88> (a
> java.util.concurrent.CountDownLatch$Sync)
> at
> java.util.concurrent.locks.LockSupport.park(java.base@11.0.8/LockSupport.java:194)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.8/AbstractQueuedSynchronizer.java:885)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(java.base@11.0.8/AbstractQueuedSynchronizer.java:1039)
> at
> java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(java.base@11.0.8/AbstractQueuedSynchronizer.java:1345)
> at
> java.util.concurrent.CountDownLatch.await(java.base@11.0.8/CountDownLatch.java:232)
> at
> org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:8106)
> at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.grid(IgnitionEx.java:1657)
> at org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1292)
> at org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1270)
> at org.apache.ignite.Ignition.allGrids(Ignition.java:503)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1563)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1550)
> at
> org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1542)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.checkRestartWithTx(GridCacheAbstractNodeRestartSelfTest.java:856)
> at
> org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.testRestartWithTxTenNodesTwoBackups(GridCacheAbstractNodeRestartSelfTest.java:543)
> at
>
[jira] [Updated] (IGNITE-16805) Cache Restarts 1 suite hangs
[
https://issues.apache.org/jira/browse/IGNITE-16805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-16805:
--
Description:
Cache Restarts 1 suite hangs on TeamCity
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_CacheRestarts1=buildTypeHistoryList_IgniteTests24Java8=%3Cdefault%3E
{noformat}
Thread
[name="test-runner-#376077%near.GridCachePartitionedOptimisticTxNodeRestartTest%",
id=383240, state=WAITING, blockCnt=20, waitCnt=42]
Lock [object=java.lang.Thread@686cf8ad, ownerName=null, ownerId=-1]
at java.base@11.0.8/java.lang.Object.wait(Native Method)
at java.base@11.0.8/java.lang.Thread.join(Thread.java:1305)
at java.base@11.0.8/java.lang.Thread.join(Thread.java:1380)
at
o.a.i.i.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.checkRestartWithTx(GridCacheAbstractNodeRestartSelfTest.java:850)
at
o.a.i.i.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.testRestartWithTxTenNodesTwoBackups(GridCacheAbstractNodeRestartSelfTest.java:543)
at
o.a.i.i.processors.cache.distributed.near.GridCachePartitionedOptimisticTxNodeRestartTest.testRestartWithTxTenNodesTwoBackups(GridCachePartitionedOptimisticTxNodeRestartTest.java:141)
at
java.base@11.0.8/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
at
java.base@11.0.8/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at
java.base@11.0.8/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base@11.0.8/java.lang.reflect.Method.invoke(Method.java:566)
at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at
o.a.i.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2431)
at java.base@11.0.8/java.lang.Thread.run(Thread.java:834)
"test-runner-#376077%near.GridCachePartitionedOptimisticTxNodeRestartTest%"
#383240 prio=5 os_prio=0 cpu=649.37ms elapsed=6627.99s tid=0x7f69575ff000
nid=0x6474 waiting on condition [0x7f68edcc2000]
java.lang.Thread.State: WAITING (parking)
at jdk.internal.misc.Unsafe.park(java.base@11.0.8/Native Method)
- parking to wait for <0x87987d88> (a
java.util.concurrent.CountDownLatch$Sync)
at
java.util.concurrent.locks.LockSupport.park(java.base@11.0.8/LockSupport.java:194)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.8/AbstractQueuedSynchronizer.java:885)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(java.base@11.0.8/AbstractQueuedSynchronizer.java:1039)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(java.base@11.0.8/AbstractQueuedSynchronizer.java:1345)
at
java.util.concurrent.CountDownLatch.await(java.base@11.0.8/CountDownLatch.java:232)
at
org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:8106)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.grid(IgnitionEx.java:1657)
at org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1292)
at org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1270)
at org.apache.ignite.Ignition.allGrids(Ignition.java:503)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1563)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1550)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1542)
at
org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.checkRestartWithTx(GridCacheAbstractNodeRestartSelfTest.java:856)
at
org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.testRestartWithTxTenNodesTwoBackups(GridCacheAbstractNodeRestartSelfTest.java:543)
at
org.apache.ignite.internal.processors.cache.distributed.near.GridCachePartitionedOptimisticTxNodeRestartTest.testRestartWithTxTenNodesTwoBackups(GridCachePartitionedOptimisticTxNodeRestartTest.java:141)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(java.base@11.0.8/Native
Method)
at
jdk.internal.reflect.NativeMethodAccessorImpl.invoke(java.base@11.0.8/NativeMethodAccessorImpl.java:62)
at
[jira] [Created] (IGNITE-16805) Cache Restarts 1 suite hangs
Pavel Pereslegin created IGNITE-16805:
-
Summary: Cache Restarts 1 suite hangs
Key: IGNITE-16805
URL: https://issues.apache.org/jira/browse/IGNITE-16805
Project: Ignite
Issue Type: Bug
Reporter: Pavel Pereslegin
Assignee: Pavel Pereslegin
Cache Restarts 1 suite hangs on TeamCity
https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_CacheRestarts1=buildTypeHistoryList_IgniteTests24Java8=%3Cdefault%3E
{noformat}
[00:47:38] : [Step 4/5] Thread
[name="test-runner-#376077%near.GridCachePartitionedOptimisticTxNodeRestartTest%",
id=383240, state=WAITING, blockCnt=20, waitCnt=42]
[00:47:38] : [Step 4/5] Lock [object=java.lang.Thread@686cf8ad,
ownerName=null, ownerId=-1]
[00:47:38] : [Step 4/5] at
java.base@11.0.8/java.lang.Object.wait(Native Method)
[00:47:38] : [Step 4/5] at
java.base@11.0.8/java.lang.Thread.join(Thread.java:1305)
[00:47:38] : [Step 4/5] at
java.base@11.0.8/java.lang.Thread.join(Thread.java:1380)
[00:47:38] : [Step 4/5] at
o.a.i.i.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.checkRestartWithTx(GridCacheAbstractNodeRestartSelfTest.java:850)
[00:47:38] : [Step 4/5] at
o.a.i.i.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.testRestartWithTxTenNodesTwoBackups(GridCacheAbstractNodeRestartSelfTest.java:543)
[00:47:38] : [Step 4/5] at
o.a.i.i.processors.cache.distributed.near.GridCachePartitionedOptimisticTxNodeRestartTest.testRestartWithTxTenNodesTwoBackups(GridCachePartitionedOptimisticTxNodeRestartTest.java:141)
[00:47:38] : [Step 4/5] at
java.base@11.0.8/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native
Method)
[00:47:38] : [Step 4/5] at
java.base@11.0.8/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
[00:47:38] : [Step 4/5] at
java.base@11.0.8/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[00:47:38] : [Step 4/5] at
java.base@11.0.8/java.lang.reflect.Method.invoke(Method.java:566)
[00:47:38] : [Step 4/5] at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
[00:47:38] : [Step 4/5] at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
[00:47:38] : [Step 4/5] at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
[00:47:38] : [Step 4/5] at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
[00:47:38] : [Step 4/5] at
o.a.i.testframework.junits.GridAbstractTest$6.run(GridAbstractTest.java:2431)
[00:47:38] : [Step 4/5] at
java.base@11.0.8/java.lang.Thread.run(Thread.java:834)
"test-runner-#376077%near.GridCachePartitionedOptimisticTxNodeRestartTest%"
#383240 prio=5 os_prio=0 cpu=649.37ms elapsed=6627.99s tid=0x7f69575ff000
nid=0x6474 waiting on condition [0x7f68edcc2000]
java.lang.Thread.State: WAITING (parking)
at jdk.internal.misc.Unsafe.park(java.base@11.0.8/Native Method)
- parking to wait for <0x87987d88> (a
java.util.concurrent.CountDownLatch$Sync)
at
java.util.concurrent.locks.LockSupport.park(java.base@11.0.8/LockSupport.java:194)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.8/AbstractQueuedSynchronizer.java:885)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.doAcquireSharedInterruptibly(java.base@11.0.8/AbstractQueuedSynchronizer.java:1039)
at
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireSharedInterruptibly(java.base@11.0.8/AbstractQueuedSynchronizer.java:1345)
at
java.util.concurrent.CountDownLatch.await(java.base@11.0.8/CountDownLatch.java:232)
at
org.apache.ignite.internal.util.IgniteUtils.awaitQuiet(IgniteUtils.java:8106)
at
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.grid(IgnitionEx.java:1657)
at org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1292)
at org.apache.ignite.internal.IgnitionEx.allGrids(IgnitionEx.java:1270)
at org.apache.ignite.Ignition.allGrids(Ignition.java:503)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1563)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1550)
at
org.apache.ignite.testframework.junits.GridAbstractTest.stopAllGrids(GridAbstractTest.java:1542)
at
org.apache.ignite.internal.processors.cache.distributed.GridCacheAbstractNodeRestartSelfTest.checkRestartWithTx(GridCacheAbstractNodeRestartSelfTest.java:856)
at
[jira] [Created] (IGNITE-16804) Add ability to collect metrics from ducktests
Sergey Korotkov created IGNITE-16804:
Summary: Add ability to collect metrics from ducktests
Key: IGNITE-16804
URL: https://issues.apache.org/jira/browse/IGNITE-16804
Project: Ignite
Issue Type: Improvement
Reporter: Sergey Korotkov
Assignee: Sergey Korotkov
Add ability to run ducktests with the metrics export enabled.
It should be possible to export metrics both via the JMX remote and in the
prometheus format via the HTTP.
It should be possible both for local run in docker and for runs in real
environment.
It should be possible to separate metrics obtained for each individual test.
Metrics export configuration should be defined via the _globals_ parameters like
{code:java}
{
"jmx_remote_enabled":true,
"metrics": {
"opencensus": {
"enabled":true,
"port": 8082
},
"jmx": {
"enabled":true
}
}
}{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16757) Add cache create/destroy events to CDCConsumer
[
https://issues.apache.org/jira/browse/IGNITE-16757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Evgeny Stanilovsky updated IGNITE-16757:
Summary: Add cache create/destroy events to CDCConsumer (was: Add cache
create/destroy events to CDCCosumer)
> Add cache create/destroy events to CDCConsumer
> --
>
> Key: IGNITE-16757
> URL: https://issues.apache.org/jira/browse/IGNITE-16757
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-59
>
> Need to provide the way to notify {{CDCConsumer}} about creation/destroying
> caches(tables).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16757) Add cache create/destroy events to CDCCosumer
[
https://issues.apache.org/jira/browse/IGNITE-16757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nikolay Izhikov reassigned IGNITE-16757:
Assignee: Nikolay Izhikov
> Add cache create/destroy events to CDCCosumer
> -
>
> Key: IGNITE-16757
> URL: https://issues.apache.org/jira/browse/IGNITE-16757
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Labels: IEP-59
>
> Need to provide the way to notify {{CDCConsumer}} about creation/destroying
> caches(tables).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16160) [ignite-extensions] Failed CDC tests
[ https://issues.apache.org/jira/browse/IGNITE-16160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergei Ryzhov updated IGNITE-16160: --- Description: https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Cdc?branch=%3Cdefault%3E=builds#all-projects [2021-12-20 10:59:51,303][INFO ][shutdown-hook][CdcKafkaReplicationAppsTest2] >>> +---+ >>> Ignite ver. 2.13.0-SNAPSHOT#20211219-sha1:a56fb60140e744db382b1ba266d1fe695fd823eb stopped OK >>> +---+ >>> Ignite instance name: kafka.CdcKafkaReplicationAppsTest2 >>> Grid uptime: 00:00:14.162 Process exited with code 255 Process exited with code 255 (Step: Run Extension's tests (Maven)) Waiting for 2 service processes to complete Surefire report watcher 1 report found for paths: /opt/buildagent/work/9319dd66c384518/modules/cdc-ext/target/surefire-reports/TEST-*.xml Successfully parsed 1 report modules/cdc-ext/target/surefire-reports/TEST-org.apache.ignite.cdc.CacheConflictOperationsWithFieldTest.xml Step Run Extension's tests (Maven) failed Publishing internal artifacts was: https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_RunAllTests?branch=%3Cdefault%3E=overview=builds [2021-12-20 10:59:51,303][INFO ][shutdown-hook][CdcKafkaReplicationAppsTest2] >>> +---+ >>> Ignite ver. 2.13.0-SNAPSHOT#20211219-sha1:a56fb60140e744db382b1ba266d1fe695fd823eb stopped OK >>> +---+ >>> Ignite instance name: kafka.CdcKafkaReplicationAppsTest2 >>> Grid uptime: 00:00:14.162 Process exited with code 255 Process exited with code 255 (Step: Run Extension's tests (Maven)) Waiting for 2 service processes to complete Surefire report watcher 1 report found for paths: /opt/buildagent/work/9319dd66c384518/modules/cdc-ext/target/surefire-reports/TEST-*.xml Successfully parsed 1 report modules/cdc-ext/target/surefire-reports/TEST-org.apache.ignite.cdc.CacheConflictOperationsWithFieldTest.xml Step Run Extension's tests (Maven) failed Publishing internal artifacts > [ignite-extensions] Failed CDC tests > > > Key: IGNITE-16160 > URL: https://issues.apache.org/jira/browse/IGNITE-16160 > Project: Ignite > Issue Type: Test >Reporter: Sergei Ryzhov >Priority: Major > Labels: ise > > https://ci2.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_Cdc?branch=%3Cdefault%3E=builds#all-projects > [2021-12-20 10:59:51,303][INFO ][shutdown-hook][CdcKafkaReplicationAppsTest2] > >>> > +---+ > >>> Ignite ver. > 2.13.0-SNAPSHOT#20211219-sha1:a56fb60140e744db382b1ba266d1fe695fd823eb > stopped OK > >>> > +---+ > >>> Ignite instance name: kafka.CdcKafkaReplicationAppsTest2 > >>> Grid uptime: 00:00:14.162 > Process exited with code 255 > Process exited with code 255 (Step: Run Extension's tests (Maven)) > Waiting for 2 service processes to complete > Surefire report watcher > 1 report found for paths: > > /opt/buildagent/work/9319dd66c384518/modules/cdc-ext/target/surefire-reports/TEST-*.xml > Successfully parsed > 1 report > > modules/cdc-ext/target/surefire-reports/TEST-org.apache.ignite.cdc.CacheConflictOperationsWithFieldTest.xml > Step Run Extension's tests (Maven) failed > Publishing internal artifacts -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16802) Raft log storage creates rocksdb instance per group
[ https://issues.apache.org/jira/browse/IGNITE-16802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-16802: - Priority: Blocker (was: Major) > Raft log storage creates rocksdb instance per group > --- > > Key: IGNITE-16802 > URL: https://issues.apache.org/jira/browse/IGNITE-16802 > Project: Ignite > Issue Type: Bug >Reporter: Semyon Danilov >Priority: Blocker > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > At this moment, every raft group creates RocksDBLogStorage which, in turn, > creates an instance of RocksDB without sharing resources with other log > storages. This inflicts memory overhead and leads to out of memory killer > killing process on TeamCity. > We need to use one rocksdb instance for all log storages -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16802) Raft log storage creates rocksdb instance per group
[ https://issues.apache.org/jira/browse/IGNITE-16802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-16802: - Fix Version/s: 3.0.0-alpha5 > Raft log storage creates rocksdb instance per group > --- > > Key: IGNITE-16802 > URL: https://issues.apache.org/jira/browse/IGNITE-16802 > Project: Ignite > Issue Type: Bug >Reporter: Semyon Danilov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > At this moment, every raft group creates RocksDBLogStorage which, in turn, > creates an instance of RocksDB without sharing resources with other log > storages. This inflicts memory overhead and leads to out of memory killer > killing process on TeamCity. > We need to use one rocksdb instance for all log storages -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16802) Raft log storage creates rocksdb instance per group
[ https://issues.apache.org/jira/browse/IGNITE-16802?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergey Chugunov updated IGNITE-16802: - Ignite Flags: (was: Docs Required,Release Notes Required) > Raft log storage creates rocksdb instance per group > --- > > Key: IGNITE-16802 > URL: https://issues.apache.org/jira/browse/IGNITE-16802 > Project: Ignite > Issue Type: Bug >Reporter: Semyon Danilov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > At this moment, every raft group creates RocksDBLogStorage which, in turn, > creates an instance of RocksDB without sharing resources with other log > storages. This inflicts memory overhead and leads to out of memory killer > killing process on TeamCity. > We need to use one rocksdb instance for all log storages -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16160) [ignite-extensions] Failed CDC tests
[ https://issues.apache.org/jira/browse/IGNITE-16160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergei Ryzhov updated IGNITE-16160: --- Labels: ise (was: ) > [ignite-extensions] Failed CDC tests > > > Key: IGNITE-16160 > URL: https://issues.apache.org/jira/browse/IGNITE-16160 > Project: Ignite > Issue Type: Test >Reporter: Sergei Ryzhov >Priority: Major > Labels: ise > > https://ci.ignite.apache.org/buildConfiguration/IgniteExtensions_Tests_RunAllTests?branch=%3Cdefault%3E=overview=builds > [2021-12-20 10:59:51,303][INFO ][shutdown-hook][CdcKafkaReplicationAppsTest2] > >>> > +---+ > >>> Ignite ver. > 2.13.0-SNAPSHOT#20211219-sha1:a56fb60140e744db382b1ba266d1fe695fd823eb > stopped OK > >>> > +---+ > >>> Ignite instance name: kafka.CdcKafkaReplicationAppsTest2 > >>> Grid uptime: 00:00:14.162 > Process exited with code 255 > Process exited with code 255 (Step: Run Extension's tests (Maven)) > Waiting for 2 service processes to complete > Surefire report watcher > 1 report found for paths: > > /opt/buildagent/work/9319dd66c384518/modules/cdc-ext/target/surefire-reports/TEST-*.xml > Successfully parsed > 1 report > > modules/cdc-ext/target/surefire-reports/TEST-org.apache.ignite.cdc.CacheConflictOperationsWithFieldTest.xml > Step Run Extension's tests (Maven) failed > Publishing internal artifacts -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-14196) SQL Calcite: prepare examples for documentation
[ https://issues.apache.org/jira/browse/IGNITE-14196?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-14196: - Component/s: examples > SQL Calcite: prepare examples for documentation > --- > > Key: IGNITE-14196 > URL: https://issues.apache.org/jira/browse/IGNITE-14196 > Project: Ignite > Issue Type: Task > Components: examples, sql > Environment: SQL >Reporter: Yury Gerzhedovich >Priority: Major > Labels: calcite2-required, calcite3-required > Fix For: 2.13 > > > Seems the first pre-alpha version of the Calcite engine will be released > together with the next version of Apache Ignite (2.11). So it required to > start preparing documentation. > The first step is preparing examples with explanation comments. Let's do it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16619) IndexQuery should support limit
[ https://issues.apache.org/jira/browse/IGNITE-16619?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16619: - Fix Version/s: 2.14 (was: 2.13) > IndexQuery should support limit > --- > > Key: IGNITE-16619 > URL: https://issues.apache.org/jira/browse/IGNITE-16619 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-71 > Fix For: 2.14 > > > IndexQuery should provide functionality to limit result rows (by analogue > with TextQuery). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16253) SQL:IgniteSQLException:Failed to wrap object into H2 value.[B cannot be cast to java.lang.Byte
[ https://issues.apache.org/jira/browse/IGNITE-16253?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16253: - Fix Version/s: (was: 2.13) > SQL:IgniteSQLException:Failed to wrap object into H2 value.[B cannot be cast > to java.lang.Byte > -- > > Key: IGNITE-16253 > URL: https://issues.apache.org/jira/browse/IGNITE-16253 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.11.1 >Reporter: YuJue Li >Priority: Minor > Attachments: igniteThinTest.zip > > > the reproducer see attachment. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15040) Thin Client Compute: keepBinary flag is ignored when arg is an array
[
https://issues.apache.org/jira/browse/IGNITE-15040?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-15040:
-
Fix Version/s: 2.14
(was: 2.13)
> Thin Client Compute: keepBinary flag is ignored when arg is an array
>
>
> Key: IGNITE-15040
> URL: https://issues.apache.org/jira/browse/IGNITE-15040
> Project: Ignite
> Issue Type: Bug
> Components: thin client
>Affects Versions: 2.9, 2.10, 2.9.1
>Reporter: Pavel Tupitsyn
>Priority: Major
> Fix For: 2.14
>
>
> {{ClientExecuteTaskRequest}} has {{arg instanceof BinaryObject}} check. When
> arg is an array, elements won't be deserialized even when KEEP_BINARY flag is
> not set.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16736) Stress test JDBC Driver: partitionAwareness=true, the execution performance of INSERT statement becomes worse
[ https://issues.apache.org/jira/browse/IGNITE-16736?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16736: - Fix Version/s: (was: 2.13) > Stress test JDBC Driver: partitionAwareness=true, the execution performance > of INSERT statement becomes worse > - > > Key: IGNITE-16736 > URL: https://issues.apache.org/jira/browse/IGNITE-16736 > Project: Ignite > Issue Type: Improvement > Components: jdbc >Affects Versions: 2.12 >Reporter: YuJue Li >Priority: Major > Attachments: partitionAwasome-false.png, partitionAwasome-true.png > > > When use JDBC to perform the stress test of INSERT statement, you will find > that the performance will deteriorate after partitionAwareness=true. In other > scenarios, such as SQL query or KV read/write, the performance will be > greatly improved, which is abnormal. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16519) Adding a system view for recently completed compute tasks
[ https://issues.apache.org/jira/browse/IGNITE-16519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16519: - Fix Version/s: (was: 2.13) > Adding a system view for recently completed compute tasks > - > > Key: IGNITE-16519 > URL: https://issues.apache.org/jira/browse/IGNITE-16519 > Project: Ignite > Issue Type: Improvement > Components: compute >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Minor > > It would be useful to do a system view to get the latest *N(system property)* > completed compute tasks. > It is proposed to make it look like the existing system view > *org.apache.ignite.spi.systemview.view.ComputeTaskView* using a > *org.apache.ignite.internal.processors.task.monitor.ComputeGridMonitor* > (based on a ring buffer). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15710) .NET: Some tests fail on Windows and net461
[ https://issues.apache.org/jira/browse/IGNITE-15710?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-15710: - Fix Version/s: (was: 2.13) > .NET: Some tests fail on Windows and net461 > --- > > Key: IGNITE-15710 > URL: https://issues.apache.org/jira/browse/IGNITE-15710 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.11 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Minor > Labels: .NET > > The following tests fail on Windows with .NET 4.6.1 and were disabled in > IGNITE-15504 with conditional compilation: > * DataStreamerClientTest.TestFlushThrowsOnCacheStoreException > * > PartitionAwarenessTest.CacheGet_NewNodeEnteredTopology_RequestIsRoutedToNewNode > * > ClientClusterDiscoveryTestsNoLocalhost.TestClientWithOneEndpointDiscoversAllServers > * PartitionLossTest.TestReadWriteSafe > Re-enable the tests and fix them. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16452) IndexQuery can run on non-ready dynamically created index or rebuilding indexes
[ https://issues.apache.org/jira/browse/IGNITE-16452?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16452: - Fix Version/s: 2.14 (was: 2.13) > IndexQuery can run on non-ready dynamically created index or rebuilding > indexes > --- > > Key: IGNITE-16452 > URL: https://issues.apache.org/jira/browse/IGNITE-16452 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.12 >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-49, IEP-71 > Fix For: 2.14 > > Time Spent: 10m > Remaining Estimate: 0h > > IndexProcessor register dynamically created index earlier than fill it with > data. > Then IndexQuery can reach the index before it actually ready. So we need to > restrict access for such indexes. > The same behavior is for rebuilding indexes. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16319) Replace DataLoaderApplication with DataGenerationApplication
[
https://issues.apache.org/jira/browse/IGNITE-16319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-16319:
-
Fix Version/s: 2.14
(was: 2.13)
> Replace DataLoaderApplication with DataGenerationApplication
>
>
> Key: IGNITE-16319
> URL: https://issues.apache.org/jira/browse/IGNITE-16319
> Project: Ignite
> Issue Type: Improvement
>Reporter: Nikolay Izhikov
>Assignee: Sergey Korotkov
>Priority: Minor
> Labels: ducktests
> Fix For: 2.14
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> Currently, two application exists in ducktape for one purpose - generate some
> data and put it in the cluster.
> We should remove {{DataLoaderApplication}} and use
> {{DataGenerationApplication}} instead.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16098) Key type and schema must be validated on a data insertion
[
https://issues.apache.org/jira/browse/IGNITE-16098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-16098:
-
Fix Version/s: (was: 2.13)
> Key type and schema must be validated on a data insertion
> -
>
> Key: IGNITE-16098
> URL: https://issues.apache.org/jira/browse/IGNITE-16098
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.11
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> There are two cases that break the consistency between indexes and data and
> can cause the index tree to break.
> *1. Put different entities that are logically same for SQL*
> {{CREATE TABLE TEST(ID0 INT, ID1 INT, VAL int, PRIMARY KEY (ID0, ID1)) WITH
> "KEY_TYPE=MyType,CACHE_NAME=test"}};
> then create to keys with hidden field and put to cache test.
> {code}
> BinaryObjectBuilder bobKey0 = grid(0).binary().builder("MyType");
> bobKey0.setField("ID0", 0);
> bobKey0.setField("ID1", 0);
> bobKey0.setField("hidden", 0);
> BinaryObjectBuilder bobKey1 = grid(0).binary().builder("MyType");
> bobKey0.setField("ID0", 0);
> bobKey0.setField("ID1", 0);
> bobKey0.setField("hidden", 1);
> {code}
> These key object are different by hidden field and cache will contains two
> entries.
> But (ID0, ID1) fields are same and sorted PK index will contain only one
> record.
> Now this case is applied only for SQL CREATE TABLE and cannot be reproduced
> via cache API.
> Because PK fields are unwrap only for SQL tables.
> Different functions of the cache API and SQL API should be fixed by
> IGNITE-11402.
> It should be possible to create identical tables by SQL and cache API.
> *2. Object with different key types*
> Now the value type is specify the table. If the value type doesn't not equal
> to value type specified by the {{QueryEntity#valueType}} the entity is not
> indexed (not applied fr the table).
> But {{QueryEntity#keyType}} isn't used to validate entry on insertion. Only
> fields of inserted entry are validated.
> Only {{QueryBinaryProperty#field}} is prevent of insertion the keys with
> different types. Such insertion produce critical error.
> But this property is set up on the first insertion on the node locally.
> So, the steps to fail:
> 1. Put key with type "Key0" on the one node - OK;
> 2. Put key with type "Key1" on the other node - OK;
> 3. Re-balance the cluster so that both keys are owned by one node - FAIL (on
> build index);
> *Suggestion fix:*
> 1. Validate key type at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
> (fixes the second case);
> 2. *Before* table creation register {{BinaryMetadata}} for specified key type;
> 3. If the type corresponding for KEY is already registered and schemas differ
> - fail the table creation;
> 3. Save the proper {{schemaId}} for the KEY at the {{QueryEntityEx}} to
> cluster-wide propagation and store at the persistence configuration;
> 4. Validate key schema at the {{QueryTypeDescriptorImpl#validateKeyAndValue}}
> (fixes the first case)
> 5. Introduce distributed property to disable these validation for backward
> compatibility.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16348) Use IgniteLogger in the control.sh utility
[
https://issues.apache.org/jira/browse/IGNITE-16348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-16348:
-
Fix Version/s: (was: 2.13)
> Use IgniteLogger in the control.sh utility
> --
>
> Key: IGNITE-16348
> URL: https://issues.apache.org/jira/browse/IGNITE-16348
> Project: Ignite
> Issue Type: Improvement
>Reporter: Amelchev Nikita
>Assignee: Amelchev Nikita
>Priority: Major
> Labels: ise
>
> For now, {{control.sh}} utility uses JUL logger with hard-coded configuration.
> The IgniteLogger was reworked (IGNITE-14353) and can be used for logging as a
> separate application.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16251) .NET: Improve startup debug logging when locating JVM and classpath
[ https://issues.apache.org/jira/browse/IGNITE-16251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16251: - Fix Version/s: (was: 2.13) > .NET: Improve startup debug logging when locating JVM and classpath > --- > > Key: IGNITE-16251 > URL: https://issues.apache.org/jira/browse/IGNITE-16251 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Minor > Labels: .NET > > Log more details when locating JVM (*GetJvmDllPaths*) and classpath. In > particular, log errors from *Shell.ExecuteSafe* to understand what has gone > wrong. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15975) Snapshot restore should wait for the index rebuild prior to releasing future
[ https://issues.apache.org/jira/browse/IGNITE-15975?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-15975: - Fix Version/s: (was: 2.13) > Snapshot restore should wait for the index rebuild prior to releasing future > > > Key: IGNITE-15975 > URL: https://issues.apache.org/jira/browse/IGNITE-15975 > Project: Ignite > Issue Type: Improvement >Reporter: Maxim Muzafarov >Priority: Major > Labels: iep-43 > > Currently, the snapshot restore procedure doesn't wait for the indexes to be > rebuilt (rebuild procedures will be finished asynchronously). We should > improve this behaviour that way - restoring cache groups will be available to > the user only after all the indexes will be rebuilt (add a system property to > control this behaviour). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16068) Operations hang with different characters encoding on nodes and authentication enabled.
[
https://issues.apache.org/jira/browse/IGNITE-16068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-16068:
-
Fix Version/s: (was: 2.13)
> Operations hang with different characters encoding on nodes and
> authentication enabled.
> ---
>
> Key: IGNITE-16068
> URL: https://issues.apache.org/jira/browse/IGNITE-16068
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Reproducer:
> {code:java}
> /** */
> public class AuthenticatorMultiJvmEncodingTest extends GridCommonAbstractTest
> {
> /** Character encoding name that will be applied to the next Ignite
> process start. */
> private String jvmCharacterEncoding;
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setAuthenticationEnabled(true);
> cfg.setDataStorageConfiguration(new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(new DataRegionConfiguration()
> .setMaxSize(100 * (1 << 20))
> .setPersistenceEnabled(true)));
> return cfg;
> }
> /** {@inheritDoc} */
> @Override protected List additionalRemoteJvmArgs() {
> List args = super.additionalRemoteJvmArgs();
> args.add("-Dfile.encoding=" + jvmCharacterEncoding);
> return args;
> }
> /** {@inheritDoc} */
> @Override protected boolean isRemoteJvm(String igniteInstanceName) {
> return getTestIgniteInstanceIndex(igniteInstanceName) != 0;
> }
> /** {@inheritDoc} */
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> cleanPersistenceDir();
> }
> /** */
> @Test
> public void testMultipleJvmInstancesWithDifferentEncoding() throws
> Exception {
> startGrid(0);
> jvmCharacterEncoding = "Big5";
> startGrid(1);
> jvmCharacterEncoding = "UTF-8";
> startGrid(2);
> grid(0).cluster().state(ACTIVE);
> grid(0).createCache(DEFAULT_CACHE_NAME);
> String login = "語";
> String pwd = "語";
> try (AutoCloseable ignored =
> withSecurityContextOnAllNodes(authenticate(grid(0), "ignite", "ignite"))) {
> grid(0).context().security().createUser(login, pwd.toCharArray());
> }
> try (
> IgniteClient cli = Ignition.startClient(new
> ClientConfiguration().setAddresses("127.0.0.1:10800")
> .setUserName(login)
> .setUserPassword(pwd))
> ) {
> ClientCache cache =
> cli.cache(DEFAULT_CACHE_NAME);
> Map entries = new HashMap<>();
> for (int i = 0; i < 1000; i++)
> entries.put(i, i);
> cache.putAll(entries);
> }
> }
> }
> {code}
> Exception on server node before hanging:
> {code:java}
> java.lang.IllegalStateException: Failed to find security context for subject
> with given ID : c950cc94-38f1-304d-b858-2aa6e9478357
> [2021-12-06 23:24:10,507][INFO ][Thread-2][jvm-5950cce2] at
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.withContext(IgniteSecurityProcessor.java:167)
> [2021-12-06 23:24:10,507][INFO ][Thread-2][jvm-5950cce2] at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1906)
> [2021-12-06 23:24:10,507][INFO ][Thread-2][jvm-5950cce2] at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
> [2021-12-06 23:24:10,507][INFO ][Thread-2][jvm-5950cce2] at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:242)
> [2021-12-06 23:24:10,507][INFO ][Thread-2][jvm-5950cce2] at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
> [2021-12-06 23:24:10,507][INFO ][Thread-2][jvm-5950cce2] at
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
> [2021-12-06 23:24:10,507][INFO ][Thread-2][jvm-5950cce2] at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:569)
> [2021-12-06 23:24:10,507][INFO ][Thread-2][jvm-5950cce2] at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> [2021-12-06 23:24:10,507][INFO ][Thread-2][jvm-5950cce2] at
> java.lang.Thread.run(Thread.java:748)
> {code}
> The main reason of described above behavior is that
> IgniteAuthenticatorProcessor uses default JVM character encoding
[jira] [Updated] (IGNITE-15966) [Security] Operation can hang with authentication enabled after user drop operation
[
https://issues.apache.org/jira/browse/IGNITE-15966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-15966:
-
Fix Version/s: (was: 2.13)
> [Security] Operation can hang with authentication enabled after user drop
> operation
> ---
>
> Key: IGNITE-15966
> URL: https://issues.apache.org/jira/browse/IGNITE-15966
> Project: Ignite
> Issue Type: Bug
>Reporter: Mikhail Petrov
>Priority: Major
> Labels: ise
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Reproducer:
> {code:java}
> /** */
> public class UserDropTest extends GridCommonAbstractTest {
> /** {@inheritDoc} */
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> IgniteConfiguration cfg = super.getConfiguration(igniteInstanceName);
> cfg.setAuthenticationEnabled(true);
> cfg.setDataStorageConfiguration(new DataStorageConfiguration()
> .setDefaultDataRegionConfiguration(new DataRegionConfiguration()
> .setPersistenceEnabled(true)));
> return cfg;
> }
> /** */
> @Test
> public void test() throws Exception {
> startGrid(0);
> startGrid(1);
> grid(0).cluster().state(ClusterState.ACTIVE);
> grid(0).createCache(DEFAULT_CACHE_NAME);
> try (AutoCloseable ignored =
> withSecurityContextOnAllNodes(authenticate(grid(0), "ignite", "ignite"))) {
> grid(0).context().security().createUser("cli",
> "pwd".toCharArray());
> }
> IgniteClient client = Ignition.startClient(new
> ClientConfiguration().setAddresses("127.0.0.1:10800").setUserName("cli").setUserPassword("pwd"));
> ClientCache cache = client.cache(DEFAULT_CACHE_NAME);
> try (AutoCloseable ignored =
> withSecurityContextOnAllNodes(authenticate(grid(0), "ignite", "ignite"))) {
> grid(0).context().security().dropUser("cli");
> }
> Map entries = new HashMap<>();
> for (int i = 0; i < 1; i++)
> entries.put(i, i);
> cache.putAll(entries);
> }
> /** {@inheritDoc} */
> @Override protected void beforeTest() throws Exception {
> super.beforeTest();
> cleanPersistenceDir();
> }
> }
> {code}
> Exception:
> {code:java}
> [2021-11-22
> 11:04:32,390][ERROR][sys-stripe-3-#92%ignite.UserDropTest1%][IgniteTestResources]
> Critical system error detected. Will be handled accordingly to configured
> handler [hnd=NoOpFailureHandler [super=AbstractFailureHandler
> [ignoredFailureTypes=UnmodifiableSet [SYSTEM_WORKER_BLOCKED,
> SYSTEM_CRITICAL_OPERATION_TIMEOUT]]], failureCtx=FailureContext
> [type=SYSTEM_WORKER_TERMINATION, err=java.lang.IllegalStateException: Failed
> to find security context for subject with given ID :
> 0898b227-30d5-3afc-9394-d8e4889ece4a]]
> java.lang.IllegalStateException: Failed to find security context for subject
> with given ID : 0898b227-30d5-3afc-9394-d8e4889ece4a
> at
> org.apache.ignite.internal.processors.security.IgniteSecurityProcessor.withContext(IgniteSecurityProcessor.java:167)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1906)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:242)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
> at
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
> at
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:569)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at java.lang.Thread.run(Thread.java:748)
> {code}
> The main problem is:
> Implementation of authentication plugin ties security user with the subject
> ID that is propagated through cluster nodes.
> If some node receives operation initiated by the deleted user, it fails to
> obtain its security context via subject id and hangs with mentioned above
> exception.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16008) Remove outdated ignite system cache (utility cache)
[ https://issues.apache.org/jira/browse/IGNITE-16008?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16008: - Fix Version/s: (was: 2.13) > Remove outdated ignite system cache (utility cache) > --- > > Key: IGNITE-16008 > URL: https://issues.apache.org/jira/browse/IGNITE-16008 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > > After removing the legacy service grid implementation [1] there is no need to > keep ignite utility cache that was used by it. However, it is still possible > that some of Ignite plugin implementations still use the ignite-sys-cache > they should be updated to use the metastorage instead. > [1] https://issues.apache.org/jira/browse/IGNITE-15758 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15647) -e parameter of sqlline command does not work properly
[
https://issues.apache.org/jira/browse/IGNITE-15647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-15647:
-
Fix Version/s: 2.14
(was: 2.13)
> -e parameter of sqlline command does not work properly
> --
>
> Key: IGNITE-15647
> URL: https://issues.apache.org/jira/browse/IGNITE-15647
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 2.10
> Environment: CentOS7.8.2003
>Reporter: Anton Kondratev
>Assignee: Ilya Kasnacheev
>Priority: Critical
> Fix For: 2.14
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> SQL query specified in -e parameter of sqlline command does not get parsed
> properly and therefore not executed.
> I'm trying to use it like this:
> {code:java}
> ./sqlline.sh -u jdbc:ignite:thin://1.2.3.4 -n login -p password -e 'select *
> from \"sys\".\"tables\";'{code}
> and output is:
> {code:java}
> Property "url" is required
> Property "url" is required
> Property "url" is required
> Property "url" is required
> Property "url" is required
> Property "url" is required
> Property "url" is required
> Property "url" is required
> include (Is a directory)
> Property "url" is required
> Property "url" is required
> from (No such file or directory)
> \"sys\".\"tables\"; (No such file or directory)
> Error: Failed to parse query. Syntax error in SQL statement "SELECT [*]";
> expected "TOP, LIMIT, DISTINCT, ALL, *, NOT, EXISTS, INTERSECTS"; SQL
> statement:
> select [42001-197] (state=42000,code=1001)
> java.sql.SQLException: Failed to parse query. Syntax error in SQL statement
> "SELECT [*]"; expected "TOP, LIMIT, DISTINCT, ALL, *, NOT, EXISTS,
> INTERSECTS"; SQL statement:
> select [42001-197]
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinConnection.sendRequest(JdbcThinConnection.java:1009)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute0(JdbcThinStatement.java:234)
> at
> org.apache.ignite.internal.jdbc.thin.JdbcThinStatement.execute(JdbcThinStatement.java:560)
> at sqlline.Commands.executeSingleQuery(Commands.java:1054)
> at sqlline.Commands.execute(Commands.java:1003)
> at sqlline.Commands.sql(Commands.java:967)
> at sqlline.SqlLine.dispatch(SqlLine.java:734)
> at sqlline.SqlLine.initArgs(SqlLine.java:449)
> at sqlline.SqlLine.begin(SqlLine.java:515)
> at sqlline.SqlLine.start(SqlLine.java:267)
> at sqlline.SqlLine.main(SqlLine.java:206)
> sqlline version 1.9.0{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16212) Possible class-loading deadlock for PageIO implementations
[
https://issues.apache.org/jira/browse/IGNITE-16212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-16212:
-
Fix Version/s: (was: 2.13)
> Possible class-loading deadlock for PageIO implementations
> --
>
> Key: IGNITE-16212
> URL: https://issues.apache.org/jira/browse/IGNITE-16212
> Project: Ignite
> Issue Type: Bug
> Components: general
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
>
> At least PageMetaIO and PagePartitionMetaIO (and probably others need to be
> checked as well) are prone to class-loading deadlock due to constructs like
> this:
> {{public class PageMetaIO extends PageIO {}}
> {{...}}
> {{ public static final IOVersions VERSIONS = new
> IOVersions<>(}}
> {{ new PageMetaIO(1),}}
> {{ new PageMetaIOV2(2)}}
> {{);}}
> where PageMetaIOV2 is a subclass of PageMetaIO.
> If we are unlucky with the loading order, it might happen that the
> superclass, to initialize itself, needs to load a subclass, and the sub-class
> needs to initialize the superclass first.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-14548) BinaryThreadLocalContext must be cleaned when client is closed
[
https://issues.apache.org/jira/browse/IGNITE-14548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-14548:
-
Fix Version/s: (was: 2.13)
> BinaryThreadLocalContext must be cleaned when client is closed
> --
>
> Key: IGNITE-14548
> URL: https://issues.apache.org/jira/browse/IGNITE-14548
> Project: Ignite
> Issue Type: Bug
> Components: binary
>Affects Versions: 2.10
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
>
> ThreadLocal {{BinaryThreadLocalContext#CTX}} must be cleaned when thin client
> and JDBC thin client are closed.
> Fail case: [Stack
> overflow|https://stackoverflow.com/questions/67086723/unable-to-remove-org-apache-ignite-internal-binary-binarythreadlocal-error-in-we?noredirect=1#comment118615654_67086723]
> Previous discussion: IGNITE-967
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15502) NullPointerException during a snapshot check
[
https://issues.apache.org/jira/browse/IGNITE-15502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-15502:
-
Fix Version/s: (was: 2.13)
> NullPointerException during a snapshot check
>
>
> Key: IGNITE-15502
> URL: https://issues.apache.org/jira/browse/IGNITE-15502
> Project: Ignite
> Issue Type: Bug
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Critical
>
> {code}
> java.lang.NullPointerException
> at java.util.HashSet.(HashSet.java:119)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsVerifyHandler.invoke(SnapshotPartitionsVerifyHandler.java:106)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotPartitionsVerifyHandler.invoke(SnapshotPartitionsVerifyHandler.java:70)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.invoke(IgniteSnapshotManager.java:2038)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.IgniteSnapshotManager$SnapshotHandlers.invokeAll(IgniteSnapshotManager.java:1976)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotHandlerRestoreTask$SnapshotHandlerRestoreJob.execute(SnapshotHandlerRestoreTask.java:132)
> at
> org.apache.ignite.internal.processors.cache.persistence.snapshot.SnapshotHandlerRestoreTask$SnapshotHandlerRestoreJob.execute(SnapshotHandlerRestoreTask.java:93)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:601)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7270)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:595)
> at
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:522)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1379)
> at
> org.apache.ignite.internal.processors.job.GridJobProcessor$JobExecutionListener.onMessage(GridJobProcessor.java:2155)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.invokeListener(GridIoManager.java:1907)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.processRegularMessage0(GridIoManager.java:1528)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager.access$5300(GridIoManager.java:242)
> at
> org.apache.ignite.internal.managers.communication.GridIoManager$9.execute(GridIoManager.java:1421)
> at
> org.apache.ignite.internal.managers.communication.TraceRunnable.run(TraceRunnable.java:55)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15636) CPP: Run tests and build ODBC driver using MS Visual Studio 2017
[ https://issues.apache.org/jira/browse/IGNITE-15636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-15636: - Fix Version/s: (was: 2.13) > CPP: Run tests and build ODBC driver using MS Visual Studio 2017 > > > Key: IGNITE-15636 > URL: https://issues.apache.org/jira/browse/IGNITE-15636 > Project: Ignite > Issue Type: Improvement > Components: platforms >Reporter: Ivan Daschinsky >Priority: Major > > Since VS2015, 2017 and 2019 share same redistributables and old > redistributables are deprecated, lets upgrade VS. > Currently, bundled ODBC driver are quite hard to install correctly since it > is hard to find vs2010 redist for windows 10 and seems that old resitrs are > to be deleted. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-14099) CPP: Remove 32-bit configs
[ https://issues.apache.org/jira/browse/IGNITE-14099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-14099: - Fix Version/s: (was: 2.13) > CPP: Remove 32-bit configs > -- > > Key: IGNITE-14099 > URL: https://issues.apache.org/jira/browse/IGNITE-14099 > Project: Ignite > Issue Type: Bug > Components: platforms >Affects Versions: 2.9.1 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > > 32-bit test config files are not needed anymore, as we do not run them > anyway. Remove them. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15067) Add custom destination path to the snapshost API
[
https://issues.apache.org/jira/browse/IGNITE-15067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-15067:
-
Fix Version/s: (was: 2.13)
> Add custom destination path to the snapshost API
>
>
> Key: IGNITE-15067
> URL: https://issues.apache.org/jira/browse/IGNITE-15067
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maxim Muzafarov
>Assignee: Maxim Muzafarov
>Priority: Major
> Labels: iep-43
>
> The default configuration path obtains from the IgniteConfiguration. However,
> in some circumstances, it is good to set this destination path at runtime.
> This path must be configured relatively in the node working directory and
> must be accessible from the security point of view.
> Proposed API:
> {code}
> public IgniteFuture createSnapshot(String name, Path locPath);
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-14515) Support MissingSwitchDefaultCheck checkstyle check
[ https://issues.apache.org/jira/browse/IGNITE-14515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-14515: - Fix Version/s: (was: 2.13) > Support MissingSwitchDefaultCheck checkstyle check > -- > > Key: IGNITE-14515 > URL: https://issues.apache.org/jira/browse/IGNITE-14515 > Project: Ignite > Issue Type: Task >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Labels: checkstyle > > Every switch statement should include a default case. The break in the > default case is redundant, but it prevents a fall-through error if later > another case is added. > https://www.oracle.com/java/technologies/javase/codeconventions-statements.html#468 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-14966) Java thin: ClientFieldsQueryCursor fails to return columns before the first row gets accessed
[ https://issues.apache.org/jira/browse/IGNITE-14966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-14966: - Fix Version/s: (was: 2.13) > Java thin: ClientFieldsQueryCursor fails to return columns before the first > row gets accessed > - > > Key: IGNITE-14966 > URL: https://issues.apache.org/jira/browse/IGNITE-14966 > Project: Ignite > Issue Type: Bug > Components: thin client >Affects Versions: 2.10 >Reporter: Ivan Fedorenkov >Priority: Major > > When user issues a SQL query using the IgniteClient instance and wants to > access the resulting list of columns as well as their total count he gets > nothing and zero before the first row gets accessed. This behavior is > incompatible with "fat" client nodes and server nodes that get this > information right away. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15967) Copying the remote index from the snapshot if the node has the same partition distribution
[ https://issues.apache.org/jira/browse/IGNITE-15967?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-15967: - Fix Version/s: (was: 2.13) > Copying the remote index from the snapshot if the node has the same partition > distribution > -- > > Key: IGNITE-15967 > URL: https://issues.apache.org/jira/browse/IGNITE-15967 > Project: Ignite > Issue Type: Improvement >Affects Versions: 2.12 >Reporter: Maxim Muzafarov >Priority: Major > Labels: iep-43 > > During a snapshot restore procedure, the data (cache group partitions) is > copied from a remote node to the local node according to affinity partition > distribution on the local node. If a cache group has the distribution of the > same partition as the snapshot on a remote node does it may be necessary to > copy all the data right with the indexes (index partition) and avoid the > index rebuild this way. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-14750) NullPointerException when starting MaintenanceProcessor after upgrade from 2.9
[
https://issues.apache.org/jira/browse/IGNITE-14750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-14750:
-
Fix Version/s: (was: 2.13)
> NullPointerException when starting MaintenanceProcessor after upgrade from 2.9
> --
>
> Key: IGNITE-14750
> URL: https://issues.apache.org/jira/browse/IGNITE-14750
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.10
>Reporter: Stephen Darlington
>Assignee: Stephen Darlington
>Priority: Minor
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Upgrading from Ignite 2.9 to 2.10, using persistence we got the following
> error on one node. The other nodes started correctly. Ended up deleting the
> persistence store and creating a new node.
> {{[2021-05-18 15:21:51,949][WARN ][main][MaintenanceProcessor] Caught
> exception when starting MaintenanceProcessor, maintenance mode won't be
> entered}}{{_java.lang.NullPointerException_}}{{_at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.visitFolder(PdsConsistentIdProcessor.java:246)_}}{{
> _at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.folderSize(PdsConsistentIdProcessor.java:234)_}}{{
> _at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.getPathDisplayableInfo(PdsConsistentIdProcessor.java:265)_}}{{
> _at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.prepareNewSettings(PdsConsistentIdProcessor.java:195)_}}{{
> _at
> org.apache.ignite.internal.processors.cache.persistence.filename.PdsConsistentIdProcessor.resolveFolders(PdsConsistentIdProcessor.java:140)_}}{{
> _at
> org.apache.ignite.internal.maintenance.MaintenanceFileStore.init(MaintenanceFileStore.java:103)_}}{{
> _at
> org.apache.ignite.internal.maintenance.MaintenanceProcessor.start(MaintenanceProcessor.java:137)_}}{{
> _at
> org.apache.ignite.internal.IgniteKernal.startProcessor(IgniteKernal.java:1986)_}}{{
> _at
> org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1211)_}}{{
> _at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:2112)_}}{{
> _at
> org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1758)_}}{{
> _at
> org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1143)_}}{{
> _at
> org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1061)_}}{{
> _at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:947)_}}{{
> _at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:846)_}}{{
> _at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:716)_}}{{
> _at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:685)_}}{{
> _at org.apache.ignite.Ignition.start(Ignition.java:353)_}}{{_at
> org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:367)_}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-14513) .NET Examples: Invalid test name in the error text
[
https://issues.apache.org/jira/browse/IGNITE-14513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-14513:
-
Fix Version/s: (was: 2.13)
> .NET Examples: Invalid test name in the error text
> --
>
> Key: IGNITE-14513
> URL: https://issues.apache.org/jira/browse/IGNITE-14513
> Project: Ignite
> Issue Type: Bug
> Components: examples, platforms
>Reporter: Fedor Malchikov
>Assignee: Pavel Tupitsyn
>Priority: Minor
> Labels: .NET
>
> Test: *Thick/Cache/Multi Tiered Cache*
> Error message:
> {code:java}
> Unhandled Exception: System.Exception: Extra nodes detected. ClientReconnect
> example should be run without external nodes. at
> Apache.Ignite.Examples.Thick.Cache.MultiTieredCache.Program.Main() in
> /opt/buildagent/work/fdcb4fb5bbd0f7b3/i2test/var/suite-examples/art-gg-ent/platforms/dotnet/examples/Thick/Cache/MultiTieredCache/Program.cs:line
> 58
> {code}
> ClientReconnect instead MultiTieredCache
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-14532) Thin client: Unordered map used for putAll warning is unavoidable
[
https://issues.apache.org/jira/browse/IGNITE-14532?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-14532:
-
Fix Version/s: 2.14
(was: 2.13)
> Thin client: Unordered map used for putAll warning is unavoidable
> -
>
> Key: IGNITE-14532
> URL: https://issues.apache.org/jira/browse/IGNITE-14532
> Project: Ignite
> Issue Type: New Feature
> Components: thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
> Fix For: 2.14
>
>
> Thin client uses LinkedHashMap to preserve client-side entry order. Ignite
> logs a warning and there is no way to fix it for the user:
> {code}
> Unordered map java.util.HashMap is used for putAll operation on cache exact.
> This can lead to a distributed deadlock. Switch to a sorted map like TreeMap
> instead.
> {code}
> We should suppress this warning for thin client operations, since it does not
> make sense. Thin clients have different language-specific APIs, some of them
> don't even use maps. The same applies to PlatformCache (thick C# & C++).
> We should have an internal method that does not produce a warning, and,
> ideally, does not require a Map. Using LinkedHashMap as an intermediate
> collection produces unnecessary overhead and allocations, we could use an
> array of key-value pairs instead.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15516) Add DistributedProcess chaining
[
https://issues.apache.org/jira/browse/IGNITE-15516?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-15516:
-
Fix Version/s: (was: 2.13)
> Add DistributedProcess chaining
> ---
>
> Key: IGNITE-15516
> URL: https://issues.apache.org/jira/browse/IGNITE-15516
> Project: Ignite
> Issue Type: Improvement
>Reporter: Maxim Muzafarov
>Priority: Major
>
> The Ignite's {{DistributedProcess}} is a cluster-wide process that
> accumulates single nodes results to finish itself. The process has of the
> following phases:
> - The initial request starts the process via discovery.
> - The coordinator accumulates all single nodes results and finish process.
> The finished message sends via discory to each node.
> To run a distributed processes afther the desired distributed process is
> finished you need to call 'start' of the next distributed process on
> coordinator. This lead to the creation of boilerplate code each time you need
> to run next.
> It is necessary to configure such thing at the processes initialization.
> {{prepareSomethingDistribProc.thenRun(rollbackDistribProc)}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15761) [IEP-80] Removal of legacy JMX metrics beans
[ https://issues.apache.org/jira/browse/IGNITE-15761?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-15761: - Fix Version/s: 2.14 (was: 2.13) > [IEP-80] Removal of legacy JMX metrics beans > > > Key: IGNITE-15761 > URL: https://issues.apache.org/jira/browse/IGNITE-15761 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Priority: Major > Labels: IEP-80 > Fix For: 2.14 > > > New metric subsystem exists for a some time and highly adopted by the users. > Legacy JMX metrics beans are deprecated several releases. > Should be removed in 2.13 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16793) ZookeeperDiscoverySpiTestSuite1 execution can lead to unexpected JVM termination
[
https://issues.apache.org/jira/browse/IGNITE-16793?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17518002#comment-17518002
]
Ilya Shishkov commented on IGNITE-16793:
[~ivandasch], thanks a lot for review.
> ZookeeperDiscoverySpiTestSuite1 execution can lead to unexpected JVM
> termination
>
>
> Key: IGNITE-16793
> URL: https://issues.apache.org/jira/browse/IGNITE-16793
> Project: Ignite
> Issue Type: Test
>Reporter: Ilya Shishkov
>Assignee: Ilya Shishkov
>Priority: Minor
> Labels: ise, newbie
> Fix For: 2.13
>
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Below error can occur and lead to skipping of further tests execution:
> {code:java}
> [2022-04-04 03:37:09,971][ERROR][QuorumPeerListener][ServiceUtils] Exiting
> JVM with code 14
> Process exited with code 14
> {code}
> Build log with the error: [1].
> As discussed on DevList [2], most probable solution is to increase
> zookeeper.electionPortBindRetry for testing zk ensemble.
> Links:
> #
> [https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_ZooKeeperDiscovery1/6500597?showLog=6500597_230432_890.962.230567.230604=debug]
> # [https://lists.apache.org/thread/nwj2gjpzktv9f367ftm12rgy4fd32fzc]
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15762) [IEP-80] Migrate Ignite.C++ to C++ 11
[
https://issues.apache.org/jira/browse/IGNITE-15762?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-15762:
-
Fix Version/s: 2.14
(was: 2.13)
> [IEP-80] Migrate Ignite.C++ to C++ 11
> -
>
> Key: IGNITE-15762
> URL: https://issues.apache.org/jira/browse/IGNITE-15762
> Project: Ignite
> Issue Type: Improvement
> Components: platforms
>Reporter: Ivan Daschinsky
>Priority: Major
> Labels: IEP-80
> Fix For: 2.14
>
>
> Since C++ 11 is widely adopted, we should move forward and make our C++ part
> compatible with it.
> # Remove {{auto_ptr}} and use {{unique_ptr}}
> # Utilize move semantics.
> # Get rid of custom implementation of atomics, mutex, condition variables and
> so on.
> Use standard ones.
> # Change in tests BOOST implementations to standard library ones whenever it
> is possible.
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15759) [IEP-80] Removal of LOCAL caches support
[ https://issues.apache.org/jira/browse/IGNITE-15759?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-15759: - Fix Version/s: 2.14 (was: 2.13) > [IEP-80] Removal of LOCAL caches support > > > Key: IGNITE-15759 > URL: https://issues.apache.org/jira/browse/IGNITE-15759 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Priority: Major > Labels: IEP-80 > Fix For: 2.14 > > > LOCAL cachens has huge amount of known limitation and not intended to be used > in production environment. > Should be removed in 2.13 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15760) [IEP-80] Removal of MVCC caches support
[ https://issues.apache.org/jira/browse/IGNITE-15760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-15760: - Fix Version/s: 2.14 (was: 2.13) > [IEP-80] Removal of MVCC caches support > --- > > Key: IGNITE-15760 > URL: https://issues.apache.org/jira/browse/IGNITE-15760 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Priority: Major > Labels: IEP-80 > Fix For: 2.14 > > > MVCC cachens has huge amount of known limitation and not intended to be used > in production environment. > Should be deprecated in 2.13 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15765) [IEP-80] Removal of legacy SqlQuery support
[ https://issues.apache.org/jira/browse/IGNITE-15765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-15765: - Fix Version/s: 2.14 (was: 2.13) > [IEP-80] Removal of legacy SqlQuery support > --- > > Key: IGNITE-15765 > URL: https://issues.apache.org/jira/browse/IGNITE-15765 > Project: Ignite > Issue Type: Improvement >Reporter: Nikolay Izhikov >Priority: Major > Labels: IEP-80 > Fix For: 2.14 > > > Legacy SqlQuery deprecated for a while and can be remove -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-9005) Eviction policy MBeans change failed LifecycleAwareTest on cache name injectoin
[
https://issues.apache.org/jira/browse/IGNITE-9005?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-9005:
Fix Version/s: 2.14
(was: 2.13)
> Eviction policy MBeans change failed LifecycleAwareTest on cache name
> injectoin
> ---
>
> Key: IGNITE-9005
> URL: https://issues.apache.org/jira/browse/IGNITE-9005
> Project: Ignite
> Issue Type: Bug
>Reporter: Dmitry Pavlov
>Assignee: Nikolai Kulagin
>Priority: Major
> Labels: MakeTeamcityGreenAgain
> Fix For: 2.14
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> http://apache-ignite-developers.2346864.n4.nabble.com/MTCGA-new-failures-in-builds-1485687-needs-to-be-handled-td32531.html
> New test failure detected
> https://ci.ignite.apache.org/project.html?projectId=IgniteTests24Java8=7246907407546697403=%3Cdefault%3E=testDetails
> after merging
> IGNITE-8776 Eviction policy MBeans are never registered if
> evictionPolicyFactory is used
> Revert of commit makes test passing.
> Locally test also failed. Failed with message
> {noformat}
> Unexpected cache name for
> org.apache.ignite.internal.processors.cache.GridCacheLifecycleAwareSelfTest$TestEvictionPolicy@322714f4
> expected: but was:
> {noformat}
> Message of failure seems to be related to TestEvictionPolicy instance from
> test class.
> Seems that returing call to cctx.kernalContext (). resource ().
> injectCacheName (rsrc, cfg.getName ()); should fix issue.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-13726) Add an ability to view count of hot and cold pages in page memory
[ https://issues.apache.org/jira/browse/IGNITE-13726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-13726: - Fix Version/s: 2.14 (was: 2.13) > Add an ability to view count of hot and cold pages in page memory > - > > Key: IGNITE-13726 > URL: https://issues.apache.org/jira/browse/IGNITE-13726 > Project: Ignite > Issue Type: New Feature >Reporter: Aleksey Plekhanov >Assignee: Aleksey Plekhanov >Priority: Major > Labels: IEP-35, iep-62 > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > Currently, we can't determine how many hot (touched recently) and cold pages > we have in the page-memory. This information can be helpful for data region > size tuning and can show the effectiveness of the page replacement algorithm. > Such information can be represented as a histogram showing the count of pages > last touched in each time interval. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-13578) Update ignite-kafka dependencies to get rid of reported CVEs
[ https://issues.apache.org/jira/browse/IGNITE-13578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-13578: - Fix Version/s: 2.14 (was: 2.13) > Update ignite-kafka dependencies to get rid of reported CVEs > > > Key: IGNITE-13578 > URL: https://issues.apache.org/jira/browse/IGNITE-13578 > Project: Ignite > Issue Type: Bug > Components: integrations >Reporter: Stepachev Maksim >Assignee: Stepachev Maksim >Priority: Major > Fix For: 2.14 > > Time Spent: 20m > Remaining Estimate: 0h > > The libraries to update: > connect-api-2.1.1.jar > kafka-clients-2.1.1.jar -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-13348) Creating IgniteAtomicLong from the client node may hang.
[
https://issues.apache.org/jira/browse/IGNITE-13348?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-13348:
-
Fix Version/s: 2.14
(was: 2.13)
> Creating IgniteAtomicLong from the client node may hang.
>
>
> Key: IGNITE-13348
> URL: https://issues.apache.org/jira/browse/IGNITE-13348
> Project: Ignite
> Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
> Fix For: 2.14
>
> Attachments: DataStructuresInitializationTest.java
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> It looks like, the data structure processor does not properly initialize when
> a client node connects to a cluster that changes its own state (state
> transition from the inactive state to active).
> reproducer attached.
> *UPDATE*
> It seems to me, the root cause of the issue is that {{joinFut}} is always
> completed with {{false}}.
> {code:java|title=GridClusterStateProcessor.java}
> /** {@inheritDoc} */
> @Override public void onStateFinishMessage(ChangeGlobalStateFinishMessage
> msg) {
> DiscoveryDataClusterState discoClusterState = globalState;
> if (msg.requestId().equals(discoClusterState.transitionRequestId())) {
> ...
> TransitionOnJoinWaitFuture joinFut = this.joinFut;
> if (joinFut != null)
> joinFut.onDone(false);
> ...
> }
> else
> U.warn(log, "Received state finish message with unexpected ID: "
> + msg);
> }
> {code}
> On the other hand, this value is used to determine the state of the cluster
> when a new node joins the cluster
> {code:java|title=IgniteKernal.java}
> public void start(
> DiscoveryLocalJoinData joinData = ctx.discovery().localJoin();
> IgniteInternalFuture transitionWaitFut =
> joinData.transitionWaitFuture();
> ...
> boolean active;
> if (transitionWaitFut != null) {
> if (log.isInfoEnabled()) {
> log.info("Join cluster while cluster state transition is
> in progress, waiting when transition finish.");
> }
> active = transitionWaitFut.get();
> }
> else
> active = joinData.active();
> startTimer.finishGlobalStage("Await transition");
> ...
> }
> {code}
> User list discussion:
> http://apache-ignite-users.70518.x6.nabble.com/Ignite-client-node-hangs-while-IgniteAtomicLong-is-created-tp33537.html
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-12662) Get rid of CacheConfiguration#getRebalanceDelay and related functionality.
[ https://issues.apache.org/jira/browse/IGNITE-12662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-12662: - Fix Version/s: 2.14 (was: 2.13) > Get rid of CacheConfiguration#getRebalanceDelay and related functionality. > -- > > Key: IGNITE-12662 > URL: https://issues.apache.org/jira/browse/IGNITE-12662 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Scherbakov >Priority: Major > Labels: IEP-80 > Fix For: 2.14 > > > We have for a long time this property to mitigate a case with premature > rebalancing on node restart. > Currently this is handled by baseline topology. > I suggest to deprecate and remove related functionality in next releases. > For example org.apache.ignite.IgniteCache#rebalance is no longer needed as > well. > [Dev list > discussion|http://apache-ignite-developers.2346864.n4.nabble.com/DISCUSSION-Deprecation-of-obsolete-rebalancing-functionality-td45824.html] > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-9386) control.sh --tx can produce confusing results when limit is set to small value
[ https://issues.apache.org/jira/browse/IGNITE-9386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-9386: Fix Version/s: 2.14 (was: 2.13) > control.sh --tx can produce confusing results when limit is set to small value > -- > > Key: IGNITE-9386 > URL: https://issues.apache.org/jira/browse/IGNITE-9386 > Project: Ignite > Issue Type: Improvement > Components: control.sh >Affects Versions: 2.10 >Reporter: Alexey Scherbakov >Assignee: Rodion Smolnikov >Priority: Major > Fix For: 2.14 > > Time Spent: 1h 50m > Remaining Estimate: 0h > > This is happening because currently the limit is applied to primary and > backup transactions, which breaks output post-filtering (removal of primary > and backup transactions from output if near is present). > Possible solution: apply limit only to near valid transactions. If some txs > have no near part (broken tx topology), they should be always visible in > output, probably with special "broken" marking. > Best way to achieve this - implement tx paging on client side (using > continuous mapping) -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-14266) System views for page statistics must include the buckets sizes
[ https://issues.apache.org/jira/browse/IGNITE-14266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-14266: - Fix Version/s: 2.14 (was: 2.13) > System views for page statistics must include the buckets sizes > --- > > Key: IGNITE-14266 > URL: https://issues.apache.org/jira/browse/IGNITE-14266 > Project: Ignite > Issue Type: Improvement >Reporter: Maxim Muzafarov >Priority: Major > Fix For: 2.14 > > > Affected system views: CACHE_GROUP_PAGE_LISTS, DATA_REGION_PAGE_LISTS > The bucket index corresponds to the interval of free space on pages it > contains. We must add this info to the system views. > [1] > https://ignite.apache.org/docs/latest/monitoring-metrics/system-views#page_lists -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15342) Fix partition eviction process logging
[
https://issues.apache.org/jira/browse/IGNITE-15342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-15342:
-
Fix Version/s: 2.14
(was: 2.13)
> Fix partition eviction process logging
> --
>
> Key: IGNITE-15342
> URL: https://issues.apache.org/jira/browse/IGNITE-15342
> Project: Ignite
> Issue Type: Task
>Reporter: Maxim Muzafarov
>Priority: Major
> Fix For: 2.14
>
>
> There is unnecessary logging during the eviction process.
> {code}
> [2021-08-19 18:07:08,483][INFO
> ][exchange-worker-#63%snapshot.IgniteClusterSnapshotRestoreSelfTest0%][PartitionsEvictManager]
> Eviction in progress [groups=1, remainingPartsToEvict=0]
> [2021-08-19 18:07:08,483][INFO
> ][exchange-worker-#131%snapshot.IgniteClusterSnapshotRestoreSelfTest1%][PartitionsEvictManager]
> Eviction in progress [groups=1, remainingPartsToEvict=0]
> [2021-08-19 18:07:08,484][INFO
> ][exchange-worker-#131%snapshot.IgniteClusterSnapshotRestoreSelfTest1%][PartitionsEvictManager]
> Group eviction in progress [grpName=default, grpId=1544803905,
> remainingPartsToEvict=1, partsEvictInProgress=0, totalParts=4]
> [2021-08-19 18:07:08,484][INFO
> ][exchange-worker-#63%snapshot.IgniteClusterSnapshotRestoreSelfTest0%][PartitionsEvictManager]
> Group eviction in progress [grpName=shared, grpId=-903566235,
> remainingPartsToEvict=1, partsEvictInProgress=0, totalParts=4]
> [2021-08-19 18:07:08,485][INFO
> ][exchange-worker-#63%snapshot.IgniteClusterSnapshotRestoreSelfTest0%][PartitionsEvictManager]
> Partitions have been scheduled for eviction: [grpId=-903566235,
> grpName=shared, clearing=[0]]
> [2021-08-19 18:07:08,485][INFO
> ][exchange-worker-#131%snapshot.IgniteClusterSnapshotRestoreSelfTest1%][PartitionsEvictManager]
> Partitions have been scheduled for eviction: [grpId=1544803905,
> grpName=default, eviction=[2]]
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15268) Maintenance mode log messages need to be more informative
[
https://issues.apache.org/jira/browse/IGNITE-15268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-15268:
-
Fix Version/s: 2.14
(was: 2.13)
> Maintenance mode log messages need to be more informative
> -
>
> Key: IGNITE-15268
> URL: https://issues.apache.org/jira/browse/IGNITE-15268
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.10
>Reporter: Sergey Chugunov
>Priority: Major
> Fix For: 2.14
>
>
> When a node enters maintenance mode (for any reason), only basic information
> is printed to the logs:
> {code:java}
> [INFO] Node requires maintenance, non-empty set of maintenance tasks is
> found: [corrupted-cache-data-files-task]
> {code}
> It would be better for end-user to provide a link to some documentation about
> maintenance mode or some help for the particular maintenance situation.
> Right now users may be confused what to do next and how to make Ignite node
> leave maintenance mode and restore normal operations.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-15147) Possible leak in metrics in PageLockTracker
[
https://issues.apache.org/jira/browse/IGNITE-15147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-15147:
-
Fix Version/s: 2.14
(was: 2.13)
> Possible leak in metrics in PageLockTracker
> ---
>
> Key: IGNITE-15147
> URL: https://issues.apache.org/jira/browse/IGNITE-15147
> Project: Ignite
> Issue Type: Bug
> Components: persistence
>Affects Versions: 2.10
>Reporter: Sergey Chugunov
>Priority: Major
> Fix For: 2.14
>
>
> In one of PageHandler#readPage methods there is the following code:
> {code:java}
> long pageAddr = readLock(pageMem, cacheId, pageId, page, lsnr);
> if (pageAddr == 0L)
> return lockFailed;
> try {
> PageIO io = pageIoRslvr.resolve(pageAddr);
> return h.run(cacheId, pageId, page, pageAddr, io, null, arg, intArg,
> statHolder);
> }
> finally {
> readUnlock(pageMem, cacheId, pageId, page, pageAddr, lsnr);
> }
> {code}
> Here we obtain a read lock on a page by calling {{readLock}} method, its
> implementation is as following:
> {code:java}
> lsnr.onBeforeReadLock(cacheId, pageId, page);
> long pageAddr = pageMem.readLock(cacheId, pageId, page);
> lsnr.onReadLock(cacheId, pageId, page, pageAddr);
> return pageAddr;
> {code}
> And here is a problem: in {{readLock}} we always call {{onReadLock}} for the
> page but {{onReadUnlock}} is called *only if lock was acquired successfully*.
> Otherwise lock counters end up in incorrect state: {{onReadLock}} called
> although no lock was actually acqured.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-12852) Comma in field is not supported by COPY command
[ https://issues.apache.org/jira/browse/IGNITE-12852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-12852: - Fix Version/s: 2.14 > Comma in field is not supported by COPY command > --- > > Key: IGNITE-12852 > URL: https://issues.apache.org/jira/browse/IGNITE-12852 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: YuJue Li >Assignee: YuJue Li >Priority: Critical > Fix For: 2.14 > > Time Spent: 0.5h > Remaining Estimate: 0h > > CREATE TABLE test(a int,b varchar(100),c int,PRIMARY key(a)); > > a.csv: > 1,"a,b",2 > > COPY FROM '/data/a.csv' INTO test (a,b,c) FORMAT CSV; > > The copy command fails because there is a comma in the second field,but this > is a fully legal and compliant CSV format -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-12852) Comma in field is not supported by COPY command
[ https://issues.apache.org/jira/browse/IGNITE-12852?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-12852: - Fix Version/s: (was: 2.13) > Comma in field is not supported by COPY command > --- > > Key: IGNITE-12852 > URL: https://issues.apache.org/jira/browse/IGNITE-12852 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.8 >Reporter: YuJue Li >Assignee: YuJue Li >Priority: Critical > Time Spent: 0.5h > Remaining Estimate: 0h > > CREATE TABLE test(a int,b varchar(100),c int,PRIMARY key(a)); > > a.csv: > 1,"a,b",2 > > COPY FROM '/data/a.csv' INTO test (a,b,c) FORMAT CSV; > > The copy command fails because there is a comma in the second field,but this > is a fully legal and compliant CSV format -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15318) Cache (Restarts) 1 still flaky
[ https://issues.apache.org/jira/browse/IGNITE-15318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-15318: - Fix Version/s: 2.14 (was: 2.13) > Cache (Restarts) 1 still flaky > -- > > Key: IGNITE-15318 > URL: https://issues.apache.org/jira/browse/IGNITE-15318 > Project: Ignite > Issue Type: Bug >Affects Versions: 2.10 >Reporter: Alexey Scherbakov >Priority: Major > Fix For: 2.14 > > > This is a follow up ticket to [1] > There were various fixes implemented but it seems a root cause still not > determined, see TC history [2] > Most likely the issue is caused by buggy near tx protocol. > [1] https://issues.apache.org/jira/browse/IGNITE-13441 > [2] > [https://ci.ignite.apache.org/viewType.html?buildTypeId=IgniteTests24Java8_CacheRestarts1=buildTypeStatusDiv_IgniteTests24Java8=%3Cdefault%3E=true] -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16803) RocksDB usage refinement
Semyon Danilov created IGNITE-16803: --- Summary: RocksDB usage refinement Key: IGNITE-16803 URL: https://issues.apache.org/jira/browse/IGNITE-16803 Project: Ignite Issue Type: Improvement Reporter: Semyon Danilov Ignite 3 uses RocksDB in many different components: metastorage, partition storage, log storage and vault. At this moment, every component creates its own instance of rocksdb. Moreover, partition storage and log storage create multiple instances: partition storage creates an instance per table and log storage creates an instance per raft group. This creates high memory overhead and causes out of memory errors. We have to find a way to use as few instances as possible (ideally one per ignite node). For example, MySQL over RocksDB uses only one instance of RocksDB but "create table" query offers a way to put data into another column family. Maybe we can store all raft logs in one column family and data (partitions and meta) in another. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16667) AFFINITY_COLUMN & PK column in the TABLE_COLUMNS view are always FALSE.
[ https://issues.apache.org/jira/browse/IGNITE-16667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-16667: - Fix Version/s: (was: 2.13) > AFFINITY_COLUMN & PK column in the TABLE_COLUMNS view are always FALSE. > --- > > Key: IGNITE-16667 > URL: https://issues.apache.org/jira/browse/IGNITE-16667 > Project: Ignite > Issue Type: Bug > Components: sql >Affects Versions: 2.12 >Reporter: YuJue Li >Priority: Critical > > execute the sql: > CREATE TABLE City ( > ID INT, > Name VARCHAR, > CountryCode CHAR(3), > District VARCHAR, > Population INT, > PRIMARY KEY (ID, CountryCode) > ); > then select * from sys.table_column where table_name = 'CITY'; -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16136) System Thread pool starvation and out of memory
[
https://issues.apache.org/jira/browse/IGNITE-16136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-16136:
-
Fix Version/s: 2.14
(was: 2.13)
> System Thread pool starvation and out of memory
> ---
>
> Key: IGNITE-16136
> URL: https://issues.apache.org/jira/browse/IGNITE-16136
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.7.6
>Reporter: David Albrecht
>Priority: Critical
> Labels: ise
> Fix For: 2.14
>
> Attachments: image-2021-12-15-21-13-43-775.png,
> image-2021-12-15-21-17-47-652.png
>
>
> We are experiencing thread pool starvations and after some time out of memory
> exceptions in some of our ignite client nodes while the server node seems to
> be running without any problems. It seems like all sys threads are stuck when
> calling MarshallerContextImpl.getClassName. Which in turn leads to a growing
> worker queue.
>
> First warnings regarding the thread pool starvation:
> {code:java}
> 10.12.21 11:22:34.603 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:27:34.654 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:32:34.713 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:37:34.764 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:42:34.796 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> 10.12.21 11:47:34.839 [WARN ]
> IgniteKernal.warning(127): Possible thread pool starvation detected (no task
> completed in last 3ms, is system thread pool size large enough?)
> {code}
> Out of memory error leading to a crash of the application:
> {code}
> Exception: java.lang.OutOfMemoryError thrown from the
> UncaughtExceptionHandler in thread "https-openssl-nio-16443-ClientPoller"
> Exception: java.lang.OutOfMemoryError thrown from the
> UncaughtExceptionHandler in thread "ajp-nio-16009-ClientPoller"
> 11-Dec-2021 03:07:24.446 SEVERE [Catalina-utility-1]
> org.apache.coyote.AbstractProtocol.startAsyncTimeout Error processing async
> timeouts
> java.util.concurrent.ExecutionException: java.lang.OutOfMemoryError:
> Java heap space
> {code}
> The queue full of messages:
> !image-2021-12-15-21-17-47-652.png!
> It seems like all sys threads are stuck while waiting at:
> {code}
> sys-#170
> at jdk.internal.misc.Unsafe.park(ZJ)V (Native Method)
> at java.util.concurrent.locks.LockSupport.park()V (LockSupport.java:323)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(Z)Ljava/lang/Object;
> (GridFutureAdapter.java:178)
> at
> org.apache.ignite.internal.util.future.GridFutureAdapter.get()Ljava/lang/Object;
> (GridFutureAdapter.java:141)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClassName(BI)Ljava/lang/String;
> (MarshallerContextImpl.java:379)
> at
> org.apache.ignite.internal.MarshallerContextImpl.getClass(ILjava/lang/ClassLoader;)Ljava/lang/Class;
> (MarshallerContextImpl.java:344)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedMarshallerUtils.classDescriptor(Ljava/util/concurrent/ConcurrentMap;ILjava/lang/ClassLoader;Lorg/apache/ignite/marshaller/MarshallerContext;Lorg/apache/ignite/internal/marshaller/optimized/OptimizedMarshallerIdMapper;)Lorg/apache/ignite/internal/marshaller/optimized/OptimizedClassDescriptor;
> (OptimizedMarshallerUtils.java:264)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObject0()Ljava/lang/Object;
> (OptimizedObjectInputStream.java:341)
> at
> org.apache.ignite.internal.marshaller.optimized.OptimizedObjectInputStream.readObjectOverride()Ljava/lang/Object;
> (OptimizedObjectInputStream.java:198)
> at
> java.io.ObjectInputStream.readObject(Ljava/lang/Class;)Ljava/lang/Object;
> (ObjectInputStream.java:484)
> at java.io.ObjectInputStream.readObject()Ljava/lang/Object;
> (ObjectInputStream.java:451)
> at
>
[jira] [Updated] (IGNITE-12194) [Phase-2] Calculate expected rebalancing cache group keys
[ https://issues.apache.org/jira/browse/IGNITE-12194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Amelchev Nikita updated IGNITE-12194: - Fix Version/s: (was: 2.13) > [Phase-2] Calculate expected rebalancing cache group keys > - > > Key: IGNITE-12194 > URL: https://issues.apache.org/jira/browse/IGNITE-12194 > Project: Ignite > Issue Type: Sub-task >Reporter: Maxim Muzafarov >Assignee: Nikolai Kulagin >Priority: Critical > Labels: IEP-35 > Time Spent: 10m > Remaining Estimate: 0h > > We need to implement expected to be rebalanced cache group keys and total > bytes. Currently, 'estimatedKeysCount' cache metric returns '-1' for some of > the cases (see comments IGNITE-11330). > * rebalancingExpectedKeys long metric > * rebalancingExpectedBytes long metric > * rebalancingEvictedPartitionsLeft long metric -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16723) TX Recovery protocol in Cockroach in case of a failure of enlisted leaseholder
[
https://issues.apache.org/jira/browse/IGNITE-16723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Uttsel updated IGNITE-16723:
---
Description:
*Transaction recovery* is closely related to concurrency control.
Concurrency control is described in
[https://github.com/cockroachdb/cockroach/blob/master/docs/design.md#lock-free-distributed-transactions]
(especially the chapter “Transaction interactions”) and
[https://dl.acm.org/doi/pdf/10.1145/3318464.3386134].
*Read locks.*
Most reads in CRDB don’t take any locks. Instead it puts a read timestamp to
timestamp cache.
Timestamp cache is a bounded in-memory cache that records the maximum timestamp
that key ranges were read from and written to. Cache corresponds to the "status
oracle" discussed in Yabandeh's A Critique of Snapshot Isolation.
The cache is updated after the completion of each read operation with the range
of all keys that the request was predicated upon. It is then consulted for each
write operation, allowing them to detect read-write violations that would allow
them to write "under" a read that has already been performed.
The cache is size-limited, so to prevent read-write conflicts for arbitrarily
old requests, it pessimistically maintains a “low water mark”. This value
always ratchets with monotonic increases and is equivalent to the earliest
timestamp of any key range that is present in the cache. If a write operation
writes to a key not present in the cache, the “low water mark” is consulted
instead to determine read-write conflicts. The low water mark is initialized to
the current system time plus the maximum clock offset.
On lease changing a timestamp cache snapshot is accepted on a new leaseholder
with a summary of the reads served on the range by prior leaseholders. This can
be used by the new leaseholder to ensure that no future writes are allowed to
invalidate prior reads. If a summary is not provided, for example after a
leaseholder failure, the method pessimistically assumes that prior leaseholders
served reads all the way up to the start of the new lease.
Some reads, like SELECT FOR UPDATE take read locks, but it is local and will be
lost on leaseholder failure. In this case a “SELECT FOR UPDATE” request falls
back to a regular “SELECT”.
A key and a value of the timestamp cache is structures:
{code:java}
key {startKey, endKey}
value {timestamp, txnID}
{code}
A range lock also uses a timestamp cache:
{code:java}
Add(start, end roachpb.Key, ts hlc.Timestamp, txnID uuid.UUID){code}
*Write locks.*
CockroachDB has distributed write locks - write intents. An intent is a regular
MVCC KV pair, except that it is preceded by metadata indicating that what
follows is an intent. This metadata points to a transaction record, which is a
special key (unique per transaction) that stores the current disposition of the
transaction: pending, staging, committed or aborted. Because write intents and
tx records are replicated, they persist even after the leaseholder falls.
Theare is a topic with a discussion of this example on the CocroachDB forum:
[https://forum.cockroachlabs.com/t/read-write-tx-conflicts-on-leaseholder-failover/5213]
was:
*Transaction recovery* is closely related to concurrency control.
Concurrency control is described in
[https://github.com/cockroachdb/cockroach/blob/master/docs/design.md#lock-free-distributed-transactions]
(especially the chapter “Transaction interactions”) and
[https://dl.acm.org/doi/pdf/10.1145/3318464.3386134].
*Read locks.*
Most reads in CRDB don’t take any locks. Instead it puts a read timestamp to
timestamp cache.
Timestamp cache is a bounded in-memory cache that records the maximum timestamp
that key ranges were read from and written to. Cache corresponds to the "status
oracle" discussed in Yabandeh's A Critique of Snapshot Isolation.
The cache is updated after the completion of each read operation with the range
of all keys that the request was predicated upon. It is then consulted for each
write operation, allowing them to detect read-write violations that would allow
them to write "under" a read that has already been performed.
The cache is size-limited, so to prevent read-write conflicts for arbitrarily
old requests, it pessimistically maintains a “low water mark”. This value
always ratchets with monotonic increases and is equivalent to the earliest
timestamp of any key range that is present in the cache. If a write operation
writes to a key not present in the cache, the “low water mark” is consulted
instead to determine read-write conflicts. The low water mark is initialized to
the current system time plus the maximum clock offset.
On lease changing a timestamp cache snapshot is accepted on a new leaseholder
with a summary of the reads served on the range by prior leaseholders. This can
be used by the new leaseholder to ensure that no future writes
[jira] [Updated] (IGNITE-16723) TX Recovery protocol in Cockroach in case of a failure of enlisted leaseholder
[
https://issues.apache.org/jira/browse/IGNITE-16723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Uttsel updated IGNITE-16723:
---
Description:
*Transaction recovery* is closely related to concurrency control.
Concurrency control is described in
[https://github.com/cockroachdb/cockroach/blob/master/docs/design.md#lock-free-distributed-transactions]
(especially the chapter “Transaction interactions”) and
[https://dl.acm.org/doi/pdf/10.1145/3318464.3386134].
*Read locks.*
Most reads in CRDB don’t take any locks. Instead it puts a read timestamp to
timestamp cache.
Timestamp cache is a bounded in-memory cache that records the maximum timestamp
that key ranges were read from and written to. Cache corresponds to the "status
oracle" discussed in Yabandeh's A Critique of Snapshot Isolation.
The cache is updated after the completion of each read operation with the range
of all keys that the request was predicated upon. It is then consulted for each
write operation, allowing them to detect read-write violations that would allow
them to write "under" a read that has already been performed.
The cache is size-limited, so to prevent read-write conflicts for arbitrarily
old requests, it pessimistically maintains a “low water mark”. This value
always ratchets with monotonic increases and is equivalent to the earliest
timestamp of any key range that is present in the cache. If a write operation
writes to a key not present in the cache, the “low water mark” is consulted
instead to determine read-write conflicts. The low water mark is initialized to
the current system time plus the maximum clock offset.
On lease changing a timestamp cache snapshot is accepted on a new leaseholder
with a summary of the reads served on the range by prior leaseholders. This can
be used by the new leaseholder to ensure that no future writes are allowed to
invalidate prior reads. If a summary is not provided, for example after a
leaseholder failure, the method pessimistically assumes that prior leaseholders
served reads all the way up to the start of the new lease.
Some reads, like SELECT FOR UPDATE take read locks, but it is local and will be
lost on leaseholder failure. In this case a “SELECT FOR UPDATE” request falls
back to a regular “SELECT”.
A key and a value of the timestamp cache is structures:
{code:java}
key {startKey, endKey}
value {timestamp, txnID}
{code}
A range lock also uses a timestamp cache:
{code:java}
Add(start, end roachpb.Key, ts hlc.Timestamp, txnID uuid.UUID){code}
*Write locks.*
CockroachDB has distributed write locks - write intents. An intent is a regular
MVCC KV pair, except that it is preceded by metadata indicating that what
follows is an intent. This metadata points to a transaction record, which is a
special key (unique per transaction) that stores the current disposition of the
transaction: pending, staging, committed or aborted. Because write intents and
tx records are replicated, they persist even after the leaseholder falls.
Theare is a topic with a discussion of this example on the CocroachDB forum:
[https://forum.cockroachlabs.com/t/read-write-tx-conflicts-on-leaseholder-failover/5213]
was:
*Transaction recovery* is closely related to concurrency control.
Concurrency control is described in
[https://github.com/cockroachdb/cockroach/blob/master/docs/design.md#lock-free-distributed-transactions]
(especially the chapter “Transaction interactions”) and
[https://dl.acm.org/doi/pdf/10.1145/3318464.3386134].
*Read locks.*
Most reads in CRDB don’t take any locks. Instead it puts a read timestamp to
timestamp cache.
Timestamp cache is a bounded in-memory cache that records the maximum timestamp
that key ranges were read from and written to. Cache corresponds to the "status
oracle" discussed in Yabandeh's A Critique of Snapshot Isolation.
The cache is updated after the completion of each read operation with the range
of all keys that the request was predicated upon. It is then consulted for each
write operation, allowing them to detect read-write violations that would allow
them to write "under" a read that has already been performed.
The cache is size-limited, so to prevent read-write conflicts for arbitrarily
old requests, it pessimistically maintains a “low water mark”. This value
always ratchets with monotonic increases and is equivalent to the earliest
timestamp of any key range that is present in the cache. If a write operation
writes to a key not present in the cache, the “low water mark” is consulted
instead to determine read-write conflicts. The low water mark is initialized to
the current system time plus the maximum clock offset.
On lease changing a timestamp cache snapshot is accepted on a new leaseholder
with a summary of the reads served on the range by prior leaseholders. This can
be used by the new leaseholder to ensure that no future
