[jira] [Created] (IGNITE-16990) .NET: Thin 3.0: Add partition awareness to ExecuteColocated
Pavel Tupitsyn created IGNITE-16990: --- Summary: .NET: Thin 3.0: Add partition awareness to ExecuteColocated Key: IGNITE-16990 URL: https://issues.apache.org/jira/browse/IGNITE-16990 Project: Ignite Issue Type: Improvement Components: clients Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-alpha5 1. Compute key hash on the client 2. Retrieve and maintain up-to-date partitionMap 2. Send the request directly to the target node if a connection exists -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-15723) Implement a component factory
[ https://issues.apache.org/jira/browse/IGNITE-15723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-15723: Description: Today we have many component (managers) that configure during start node. All of it created into the Ignite node constructor (IgniteImpl#IgniteImpl) and cannot be configurable: for example, no way to replace (or reconfigure) a Metastore for test. There is a recommendation to create the component factory, that can to create other managers itself. It should work as now by default, but in a test we will be able to rewrite some method for test purpose. In the ticket, need to create a default component factory and a method for IgniteManager which allow passing it. This new method does not need in ordinal cases, that means an internal interface for IgniteManager is required (IgniteManagerImpl). was: Today we have many component (managers) that configure during start node. All of it created into the Ignite node constructor (IgniteImpl#IgniteImpl) and cannot be configurable: for example, no way to replace (or reconfigure) a Metarore for test. There is a recommendation to create the component factory, that can to create other managers itself. It should work as now by default, but in a test we will be able to rewrite some method for test purpose. In the ticket, need to create a default component factory and a method for IgniteManager which allow passing it. This new method does not need in ordinal cases, that means an internal interface for IgniteManager is required (IgniteManagerImpl). > Implement a component factory > - > > Key: IGNITE-15723 > URL: https://issues.apache.org/jira/browse/IGNITE-15723 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > Today we have many component (managers) that configure during start node. > All of it created into the Ignite node constructor (IgniteImpl#IgniteImpl) > and cannot be configurable: for example, no way to replace (or reconfigure) a > Metastore for test. > There is a recommendation to create the component factory, that can to create > other managers itself. It should work as now by default, but in a test we > will be able to rewrite some method for test purpose. > In the ticket, need to create a default component factory and a method for > IgniteManager which allow passing it. This new method does not need in > ordinal cases, that means an internal interface for IgniteManager is required > (IgniteManagerImpl). -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (IGNITE-16050) Common implementation for base mock dependent tests.
[ https://issues.apache.org/jira/browse/IGNITE-16050?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky reassigned IGNITE-16050: --- Assignee: (was: Evgeny Stanilovsky) > Common implementation for base mock dependent tests. > > > Key: IGNITE-16050 > URL: https://issues.apache.org/jira/browse/IGNITE-16050 > Project: Ignite > Issue Type: Improvement >Reporter: Evgeny Stanilovsky >Priority: Major > Labels: ignite-3 > > now we have _TableManagerTest_ which mocks useful inner classes, further mock > dependent tests implementation will raise copy-paste of such a code, we need > a common abstract class for such a purposes. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-16991) SQL in clause with array arg fails since ignite 2.11
Nikolay Izhikov created IGNITE-16991: Summary: SQL in clause with array arg fails since ignite 2.11 Key: IGNITE-16991 URL: https://issues.apache.org/jira/browse/IGNITE-16991 Project: Ignite Issue Type: Bug Reporter: Nikolay Izhikov Reproducer. Test passes on ignite-2.10 and fails on ignite-2.11 {code:java} /** */ public class SqlInQueryTest extends GridCommonAbstractTest { /** */ private static IgniteEx server; /** {@inheritDoc} */ @Override protected void beforeTestsStarted() throws Exception { super.beforeTestsStarted(); server = startGrid(0); } /** */ @Test public void testSelectWithInClause() throws Exception { sql("CREATE TABLE T1(ID VARCHAR, IID VARCHAR, DATA VARCHAR, PRIMARY KEY(ID, IID))", null); for (int i = 0; i < 10; i++) sql( "INSERT INTO T1(ID, IID, DATA) VALUES(?, ?, ?)", new Object[] {String.valueOf(i), String.valueOf(i % 3), "just data"} ); assertEquals(10, sql("SELECT ID, IID FROM T1", null).size()); // One ID inside IN clause. assertEquals(1, sql( "SELECT IID FROM T1 WHERE ID IN (?) AND IID = ?", new Object[] {Arrays.asList("1").toArray(), "1"} ).size()); // Two ID inside IN clause. assertEquals(2, sql( "SELECT IID FROM T1 WHERE ID IN ('1', '4') AND IID = ?", new Object[] {"1"} ).size()); // Two ID inside IN clause. Pass as patameters. //assertEquals(2, sql( //"SELECT IID FROM T1 WHERE ID IN (?) AND IID = ?", //new Object[] {Arrays.asList("1", "4").toArray(), "1"}).size() //); } /** */ private List> sql(String sqlText, Object[] args) { return server.context().query().querySqlFields( new SqlFieldsQuery(sqlText).setDistributedJoins(true).setArgs(args), true ).getAll(); } } {code} -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16013) Calcite engine. Introduce sort-with-limit physical relational operator
[ https://issues.apache.org/jira/browse/IGNITE-16013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-16013: --- Labels: calcite3-required (was: calcite2-required calcite3-required) > Calcite engine. Introduce sort-with-limit physical relational operator > -- > > Key: IGNITE-16013 > URL: https://issues.apache.org/jira/browse/IGNITE-16013 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksey Plekhanov >Assignee: Vladimir Steshin >Priority: Major > Labels: calcite3-required > Fix For: 2.14 > > Time Spent: 7h 50m > Remaining Estimate: 0h > > Currently, sort and limit are different physical relational operators, but in > some cases, sort combined with a limit can be more effective. For example > {{ORDER BY x LIMIT 1}} requires to store only one row and can be processed > with {{O(rowsCount)}} operations. In general. {{ORDER BY x LIMIT m}} requires > {{O(min(rowsCount, m))}} memory and have {{O(rowsCount * ln(min(rowsCount, > m)))}} complexity. > Since {{Limit}} node can't be moved below the {{Exchange}} node, {{ORDER BY x > LIMIT m}} clause should produce two nodes: {{Limit}} node, with single > distribution, and {{SortWithLimit}} node, which can be moved below the > {{Exchange}} node and can reduce network traffic. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16013) Calcite engine. Introduce sort-with-limit physical relational operator
[ https://issues.apache.org/jira/browse/IGNITE-16013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Plekhanov updated IGNITE-16013: --- Labels: calcite calcite3-required (was: calcite3-required) > Calcite engine. Introduce sort-with-limit physical relational operator > -- > > Key: IGNITE-16013 > URL: https://issues.apache.org/jira/browse/IGNITE-16013 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksey Plekhanov >Assignee: Vladimir Steshin >Priority: Major > Labels: calcite, calcite3-required > Fix For: 2.14 > > Time Spent: 7h 50m > Remaining Estimate: 0h > > Currently, sort and limit are different physical relational operators, but in > some cases, sort combined with a limit can be more effective. For example > {{ORDER BY x LIMIT 1}} requires to store only one row and can be processed > with {{O(rowsCount)}} operations. In general. {{ORDER BY x LIMIT m}} requires > {{O(min(rowsCount, m))}} memory and have {{O(rowsCount * ln(min(rowsCount, > m)))}} complexity. > Since {{Limit}} node can't be moved below the {{Exchange}} node, {{ORDER BY x > LIMIT m}} clause should produce two nodes: {{Limit}} node, with single > distribution, and {{SortWithLimit}} node, which can be moved below the > {{Exchange}} node and can reduce network traffic. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-15566) Calcite. Join with correlated subqueries returns wrong result.
[ https://issues.apache.org/jira/browse/IGNITE-15566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-15566: Labels: calcite (was: calcite calcite3-required ignite-3) > Calcite. Join with correlated subqueries returns wrong result. > -- > > Key: IGNITE-15566 > URL: https://issues.apache.org/jira/browse/IGNITE-15566 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Evgeny Stanilovsky >Assignee: Aleksey Plekhanov >Priority: Major > Labels: calcite > Time Spent: 40m > Remaining Estimate: 0h > > Example from ScriptRunner : > {noformat} > query IIT > SELECT * FROM test WHERE EXISTS(SELECT * FROM test2 WHERE test.a=test2.a AND > test.b<>test2.c) AND NOT EXISTS(SELECT * FROM test2 WHERE test.a=test2.a AND > test.b > 122 b > query IIT > SELECT * FROM test WHERE NOT EXISTS(SELECT * FROM test2 WHERE test.a=test2.a > AND test.b test.a=test2.a AND test.b>test2.c AND test2.a=12) ORDER BY a; > > 111 a > 133 c > {noformat} > {noformat} > /join/inner/test_eq_ineq_join.test[_ignore] > {noformat} -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-16991) SQL in clause with array arg fails since ignite 2.11
[ https://issues.apache.org/jira/browse/IGNITE-16991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538073#comment-17538073 ] Nikolay Izhikov commented on IGNITE-16991: -- Introduced by 35b3528fa020fd5bf1dce03cd2fc63508c9912a3 IGNITE-13056 Move indexes from the indexing to the core module (closes #8490) > SQL in clause with array arg fails since ignite 2.11 > > > Key: IGNITE-16991 > URL: https://issues.apache.org/jira/browse/IGNITE-16991 > Project: Ignite > Issue Type: Bug >Reporter: Nikolay Izhikov >Priority: Major > > Reproducer. > Test passes on ignite-2.10 and fails on ignite-2.11 > {code:java} > /** */ > public class SqlInQueryTest extends GridCommonAbstractTest { > /** */ > private static IgniteEx server; > /** {@inheritDoc} */ > @Override protected void beforeTestsStarted() throws Exception { > super.beforeTestsStarted(); > server = startGrid(0); > } > /** */ > @Test > public void testSelectWithInClause() throws Exception { > sql("CREATE TABLE T1(ID VARCHAR, IID VARCHAR, DATA VARCHAR, PRIMARY > KEY(ID, IID))", null); > for (int i = 0; i < 10; i++) > sql( > "INSERT INTO T1(ID, IID, DATA) VALUES(?, ?, ?)", > new Object[] {String.valueOf(i), String.valueOf(i % 3), "just > data"} > ); > assertEquals(10, sql("SELECT ID, IID FROM T1", null).size()); > // One ID inside IN clause. > assertEquals(1, sql( > "SELECT IID FROM T1 WHERE ID IN (?) AND IID = ?", > new Object[] {Arrays.asList("1").toArray(), "1"} > ).size()); > // Two ID inside IN clause. > assertEquals(2, sql( > "SELECT IID FROM T1 WHERE ID IN ('1', '4') AND IID = ?", > new Object[] {"1"} > ).size()); > // Two ID inside IN clause. Pass as patameters. > //assertEquals(2, sql( > //"SELECT IID FROM T1 WHERE ID IN (?) AND IID = ?", > //new Object[] {Arrays.asList("1", "4").toArray(), "1"}).size() > //); > } > /** */ > private List> sql(String sqlText, Object[] args) { > return server.context().query().querySqlFields( > new > SqlFieldsQuery(sqlText).setDistributedJoins(true).setArgs(args), true > ).getAll(); > } > } > {code} -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16956) Tracing for rebalance logs
[ https://issues.apache.org/jira/browse/IGNITE-16956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-16956: --- Labels: ignite-3 (was: ) > Tracing for rebalance logs > -- > > Key: IGNITE-16956 > URL: https://issues.apache.org/jira/browse/IGNITE-16956 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Priority: Major > Labels: ignite-3 > > We need to implement a tracing of the rebalance process by the one trace id > to simplify issues' debugging in future. For this purposes we need to: > * create unique trace id, when rebalance triggered (update of replicas' > number, baseline changes) > * attach this trace id to all logs, connected with rebalance process > (https://issues.apache.org/jira/browse/IGNITE-16955). > The spreading of this trace id to the raft logs can be the most complex part > of the implementation. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16976) Replace ignite-cli with a new one
[ https://issues.apache.org/jira/browse/IGNITE-16976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-16976: --- Labels: ignite-3 (was: ) > Replace ignite-cli with a new one > - > > Key: IGNITE-16976 > URL: https://issues.apache.org/jira/browse/IGNITE-16976 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr >Priority: Major > Labels: ignite-3 > > Drop existing ignite-cli module. > Change the documentation (installation process and commands description). > Provide the developer documentation (readme.md), so ignite developer can > understand how to add new commands and how to install the tool locally. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16985) Design table management flow
[ https://issues.apache.org/jira/browse/IGNITE-16985?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-16985: --- Labels: ignite-3 (was: ) > Design table management flow > > > Key: IGNITE-16985 > URL: https://issues.apache.org/jira/browse/IGNITE-16985 > Project: Ignite > Issue Type: Improvement >Reporter: Alexander Lapin >Priority: Major > Labels: ignite-3 > > TBD -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-16986) Incorrect GridCacheProcessor#stop parameters
[ https://issues.apache.org/jira/browse/IGNITE-16986?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538157#comment-17538157 ] Ignite TC Bot commented on IGNITE-16986: {panel:title=Branch: [pull/10025/head] Base: [master] : No blockers found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel} {panel:title=Branch: [pull/10025/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=6572119&buildTypeId=IgniteTests24Java8_RunAll] > Incorrect GridCacheProcessor#stop parameters > - > > Key: IGNITE-16986 > URL: https://issues.apache.org/jira/browse/IGNITE-16986 > Project: Ignite > Issue Type: Bug >Reporter: Semyon Danilov >Assignee: Semyon Danilov >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-16993) [Native Persistence 3.0] Consider replacing Checkpointer#isShutdownNow with an busy lock
Kirill Tkalenko created IGNITE-16993: Summary: [Native Persistence 3.0] Consider replacing Checkpointer#isShutdownNow with an busy lock Key: IGNITE-16993 URL: https://issues.apache.org/jira/browse/IGNITE-16993 Project: Ignite Issue Type: Task Reporter: Kirill Tkalenko Consider whether *Checkpointer#isShutdownNow* should be replaced with a busy lock so that the code is more understandable without the use of {code:java} BooleanSupplier shutdownNow {code} in the linked code. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-16992) Partial node in ItIgniteNodeRestartTest should join the CMG
Aleksandr Polovtcev created IGNITE-16992: Summary: Partial node in ItIgniteNodeRestartTest should join the CMG Key: IGNITE-16992 URL: https://issues.apache.org/jira/browse/IGNITE-16992 Project: Ignite Issue Type: Bug Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev {{ItIgniteNodeRestartTest#testMetastorageStop}} test fails if the node, started in {{startPartialNode}}, executes {{cmgManager.joinFuture()}}. For some reason, it stops receiving Meta Storage revision updates after the Meta Storage node is restarted. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-16994) .NET: Thin 3.0: Upgrade to SDK 6.0
Pavel Tupitsyn created IGNITE-16994: --- Summary: .NET: Thin 3.0: Upgrade to SDK 6.0 Key: IGNITE-16994 URL: https://issues.apache.org/jira/browse/IGNITE-16994 Project: Ignite Issue Type: Improvement Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn .NET Core 3.1 LTS support ends in December 2022: https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core Upgrade to .NET 6. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (IGNITE-16909) [Extensions] Release Ignite Spring and Cloud Extensions
[ https://issues.apache.org/jira/browse/IGNITE-16909?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maxim Muzafarov resolved IGNITE-16909. -- Resolution: Fixed > [Extensions] Release Ignite Spring and Cloud Extensions > > > Key: IGNITE-16909 > URL: https://issues.apache.org/jira/browse/IGNITE-16909 > Project: Ignite > Issue Type: Task > Components: extensions >Reporter: Maxim Muzafarov >Assignee: Maxim Muzafarov >Priority: Major > Fix For: 2.14 > > > The following extenstions must be released: > - ignite-spring-data-ext > - ignite-spring-session-ext > - ignite-gce-ext > - ignite-aws-ext > - ignite-azure-ext > - ignite-zookeeper-ip-finder-ext -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] (IGNITE-16994) .NET: Thin 3.0: Upgrade to SDK 6.0
[ https://issues.apache.org/jira/browse/IGNITE-16994 ] Pavel Tupitsyn deleted comment on IGNITE-16994: - was (Author: ptupitsyn): [~isapego] please review. > .NET: Thin 3.0: Upgrade to SDK 6.0 > -- > > Key: IGNITE-16994 > URL: https://issues.apache.org/jira/browse/IGNITE-16994 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > .NET Core 3.1 LTS support ends in December 2022: > https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core > Upgrade to .NET 6. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16994) .NET: Thin 3.0: Upgrade to SDK 6.0
[ https://issues.apache.org/jira/browse/IGNITE-16994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-16994: Fix Version/s: (was: 3.0.0-alpha5) > .NET: Thin 3.0: Upgrade to SDK 6.0 > -- > > Key: IGNITE-16994 > URL: https://issues.apache.org/jira/browse/IGNITE-16994 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > > .NET Core 3.1 LTS support ends in December 2022: > https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core > Upgrade to .NET 6. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16939) ClientComputeTest.testClientSendsComputeJobToTargetNodeWhenDirectConnectionExists is flaky
[ https://issues.apache.org/jira/browse/IGNITE-16939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-16939: Description: See [https://ci.ignite.apache.org/viewLog.html?buildId=6560290&buildTypeId=ignite3_Test_RunUnitTests] {code:java} org.opentest4j.AssertionFailedError org.opentest4j.AssertionFailedError: expected: but was: at org.apache.ignite.client.ClientComputeTest.testClientSendsComputeJobToTargetNodeWhenDirectConnectionExists(ClientComputeTest.java:68) {code} The branch is main with one commit which disables one test, so it's equivalent to main branch in everything that concerns the failed test. was: See [https://ci.ignite.apache.org/viewLog.html?buildId=6560290&buildTypeId=ignite3_Test_RunUnitTests] {{org.opentest4j.AssertionFailedError: expected: but was: }} {{ at org.apache.ignite.client.ClientComputeTest.testClientSendsComputeJobToTargetNodeWhenDirectConnectionExists(ClientComputeTest.java:68)}} The branch is main with one commit which disables one test, so it's equivalent to main branch in everything that concerns the failed test. > ClientComputeTest.testClientSendsComputeJobToTargetNodeWhenDirectConnectionExists > is flaky > -- > > Key: IGNITE-16939 > URL: https://issues.apache.org/jira/browse/IGNITE-16939 > Project: Ignite > Issue Type: Bug > Components: clients >Reporter: Roman Puchkovskiy >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > See > [https://ci.ignite.apache.org/viewLog.html?buildId=6560290&buildTypeId=ignite3_Test_RunUnitTests] > {code:java} > org.opentest4j.AssertionFailedError > org.opentest4j.AssertionFailedError: expected: but was: > at > org.apache.ignite.client.ClientComputeTest.testClientSendsComputeJobToTargetNodeWhenDirectConnectionExists(ClientComputeTest.java:68) > {code} > The branch is main with one commit which disables one test, so it's > equivalent to main branch in everything that concerns the failed test. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-16930) .NET: Thin 3.0: Implement Compute.ExecuteColocated
[ https://issues.apache.org/jira/browse/IGNITE-16930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538206#comment-17538206 ] Igor Sapego commented on IGNITE-16930: -- [~ptupitsyn] looks good to me. > .NET: Thin 3.0: Implement Compute.ExecuteColocated > -- > > Key: IGNITE-16930 > URL: https://issues.apache.org/jira/browse/IGNITE-16930 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > Implement executeColocated without partition awareness (send the request > using the default connection, let the server route it to the correct node). > See IGNITE-16786 for a reference implementation. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-16930) .NET: Thin 3.0: Implement Compute.ExecuteColocated
[ https://issues.apache.org/jira/browse/IGNITE-16930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538210#comment-17538210 ] Pavel Tupitsyn commented on IGNITE-16930: - Merged to main: 32afeaaf02d8eb4d0d41f8cefb49263f52976ede > .NET: Thin 3.0: Implement Compute.ExecuteColocated > -- > > Key: IGNITE-16930 > URL: https://issues.apache.org/jira/browse/IGNITE-16930 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > Time Spent: 10m > Remaining Estimate: 0h > > Implement executeColocated without partition awareness (send the request > using the default connection, let the server route it to the correct node). > See IGNITE-16786 for a reference implementation. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-16995) C++ Thin: Implement a RemoteFilter for ScanQuery
Igor Sapego created IGNITE-16995: Summary: C++ Thin: Implement a RemoteFilter for ScanQuery Key: IGNITE-16995 URL: https://issues.apache.org/jira/browse/IGNITE-16995 Project: Ignite Issue Type: New Feature Components: thin client Affects Versions: 2.13 Reporter: Igor Sapego Assignee: Igor Sapego Fix For: 2.14 Let's implement a RemoteFilter feature for C++ thin client. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16877) C++ Thin: Implement ScanQuery
[ https://issues.apache.org/jira/browse/IGNITE-16877?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-16877: - Description: Need to add the ScanQuery API to C++ thin client: * The ScanQuery must have a partition property: it may be used to do parallel initial data load to improve performance. was: Need to add the ScanQuery API to C++ thin client: * The ScanQuery must have a partition property: it may be used to do parallel initial data load to improve performance. * It would be nice for the ScanQuery to have a remote filter. Having a remote filter would improve the user experience. > C++ Thin: Implement ScanQuery > - > > Key: IGNITE-16877 > URL: https://issues.apache.org/jira/browse/IGNITE-16877 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Affects Versions: 2.12 >Reporter: Igor Sapego >Assignee: Igor Sapego >Priority: Major > Fix For: 2.14 > > > Need to add the ScanQuery API to C++ thin client: > * The ScanQuery must have a partition property: it may be used to do parallel > initial data load to improve performance. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Created] (IGNITE-16996) Ignite C++: Implement a RemoteFilter for ScanQuery
Igor Sapego created IGNITE-16996: Summary: Ignite C++: Implement a RemoteFilter for ScanQuery Key: IGNITE-16996 URL: https://issues.apache.org/jira/browse/IGNITE-16996 Project: Ignite Issue Type: New Feature Components: platforms Affects Versions: 2.13 Reporter: Igor Sapego Assignee: Igor Sapego Fix For: 2.14 Let's implement a RemoteFilter feature for Ignite C++ (thick client). -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16994) .NET: Thin 3.0: Upgrade to SDK 6.0
[ https://issues.apache.org/jira/browse/IGNITE-16994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-16994: Labels: .NET ignite-3 (was: ignite-3) > .NET: Thin 3.0: Upgrade to SDK 6.0 > -- > > Key: IGNITE-16994 > URL: https://issues.apache.org/jira/browse/IGNITE-16994 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > > .NET Core 3.1 LTS support ends in December 2022: > https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core > Upgrade to .NET 6. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16990) .NET: Thin 3.0: Add partition awareness to ExecuteColocated
[ https://issues.apache.org/jira/browse/IGNITE-16990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-16990: Labels: .NET ignite-3 (was: ignite-3) > .NET: Thin 3.0: Add partition awareness to ExecuteColocated > --- > > Key: IGNITE-16990 > URL: https://issues.apache.org/jira/browse/IGNITE-16990 > Project: Ignite > Issue Type: Improvement > Components: clients >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > Fix For: 3.0.0-alpha5 > > > 1. Compute key hash on the client > 2. Retrieve and maintain up-to-date partitionMap > 2. Send the request directly to the target node if a connection exists -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16928) Thin 3.0: Implement sessions for Java client
[ https://issues.apache.org/jira/browse/IGNITE-16928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Sapego updated IGNITE-16928: - Description: Let's implement local sessions for Java client. Sessions AKA logical connections are described in https://cwiki.apache.org/confluence/display/IGNITE/IEP-90+Client+Lifecycle. What needs to be implemented is: 1. On handshake server should generate a Connection ID and return it in HandshakeRsp; 2. Client should save a Connection ID and associate it with a node it connected to; 3. If disconnected, server should not at once clean up connection associated data but start timer instead. Timeout should be configurable by server config; 4. If client manages to send a proper ConnectionRestoreReq during timeout, the session is restored; 5. All results of all operations that were complete while physical connection is broken is stored within session data and sent back to client if connection is restored. was:Let's implemnt local sessions for Java client. > Thin 3.0: Implement sessions for Java client > > > Key: IGNITE-16928 > URL: https://issues.apache.org/jira/browse/IGNITE-16928 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Affects Versions: 3.0.0-alpha4 >Reporter: Igor Sapego >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > Let's implement local sessions for Java client. > Sessions AKA logical connections are described in > https://cwiki.apache.org/confluence/display/IGNITE/IEP-90+Client+Lifecycle. > What needs to be implemented is: > 1. On handshake server should generate a Connection ID and return it in > HandshakeRsp; > 2. Client should save a Connection ID and associate it with a node it > connected to; > 3. If disconnected, server should not at once clean up connection associated > data but start timer instead. Timeout should be configurable by server config; > 4. If client manages to send a proper ConnectionRestoreReq during timeout, > the session is restored; > 5. All results of all operations that were complete while physical connection > is broken is stored within session data and sent back to client if connection > is restored. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-16905) Sql. ClassCastException when deserialising TIMESTAMP literal
[ https://issues.apache.org/jira/browse/IGNITE-16905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538227#comment-17538227 ] Vladimir Steshin commented on IGNITE-16905: --- [~korlov], I think I got it. But could we have some certain example like a query? > Sql. ClassCastException when deserialising TIMESTAMP literal > > > Key: IGNITE-16905 > URL: https://issues.apache.org/jira/browse/IGNITE-16905 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Konstantin Orlov >Priority: Major > Labels: calcite, ignite-3 > > The problem appears to be caused by an inconsistency of RelReader and > RexBuilder: RelReader diserializes every integer value as a value of type > Integer, but the RexBuilder assumes that for TIMESTAMP literal a value of > type Long will be passed, and make the explicit cast: > {code:java} > // RexBuilder#clean(Object, RelDataType) > case TIMESTAMP: > if (o instanceof TimestampString) { > return o; > } else if (o instanceof Calendar) { > if (!((Calendar) o).getTimeZone().equals(DateTimeUtils.UTC_ZONE)) { > throw new AssertionError(); > } > return TimestampString.fromCalendarFields((Calendar) o); > } else { > return TimestampString.fromMillisSinceEpoch((Long) o); > } {code} > > Here is a stack trace: > {noformat} > Caused by: java.lang.ClassCastException: class java.lang.Integer cannot be > cast to class java.lang.Long (java.lang.Integer and java.lang.Long are in > module java.base of loader 'bootstrap') > at org.apache.calcite.rex.RexBuilder.clean(RexBuilder.java:1780) > at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:1558) > at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:1520) > at > org.apache.ignite.internal.sql.engine.externalize.RelJson.toRex(RelJson.java:759) > at > org.apache.ignite.internal.sql.engine.externalize.RelJsonReader$RelInputImpl.getTuple(RelJsonReader.java:367) > at > org.apache.ignite.internal.sql.engine.externalize.RelJsonReader$RelInputImpl.getTuples(RelJsonReader.java:347) > ... 24 more {noformat} -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Assigned] (IGNITE-16928) Thin 3.0: Implement sessions for Java client
[ https://issues.apache.org/jira/browse/IGNITE-16928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn reassigned IGNITE-16928: --- Assignee: Pavel Tupitsyn > Thin 3.0: Implement sessions for Java client > > > Key: IGNITE-16928 > URL: https://issues.apache.org/jira/browse/IGNITE-16928 > Project: Ignite > Issue Type: New Feature > Components: platforms, thin client >Affects Versions: 3.0.0-alpha4 >Reporter: Igor Sapego >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha5 > > > Let's implement local sessions for Java client. > Sessions AKA logical connections are described in > https://cwiki.apache.org/confluence/display/IGNITE/IEP-90+Client+Lifecycle. > What needs to be implemented is: > 1. On handshake server should generate a Connection ID and return it in > HandshakeRsp; > 2. Client should save a Connection ID and associate it with a node it > connected to; > 3. If disconnected, server should not at once clean up connection associated > data but start timer instead. Timeout should be configurable by server config; > 4. If client manages to send a proper ConnectionRestoreReq during timeout, > the session is restored; > 5. All results of all operations that were complete while physical connection > is broken is stored within session data and sent back to client if connection > is restored. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] (IGNITE-16905) Sql. ClassCastException when deserialising TIMESTAMP literal
[ https://issues.apache.org/jira/browse/IGNITE-16905 ] Vladimir Steshin deleted comment on IGNITE-16905: --- was (Author: vladsz83): [~korlov], I think I got it. But could we have some certain example like a query? > Sql. ClassCastException when deserialising TIMESTAMP literal > > > Key: IGNITE-16905 > URL: https://issues.apache.org/jira/browse/IGNITE-16905 > Project: Ignite > Issue Type: Bug > Components: sql >Reporter: Konstantin Orlov >Priority: Major > Labels: calcite, ignite-3 > > The problem appears to be caused by an inconsistency of RelReader and > RexBuilder: RelReader diserializes every integer value as a value of type > Integer, but the RexBuilder assumes that for TIMESTAMP literal a value of > type Long will be passed, and make the explicit cast: > {code:java} > // RexBuilder#clean(Object, RelDataType) > case TIMESTAMP: > if (o instanceof TimestampString) { > return o; > } else if (o instanceof Calendar) { > if (!((Calendar) o).getTimeZone().equals(DateTimeUtils.UTC_ZONE)) { > throw new AssertionError(); > } > return TimestampString.fromCalendarFields((Calendar) o); > } else { > return TimestampString.fromMillisSinceEpoch((Long) o); > } {code} > > Here is a stack trace: > {noformat} > Caused by: java.lang.ClassCastException: class java.lang.Integer cannot be > cast to class java.lang.Long (java.lang.Integer and java.lang.Long are in > module java.base of loader 'bootstrap') > at org.apache.calcite.rex.RexBuilder.clean(RexBuilder.java:1780) > at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:1558) > at org.apache.calcite.rex.RexBuilder.makeLiteral(RexBuilder.java:1520) > at > org.apache.ignite.internal.sql.engine.externalize.RelJson.toRex(RelJson.java:759) > at > org.apache.ignite.internal.sql.engine.externalize.RelJsonReader$RelInputImpl.getTuple(RelJsonReader.java:367) > at > org.apache.ignite.internal.sql.engine.externalize.RelJsonReader$RelInputImpl.getTuples(RelJsonReader.java:347) > ... 24 more {noformat} -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-16897) Java thin: Implement IgniteSet
[ https://issues.apache.org/jira/browse/IGNITE-16897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538241#comment-17538241 ] Minkyu Kim commented on IGNITE-16897: - Hi. We wish Java Thin Client IgniteSet(Ignite & Gridgain Project) was also implemented with Partition Awareness for best performance like AtomicLong. Really appreciate it. > Java thin: Implement IgniteSet > -- > > Key: IGNITE-16897 > URL: https://issues.apache.org/jira/browse/IGNITE-16897 > Project: Ignite > Issue Type: New Feature > Components: thin client >Affects Versions: 2.12 >Reporter: Igor Sapego >Priority: Major > Fix For: 2.14 > > > Lets implement IgniteSet data structure for Java thin client. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Resolved] (IGNITE-16991) SQL in clause with array arg fails since ignite 2.11
[ https://issues.apache.org/jira/browse/IGNITE-16991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikolay Izhikov resolved IGNITE-16991. -- Resolution: Won't Fix > SQL in clause with array arg fails since ignite 2.11 > > > Key: IGNITE-16991 > URL: https://issues.apache.org/jira/browse/IGNITE-16991 > Project: Ignite > Issue Type: Bug >Reporter: Nikolay Izhikov >Priority: Major > > Reproducer. > Test passes on ignite-2.10 and fails on ignite-2.11 > {code:java} > /** */ > public class SqlInQueryTest extends GridCommonAbstractTest { > /** */ > private static IgniteEx server; > /** {@inheritDoc} */ > @Override protected void beforeTestsStarted() throws Exception { > super.beforeTestsStarted(); > server = startGrid(0); > } > /** */ > @Test > public void testSelectWithInClause() throws Exception { > sql("CREATE TABLE T1(ID VARCHAR, IID VARCHAR, DATA VARCHAR, PRIMARY > KEY(ID, IID))", null); > for (int i = 0; i < 10; i++) > sql( > "INSERT INTO T1(ID, IID, DATA) VALUES(?, ?, ?)", > new Object[] {String.valueOf(i), String.valueOf(i % 3), "just > data"} > ); > assertEquals(10, sql("SELECT ID, IID FROM T1", null).size()); > // One ID inside IN clause. > assertEquals(1, sql( > "SELECT IID FROM T1 WHERE ID IN (?) AND IID = ?", > new Object[] {Arrays.asList("1").toArray(), "1"} > ).size()); > // Two ID inside IN clause. > assertEquals(2, sql( > "SELECT IID FROM T1 WHERE ID IN ('1', '4') AND IID = ?", > new Object[] {"1"} > ).size()); > // Two ID inside IN clause. Pass as patameters. > //assertEquals(2, sql( > //"SELECT IID FROM T1 WHERE ID IN (?) AND IID = ?", > //new Object[] {Arrays.asList("1", "4").toArray(), "1"}).size() > //); > } > /** */ > private List> sql(String sqlText, Object[] args) { > return server.context().query().querySqlFields( > new > SqlFieldsQuery(sqlText).setDistributedJoins(true).setArgs(args), true > ).getAll(); > } > } > {code} -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-16991) SQL in clause with array arg fails since ignite 2.11
[ https://issues.apache.org/jira/browse/IGNITE-16991?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538244#comment-17538244 ] Nikolay Izhikov commented on IGNITE-16991: -- Just copy of my investigation report from user list: It seems, current behavior is correct, in general. Looks like passing list of values as a parameter is common issue for JDBC SQL queries [1] [2] [3]. Tried to find formal requirements in JDBC spec but didn’t find clear description :) Anyway, If you are interested in details: H2 engine optimize IN clause of your query to Equals query, because it contains only one item [4]. So in time Ignite receive filter it looks like «find string equals to array» - this leads to the exception after [5]. Calcite engine behave a little bit different and returns empty results for the same query. Didn’t look deeper to explain this. I will close ticket [6] as «Won’t fix». Feel free to reopen it. [1] https://www.baeldung.com/spring-jdbctemplate-in-list [2] https://stackoverflow.com/questions/45696465/how-to-pass-list-of-values-as-a-parameter-to-in-clause-using-jdbc-template [3] https://stackoverflow.com/questions/1327074/how-to-execute-in-sql-queries-with-springs-jdbctemplate-effectively [4] https://github.com/h2database/h2database/blob/master/h2/src/main/org/h2/expression/condition/ConditionIn.java#L129 [5] https://issues.apache.org/jira/browse/IGNITE-13056 [6] https://issues.apache.org/jira/browse/IGNITE-16991 > SQL in clause with array arg fails since ignite 2.11 > > > Key: IGNITE-16991 > URL: https://issues.apache.org/jira/browse/IGNITE-16991 > Project: Ignite > Issue Type: Bug >Reporter: Nikolay Izhikov >Priority: Major > > Reproducer. > Test passes on ignite-2.10 and fails on ignite-2.11 > {code:java} > /** */ > public class SqlInQueryTest extends GridCommonAbstractTest { > /** */ > private static IgniteEx server; > /** {@inheritDoc} */ > @Override protected void beforeTestsStarted() throws Exception { > super.beforeTestsStarted(); > server = startGrid(0); > } > /** */ > @Test > public void testSelectWithInClause() throws Exception { > sql("CREATE TABLE T1(ID VARCHAR, IID VARCHAR, DATA VARCHAR, PRIMARY > KEY(ID, IID))", null); > for (int i = 0; i < 10; i++) > sql( > "INSERT INTO T1(ID, IID, DATA) VALUES(?, ?, ?)", > new Object[] {String.valueOf(i), String.valueOf(i % 3), "just > data"} > ); > assertEquals(10, sql("SELECT ID, IID FROM T1", null).size()); > // One ID inside IN clause. > assertEquals(1, sql( > "SELECT IID FROM T1 WHERE ID IN (?) AND IID = ?", > new Object[] {Arrays.asList("1").toArray(), "1"} > ).size()); > // Two ID inside IN clause. > assertEquals(2, sql( > "SELECT IID FROM T1 WHERE ID IN ('1', '4') AND IID = ?", > new Object[] {"1"} > ).size()); > // Two ID inside IN clause. Pass as patameters. > //assertEquals(2, sql( > //"SELECT IID FROM T1 WHERE ID IN (?) AND IID = ?", > //new Object[] {Arrays.asList("1", "4").toArray(), "1"}).size() > //); > } > /** */ > private List> sql(String sqlText, Object[] args) { > return server.context().query().querySqlFields( > new > SqlFieldsQuery(sqlText).setDistributedJoins(true).setArgs(args), true > ).getAll(); > } > } > {code} -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-14961) Calcite engine. Arithmetic operators cannot be applied to +
[ https://issues.apache.org/jira/browse/IGNITE-14961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538245#comment-17538245 ] Vladimir Steshin commented on IGNITE-14961: --- Does it correspond the standard? Why do we need this operator? > Calcite engine. Arithmetic operators cannot be applied to + > > > Key: IGNITE-14961 > URL: https://issues.apache.org/jira/browse/IGNITE-14961 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Taras Ledkov >Priority: Major > > The query > {{SELECT CAST('2000-10-10' AS DATE) + 2}} > fails with *SqlValidatorException* > {code} > Cannot apply '+' to arguments of type ' + '. Supported > form(s): ' + ' > ' + ' > ' + ' > ' + ' > {code} > Tests: > {{function/date/test_extract_edge_cases.test_ignore}} -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-14961) Calcite engine. Arithmetic operators cannot be applied to +
[ https://issues.apache.org/jira/browse/IGNITE-14961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-14961: -- Priority: Minor (was: Major) > Calcite engine. Arithmetic operators cannot be applied to + > > > Key: IGNITE-14961 > URL: https://issues.apache.org/jira/browse/IGNITE-14961 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Taras Ledkov >Priority: Minor > Labels: uncertain > > The query > {{SELECT CAST('2000-10-10' AS DATE) + 2}} > fails with *SqlValidatorException* > {code} > Cannot apply '+' to arguments of type ' + '. Supported > form(s): ' + ' > ' + ' > ' + ' > ' + ' > {code} > Tests: > {{function/date/test_extract_edge_cases.test_ignore}} -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-14961) Calcite engine. Arithmetic operators cannot be applied to +
[ https://issues.apache.org/jira/browse/IGNITE-14961?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-14961: -- Labels: uncertain (was: ) > Calcite engine. Arithmetic operators cannot be applied to + > > > Key: IGNITE-14961 > URL: https://issues.apache.org/jira/browse/IGNITE-14961 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Taras Ledkov >Priority: Major > Labels: uncertain > > The query > {{SELECT CAST('2000-10-10' AS DATE) + 2}} > fails with *SqlValidatorException* > {code} > Cannot apply '+' to arguments of type ' + '. Supported > form(s): ' + ' > ' + ' > ' + ' > ' + ' > {code} > Tests: > {{function/date/test_extract_edge_cases.test_ignore}} -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (IGNITE-14961) Calcite engine. Arithmetic operators cannot be applied to +
[ https://issues.apache.org/jira/browse/IGNITE-14961?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538245#comment-17538245 ] Vladimir Steshin edited comment on IGNITE-14961 at 5/17/22 2:46 PM: Does it correspond the standard? Why do we need this operator? There are the intervals. was (Author: vladsz83): Does it correspond the standard? Why do we need this operator? > Calcite engine. Arithmetic operators cannot be applied to + > > > Key: IGNITE-14961 > URL: https://issues.apache.org/jira/browse/IGNITE-14961 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Taras Ledkov >Priority: Minor > Labels: uncertain > > The query > {{SELECT CAST('2000-10-10' AS DATE) + 2}} > fails with *SqlValidatorException* > {code} > Cannot apply '+' to arguments of type ' + '. Supported > form(s): ' + ' > ' + ' > ' + ' > ' + ' > {code} > Tests: > {{function/date/test_extract_edge_cases.test_ignore}} -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-15811) Rename ignite-calcite module to ignite-sql-engine at Ignite 2.x
[ https://issues.apache.org/jira/browse/IGNITE-15811?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladimir Steshin updated IGNITE-15811: -- Priority: Minor (was: Major) > Rename ignite-calcite module to ignite-sql-engine at Ignite 2.x > --- > > Key: IGNITE-15811 > URL: https://issues.apache.org/jira/browse/IGNITE-15811 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Minor > Labels: calcite, calcite2-required > > Let's rename the ignite-calcite module to ignite-sql-engine at Ignite 2.x -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-15811) Rename ignite-calcite module to ignite-sql-engine at Ignite 2.x
[ https://issues.apache.org/jira/browse/IGNITE-15811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538248#comment-17538248 ] Vladimir Steshin commented on IGNITE-15811: --- Looks controversial. It should be discussed I thing. Let's make it minor for now. > Rename ignite-calcite module to ignite-sql-engine at Ignite 2.x > --- > > Key: IGNITE-15811 > URL: https://issues.apache.org/jira/browse/IGNITE-15811 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Yury Gerzhedovich >Priority: Minor > Labels: calcite, calcite2-required > > Let's rename the ignite-calcite module to ignite-sql-engine at Ignite 2.x -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-14955) Calcite engine. Not supported DATE/TIME functions
[ https://issues.apache.org/jira/browse/IGNITE-14955?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538249#comment-17538249 ] Vladimir Steshin commented on IGNITE-14955: --- There are analogues like WEEK(date), EXTRACT(timeUnit FROM datetime), FLOOR(datetime TO timeUnit) CEIL(datetime TO timeUnit). Looks like we nedd to check EXTRACT > Calcite engine. Not supported DATE/TIME functions > -- > > Key: IGNITE-14955 > URL: https://issues.apache.org/jira/browse/IGNITE-14955 > Project: Ignite > Issue Type: Improvement >Reporter: Taras Ledkov >Priority: Major > > Not supported DATE/TIME functions operation: > - {{YEARWEEK}}; > - {{WEEKOFYEAR}}; > - {{DATE_PART}}; > - {{DATE_PART}}; > - {{DATE_TRUNC}}; > - {{EXTRACT(microseconds FROM d)}}; > - {{EXTRACT(milliseconds FROM d)}}; -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-16718) ItIgniteNodeRestartTest#testCfgGap is flaky
[ https://issues.apache.org/jira/browse/IGNITE-16718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538274#comment-17538274 ] Sergey Uttsel commented on IGNITE-16718: LGTM > ItIgniteNodeRestartTest#testCfgGap is flaky > --- > > Key: IGNITE-16718 > URL: https://issues.apache.org/jira/browse/IGNITE-16718 > Project: Ignite > Issue Type: Bug >Reporter: Denis Chudov >Assignee: Alexander Lapin >Priority: Blocker > Labels: ignite-3 > > ItIgniteNodeRestartTest#testCfgGap could be found in ignite-16362 branch. > The reason of failure is null value instead of previously upserted key. > With following (a bit simplified test: one table instead of two and one > insertion instead of one hundred) > {code:java} > public void testCfgGap(TestInfo testInfo) { > final int nodes = 4; > for (int i = 0; i < nodes; i++) { > startNode(testInfo, i); > } > createTableWithData(CLUSTER_NODES.get(0), "t1", nodes); > String igniteName = CLUSTER_NODES.get(nodes - 1).name(); > log.info("Stopping the node."); > IgnitionManager.stop(igniteName); > checkTableWithData(CLUSTER_NODES.get(0), "t1"); > log.info("Starting the node."); > Ignite newNode = IgnitionManager.start(igniteName, null, > workDir.resolve(igniteName)); > CLUSTER_NODES.set(nodes - 1, newNode); > checkTableWithData(CLUSTER_NODES.get(0), "t1"); > checkTableWithData(CLUSTER_NODES.get(nodes - 1), "t1"); > } > private void checkTableWithData(Ignite ignite, String name) { > ... > for (int i = 0; i < 1; i++) { > ... > } > } > private void createTableWithData(Ignite ignite, String name, int replicas) { > ... > for (int i = 0; i < 1; i++) { > ... > } > }{code} > an inconsistent read is reproduced under the following flow: > # table.keyValueView.put(k1) > ## PartitionListener#handleUpsertCommand on Node B > ## PartitionListener#handleUpsertCommand on Node C > ## PartitionListener#handleUpsertCommand on Node D > ## Please pay attention that upsert command wasn't handled on Node A, that's > actually fine because B, C, D is a majority. > # node D stop > # nodeA.table.keyValueView().get(k1) > ## PartitionListener#handleGetCommand on Node B // Means that B is a leader. > # node D start > ## PartitionListener#handleUpsertCommand on Node D // Inner raft rebalance > # nodeA.table.keyValueView().get(k1) > ## PartitionListener#handleGetCommand on Node B // Means that B is still a > leader. > # nodeD.table.keyValueView().get(k1) > ## PartitionListener#handleGetCommand on Node *A* // Means that leader was > changed to A and what's very important there was no handling upsert command > on Node A. > I've checked this by adding > {code:java} > private void handleUpsertCommand(UpsertCommand cmd) { > System.out.println(">>> Upserted" + > ((TxManagerImpl)txManager).clusterService.topologyService().localMember()); > ... > } {code} > and > {code:java} > private SingleRowResponse handleGetCommand(GetCommand cmd) { > System.out.println(">>> Get" + > ((TxManagerImpl)txManager).clusterService.topologyService().localMember()); >... > } {code} > Further investigation items might be: > * Checking whether k1 upsert was committed on node A or not, meaning that > committing and applying to state machine are different steps, and according > to RAFT it's not valid to be a leader with missing committed entries. > * Checking why leader was changed between reads. > h4. UPD 1: > >> Checking whether k1 upsert was committed on node A or not, meaning that > >> committing and applying to state machine are different steps, and > >> according to RAFT it's not valid to be a leader with missing committed > >> entries. > Checked. k1 upsert was committed on node A, so it's only unavailable within > state machine. It also means that leader change to node A is valid. > -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-9878) Failed to start near cache after second call of getOrCreateCache
[ https://issues.apache.org/jira/browse/IGNITE-9878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538282#comment-17538282 ] Sergey Kadaner commented on IGNITE-9878: I am getting the same error while retrieving a cache by name from the SpringCacheManager: {noformat} javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: Failed to start near cache (local node is an affinity node for cache): myCacheName at org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1270) ~[ignite-core-2.9.1.jar:2.9.1] at org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:3376) ~[ignite-core-2.9.1.jar:2.9.1] at org.apache.ignite.cache.spring.SpringCacheManager.getCache(SpringCacheManager.java:356) ~[ignite-spring-2.9.1.jar:2.9.1]{noformat} > Failed to start near cache after second call of getOrCreateCache > > > Key: IGNITE-9878 > URL: https://issues.apache.org/jira/browse/IGNITE-9878 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.6 >Reporter: Roman Guseinov >Assignee: Roman Guseinov >Priority: Major > Attachments: NearCacheIssueReproducer.java, NearCacheTest.java > > > Repeated call of `Ignite.getOrCreateCache(CacheConfiguration cacheCfg, > NearCacheConfiguration nearCfg)` lead the following exception: > {code:java} > javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: > Failed to start near cache (local node is an affinity node for cache): > ignite-test-near-rep > at > org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305) > at > org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2995) > at > org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testRepeatedGetOrCreateCache(NearCacheIssueReproducer.java:24) > Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start > near cache (local node is an affinity node for cache): ignite-test-near-rep > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheChangeRequest(GridCacheProcessor.java:5235) > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3621) > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3560) > at > org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2983) > ... 23 more > {code} > Also, if a cache is specified in the IgniteConfiguration, > `Ignite#getOrCreateNearCache` will fail with the following exception: > {code:java} > javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: > Failed to start near cache (a cache with the same name without near cache is > already started) > at > org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305) > at > org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3072) > at > org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testGetOrCreateNearCache(NearCacheIssueReproducer.java:32) > Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start > near cache (a cache with the same name without near cache is already started) > at > org.apache.ignite.internal.IgniteKernal.checkNearCacheStarted(IgniteKernal.java:3085) > at > org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3067) > ... 23 more > {code} > The test is attached [^NearCacheIssueReproducer.java]. The workaround is to > put near cache config into cache configuration > `CacheConfiguration.setNearConfiguration`. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (IGNITE-9878) Failed to start near cache after second call of getOrCreateCache
[ https://issues.apache.org/jira/browse/IGNITE-9878?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538282#comment-17538282 ] Sergey Kadaner edited comment on IGNITE-9878 at 5/17/22 3:30 PM: - I am getting the same error while retrieving a cache by name from the SpringCacheManager. What does this error mean? {noformat} javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: Failed to start near cache (local node is an affinity node for cache): myCacheName at org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1270) ~[ignite-core-2.9.1.jar:2.9.1] at org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:3376) ~[ignite-core-2.9.1.jar:2.9.1] at org.apache.ignite.cache.spring.SpringCacheManager.getCache(SpringCacheManager.java:356) ~[ignite-spring-2.9.1.jar:2.9.1]{noformat} was (Author: sergeykad): I am getting the same error while retrieving a cache by name from the SpringCacheManager: {noformat} javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: Failed to start near cache (local node is an affinity node for cache): myCacheName at org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1270) ~[ignite-core-2.9.1.jar:2.9.1] at org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:3376) ~[ignite-core-2.9.1.jar:2.9.1] at org.apache.ignite.cache.spring.SpringCacheManager.getCache(SpringCacheManager.java:356) ~[ignite-spring-2.9.1.jar:2.9.1]{noformat} > Failed to start near cache after second call of getOrCreateCache > > > Key: IGNITE-9878 > URL: https://issues.apache.org/jira/browse/IGNITE-9878 > Project: Ignite > Issue Type: Bug > Components: cache >Affects Versions: 2.6 >Reporter: Roman Guseinov >Assignee: Roman Guseinov >Priority: Major > Attachments: NearCacheIssueReproducer.java, NearCacheTest.java > > > Repeated call of `Ignite.getOrCreateCache(CacheConfiguration cacheCfg, > NearCacheConfiguration nearCfg)` lead the following exception: > {code:java} > javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: > Failed to start near cache (local node is an affinity node for cache): > ignite-test-near-rep > at > org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305) > at > org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2995) > at > org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testRepeatedGetOrCreateCache(NearCacheIssueReproducer.java:24) > Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start > near cache (local node is an affinity node for cache): ignite-test-near-rep > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.prepareCacheChangeRequest(GridCacheProcessor.java:5235) > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3621) > at > org.apache.ignite.internal.processors.cache.GridCacheProcessor.dynamicStartCache(GridCacheProcessor.java:3560) > at > org.apache.ignite.internal.IgniteKernal.getOrCreateCache(IgniteKernal.java:2983) > ... 23 more > {code} > Also, if a cache is specified in the IgniteConfiguration, > `Ignite#getOrCreateNearCache` will fail with the following exception: > {code:java} > javax.cache.CacheException: class org.apache.ignite.IgniteCheckedException: > Failed to start near cache (a cache with the same name without near cache is > already started) > at > org.apache.ignite.internal.processors.cache.GridCacheUtils.convertToCacheException(GridCacheUtils.java:1305) > at > org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3072) > at > org.apache.ignite.reproducers.cache.NearCacheIssueReproducer.testGetOrCreateNearCache(NearCacheIssueReproducer.java:32) > Caused by: class org.apache.ignite.IgniteCheckedException: Failed to start > near cache (a cache with the same name without near cache is already started) > at > org.apache.ignite.internal.IgniteKernal.checkNearCacheStarted(IgniteKernal.java:3085) > at > org.apache.ignite.internal.IgniteKernal.getOrCreateNearCache(IgniteKernal.java:3067) > ... 23 more > {code} > The test is attached [^NearCacheIssueReproducer.java]. The workaround is to > put near cache config into cache configuration > `CacheConfiguration.setNearConfiguration`. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Comment Edited] (IGNITE-16897) Java thin: Implement IgniteSet
[ https://issues.apache.org/jira/browse/IGNITE-16897?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538241#comment-17538241 ] Minkyu Kim edited comment on IGNITE-16897 at 5/17/22 8:14 PM: -- Hi. Java Thin Client IgniteSet (Ignite & Gridgain Project) also wants to be implemented with Partition Awareness for best performance. Really appreciate it. was (Author: pkgonan): Hi. We wish Java Thin Client IgniteSet(Ignite & Gridgain Project) was also implemented with Partition Awareness for best performance like AtomicLong. Really appreciate it. > Java thin: Implement IgniteSet > -- > > Key: IGNITE-16897 > URL: https://issues.apache.org/jira/browse/IGNITE-16897 > Project: Ignite > Issue Type: New Feature > Components: thin client >Affects Versions: 2.12 >Reporter: Igor Sapego >Priority: Major > Fix For: 2.14 > > > Lets implement IgniteSet data structure for Java thin client. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Updated] (IGNITE-16989) Annoying "Failed to ping node" warn messages in logs.
[ https://issues.apache.org/jira/browse/IGNITE-16989?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Evgeny Stanilovsky updated IGNITE-16989: Labels: ise storage-engine (was: storage-engine) > Annoying "Failed to ping node" warn messages in logs. > - > > Key: IGNITE-16989 > URL: https://issues.apache.org/jira/browse/IGNITE-16989 > Project: Ignite > Issue Type: Improvement > Components: general >Affects Versions: 2.13 >Reporter: Evgeny Stanilovsky >Priority: Major > Labels: ise, storage-engine > > From user list [1], seems there is present annoying uninformative message in > logs, possible we neet to print only one of such a kind of messages and wrap > others into trace or debug severity? > [1] https://lists.apache.org/thread/1mkng62pco1nsjtdgm881m5ny9v3rogd > [~vladsz83] fyi too. -- This message was sent by Atlassian Jira (v8.20.7#820007)
[jira] [Commented] (IGNITE-16318) Empty binary object is incorrect written/read/modified
[ https://issues.apache.org/jira/browse/IGNITE-16318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17538601#comment-17538601 ] Ignite TC Bot commented on IGNITE-16318: {panel:title=Branch: [pull/10021/head] Base: [master] : No blockers found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel} {panel:title=Branch: [pull/10021/head] Base: [master] : New Tests (8)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1} {color:#8b}Binary Objects{color} [[tests 8|https://ci.ignite.apache.org/viewLog.html?buildId=6572776]] * {color:#013220}IgniteBinaryObjectsTestSuite: BinaryMarshallerNonCompactSelfTest.emptyObjectBuilder[useBinaryArrays = false] - PASSED{color} * {color:#013220}IgniteBinaryObjectsTestSuite: BinaryMarshallerSelfTest.emptyObjectBuilder[useBinaryArrays = true] - PASSED{color} * {color:#013220}IgniteBinaryObjectsTestSuite: BinaryMarshallerSelfTest.emptyObjectBuilder[useBinaryArrays = false] - PASSED{color} * {color:#013220}IgniteBinaryObjectsTestSuite: BinaryMarshallerNonCompactSelfTest.emptyObjectBuilder[useBinaryArrays = true] - PASSED{color} * {color:#013220}IgniteBinaryObjectsTestSuite: BinaryMarshallerNonCompactSelfTest.emptyObjectBinarylizable[useBinaryArrays = true] - PASSED{color} * {color:#013220}IgniteBinaryObjectsTestSuite: BinaryMarshallerNonCompactSelfTest.emptyObjectBinarylizable[useBinaryArrays = false] - PASSED{color} * {color:#013220}IgniteBinaryObjectsTestSuite: BinaryMarshallerSelfTest.emptyObjectBinarylizable[useBinaryArrays = true] - PASSED{color} * {color:#013220}IgniteBinaryObjectsTestSuite: BinaryMarshallerSelfTest.emptyObjectBinarylizable[useBinaryArrays = false] - PASSED{color} {panel} [TeamCity *--> Run :: All* Results|https://ci.ignite.apache.org/viewLog.html?buildId=6572878&buildTypeId=IgniteTests24Java8_RunAll] > Empty binary object is incorrect written/read/modified > -- > > Key: IGNITE-16318 > URL: https://issues.apache.org/jira/browse/IGNITE-16318 > Project: Ignite > Issue Type: Bug > Components: binary, cache >Reporter: Andrey Belyaev >Assignee: Taras Ledkov >Priority: Major > Fix For: 2.14 > > Time Spent: 0.5h > Remaining Estimate: 0h > > Cache interceptor cause problem of missing binary scheme if sql insert > contains only entry key fields and no one value field pass in query. > There is exception happened if inside interceptor we try to make > BinaryObjectBuilder from entry value BinaryObject (#toBuilder()) and then > request builder for any field. > Interceptor example: > {code:java} > new CacheInterceptorAdapter() { > @Nullable > @Override public BinaryObject onBeforePut(Cache.Entry BinaryObject> entry, BinaryObject newVal) { > BinaryObjectBuilder newValBuilder = newVal.toBuilder(); > String bValue = newValBuilder.getField("B"); // Cannot find schema > for object with compact footer > // ... > } > } {code} > It's a pretty serious error which currupt and shutdown grid. > Code example: > {code:java} > LinkedHashMap fields = new LinkedHashMap<>(); > fields.put("A", "java.lang.String"); > fields.put("B", "java.lang.String"); > fields.put("C", "java.lang.String"); > Set keyFields = new LinkedHashSet<>(); > keyFields.add("A"); > CacheInterceptorAdapter cacheInterceptorAdapter = new > CacheInterceptorAdapter() { > @Nullable > @Override public BinaryObject onBeforePut(Cache.Entry BinaryObject> entry, BinaryObject newVal) { > BinaryObjectBuilder newValBuilder = newVal.toBuilder(); > String bValue = newValBuilder.getField("B"); // Cannot find schema > for object with compact footer > if (bValue == null || bValue.isEmpty()) { > newValBuilder.setField("B", "Some value"); > } > return newValBuilder.build(); > } > }; > CacheConfiguration cacheConfiguration = new CacheConfiguration<>() > .setName("TEST_CACHE") > .setKeyConfiguration(new CacheKeyConfiguration() > .setTypeName("TEST_CACHE_KEY") > .setAffinityKeyFieldName("InternalId")) > .setQueryEntities(Collections.singleton(new QueryEntity() > .setTableName("TEST_CACHE") > .setKeyType("TEST_CACHE_KEY") > .setValueType("TEST_CACHE_VALUE") > .setFields(fields) > .setKeyFields(keyFields))) > .setInterceptor(cacheInterceptorAdapter); > IgniteConfiguration igniteConfiguration = new IgniteConfiguration() > .setCacheConfiguration(cacheConfiguration); > try (Ignite ignite = Ignition.start(igniteConfiguration)) { > IgniteCache testCache = ignite.getOrCreateCache("TEST_CACHE"); > // putSql > testCache.query(new SqlFieldsQuery("INSERT INTO TEST_CACHE (A) VALUES > ('12
[jira] [Created] (IGNITE-16997) Design baseline concept
Alexander Lapin created IGNITE-16997: Summary: Design baseline concept Key: IGNITE-16997 URL: https://issues.apache.org/jira/browse/IGNITE-16997 Project: Ignite Issue Type: Task Reporter: Alexander Lapin TBD -- This message was sent by Atlassian Jira (v8.20.7#820007)