date:20220929



[ 
https://issues.apache.org/jira/browse/IGNITE-17785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611193#comment-17611193
 ] 

Ignite TC Bot commented on IGNITE-17785:


{panel:title=Branch: [pull/10277/head] Base: [master] : Possible Blockers 
(106)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 2{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797450]]

{color:#d04437}Cache 6{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797454]]

{color:#d04437}Platform C++ CMake (Win x64 / Release){color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797514]]

{color:#d04437}PDS (Indexing){color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797512]]

{color:#d04437}Platform .NET (Core Linux){color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797517]]

{color:#d04437}SPI (Discovery){color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797534]]

{color:#d04437}Java Client{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797492]]

{color:#d04437}PDS 6{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797508]]

{color:#d04437}Cache 13{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797449]]

{color:#d04437}Platform .NET (Windows){color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797518]]

{color:#d04437}Cache 1{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797445]]

{color:#d04437}PDS 2{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797504]]

{color:#d04437}Start Nodes{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797537]]

{color:#d04437}Basic 1{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797440]]

{color:#d04437}Control Utility{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797481]]

{color:#d04437}Cache (Failover) 2{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797461]]

{color:#d04437}Platform C++ CMake (Linux){color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797515]]

{color:#d04437}Platform C++ CMake (Linux Clang){color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797516]]

{color:#d04437}Cache 5{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797453]]

{color:#d04437}Continuous Query 2{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797478]]

{color:#d04437}Snapshots{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797531]]

{color:#d04437}PDS 5{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797507]]

{color:#d04437}PDS 3{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797505]]

{color:#d04437}Queries 3 (lazy=true){color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797524]]

{color:#d04437}Thin client: Node.js{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797540]]

{color:#d04437}PDS 4{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797506]]

{color:#d04437}PDS (Compatibility){color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797511]]

{color:#d04437}Compute (Grid){color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797475]]

{color:#d04437}Basic 4{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797443]]

{color:#d04437}Queries 3{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797523]]

{color:#d04437}ZooKeeper (Discovery) 1{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797545]]

{color:#d04437}Continuous Query 4{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797480]]

{color:#d04437}JDBC Driver{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797495]]

{color:#d04437}Cache 7{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797455]]

{color:#d04437}ZooKeeper (Discovery) 4{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797548]]

{color:#d04437}Binary Objects{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797444]]

{color:#d04437}Consistency{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797476]]

{color:#d04437}Continuous Query 3{color} [[tests 0 
CANCELLED|https://ci.ignite.apache.org/viewLog.html?buildId=6797479]]

{color:#d04437}Index Query API{color} [[tests 0

[jira] [Commented] (IGNITE-16053) Calcite. Some kind of CROSS JOIN based queries can`t be parsed.

2022-09-29 Thread Aleksey Plekhanov (Jira)



[ 
https://issues.apache.org/jira/browse/IGNITE-16053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611190#comment-17611190
 ] 

Aleksey Plekhanov commented on IGNITE-16053:


Looks like it was resolved by Calcite version upgrade. 

I propose to unignore these tests (and some other) under this ticket.

[~zstan] can you please have a look at the patch?

> Calcite. Some kind of CROSS JOIN based queries can`t be parsed.
> ---
>
> Key: IGNITE-16053
> URL: https://issues.apache.org/jira/browse/IGNITE-16053
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Evgeny Stanilovsky
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: calcite, calcite2-required, calcite3-required, ignite-3
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Queries like attached can`t be planned. 
> /modules/calcite/src/test/sql/sqlite/aggregates/agg1.test_ignored
> {noformat}
> statement ok
> CREATE TABLE tab0(col0 INTEGER, col1 INTEGER, col2 INTEGER)
> statement ok
> CREATE TABLE tab1(col0 INTEGER, col1 INTEGER, col2 INTEGER)
> statement ok
> CREATE TABLE tab2(col0 INTEGER, col1 INTEGER, col2 INTEGER)
> statement ok
> INSERT INTO tab0 VALUES(97,1,99)
> query I rowsort
> SELECT - 92 AS col1 FROM ( tab1 AS cor0 CROSS JOIN tab2 AS cor1 )
> 
> 9 values hashing to 1af709a79a3e56281ffdce4d931d5965
> query I rowsort
> SELECT - 13 FROM ( tab2 cor0 CROSS JOIN tab2 AS cor1 )
> 
> 9 values hashing to e95f5f4bd0f480397cced5f5e8a23792
> query I rowsort
> SELECT ALL + - 37 AS col0 FROM tab0 AS cor0 CROSS JOIN tab1 AS cor1
> 
> 9 values hashing to ed4644af7729c2425ea6cc3d84c6504f
> {noformat}
> {noformat}
> Caused by: class 
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to 
> parse query.
>   at 
> org.apache.ignite.internal.processors.query.calcite.util.Commons.parse(Commons.java:207)
>   at 
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:339)
>   at 
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.sql(SqlScriptRunner.java:149)
>   at 
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.access$600(SqlScriptRunner.java:58)
>   at 
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.execute(SqlScriptRunner.java:570)
>   ... 3 more
> Caused by: org.apache.calcite.sql.parser.SqlParseException: Non-query 
> expression encountered in illegal context
>   at 
> org.apache.ignite.internal.processors.query.calcite.sql.IgniteSqlParserImpl.convertException(IgniteSqlParserImpl.java:397)
>   at 
> org.apache.ignite.internal.processors.query.calcite.sql.IgniteSqlParserImpl.normalizeException(IgniteSqlParserImpl.java:161)
>   at 
> org.apache.calcite.sql.parser.SqlParser.handleException(SqlParser.java:145)
>   at 
> org.apache.calcite.sql.parser.SqlParser.parseStmtList(SqlParser.java:200)
>   at 
> org.apache.ignite.internal.processors.query.calcite.util.Commons.parse(Commons.java:222)
>   at 
> org.apache.ignite.internal.processors.query.calcite.util.Commons.parse(Commons.java:204)
>   ... 7 more
> Caused by: org.apache.calcite.runtime.CalciteException: Non-query expression 
> encountered in illegal context
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>   at 
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:505)
>   at org.apache.calcite.runtime.Resources$ExInst.ex(Resources.java:599)
>   at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:932)
>   at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:917)
>   at 
> org.apache.ignite.internal.processors.query.calcite.sql.IgniteSqlParserImpl.checkNonQueryExpression(IgniteSqlParserImpl.java:320)
>   at 
> org.apache.ignite.internal.processors.query.calcite.sql.IgniteSqlParserImpl.Expression3(IgniteSqlParserImpl.java:4471)
>   at 
> org.apache.ignite.internal.processors.query.calcite.sql.IgniteSqlParserImpl.Expression2b(IgniteSqlParserImpl.java:4163)
>   at 
> org.apache.ignite.internal.processors.query.calcite.sql.IgniteSqlParserImpl.Expression2(IgniteSqlParserImpl.java:4204)
>   at 
> org.apache.ignite.internal.processors.query.calcite.sql.IgniteSqlParserImpl.Expression(IgniteSqlParserImpl.java:4134)
>   at 
>

[jira] [Assigned] (IGNITE-16053) Calcite. Some kind of CROSS JOIN based queries can`t be parsed.

2022-09-29 Thread Aleksey Plekhanov (Jira)



 [ 
https://issues.apache.org/jira/browse/IGNITE-16053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Plekhanov reassigned IGNITE-16053:
--

Assignee: Aleksey Plekhanov

> Calcite. Some kind of CROSS JOIN based queries can`t be parsed.
> ---
>
> Key: IGNITE-16053
> URL: https://issues.apache.org/jira/browse/IGNITE-16053
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Evgeny Stanilovsky
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: calcite, calcite2-required, calcite3-required, ignite-3
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Queries like attached can`t be planned. 
> /modules/calcite/src/test/sql/sqlite/aggregates/agg1.test_ignored
> {noformat}
> statement ok
> CREATE TABLE tab0(col0 INTEGER, col1 INTEGER, col2 INTEGER)
> statement ok
> CREATE TABLE tab1(col0 INTEGER, col1 INTEGER, col2 INTEGER)
> statement ok
> CREATE TABLE tab2(col0 INTEGER, col1 INTEGER, col2 INTEGER)
> statement ok
> INSERT INTO tab0 VALUES(97,1,99)
> query I rowsort
> SELECT - 92 AS col1 FROM ( tab1 AS cor0 CROSS JOIN tab2 AS cor1 )
> 
> 9 values hashing to 1af709a79a3e56281ffdce4d931d5965
> query I rowsort
> SELECT - 13 FROM ( tab2 cor0 CROSS JOIN tab2 AS cor1 )
> 
> 9 values hashing to e95f5f4bd0f480397cced5f5e8a23792
> query I rowsort
> SELECT ALL + - 37 AS col0 FROM tab0 AS cor0 CROSS JOIN tab1 AS cor1
> 
> 9 values hashing to ed4644af7729c2425ea6cc3d84c6504f
> {noformat}
> {noformat}
> Caused by: class 
> org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to 
> parse query.
>   at 
> org.apache.ignite.internal.processors.query.calcite.util.Commons.parse(Commons.java:207)
>   at 
> org.apache.ignite.internal.processors.query.calcite.CalciteQueryProcessor.query(CalciteQueryProcessor.java:339)
>   at 
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.sql(SqlScriptRunner.java:149)
>   at 
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.access$600(SqlScriptRunner.java:58)
>   at 
> org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Query.execute(SqlScriptRunner.java:570)
>   ... 3 more
> Caused by: org.apache.calcite.sql.parser.SqlParseException: Non-query 
> expression encountered in illegal context
>   at 
> org.apache.ignite.internal.processors.query.calcite.sql.IgniteSqlParserImpl.convertException(IgniteSqlParserImpl.java:397)
>   at 
> org.apache.ignite.internal.processors.query.calcite.sql.IgniteSqlParserImpl.normalizeException(IgniteSqlParserImpl.java:161)
>   at 
> org.apache.calcite.sql.parser.SqlParser.handleException(SqlParser.java:145)
>   at 
> org.apache.calcite.sql.parser.SqlParser.parseStmtList(SqlParser.java:200)
>   at 
> org.apache.ignite.internal.processors.query.calcite.util.Commons.parse(Commons.java:222)
>   at 
> org.apache.ignite.internal.processors.query.calcite.util.Commons.parse(Commons.java:204)
>   ... 7 more
> Caused by: org.apache.calcite.runtime.CalciteException: Non-query expression 
> encountered in illegal context
>   at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>   at 
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:62)
>   at 
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
>   at java.lang.reflect.Constructor.newInstance(Constructor.java:423)
>   at 
> org.apache.calcite.runtime.Resources$ExInstWithCause.ex(Resources.java:505)
>   at org.apache.calcite.runtime.Resources$ExInst.ex(Resources.java:599)
>   at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:932)
>   at org.apache.calcite.sql.SqlUtil.newContextException(SqlUtil.java:917)
>   at 
> org.apache.ignite.internal.processors.query.calcite.sql.IgniteSqlParserImpl.checkNonQueryExpression(IgniteSqlParserImpl.java:320)
>   at 
> org.apache.ignite.internal.processors.query.calcite.sql.IgniteSqlParserImpl.Expression3(IgniteSqlParserImpl.java:4471)
>   at 
> org.apache.ignite.internal.processors.query.calcite.sql.IgniteSqlParserImpl.Expression2b(IgniteSqlParserImpl.java:4163)
>   at 
> org.apache.ignite.internal.processors.query.calcite.sql.IgniteSqlParserImpl.Expression2(IgniteSqlParserImpl.java:4204)
>   at 
> org.apache.ignite.internal.processors.query.calcite.sql.IgniteSqlParserImpl.Expression(IgniteSqlParserImpl.java:4134)
>   at 
> org.apache.ignite.internal.processors.query.calcite.sql.IgniteSqlParserImpl.LeafQueryOrExpr(IgniteSqlParserImpl.java:4116)
>   at 
> org.apache.ignite.internal.processors.query.calcite.sql.IgniteSqlParserImpl.QueryOrExpr(IgniteSqlParserImpl.java:4038)
>   at

[jira] [Comment Edited] (IGNITE-17785) Tests in IgniteClientTestSuite NodeSslConnectionMetricTest freeze



[ 
https://issues.apache.org/jira/browse/IGNITE-17785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611189#comment-17611189
 ] 

Igor Sapego edited comment on IGNITE-17785 at 9/29/22 6:58 PM:
---

[~ptupitsyn] overall looks good, but it seems like checkstyle fails in the PR:
{noformat}
/home/travis/build/apache/ignite/modules/clients/src/test/java/org/apache/ignite/common/NodeSslConnectionMetricTest.java:431:89:
 ')' is followed by whitespace. [NoWhitespaceAfter]
{noformat}


was (Author: isapego):
[~ptupitsyn] overall looks good, but it seems like checkstyle fails in the PR:
```
/home/travis/build/apache/ignite/modules/clients/src/test/java/org/apache/ignite/common/NodeSslConnectionMetricTest.java:431:89:
 ')' is followed by whitespace. [NoWhitespaceAfter]
```

> Tests in IgniteClientTestSuite NodeSslConnectionMetricTest freeze
> -
>
> Key: IGNITE-17785
> URL: https://issues.apache.org/jira/browse/IGNITE-17785
> Project: Ignite
>  Issue Type: Bug
>  Components: thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Fix For: 2.15
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> NodeSslConnectionMetricTest freeze and fail:
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_JavaClient/6797036



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (IGNITE-17785) Tests in IgniteClientTestSuite NodeSslConnectionMetricTest freeze



[ 
https://issues.apache.org/jira/browse/IGNITE-17785?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611189#comment-17611189
 ] 

Igor Sapego commented on IGNITE-17785:
--

[~ptupitsyn] overall looks good, but it seems like checkstyle fails in the PR:
```
/home/travis/build/apache/ignite/modules/clients/src/test/java/org/apache/ignite/common/NodeSslConnectionMetricTest.java:431:89:
 ')' is followed by whitespace. [NoWhitespaceAfter]
```

> Tests in IgniteClientTestSuite NodeSslConnectionMetricTest freeze
> -
>
> Key: IGNITE-17785
> URL: https://issues.apache.org/jira/browse/IGNITE-17785
> Project: Ignite
>  Issue Type: Bug
>  Components: thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Fix For: 2.15
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> NodeSslConnectionMetricTest freeze and fail:
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_JavaClient/6797036



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (IGNITE-17118) Use CompletableFuture instead of CompletionStage in all public APIs



[ 
https://issues.apache.org/jira/browse/IGNITE-17118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611187#comment-17611187
 ] 

Igor Sapego commented on IGNITE-17118:
--

[~ptupitsyn] looks good, ship it!

> Use CompletableFuture instead of CompletionStage in all public APIs
> ---
>
> Key: IGNITE-17118
> URL: https://issues.apache.org/jira/browse/IGNITE-17118
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 3.0.0-alpha5
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The majority of async public APIs return *CompletableFuture*, however there 
> are some occurrences of *CompletionStage* too.
> As discussed on the [dev 
> list|https://lists.apache.org/thread/tx15hpbddnq4tfkwyvjlgfyvnbb7xzwx], we 
> should use *CompletableFuture*.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (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:comment-tabpanel=17611186#comment-17611186
 ] 

Igor Sapego edited comment on IGNITE-16994 at 9/29/22 6:53 PM:
---

[~ptupitsyn] looks good to me. Only left single comment.


was (Author: isapego):
[~ptupitsyn] looks good to me.

> .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
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, ignite-3
> Fix For: 3.0.0-alpha6
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> .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.10#820010)

[jira] [Commented] (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:comment-tabpanel=17611186#comment-17611186
 ] 

Igor Sapego commented on IGNITE-16994:
--

[~ptupitsyn] looks good to me.

> .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
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, ignite-3
> Fix For: 3.0.0-alpha6
>
>
> .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.10#820010)

[jira] [Updated] (IGNITE-17785) Tests in IgniteClientTestSuite NodeSslConnectionMetricTest freeze



 [ 
https://issues.apache.org/jira/browse/IGNITE-17785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Tupitsyn updated IGNITE-17785:

Ignite Flags:   (was: Docs Required,Release Notes Required)

> Tests in IgniteClientTestSuite NodeSslConnectionMetricTest freeze
> -
>
> Key: IGNITE-17785
> URL: https://issues.apache.org/jira/browse/IGNITE-17785
> Project: Ignite
>  Issue Type: Bug
>  Components: thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Fix For: 2.15
>
>
> NodeSslConnectionMetricTest freeze and fail:
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_JavaClient/6797036



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (IGNITE-17785) Tests in IgniteClientTestSuite NodeSslConnectionMetricTest freeze

Pavel Tupitsyn created IGNITE-17785:
---

 Summary: Tests in IgniteClientTestSuite 
NodeSslConnectionMetricTest freeze
 Key: IGNITE-17785
 URL: https://issues.apache.org/jira/browse/IGNITE-17785
 Project: Ignite
  Issue Type: Bug
  Components: thin client
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 2.15






--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17785) Tests in IgniteClientTestSuite NodeSslConnectionMetricTest freeze



 [ 
https://issues.apache.org/jira/browse/IGNITE-17785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Tupitsyn updated IGNITE-17785:

Description: 
NodeSslConnectionMetricTest freeze and fail:
https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_JavaClient/6797036

> Tests in IgniteClientTestSuite NodeSslConnectionMetricTest freeze
> -
>
> Key: IGNITE-17785
> URL: https://issues.apache.org/jira/browse/IGNITE-17785
> Project: Ignite
>  Issue Type: Bug
>  Components: thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
> Fix For: 2.15
>
>
> NodeSslConnectionMetricTest freeze and fail:
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_JavaClient/6797036



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (IGNITE-17118) Use CompletableFuture instead of CompletionStage in all public APIs



[ 
https://issues.apache.org/jira/browse/IGNITE-17118?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611176#comment-17611176
 ] 

Pavel Tupitsyn edited comment on IGNITE-17118 at 9/29/22 6:20 PM:
--

[~isapego] please review


was (Author: ptupitsyn):
@sapego please review

> Use CompletableFuture instead of CompletionStage in all public APIs
> ---
>
> Key: IGNITE-17118
> URL: https://issues.apache.org/jira/browse/IGNITE-17118
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 3.0.0-alpha5
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> The majority of async public APIs return *CompletableFuture*, however there 
> are some occurrences of *CompletionStage* too.
> As discussed on the [dev 
> list|https://lists.apache.org/thread/tx15hpbddnq4tfkwyvjlgfyvnbb7xzwx], we 
> should use *CompletableFuture*.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17780) Update Kubernetes Deployment examples to StatefulSet

2022-09-29 Thread Jeremy McMillan (Jira)



 [ 
https://issues.apache.org/jira/browse/IGNITE-17780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy McMillan updated IGNITE-17780:
-
Ignite Flags:   (was: Docs Required,Release Notes Required)

> Update Kubernetes Deployment examples to StatefulSet
> 
>
> Key: IGNITE-17780
> URL: https://issues.apache.org/jira/browse/IGNITE-17780
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation
>Reporter: Jeremy McMillan
>Priority: Minor
>
> StatefulSet has been supported since IGNITE-6241. Experience supporting 
> Ignite in the field has led best practice recommendations to stop 
> recommending the use of Kubernetes Deployment objects because of the 
> benefits, in practice, which persistent volumes bring to common operations 
> like restarting pods.
> Persistent topology and node identity makes re-joining a cluster much cheaper 
> than always creating new Ignite nodes as pods are started.
> This should be simple for the cloud provider specific examples: just change 
> the "Creating a Pod Configuration" sections to provide a valid StatefulSet 
> example.
>  * 
> [https://ignite.apache.org/docs/2.11.1/installation/kubernetes/amazon-eks-deployment#creating-pod-configuration]
>  * 
> [https://ignite.apache.org/docs/2.11.1/installation/kubernetes/azure-deployment#creating-pod-configuration]
>  * 
> [https://ignite.apache.org/docs/2.11.1/installation/kubernetes/gke-deployment#creating-pod-configuration]
>  *  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17780) Update Kubernetes Deployment examples to StatefulSet

2022-09-29 Thread Jeremy McMillan (Jira)



 [ 
https://issues.apache.org/jira/browse/IGNITE-17780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jeremy McMillan updated IGNITE-17780:
-
Description: 
StatefulSet has been supported since IGNITE-6241. Experience supporting Ignite 
in the field has led best practice recommendations to stop recommending the use 
of Kubernetes Deployment objects because of the benefits, in practice, which 
persistent volumes bring to common operations like restarting pods.

Persistent topology and node identity makes re-joining a cluster much cheaper 
than always creating new Ignite nodes as pods are started.

This should be simple for the cloud provider specific examples: just change the 
"Creating a Pod Configuration" sections to provide a valid StatefulSet example.
 * 
[https://ignite.apache.org/docs/2.11.1/installation/kubernetes/amazon-eks-deployment#creating-pod-configuration]
 * 
[https://ignite.apache.org/docs/2.11.1/installation/kubernetes/azure-deployment#creating-pod-configuration]
 * 
[https://ignite.apache.org/docs/2.11.1/installation/kubernetes/gke-deployment#creating-pod-configuration]
 *  

  was:
StatefulSet has been supported since IGNITE-6241. Experience supporting Ignite 
in the field has led best practice recommendations to stop recommending the use 
of Kubernetes Deployment objects because of the benefits, in practice, which 
persistent volumes bring to common operations like restarting pods.

Persistent topology and node identity makes re-joining a cluster much cheaper 
than always creating new Ignite nodes as pods are started.


> Update Kubernetes Deployment examples to StatefulSet
> 
>
> Key: IGNITE-17780
> URL: https://issues.apache.org/jira/browse/IGNITE-17780
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation
>Reporter: Jeremy McMillan
>Priority: Minor
>
> StatefulSet has been supported since IGNITE-6241. Experience supporting 
> Ignite in the field has led best practice recommendations to stop 
> recommending the use of Kubernetes Deployment objects because of the 
> benefits, in practice, which persistent volumes bring to common operations 
> like restarting pods.
> Persistent topology and node identity makes re-joining a cluster much cheaper 
> than always creating new Ignite nodes as pods are started.
> This should be simple for the cloud provider specific examples: just change 
> the "Creating a Pod Configuration" sections to provide a valid StatefulSet 
> example.
>  * 
> [https://ignite.apache.org/docs/2.11.1/installation/kubernetes/amazon-eks-deployment#creating-pod-configuration]
>  * 
> [https://ignite.apache.org/docs/2.11.1/installation/kubernetes/azure-deployment#creating-pod-configuration]
>  * 
> [https://ignite.apache.org/docs/2.11.1/installation/kubernetes/gke-deployment#creating-pod-configuration]
>  *  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17613) Create incremental snapshot

[
https://issues.apache.org/jira/browse/IGNITE-17613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Nikolay Izhikov updated IGNITE-17613:
-
Description:
Incremental snapshot is a lightweight alternative to full snapshot. It bases on
the non-blocking Consistent Cut algorithm and provides a collection of WAL
segments that hold logical changes since previous snapshot (full or
incremental).

Incremental snapshot should contain:
* compacted WAL segments
* meta file with Consistent Cut to restore on
* binary_meta if it has changed since previous snapshot.

Incremental snapshot is stored within full snapshot directory.

Incremental snapshot before creation checks:
* Base snapshot (at least its metafile) exists. Exists metafile for all
incremental snapshots.
* Validate that no misses in WAL segments since previous snapshot.
* Check that new _ConsistentCutVersion_ is greater than version of previous
snapshots.
* Check that baseline topology and cacheGroups are the same (relatively to
base snapshot).

More info in IEP:
[https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=211884314]

Highlevel process of creation of incremental snapshot(without consistent cut
algorithm):

* Incremental snapshot started with create snapshot command with --incremental
flag.
* Incremental snapshot consists of:
** WAL segments from previous increment snapshot (or full snapshot in case
first incremental snapshot).
** Changed binary meta and marshaller files.
** Snapshot metafile
* Incremental snapshot are placed to
{{work/snapshots/mybackup/increments/node01/0001}} folder where
** mybackup - name of the full snapshot.
** node01 - consistent id of the node.
** 0001, 0002, etc - number of incremental snapshot.
* Incremental snapshot creation consists of the following actions executed on
each node. The whole process orchestrated by the {{DistributedProcess}} in the
same manner as the full snapshot creation:
** creation of the snapshot folder
** awaits while required WAL segments will be archived
** copy (hard-linked) required WAL segments to the incremental snapshot
folder.
** creates snapshot metafile.
* Failover guarantees (remove partially created snapshot, etc) should be the
same as for the full snapshot.
* Removal of the full snapshot must also removes all the incremental snapshot
based on the full one.
* Removal of the incremental snapshot may be done only for the last one. If
there are next incremental snapshot (0003, for example) then removal of any
previous (0001 or 0002) must be restricted.

was:
Incremental snapshot is a lightweight alternative to full snapshot. It bases on
the non-blocking Consistent Cut algorithm and provides a collection of WAL
segments that hold logical changes since previous snapshot (full or
incremental).

Incremental snapshot should contain:
* compacted WAL segments
* meta file with Consistent Cut to restore on
* binary_meta if it has changed since previous snapshot.

Incremental snapshot is stored within full snapshot directory.

More info in IEP:
[https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=211884314]

Highlevel process of creation of incremental snapshot(without consistent cut
algorithm):

> Create incremental snapshot
> ---
>
> Key: IGNITE-17613
> URL: https://issues.apache.org/jira/browse/IGNITE-17613
> Project: Ignite
> Issue Type: Sub-task
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>

[jira] [Updated] (IGNITE-17613) Create incremental snapshot



 [ 
https://issues.apache.org/jira/browse/IGNITE-17613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikolay Izhikov updated IGNITE-17613:
-
Description: 
Incremental snapshot is a lightweight alternative to full snapshot. It bases on 
the non-blocking Consistent Cut algorithm and provides a collection of WAL 
segments that hold logical changes since previous snapshot (full or 
incremental).

Incremental snapshot should contain:
 * compacted WAL segments
 * meta file with Consistent Cut to restore on
 * binary_meta if it has changed since previous snapshot.

Incremental snapshot is stored within full snapshot directory.

Incremental snapshot before creation checks:
 * Base snapshot (at least its metafile) exists. Exists metafile for all 
incremental snapshots.
 * Validate that no misses in WAL segments since previous snapshot.
 * Check that new _ConsistentCutVersion_ is greater than version of previous 
snapshots.
 * Check that baseline topology and cacheGroups are the same (relatively to 
base snapshot).

More info in IEP: 
[https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=211884314]




Highlevel process of creation of incremental snapshot(without consistent cut 
algorithm):

* Incremental snapshot started with create snapshot command with --incremental 
flag.
* Incremental snapshot consists of:
  ** WAL segments from previous increment snapshot (or full snapshot in case 
first incremental snapshot).
  ** Changed binary meta and marshaller files.
  ** Snapshot metafile
* Incremental snapshot are placed to 
{{work/snapshots/mybackup/increments/node01/0001}} folder where
  ** mybackup - name of the full snapshot. 
  ** node01 - consistent id of the node.
  ** 0001, 0002, etc - number of incremental snapshot.
* Incremental snapshot creation consists of the following actions executed on 
each node. The whole process orchestrated by the {{DistributedProcess}} in the 
same manner as the full snapshot creation:
  ** creation of the snapshot folder
  ** awaits while required WAL segments will be archived
  ** copy (hard-linked) required WAL segments to the incremental snapshot 
folder.
  ** creates snapshot metafile.

  was:
Incremental snapshot is a lightweight alternative to full snapshot. It bases on 
the non-blocking Consistent Cut algorithm and provides a collection of WAL 
segments that hold logical changes since previous snapshot (full or 
incremental).

Incremental snapshot should contain:
 * compacted WAL segments
 * meta file with Consistent Cut to restore on
 * binary_meta if it has changed since previous snapshot.

Incremental snapshot is stored within full snapshot directory.

Incremental snapshot before creation checks:
 * Base snapshot (at least its metafile) exists. Exists metafile for all 
incremental snapshots.
 * Validate that no misses in WAL segments since previous snapshot.
 * Check that new _ConsistentCutVersion_ is greater than version of previous 
snapshots.
 * Check that baseline topology and cacheGroups are the same (relatively to 
base snapshot).

More info in IEP: 
[https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=211884314]




Highlevel process of creation of incremental snapshot(without consistent cut 
algorithm):

1. Incremental snapshot started with create snapshot command with --incremental 
flag.
2. 




> Create incremental snapshot
> ---
>
> Key: IGNITE-17613
> URL: https://issues.apache.org/jira/browse/IGNITE-17613
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
>  Labels: IEP-89, ise
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Incremental snapshot is a lightweight alternative to full snapshot. It bases 
> on the non-blocking Consistent Cut algorithm and provides a collection of WAL 
> segments that hold logical changes since previous snapshot (full or 
> incremental).
> Incremental snapshot should contain:
>  * compacted WAL segments
>  * meta file with Consistent Cut to restore on
>  * binary_meta if it has changed since previous snapshot.
> Incremental snapshot is stored within full snapshot directory.
> Incremental snapshot before creation checks:
>  * Base snapshot (at least its metafile) exists. Exists metafile for all 
> incremental snapshots.
>  * Validate that no misses in WAL segments since previous snapshot.
>  * Check that new _ConsistentCutVersion_ is greater than version of previous 
> snapshots.
>  * Check that baseline topology and cacheGroups are the same (relatively to 
> base snapshot).
> More info in IEP: 
> [https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=211884314]
> 
> Highlevel process of creation of incremental snapshot(without consistent cut 
> algorithm):
> * Incremental snapshot started with create snapshot command with

[jira] [Created] (IGNITE-17784) Fix freezes in ItThinClientTransactionsTest

2022-09-29 Thread Vladislav Pyatkov (Jira)

Vladislav Pyatkov created IGNITE-17784:
--

 Summary: Fix freezes in ItThinClientTransactionsTest
 Key: IGNITE-17784
 URL: https://issues.apache.org/jira/browse/IGNITE-17784
 Project: Ignite
  Issue Type: Bug
Reporter: Vladislav Pyatkov
Assignee: Vladislav Pyatkov


Tests in ItThinClientTransactionsTest freezes periodically.

There are two reasons:
 * Transactions are not committed (rolled back) when the test fails.
 * testAccessLockedKeyTimesOut test is waiting of timeout on operation. But if 
the transaction was started into primary replica, it has no timeout due to 
nothing network communication between their replica manager and the primary 
replica. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17613) Create incremental snapshot



 [ 
https://issues.apache.org/jira/browse/IGNITE-17613?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikolay Izhikov updated IGNITE-17613:
-
Description: 
Incremental snapshot is a lightweight alternative to full snapshot. It bases on 
the non-blocking Consistent Cut algorithm and provides a collection of WAL 
segments that hold logical changes since previous snapshot (full or 
incremental).

Incremental snapshot should contain:
 * compacted WAL segments
 * meta file with Consistent Cut to restore on
 * binary_meta if it has changed since previous snapshot.

Incremental snapshot is stored within full snapshot directory.

Incremental snapshot before creation checks:
 * Base snapshot (at least its metafile) exists. Exists metafile for all 
incremental snapshots.
 * Validate that no misses in WAL segments since previous snapshot.
 * Check that new _ConsistentCutVersion_ is greater than version of previous 
snapshots.
 * Check that baseline topology and cacheGroups are the same (relatively to 
base snapshot).

More info in IEP: 
[https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=211884314]




Highlevel process of creation of incremental snapshot(without consistent cut 
algorithm):

1. Incremental snapshot started with create snapshot command with --incremental 
flag.
2. 



  was:
Incremental snapshot is a lightweight alternative to full snapshot. It bases on 
the non-blocking Consistent Cut algorithm and provides a collection of WAL 
segments that hold logical changes since previous snapshot (full or 
incremental).

Incremental snapshot should contain:
 * compacted WAL segments
 * meta file with Consistent Cut to restore on
 * binary_meta if it has changed since previous snapshot.

Incremental snapshot is stored within full snapshot directory.

Incremental snapshot before creation checks:
 * Base snapshot (at least its metafile) exists. Exists metafile for all 
incremental snapshots.
 * Validate that no misses in WAL segments since previous snapshot.
 * Check that new _ConsistentCutVersion_ is greater than version of previous 
snapshots.
 * Check that baseline topology and cacheGroups are the same (relatively to 
base snapshot).

More info in IEP: 
[https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=211884314]


> Create incremental snapshot
> ---
>
> Key: IGNITE-17613
> URL: https://issues.apache.org/jira/browse/IGNITE-17613
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
>  Labels: IEP-89, ise
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Incremental snapshot is a lightweight alternative to full snapshot. It bases 
> on the non-blocking Consistent Cut algorithm and provides a collection of WAL 
> segments that hold logical changes since previous snapshot (full or 
> incremental).
> Incremental snapshot should contain:
>  * compacted WAL segments
>  * meta file with Consistent Cut to restore on
>  * binary_meta if it has changed since previous snapshot.
> Incremental snapshot is stored within full snapshot directory.
> Incremental snapshot before creation checks:
>  * Base snapshot (at least its metafile) exists. Exists metafile for all 
> incremental snapshots.
>  * Validate that no misses in WAL segments since previous snapshot.
>  * Check that new _ConsistentCutVersion_ is greater than version of previous 
> snapshots.
>  * Check that baseline topology and cacheGroups are the same (relatively to 
> base snapshot).
> More info in IEP: 
> [https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=211884314]
> 
> Highlevel process of creation of incremental snapshot(without consistent cut 
> algorithm):
> 1. Incremental snapshot started with create snapshot command with 
> --incremental flag.
> 2. 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17783) Size metrics improvement part 2

2022-09-29 Thread Aleksandr Polovtcev (Jira)



 [ 
https://issues.apache.org/jira/browse/IGNITE-17783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksandr Polovtcev updated IGNITE-17783:
-
Description: When implementing IGNITE-17728, PagesFillFactor metrics was 
interpreted incorrectly. It was assumed (mostly due to non-existent javadoc) 
that it should reflect the ratio of occupied space to the total allocated 
space. It turns out that it is actually used to understand if a lot of pages 
are not filled completely (which may indicate an unsuitable cache entry size, 
for example), so it should be computed as a ratio of total occupied space (page 
data without fragmentation) to the space of all non-empty pages.  

> Size metrics improvement part 2
> ---
>
> Key: IGNITE-17783
> URL: https://issues.apache.org/jira/browse/IGNITE-17783
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
>
> When implementing IGNITE-17728, PagesFillFactor metrics was interpreted 
> incorrectly. It was assumed (mostly due to non-existent javadoc) that it 
> should reflect the ratio of occupied space to the total allocated space. It 
> turns out that it is actually used to understand if a lot of pages are not 
> filled completely (which may indicate an unsuitable cache entry size, for 
> example), so it should be computed as a ratio of total occupied space (page 
> data without fragmentation) to the space of all non-empty pages.  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (IGNITE-11461) Automatic modules support for Apache Ignite: find and resolve packages conflicts

2022-09-29 Thread Simon Ochsenreither (Jira)



[ 
https://issues.apache.org/jira/browse/IGNITE-11461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611076#comment-17611076
 ] 

Simon Ochsenreither edited comment on IGNITE-11461 at 9/29/22 4:56 PM:
---

It's kinda hard to expect a mass migration on one hand while needlessly 
[creating new 
conflicts|https://github.com/apache/ignite/tree/master/modules/kubernetes/src/main/java/org/apache/ignite/client]
 on the other.


Trying to fix ignite-kubernetes:

{code}
Index: modules/kubernetes/src/main/java/module-info.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
diff --git a/modules/kubernetes/src/main/java/module-info.java 
b/modules/kubernetes/src/main/java/module-info.java
new file mode 100644
--- /dev/null    (date 1664468172190)
+++ b/modules/kubernetes/src/main/java/module-info.java    (date 1664468172190)
@@ -0,0 +1,6 @@
+module org.apache.ignite.kubernetes {
+  requires org.apache.ignite.core;
+
+  requires com.fasterxml.jackson.annotation;
+  requires com.fasterxml.jackson.databind;
+}
Index: 
modules/kubernetes/src/main/java/org/apache/ignite/client/ThinClientKubernetesAddressFinder.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
diff --git 
a/modules/kubernetes/src/main/java/org/apache/ignite/client/ThinClientKubernetesAddressFinder.java
 
b/modules/kubernetes/src/main/java/org/apache/ignite/kubernetes/client/ThinClientKubernetesAddressFinder.java
rename from 
modules/kubernetes/src/main/java/org/apache/ignite/client/ThinClientKubernetesAddressFinder.java
rename to 
modules/kubernetes/src/main/java/org/apache/ignite/kubernetes/client/ThinClientKubernetesAddressFinder.java
--- 
a/modules/kubernetes/src/main/java/org/apache/ignite/client/ThinClientKubernetesAddressFinder.java
    (revision 996e1ad4361f0d9dc8974689ddf6931c56ab5083)
+++ 
b/modules/kubernetes/src/main/java/org/apache/ignite/kubernetes/client/ThinClientKubernetesAddressFinder.java
    (date 1664468060678)
@@ -15,8 +15,9 @@
  * limitations under the License.
  */
 
-package org.apache.ignite.client;
+package org.apache.ignite.kubernetes.client;
 
+import org.apache.ignite.client.ClientAddressFinder;
 import 
org.apache.ignite.internal.kubernetes.connection.KubernetesServiceAddressResolver;
 import 
org.apache.ignite.kubernetes.configuration.KubernetesConnectionConfiguration;
 
Index: 
modules/kubernetes/src/test/java/org/apache/ignite/kubernetes/discovery/TestClusterClientConnection.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
diff --git 
a/modules/kubernetes/src/test/java/org/apache/ignite/kubernetes/discovery/TestClusterClientConnection.java
 
b/modules/kubernetes/src/test/java/org/apache/ignite/kubernetes/discovery/TestClusterClientConnection.java
--- 
a/modules/kubernetes/src/test/java/org/apache/ignite/kubernetes/discovery/TestClusterClientConnection.java
    (revision 996e1ad4361f0d9dc8974689ddf6931c56ab5083)
+++ 
b/modules/kubernetes/src/test/java/org/apache/ignite/kubernetes/discovery/TestClusterClientConnection.java
    (date 1664468060690)
@@ -20,7 +20,7 @@
 import org.apache.ignite.Ignition;
 import org.apache.ignite.client.ClientCache;
 import org.apache.ignite.client.IgniteClient;
-import org.apache.ignite.client.ThinClientKubernetesAddressFinder;
+import org.apache.ignite.kubernetes.client.ThinClientKubernetesAddressFinder;
 import org.apache.ignite.configuration.ClientConfiguration;
 import org.apache.ignite.configuration.ClientConnectorConfiguration;
 import org.apache.ignite.configuration.IgniteConfiguration;
Index: modules/core/src/main/java/module-info.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===
diff --git a/modules/core/src/main/java/module-info.java 
b/modules/core/src/main/java/module-info.java
new file mode 100644
--- /dev/null    (date 1664470741994)
+++ b/modules/core/src/main/java/module-info.java    (date 1664470741994)
@@ -0,0 +1,10 @@
+module org.apache.ignite.core {
+  requires static org.jetbrains.annotations;
+
+
+  exports org.apache.ignite;
+  exports org.apache.ignite.client;
+  exports org.apache.ignite.configuration;
+  exports org.apache.ignite.internal;
+  exports org.apache.ignite.internal.util.typedef.internal;
+}

{code}


was (Author: soc):
It's kinda hard to expect a mass migration on one hand while needlessly 
[creating new 
conflicts|https://github.com/apache/ignite/tree/master/modules/kubernetes/src/main/java/org/apache/ignite/client]
 on the other.

> Automatic modules support for Apache Ignite: find and resolve packages 
> conflicts
>

[jira] [Updated] (IGNITE-17728) Improve data size-related metrics

2022-09-29 Thread Aleksandr Polovtcev (Jira)



 [ 
https://issues.apache.org/jira/browse/IGNITE-17728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksandr Polovtcev updated IGNITE-17728:
-
Ignite Flags: Docs Required,Release Notes Required

> Improve data size-related metrics
> -
>
> Key: IGNITE-17728
> URL: https://issues.apache.org/jira/browse/IGNITE-17728
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Fix For: 2.15
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> There are several problems with the current approach to metrics related to 
> pages and sizes occupied by data:
> # {{PagesFillFactor}} implementation is strange: though its javadoc is pretty 
> much useless, one might think that it represents a percentage of bytes 
> occupied by data in relation to the whole available bytes. However, for some 
> reason, it is calculated as {{(TotalSpace - FreeSpaceInDataPages) / 
> TotalSpace}}, i.e. it does not take completely empty pages into account.
> # There exists a {{TotalUsedPages}} metric that is only available through 
> JMX, it does not get registered in the MetricsRegistry.
> # There exists {{TotalAllocatedPages}} and {{TotalAllocatedSize}} metrics, 
> but no {{TotalUsedSize}} metrics.
> # It would be helpful to add a metric that calculates bytes, occupied by the 
> data (even though it can be indirectly computed using the 
> {{PagesFillFactor}}).



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (IGNITE-17783) Size metrics improvement part 2

2022-09-29 Thread Aleksandr Polovtcev (Jira)

Aleksandr Polovtcev created IGNITE-17783:


 Summary: Size metrics improvement part 2
 Key: IGNITE-17783
 URL: https://issues.apache.org/jira/browse/IGNITE-17783
 Project: Ignite
  Issue Type: Improvement
Reporter: Aleksandr Polovtcev
Assignee: Aleksandr Polovtcev






--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[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: 3.0.0-alpha6

> .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
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, ignite-3
> Fix For: 3.0.0-alpha6
>
>
> .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.10#820010)

[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:

Component/s: platforms
 thin client

> .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
>  Components: platforms, thin client
>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.10#820010)

[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:

Ignite Flags:   (was: Docs Required,Release Notes Required)

> .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.10#820010)

[jira] [Updated] (IGNITE-17623) .NET: Thin 3.0: Perf: review exception throw sites



 [ 
https://issues.apache.org/jira/browse/IGNITE-17623?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Tupitsyn updated IGNITE-17623:

Priority: Minor  (was: Major)

> .NET: Thin 3.0: Perf: review exception throw sites
> --
>
> Key: IGNITE-17623
> URL: https://issues.apache.org/jira/browse/IGNITE-17623
> Project: Ignite
>  Issue Type: Task
>  Components: platforms
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: .NET, ignite-3
> Fix For: 3.0.0-alpha6
>
>
> *throw* statement prevents inlining. Review all throw statements:
> * Internal sanity checks can be replaced with Debug.Assert
> * When *throw* is still necessary, and the method is small (candidate for 
> inlining) - move throw logic into a separate method.
> https://devblogs.microsoft.com/dotnet/performance_improvements_in_net_7/#exceptions



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Resolved] (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 resolved IGNITE-16939.
-
Resolution: Not A Problem

> 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-alpha6
>
>
> See 
> [https://ci.ignite.apache.org/viewLog.html?buildId=6560290=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.10#820010)

[jira] [Commented] (IGNITE-16939) ClientComputeTest.testClientSendsComputeJobToTargetNodeWhenDirectConnectionExists is flaky



[ 
https://issues.apache.org/jira/browse/IGNITE-16939?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611089#comment-17611089
 ] 

Pavel Tupitsyn commented on IGNITE-16939:
-

1 failure out of 646 recent runs. I've added an assertion around 
waitForCondition as part of IGNITE-17763. Closing this for now.

> 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-alpha6
>
>
> See 
> [https://ci.ignite.apache.org/viewLog.html?buildId=6560290=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.10#820010)

[jira] [Updated] (IGNITE-17696) C++ coding conventions for ignite-3

2022-09-29 Thread Aleksey Demakov (Jira)



 [ 
https://issues.apache.org/jira/browse/IGNITE-17696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Demakov updated IGNITE-17696:
-
Description: 
Establish common style for C++ code in Apache Ignite 3. -The suggested approach 
is as follows:-
 * {-}the C++ code style should resemble the Java style for consistency{-};
 * -for things that are specific to C++ or break C++ industry-established 
practices too violently the rules will be settled one by one and described in a 
MD document in the repo.-

A MD document in the repo will describe the coding style.

A clang-format file will be provided for automatic indentation of the code.

  was:
Establish common style for C++ code in Apache Ignite 3. -The suggested approach 
is as follows:-
 * {-}the C++ code style should resemble the Java style for consistency{-};
 * -for things that are specific to C++ or break C++ industry-established 
practices too violently the rules will be settled one by one and described in a 
MD document in the repo.-

A MD document in the repo will  describe the coding style.

A clang-format file will be provided for automatic indentation of the code.


> C++ coding conventions for ignite-3
> ---
>
> Key: IGNITE-17696
> URL: https://issues.apache.org/jira/browse/IGNITE-17696
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 3.0.0-alpha6
>Reporter: Aleksey Demakov
>Assignee: Aleksey Demakov
>Priority: Minor
>  Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>
> Establish common style for C++ code in Apache Ignite 3. -The suggested 
> approach is as follows:-
>  * {-}the C++ code style should resemble the Java style for consistency{-};
>  * -for things that are specific to C++ or break C++ industry-established 
> practices too violently the rules will be settled one by one and described in 
> a MD document in the repo.-
> A MD document in the repo will describe the coding style.
> A clang-format file will be provided for automatic indentation of the code.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (IGNITE-11461) Automatic modules support for Apache Ignite: find and resolve packages conflicts

2022-09-29 Thread Simon Ochsenreither (Jira)



[ 
https://issues.apache.org/jira/browse/IGNITE-11461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611076#comment-17611076
 ] 

Simon Ochsenreither edited comment on IGNITE-11461 at 9/29/22 2:56 PM:
---

It's kinda hard to expect a mass migration on one hand while needlessly 
[creating new 
conflicts|https://github.com/apache/ignite/tree/master/modules/kubernetes/src/main/java/org/apache/ignite/client]
 on the other.


was (Author: soc):
It's kinda hard to expect a mass migration from others on one hand while 
needlessly [creating new 
conflicts|https://github.com/apache/ignite/tree/master/modules/kubernetes/src/main/java/org/apache/ignite/client]
 on the other.

> Automatic modules support for Apache Ignite: find and resolve packages 
> conflicts
> 
>
> Key: IGNITE-11461
> URL: https://issues.apache.org/jira/browse/IGNITE-11461
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Dmitry Pavlov
>Priority: Minor
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Example of failure in a modular environment:
> Error:java: the unnamed module reads package 
> org.apache.ignite.internal.processors.cache.persistence.file from both 
> ignite.core and ignite.direct.io
> This type of failure is named package inference, but it is strictly 
> prohibited 
> http://openjdk.java.net/projects/jigsaw/spec/reqs/#non-interference 
> Ignite compatibility with Jigsaw is tested in a separate project. See details 
> in
> https://github.com/apache/ignite/tree/ignite-11461-java11/modules/dev-utils/ignite-modules-test#ignite-modular-environment-test-project
>  
> Following table contains currenly investigated Ignite modules if this 
> applicability as automatic modules:
> ||Module||Run In Modular Environment||Changeable using private API only || 
> Notes ||
> |ignite-code|(/)|(/)| |
> |ignite-indexing|(x) [IGNITE-11464] | (?) Refacrtoing to use 
> ignite-indexing-text may be a breaking change | Lucene artifacts exclusion is 
> required by user manually. |
> |ignite-compress | (x) | (/) not releaseed | 
> org.apache.ignite.internal.processors.compress package conflict |
> |ignite-direct-io|(x) blocked by indexind | (/) | 
> org.apache.ignite.internal.processors.cache.persistence.file package conflict 
> |
> |ignite-spring|(x) [IGNITE-11467] blocked by indexing | (x) 
> org.apache.ignite.IgniteSpringBean affected | |
> |ignite-ml |(x) blocked by indexing | | |
> |ignite-log4j|(/)|(/) | But may not compile with other logging dependencies - 
> EOL https://blogs.apache.org/logging/entry/moving_on_to_log4j_2 |
> |ignite-log4j2|(/)|(/)| |
> |ignite-slf4j | (/)|(/)| |
> |ignite-rest-http | (x) IGNITE-11469 & Mirgate to log4j2x [IGNITE-11486] | 
> (/) | Usage with slf4j may break compilation because conflict of packages |
> |ignite-hibernate_5.3 and others | (x) [IGNITE-11485] | (?) | avoid of API 
> breaking is possibleif hibernate core classes not used by third party code |
> |ignite-zookeeper| (x) IGNITE-11486 | (/) | | 
> |ignite-spring-data_2-0 | (x) blocked by spring | org.apache.commons.logging 
> from both commons.logging and spring.jcl conflict | 
> https://jira.spring.io/browse/SPR-16605 | 
> |ignite-ml | (/) master (x) 2.7 | | | 
> |ignite-cassandra-store | (x)  [IGNITE-11467]  blocked by spring  | (/) | 
> Only spring needs to be fixed | 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (IGNITE-17782) `sql` with withe space in repl fails

2022-09-29 Thread Aleksandr (Jira)

Aleksandr created IGNITE-17782:
--

 Summary: `sql` with withe space in repl fails
 Key: IGNITE-17782
 URL: https://issues.apache.org/jira/browse/IGNITE-17782
 Project: Ignite
  Issue Type: Bug
  Components: cli
Reporter: Aleksandr


How to reproduce:
- start ignite node
- enter to the CLI REPL mode
- connect to the node and initialize the cluster
- run "sql " with white space

Expected:
REPL enters to SQL REPL 

Actual:
Unknown error



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (IGNITE-11461) Automatic modules support for Apache Ignite: find and resolve packages conflicts

2022-09-29 Thread Simon Ochsenreither (Jira)



[ 
https://issues.apache.org/jira/browse/IGNITE-11461?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611076#comment-17611076
 ] 

Simon Ochsenreither commented on IGNITE-11461:
--

It's kinda hard to expect a mass migration from others on one hand while 
needlessly [creating new 
conflicts|https://github.com/apache/ignite/tree/master/modules/kubernetes/src/main/java/org/apache/ignite/client]
 on the other.

> Automatic modules support for Apache Ignite: find and resolve packages 
> conflicts
> 
>
> Key: IGNITE-11461
> URL: https://issues.apache.org/jira/browse/IGNITE-11461
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Dmitry Pavlov
>Priority: Minor
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> Example of failure in a modular environment:
> Error:java: the unnamed module reads package 
> org.apache.ignite.internal.processors.cache.persistence.file from both 
> ignite.core and ignite.direct.io
> This type of failure is named package inference, but it is strictly 
> prohibited 
> http://openjdk.java.net/projects/jigsaw/spec/reqs/#non-interference 
> Ignite compatibility with Jigsaw is tested in a separate project. See details 
> in
> https://github.com/apache/ignite/tree/ignite-11461-java11/modules/dev-utils/ignite-modules-test#ignite-modular-environment-test-project
>  
> Following table contains currenly investigated Ignite modules if this 
> applicability as automatic modules:
> ||Module||Run In Modular Environment||Changeable using private API only || 
> Notes ||
> |ignite-code|(/)|(/)| |
> |ignite-indexing|(x) [IGNITE-11464] | (?) Refacrtoing to use 
> ignite-indexing-text may be a breaking change | Lucene artifacts exclusion is 
> required by user manually. |
> |ignite-compress | (x) | (/) not releaseed | 
> org.apache.ignite.internal.processors.compress package conflict |
> |ignite-direct-io|(x) blocked by indexind | (/) | 
> org.apache.ignite.internal.processors.cache.persistence.file package conflict 
> |
> |ignite-spring|(x) [IGNITE-11467] blocked by indexing | (x) 
> org.apache.ignite.IgniteSpringBean affected | |
> |ignite-ml |(x) blocked by indexing | | |
> |ignite-log4j|(/)|(/) | But may not compile with other logging dependencies - 
> EOL https://blogs.apache.org/logging/entry/moving_on_to_log4j_2 |
> |ignite-log4j2|(/)|(/)| |
> |ignite-slf4j | (/)|(/)| |
> |ignite-rest-http | (x) IGNITE-11469 & Mirgate to log4j2x [IGNITE-11486] | 
> (/) | Usage with slf4j may break compilation because conflict of packages |
> |ignite-hibernate_5.3 and others | (x) [IGNITE-11485] | (?) | avoid of API 
> breaking is possibleif hibernate core classes not used by third party code |
> |ignite-zookeeper| (x) IGNITE-11486 | (/) | | 
> |ignite-spring-data_2-0 | (x) blocked by spring | org.apache.commons.logging 
> from both commons.logging and spring.jcl conflict | 
> https://jira.spring.io/browse/SPR-16605 | 
> |ignite-ml | (/) master (x) 2.7 | | | 
> |ignite-cassandra-store | (x)  [IGNITE-11467]  blocked by spring  | (/) | 
> Only spring needs to be fixed | 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (IGNITE-17781) Create DEB\RPM distributions for CLI

Mikhail Pochatkin created IGNITE-17781:
--

 Summary: Create DEB\RPM distributions for CLI
 Key: IGNITE-17781
 URL: https://issues.apache.org/jira/browse/IGNITE-17781
 Project: Ignite
  Issue Type: New Feature
  Components: build, cli
Reporter: Mikhail Pochatkin
Assignee: Mikhail Pochatkin






--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17696) C++ coding conventions for ignite-3

2022-09-29 Thread Aleksey Demakov (Jira)



 [ 
https://issues.apache.org/jira/browse/IGNITE-17696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Demakov updated IGNITE-17696:
-
Description: 
Establish common style for C++ code in Apache Ignite 3. -The suggested approach 
is as follows:-
 * {-}the C++ code style should resemble the Java style for consistency{-};
 * -for things that are specific to C++ or break C++ industry-established 
practices too violently the rules will be settled one by one and described in a 
MD document in the repo.-

A MD document in the repo will  describe the coding style.

A clang-format file will be provided for automatic indentation of the code.

  was:
Establish common style for C++ code in Apache Ignite 3. -The suggested approach 
is as follows:-
 * {-}the C++ code style should resemble the Java style for consistency{-};
 * -for things that are specific to C++ or break C++ industry-established 
practices too violently the rules will be settled one by one and described in a 
MD document in the repo.-

A clang-format file will be provided for automatic indentation of the code.


> C++ coding conventions for ignite-3
> ---
>
> Key: IGNITE-17696
> URL: https://issues.apache.org/jira/browse/IGNITE-17696
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 3.0.0-alpha6
>Reporter: Aleksey Demakov
>Assignee: Aleksey Demakov
>Priority: Minor
>  Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>
> Establish common style for C++ code in Apache Ignite 3. -The suggested 
> approach is as follows:-
>  * {-}the C++ code style should resemble the Java style for consistency{-};
>  * -for things that are specific to C++ or break C++ industry-established 
> practices too violently the rules will be settled one by one and described in 
> a MD document in the repo.-
> A MD document in the repo will  describe the coding style.
> A clang-format file will be provided for automatic indentation of the code.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17696) C++ coding conventions for ignite-3

2022-09-29 Thread Aleksey Demakov (Jira)



 [ 
https://issues.apache.org/jira/browse/IGNITE-17696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Demakov updated IGNITE-17696:
-
Description: 
Establish common style for C++ code in Apache Ignite 3. -The suggested approach 
is as follows:-
 * {-}the C++ code style should resemble the Java style for consistency{-};
 * -for things that are specific to C++ or break C++ industry-established 
practices too violently the rules will be settled one by one and described in a 
MD document in the repo.-

A clang-format file will be provided for automatic indentation of the code.

  was:
Establish common style for C++ code in Apache Ignite 3. The suggested approach 
is as follows:
 * the C++ code style should resemble the Java style for consistency;
 * for things that are specific to C++ or break C++ industry-established 
practices too violently the rules will be settled one by one and described in a 
MD document in the repo.

A clang-format file will be provided for automatic indentation of the code.


> C++ coding conventions for ignite-3
> ---
>
> Key: IGNITE-17696
> URL: https://issues.apache.org/jira/browse/IGNITE-17696
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Affects Versions: 3.0.0-alpha6
>Reporter: Aleksey Demakov
>Assignee: Aleksey Demakov
>Priority: Minor
>  Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>
> Establish common style for C++ code in Apache Ignite 3. -The suggested 
> approach is as follows:-
>  * {-}the C++ code style should resemble the Java style for consistency{-};
>  * -for things that are specific to C++ or break C++ industry-established 
> practices too violently the rules will be settled one by one and described in 
> a MD document in the repo.-
> A clang-format file will be provided for automatic indentation of the code.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Created] (IGNITE-17780) Update Kubernetes Deployment examples to StatefulSet

2022-09-29 Thread Jeremy McMillan (Jira)

Jeremy McMillan created IGNITE-17780:


 Summary: Update Kubernetes Deployment examples to StatefulSet
 Key: IGNITE-17780
 URL: https://issues.apache.org/jira/browse/IGNITE-17780
 Project: Ignite
  Issue Type: Bug
  Components: documentation
Reporter: Jeremy McMillan


StatefulSet has been supported since IGNITE-6241. Experience supporting Ignite 
in the field has led best practice recommendations to stop recommending the use 
of Kubernetes Deployment objects because of the benefits, in practice, which 
persistent volumes bring to common operations like restarting pods.

Persistent topology and node identity makes re-joining a cluster much cheaper 
than always creating new Ignite nodes as pods are started.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-12391) Rename "collocated" to "colocated" in APIs and Docs



 [ 
https://issues.apache.org/jira/browse/IGNITE-12391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yury Gerzhedovich updated IGNITE-12391:
---
Description: 
Rename all the "collocated" occurrences in APIs and docs. Check discussion here 
for more details: https://issues.apache.org/jira/browse/IGNITE-12382

However public API should not be changed due to backward compatibility.

  was:Rename all the "collocated" occurrences in APIs and docs. Check 
discussion here for more details: 
https://issues.apache.org/jira/browse/IGNITE-12382


> Rename "collocated" to "colocated" in APIs and Docs
> ---
>
> Key: IGNITE-12391
> URL: https://issues.apache.org/jira/browse/IGNITE-12391
> Project: Ignite
>  Issue Type: Bug
>  Components: cache, documentation, sql
>Affects Versions: 2.7.6
>Reporter: Denis A. Magda
>Priority: Major
> Fix For: 3.0
>
>
> Rename all the "collocated" occurrences in APIs and docs. Check discussion 
> here for more details: https://issues.apache.org/jira/browse/IGNITE-12382
> However public API should not be changed due to backward compatibility.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (IGNITE-17763) Thin 3.0: testRetryReadPolicyRetriesReadOperations is flaky



[ 
https://issues.apache.org/jira/browse/IGNITE-17763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17611044#comment-17611044
 ] 

Igor Sapego commented on IGNITE-17763:
--

[~ptupitsyn] looks good to me.

> Thin 3.0: testRetryReadPolicyRetriesReadOperations is flaky
> ---
>
> Key: IGNITE-17763
> URL: https://issues.apache.org/jira/browse/IGNITE-17763
> Project: Ignite
>  Issue Type: Bug
>  Components: thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> testRetryReadPolicyRetriesReadOperations is flaky, can be reproduced by 
> running it repeatedly:
> https://ci.ignite.apache.org/test/1162127967669253460?currentProjectId=ignite3_Test=
> {code}
> 2022-09-27 10:42:04:736 +0300 
> [WARNING][nioEventLoopGroup-33-1][DefaultChannelPipeline] An 
> exceptionCaught() event was fired, and it reached at the tail of the 
> pipeline. It usually means the last handler in the pipeline did not handle 
> the exception.
> java.io.IOException: Connection reset by peer
>   at java.base/sun.nio.ch.FileDispatcherImpl.read0(Native Method)
>   at java.base/sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
>   at java.base/sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:276)
>   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:233)
>   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:223)
>   at 
> java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:356)
>   at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:253)
>   at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1132)
>   at 
> io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350)
>   at 
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:151)
>   at 
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719)
>   at 
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655)
>   at 
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581)
>   at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
>   at 
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
>   at 
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
>   at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at java.base/java.lang.Thread.run(Thread.java:829)
> 2022-09-27 10:42:04:742 +0300 
> [WARNING][nioEventLoopGroup-33-2][DefaultChannelPipeline] An 
> exceptionCaught() event was fired, and it reached at the tail of the 
> pipeline. It usually means the last handler in the pipeline did not handle 
> the exception.
> java.io.IOException: Connection reset by peer
>   at java.base/sun.nio.ch.FileDispatcherImpl.read0(Native Method)
>   at java.base/sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
>   at java.base/sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:276)
>   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:233)
>   at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:223)
>   at 
> java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:356)
>   at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:253)
>   at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1132)
>   at 
> io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:350)
>   at 
> io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:151)
>   at 
> io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:719)
>   at 
> io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:655)
>   at 
> io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:581)
>   at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:493)
>   at 
> io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:986)
>   at 
> io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
>   at 
> io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
>   at java.base/java.lang.Thread.run(Thread.java:829)
> 2022-09-27 10:42:04:759 +0300 
> [WARNING][nioEventLoopGroup-33-4][DefaultChannelPipeline] An 
> exceptionCaught() event was fired, and it reached at the tail of the 
> pipeline. It usually means the last handler in the pipeline did not handle 
> the exception.
> java.io.IOException: Connection reset by peer
>   at

[jira] [Created] (IGNITE-17779) Fix an infinite loop in RandomBalancer

2022-09-29 Thread Roman Puchkovskiy (Jira)

Roman Puchkovskiy created IGNITE-17779:
--

 Summary: Fix an infinite loop in RandomBalancer
 Key: IGNITE-17779
 URL: https://issues.apache.org/jira/browse/IGNITE-17779
 Project: Ignite
  Issue Type: Bug
  Components: networking
Reporter: Roman Puchkovskiy
Assignee: Roman Puchkovskiy
 Fix For: 2.15


If selectorCount is 1, then RandomBalancer falls into an infinite loop because 
it cannot choose 2 different indices.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17779) Fix infinite loop in RandomBalancer

2022-09-29 Thread Roman Puchkovskiy (Jira)



 [ 
https://issues.apache.org/jira/browse/IGNITE-17779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Roman Puchkovskiy updated IGNITE-17779:
---
Summary: Fix infinite loop in RandomBalancer  (was: Fix an infinite loop in 
RandomBalancer)

> Fix infinite loop in RandomBalancer
> ---
>
> Key: IGNITE-17779
> URL: https://issues.apache.org/jira/browse/IGNITE-17779
> Project: Ignite
>  Issue Type: Bug
>  Components: networking
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Fix For: 2.15
>
>
> If selectorCount is 1, then RandomBalancer falls into an infinite loop 
> because it cannot choose 2 different indices.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-15128) Calcite: Take own control of SQL functions



 [ 
https://issues.apache.org/jira/browse/IGNITE-15128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yury Gerzhedovich updated IGNITE-15128:
---
Labels: calcite3-required  (was: )

> Calcite: Take own control of SQL functions
> --
>
> Key: IGNITE-15128
> URL: https://issues.apache.org/jira/browse/IGNITE-15128
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: calcite3-required
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> As of now, we use a set of 4 database function dialects:
> SqlLibrary.STANDARD,
> SqlLibrary.POSTGRESQL,
> SqlLibrary.ORACLE,
> SqlLibrary.MYSQL
> Seems we should have owned our dialect with a subset of the aforementioned 
> functions and have the ability to modify already exists functions and add a 
> new one.
> During implementation need to sort out similar functions and choose just one 
> of them to avoid duplication, 
> See :
> org.apache.calcite.util.BuiltInMethod
> org.apache.calcite.sql.fun.SqlLibraryOperators
> org.apache.calcite.runtime.SqlFunctions
> org.apache.ignite.internal.processors.query.calcite.exec.exp.RexImpTable



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (IGNITE-16375) GridAbstractTest.startClientGrid() method does not guarantee that started node will be the client



 [ 
https://issues.apache.org/jira/browse/IGNITE-16375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yury Gerzhedovich reassigned IGNITE-16375:
--

Assignee: Sergey Korotkov  (was: Yury Gerzhedovich)

> GridAbstractTest.startClientGrid() method does not guarantee that started 
> node will be the client
> -
>
> Key: IGNITE-16375
> URL: https://issues.apache.org/jira/browse/IGNITE-16375
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Vinogradov
>Assignee: Sergey Korotkov
>Priority: Major
>  Labels: newbie
> Attachments: Client_node_start_failed_reproducer.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> If {{cfg.setClientMode(false)}} was applied to the Ignite configuration, 
> {{GridAbstractTest.startClientGrid()}} will start the server node, while 
> client node is expected according to the method name and JavaDoc.
> {noformat}
> Starts new client grid with given index.
> {noformat}
> {{GridAbstractTest.startClientGrid()}} should start client node even when 
> {{cfg.setClientMode(false)}} is set or throw an exception (preferred). 
> See reproducer at  [^Client_node_start_failed_reproducer.patch] 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (IGNITE-16375) GridAbstractTest.startClientGrid() method does not guarantee that started node will be the client



 [ 
https://issues.apache.org/jira/browse/IGNITE-16375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yury Gerzhedovich reassigned IGNITE-16375:
--

Assignee: Yury Gerzhedovich  (was: Sergey Korotkov)

> GridAbstractTest.startClientGrid() method does not guarantee that started 
> node will be the client
> -
>
> Key: IGNITE-16375
> URL: https://issues.apache.org/jira/browse/IGNITE-16375
> Project: Ignite
>  Issue Type: Bug
>Reporter: Anton Vinogradov
>Assignee: Yury Gerzhedovich
>Priority: Major
>  Labels: newbie
> Attachments: Client_node_start_failed_reproducer.patch
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> If {{cfg.setClientMode(false)}} was applied to the Ignite configuration, 
> {{GridAbstractTest.startClientGrid()}} will start the server node, while 
> client node is expected according to the method name and JavaDoc.
> {noformat}
> Starts new client grid with given index.
> {noformat}
> {{GridAbstractTest.startClientGrid()}} should start client node even when 
> {{cfg.setClientMode(false)}} is set or throw an exception (preferred). 
> See reproducer at  [^Client_node_start_failed_reproducer.patch] 



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (IGNITE-17662) Update Ignite version to 2.15.0-SNAPSHOT



[ 
https://issues.apache.org/jira/browse/IGNITE-17662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17610899#comment-17610899
 ] 

Taras Ledkov edited comment on IGNITE-17662 at 9/29/22 10:46 AM:
-

[~ivandasch], please review the patch


was (Author: tledkov):
[~namelchev], please review the patch

> Update Ignite version to 2.15.0-SNAPSHOT
> 
>
> Key: IGNITE-17662
> URL: https://issues.apache.org/jira/browse/IGNITE-17662
> Project: Ignite
>  Issue Type: Task
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.14
>
>
> Update Ignite version to 2.15.0-SNAPSHOT
> The pom dependencies must be updated due to the ignite-2.14 branch has been 
> created.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17755) Add common interface for sorted and hash indices

2022-09-29 Thread Semyon Danilov (Jira)



 [ 
https://issues.apache.org/jira/browse/IGNITE-17755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Semyon Danilov updated IGNITE-17755:

Fix Version/s: 3.0.0-alpha6

> Add common interface for sorted and hash indices
> 
>
> Key: IGNITE-17755
> URL: https://issues.apache.org/jira/browse/IGNITE-17755
> Project: Ignite
>  Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Create an interface with some common methods across all index implementations 
> so that it would be possible to work with indices without knowing the actual 
> index type.
> A new interface may look like this:
> {code:java}
> public interface IndexStorage {
> Cursor get(BinaryTuple key) throws StorageException;
> void put(IndexRow row) throws StorageException;
> void remove(IndexRow row) throws StorageException;
> }
> {code}
> Also, a new method should be added to {{MvTableStorage}}:
> {code:java}
> IndexStorage getIndex(int partitionId, UUID indexId);
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (IGNITE-17702) Move schema changes history from configuration to metastore

2022-09-29 Thread Evgeny Stanilovsky (Jira)



 [ 
https://issues.apache.org/jira/browse/IGNITE-17702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Evgeny Stanilovsky reassigned IGNITE-17702:
---

Assignee: Evgeny Stanilovsky

> Move schema changes history from configuration to metastore
> ---
>
> Key: IGNITE-17702
> URL: https://issues.apache.org/jira/browse/IGNITE-17702
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Evgeny Stanilovsky
>Priority: Major
>  Labels: ignite-3, tech-debt
>
> History of schema changes keeps in configuration.Looks like it wrong, due to 
> configuration it is just a thing which requires to recreate similar cluster. 
> History schema more looks like a internal part which could keeps in Metastore.
> Start points:
> org.apache.ignite.internal.configuration.schema.SchemaConfigurationSchema
> org.apache.ignite.internal.configuration.schema.ExtendedTableConfigurationSchema



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17027) Incorrect result of the DML delete operation, in some environment

2022-09-29 Thread Aleksey Plekhanov (Jira)



 [ 
https://issues.apache.org/jira/browse/IGNITE-17027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Aleksey Plekhanov updated IGNITE-17027:
---
Ignite Flags: Release Notes Required  (was: Docs Required,Release Notes 
Required)

>  Incorrect result of the DML delete operation, in some environment
> --
>
> Key: IGNITE-17027
> URL: https://issues.apache.org/jira/browse/IGNITE-17027
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Luchnikov Alexander
>Assignee: Aleksey Plekhanov
>Priority: Minor
>  Labels: ise
> Fix For: 2.15
>
> Attachments: IndexSetArgsAndCastTest.patch
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Description of the case, in some environment, the DML operation does not 
> delete all data (this DML delete operation is an example). To reproduce the 
> problem, you must:
> # Create a table with a varchar field.
> # Create an index on the given field.
> # Fill the table with data, use int as the value.
> # Delete data by specifying in the DML operation, as a condition, an indexed 
> value, without String.valueOf(intValue)
> The reproducer( [^IndexSetArgsAndCastTest.patch] ) shows this behavior in 
> indexOnAutocastOff() test.
> The result of all tests should be the same, specifically in this example (DML 
> delete) - the number of entries in the cache, according to the result of each 
> test, should be equal to zero.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (IGNITE-15431) .NET: Thin 3.0: Add support for all native data types



[ 
https://issues.apache.org/jira/browse/IGNITE-15431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17610905#comment-17610905
 ] 

Pavel Tupitsyn commented on IGNITE-15431:
-

Merged to main: 2240ca187a93b774183f8b43378f1eb826b69781

> .NET: Thin 3.0: Add support for all native data types
> -
>
> Key: IGNITE-15431
> URL: https://issues.apache.org/jira/browse/IGNITE-15431
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Affects Versions: 3.0.0-alpha3
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, iep-78, ignite-3
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Add support for all data types in .NET thin client: Date, Time, etc - see 
> -org.apache.ignite.client.proto.ClientDataType- 
> *org.apache.ignite.internal.schema.NativeTypes*.
> * We now use *BinaryTuple* format to exchange row data => .NET *BinaryTuple* 
> implementation should be updated to support all missing types.
> * Update *IgniteTuple*
> * Support those types in object mapper (*IRecordView*)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (IGNITE-17662) Update Ignite version to 2.15.0-SNAPSHOT



[ 
https://issues.apache.org/jira/browse/IGNITE-17662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17610899#comment-17610899
 ] 

Taras Ledkov commented on IGNITE-17662:
---

[~namelchev], please review the patch

> Update Ignite version to 2.15.0-SNAPSHOT
> 
>
> Key: IGNITE-17662
> URL: https://issues.apache.org/jira/browse/IGNITE-17662
> Project: Ignite
>  Issue Type: Task
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.14
>
>
> Update Ignite version to 2.15.0-SNAPSHOT
> The pom dependencies must be updated due to the ignite-2.14 branch has been 
> created.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (IGNITE-17662) Update Ignite version to 2.15.0-SNAPSHOT



[ 
https://issues.apache.org/jira/browse/IGNITE-17662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17610898#comment-17610898
 ] 

Ignite TC Bot commented on IGNITE-17662:


{panel:title=Branch: [pull/10246/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10246/head] Base: [master] : New Tests 
(4)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}PDS (Compatibility){color} [[tests 
4|https://ci2.ignite.apache.org/viewLog.html?buildId=6600739]]
* {color:#013220}IgniteCompatibilityBasicTestSuite: 
JdbcThinCompatibilityTest.testOldClientToCurrentServer[Version 2.15.0-SNAPSHOT] 
- PASSED{color}
* {color:#013220}IgniteCompatibilityBasicTestSuite: 
JavaThinCompatibilityTest.testCurrentClientToOldServer[Version 2.15.0-SNAPSHOT] 
- PASSED{color}
* {color:#013220}IgniteCompatibilityBasicTestSuite: 
JavaThinCompatibilityTest.testOldClientToCurrentServer[Version 2.15.0-SNAPSHOT] 
- PASSED{color}
* {color:#013220}IgniteCompatibilityBasicTestSuite: 
JdbcThinCompatibilityTest.testCurrentClientToOldServer[Version 2.15.0-SNAPSHOT] 
- PASSED{color}

{panel}
[TeamCity *-- Run :: All* 
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6600777buildTypeId=IgniteTests24Java8_RunAll]

> Update Ignite version to 2.15.0-SNAPSHOT
> 
>
> Key: IGNITE-17662
> URL: https://issues.apache.org/jira/browse/IGNITE-17662
> Project: Ignite
>  Issue Type: Task
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
> Fix For: 2.14
>
>
> Update Ignite version to 2.15.0-SNAPSHOT
> The pom dependencies must be updated due to the ignite-2.14 branch has been 
> created.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (IGNITE-15431) .NET: Thin 3.0: Add support for all native data types



[ 
https://issues.apache.org/jira/browse/IGNITE-15431?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17610897#comment-17610897
 ] 

Igor Sapego commented on IGNITE-15431:
--

[~ptupitsyn] looks good to me.

> .NET: Thin 3.0: Add support for all native data types
> -
>
> Key: IGNITE-15431
> URL: https://issues.apache.org/jira/browse/IGNITE-15431
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Affects Versions: 3.0.0-alpha3
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, iep-78, ignite-3
>
> Add support for all data types in .NET thin client: Date, Time, etc - see 
> -org.apache.ignite.client.proto.ClientDataType- 
> *org.apache.ignite.internal.schema.NativeTypes*.
> * We now use *BinaryTuple* format to exchange row data => .NET *BinaryTuple* 
> implementation should be updated to support all missing types.
> * Update *IgniteTuple*
> * Support those types in object mapper (*IRecordView*)



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17742) Trying to insert a large entry in an atomic cache results in CorruptedTreeException

2022-09-29 Thread Vyacheslav Koptilin (Jira)



 [ 
https://issues.apache.org/jira/browse/IGNITE-17742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Vyacheslav Koptilin updated IGNITE-17742:
-
Release Note: Fixed an issue that could lead to data corruption of atomic 
cache when a new updated entry is greater than WAL buffer size.

> Trying to insert a large entry in an atomic cache results in 
> CorruptedTreeException
> ---
>
> Key: IGNITE-17742
> URL: https://issues.apache.org/jira/browse/IGNITE-17742
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.13
>Reporter: Vyacheslav Koptilin
>Assignee: Vyacheslav Koptilin
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In case of using Ignite Native Persistence, the attempt to insert a new entry 
> which size is greater than WAL buffer size leads to CorruptedTreeException:
> {noformat}
>  
> org.apache.ignite.internal.processors.cache.persistence.tree.CorruptedTreeException:
>  B+Tree is corrupted [groupId=-1407396309, pageIds=[1125904201809926], 
> msg=Runtime failure on search row: SearchRow [key=KeyCacheObjectImpl [part=1, 
> val=1, hasValBytes=true], hash=1, cacheId=0]]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.corruptedTreeException(BPlusTree.java:6487)
>  ~[classes/:?]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.tree.BPlusTree.invoke(BPlusTree.java:2202)
>  ~[classes/:?]
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke0(IgniteCacheOffheapManagerImpl.java:1698)
>  ~[classes/:?]
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl$CacheDataStoreImpl.invoke(IgniteCacheOffheapManagerImpl.java:1681)
>  ~[classes/:?]
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheOffheapManager$GridCacheDataStore.invoke(GridCacheOffheapManager.java:2762)
>  ~[classes/:?]
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheOffheapManagerImpl.invoke(IgniteCacheOffheapManagerImpl.java:425)
>  ~[classes/:?]
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.innerUpdate(GridCacheMapEntry.java:1975)
>  ~[classes/:?]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateSingle(GridDhtAtomicCache.java:2554)
>  ~[classes/:?]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update(GridDhtAtomicCache.java:2014)
>  ~[classes/:?]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal0(GridDhtAtomicCache.java:1833)
>  ~[classes/:?]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.updateAllAsyncInternal(GridDhtAtomicCache.java:1706)
>  ~[classes/:?]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.sendSingleRequest(GridNearAtomicAbstractUpdateFuture.java:300)
>  ~[classes/:?]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.map(GridNearAtomicSingleUpdateFuture.java:481)
>  ~[classes/:?]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicSingleUpdateFuture.mapOnTopology(GridNearAtomicSingleUpdateFuture.java:441)
>  ~[classes/:?]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridNearAtomicAbstractUpdateFuture.map(GridNearAtomicAbstractUpdateFuture.java:249)
>  ~[classes/:?]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.update0(GridDhtAtomicCache.java:1151)
>  ~[classes/:?]
>   at 
> org.apache.ignite.internal.processors.cache.distributed.dht.atomic.GridDhtAtomicCache.put0(GridDhtAtomicCache.java:619)
>  ~[classes/:?]
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2487)
>  ~[classes/:?]
>   at 
> org.apache.ignite.internal.processors.cache.GridCacheAdapter.put(GridCacheAdapter.java:2466)
>  ~[classes/:?]
>   at 
> org.apache.ignite.internal.processors.cache.IgniteCacheProxyImpl.put(IgniteCacheProxyImpl.java:1332)
>  ~[classes/:?]
>   at 
> org.apache.ignite.internal.processors.cache.GatewayProtectedCacheProxy.put(GatewayProtectedCacheProxy.java:867)
>  ~[classes/:?]
>   at 
> org.apache.ignite.internal.processors.database.IgniteDbPutGetAbstractTest.lambda$testPutLargeEntry$4bb74d57$1(IgniteDbPutGetAbstractTest.java:331)
>  ~[test-classes/:?]
>   at 
> org.apache.ignite.internal.util.lang.RunnableX.run(RunnableX.java:37) 
> ~[classes/:?]
>   at

[jira] [Commented] (IGNITE-17717) Logging cdc in ignite2ignite mode



[ 
https://issues.apache.org/jira/browse/IGNITE-17717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17610880#comment-17610880
 ] 

Taras Ledkov commented on IGNITE-17717:
---

Cherry-picked to 
[igntie-2.14|https://github.com/apache/ignite/commit/951e8deb73338b83f207bb4d0828e2353cc8da17]

> Logging cdc in ignite2ignite mode
> -
>
> Key: IGNITE-17717
> URL: https://issues.apache.org/jira/browse/IGNITE-17717
> Project: Ignite
>  Issue Type: Task
>Reporter: Luchnikov Alexander
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: ise
> Fix For: 2.14
>
> Attachments: 3b799724-998a-434b-8ca3-eb9877490ce9.png
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> When using cdc in ignite2ignite mode, there is a problem with logging.
> When running ignite-cdc.sh, the log is written to ignite-cdc.log until the 
> ignite client starts, after it starts, the recording continues to ignite.log.
> Probably the problem is related to the replacement of appId at the start of 
> the client node.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17717) Logging cdc in ignite2ignite mode



 [ 
https://issues.apache.org/jira/browse/IGNITE-17717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Taras Ledkov updated IGNITE-17717:
--
Ignite Flags:   (was: Docs Required,Release Notes Required)

> Logging cdc in ignite2ignite mode
> -
>
> Key: IGNITE-17717
> URL: https://issues.apache.org/jira/browse/IGNITE-17717
> Project: Ignite
>  Issue Type: Task
>Reporter: Luchnikov Alexander
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: ise
> Fix For: 2.14
>
> Attachments: 3b799724-998a-434b-8ca3-eb9877490ce9.png
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> When using cdc in ignite2ignite mode, there is a problem with logging.
> When running ignite-cdc.sh, the log is written to ignite-cdc.log until the 
> ignite client starts, after it starts, the recording continues to ignite.log.
> Probably the problem is related to the replacement of appId at the start of 
> the client node.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (IGNITE-17027) Incorrect result of the DML delete operation, in some environment



[ 
https://issues.apache.org/jira/browse/IGNITE-17027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17610876#comment-17610876
 ] 

Taras Ledkov commented on IGNITE-17027:
---

[~alex_pl], the patch is OK with me.

>  Incorrect result of the DML delete operation, in some environment
> --
>
> Key: IGNITE-17027
> URL: https://issues.apache.org/jira/browse/IGNITE-17027
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Luchnikov Alexander
>Assignee: Aleksey Plekhanov
>Priority: Minor
>  Labels: ise
> Attachments: IndexSetArgsAndCastTest.patch
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Description of the case, in some environment, the DML operation does not 
> delete all data (this DML delete operation is an example). To reproduce the 
> problem, you must:
> # Create a table with a varchar field.
> # Create an index on the given field.
> # Fill the table with data, use int as the value.
> # Delete data by specifying in the DML operation, as a condition, an indexed 
> value, without String.valueOf(intValue)
> The reproducer( [^IndexSetArgsAndCastTest.patch] ) shows this behavior in 
> indexOnAutocastOff() test.
> The result of all tests should be the same, specifically in this example (DML 
> delete) - the number of entries in the cache, according to the result of each 
> test, should be equal to zero.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17573) SQL COPY command should support all RFC4180 compatible CSV files



 [ 
https://issues.apache.org/jira/browse/IGNITE-17573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yury Gerzhedovich updated IGNITE-17573:
---
Description: 
https://www.rfc-editor.org/rfc/rfc4180

Currently, there are no ways to handle CSV files with optional headers with 
column names and with line breaks in fields content.

SQL COPY command must correctly process all RFC compatible files.

Start point is org.apache.ignite.internal.sql.SqlParser#processCopy

  was:
https://www.rfc-editor.org/rfc/rfc4180

Currently there are no ways to handle CSV files with optional header with 
column names and with line breaks in fields content.

SQL COPY command must correctly process all RFC compatible files.


> SQL COPY command should support all RFC4180 compatible CSV files
> 
>
> Key: IGNITE-17573
> URL: https://issues.apache.org/jira/browse/IGNITE-17573
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.13
>Reporter: Anton Kurbanov
>Priority: Major
>
> https://www.rfc-editor.org/rfc/rfc4180
> Currently, there are no ways to handle CSV files with optional headers with 
> column names and with line breaks in fields content.
> SQL COPY command must correctly process all RFC compatible files.
> Start point is org.apache.ignite.internal.sql.SqlParser#processCopy



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17573) SQL COPY command should support all RFC4180 compatible CSV files



 [ 
https://issues.apache.org/jira/browse/IGNITE-17573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yury Gerzhedovich updated IGNITE-17573:
---
Description: 
https://www.rfc-editor.org/rfc/rfc4180

Currently, there are no ways to handle CSV files with optional headers with 
column names and with line breaks in fields content.

SQL COPY command must correctly process all RFC compatible files.


Start point is org.apache.ignite.internal.sql.SqlParser#processCopy

  was:
https://www.rfc-editor.org/rfc/rfc4180

Currently, there are no ways to handle CSV files with optional headers with 
column names and with line breaks in fields content.

SQL COPY command must correctly process all RFC compatible files.

Start point is org.apache.ignite.internal.sql.SqlParser#processCopy


> SQL COPY command should support all RFC4180 compatible CSV files
> 
>
> Key: IGNITE-17573
> URL: https://issues.apache.org/jira/browse/IGNITE-17573
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.13
>Reporter: Anton Kurbanov
>Priority: Major
>
> https://www.rfc-editor.org/rfc/rfc4180
> Currently, there are no ways to handle CSV files with optional headers with 
> column names and with line breaks in fields content.
> SQL COPY command must correctly process all RFC compatible files.
> Start point is org.apache.ignite.internal.sql.SqlParser#processCopy



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17717) Logging cdc in ignite2ignite mode



 [ 
https://issues.apache.org/jira/browse/IGNITE-17717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Nikolay Izhikov updated IGNITE-17717:
-
Fix Version/s: 2.14

> Logging cdc in ignite2ignite mode
> -
>
> Key: IGNITE-17717
> URL: https://issues.apache.org/jira/browse/IGNITE-17717
> Project: Ignite
>  Issue Type: Task
>Reporter: Luchnikov Alexander
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: ise
> Fix For: 2.14
>
> Attachments: 3b799724-998a-434b-8ca3-eb9877490ce9.png
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> When using cdc in ignite2ignite mode, there is a problem with logging.
> When running ignite-cdc.sh, the log is written to ignite-cdc.log until the 
> ignite client starts, after it starts, the recording continues to ignite.log.
> Probably the problem is related to the replacement of appId at the start of 
> the client node.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (IGNITE-17717) Logging cdc in ignite2ignite mode



[ 
https://issues.apache.org/jira/browse/IGNITE-17717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17610862#comment-17610862
 ] 

Nikolay Izhikov commented on IGNITE-17717:
--

[~tledkov] Let's cherry-pick this issue to the 2.14?

> Logging cdc in ignite2ignite mode
> -
>
> Key: IGNITE-17717
> URL: https://issues.apache.org/jira/browse/IGNITE-17717
> Project: Ignite
>  Issue Type: Task
>Reporter: Luchnikov Alexander
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: ise
> Attachments: 3b799724-998a-434b-8ca3-eb9877490ce9.png
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> When using cdc in ignite2ignite mode, there is a problem with logging.
> When running ignite-cdc.sh, the log is written to ignite-cdc.log until the 
> ignite client starts, after it starts, the recording continues to ignite.log.
> Probably the problem is related to the replacement of appId at the start of 
> the client node.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (IGNITE-17717) Logging cdc in ignite2ignite mode



[ 
https://issues.apache.org/jira/browse/IGNITE-17717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17610860#comment-17610860
 ] 

Ignite TC Bot commented on IGNITE-17717:


{panel:title=Branch: [pull/10275/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10275/head] Base: [master] : No new tests 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All* 
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6634097buildTypeId=IgniteTests24Java8_RunAll]

> Logging cdc in ignite2ignite mode
> -
>
> Key: IGNITE-17717
> URL: https://issues.apache.org/jira/browse/IGNITE-17717
> Project: Ignite
>  Issue Type: Task
>Reporter: Luchnikov Alexander
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: ise
> Attachments: 3b799724-998a-434b-8ca3-eb9877490ce9.png
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> When using cdc in ignite2ignite mode, there is a problem with logging.
> When running ignite-cdc.sh, the log is written to ignite-cdc.log until the 
> ignite client starts, after it starts, the recording continues to ignite.log.
> Probably the problem is related to the replacement of appId at the start of 
> the client node.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Assigned] (IGNITE-17573) SQL COPY command should support all RFC4180 compatible CSV files



 [ 
https://issues.apache.org/jira/browse/IGNITE-17573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Yury Gerzhedovich reassigned IGNITE-17573:
--

Assignee: (was: Anton Kurbanov)

> SQL COPY command should support all RFC4180 compatible CSV files
> 
>
> Key: IGNITE-17573
> URL: https://issues.apache.org/jira/browse/IGNITE-17573
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 2.13
>Reporter: Anton Kurbanov
>Priority: Major
>
> https://www.rfc-editor.org/rfc/rfc4180
> Currently there are no ways to handle CSV files with optional header with 
> column names and with line breaks in fields content.
> SQL COPY command must correctly process all RFC compatible files.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17417) Node name support in CLI



 [ 
https://issues.apache.org/jira/browse/IGNITE-17417?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Pochatkin updated IGNITE-17417:
---
Description: 
Now there is only one way to point at the ignite node in the CLI – `node-url` 
or `cluster-url` options. They are represented as an URL that sometimes is too 
annoying to type and remember. It would be much more user-friendly to have the 
second option here. I think node name could be used as a CLI option. 

I propose to add `node-name` option to every command that requires 
`cluster-url` or `node-url`. So, the following user story would be possible:


{code:bash}
> ignite
[disconnected]> connect node2
[node2]> connect node2
[node2]> node config show --node-name node1
{code}


  was:
Now there is only one way to point at the ignite node in the CLI – `node-url` 
or `cluster-url` options. They are represented as an URL that sometimes is too 
annoying to type and remember. It would be much more user-friendly to have the 
second option here. I think node name could be used as a CLI option. 

I propose to add `node-name` option to every command that requires 
`cluster-url` or `node-url`. So, the following user story would be possible:


{code:bash}
> ignite
[disconnected]> node start node1
[disconnected]> node start node2
[disconnected]> connect node2
[node2]> connect node2
[node2]> node config show --node-name node1
{code}



> Node name support in CLI
> 
>
> Key: IGNITE-17417
> URL: https://issues.apache.org/jira/browse/IGNITE-17417
> Project: Ignite
>  Issue Type: Task
>  Components: cli
>Reporter: Aleksandr
>Priority: Major
>  Labels: ignite-3, ignite-3-cli-tool
>
> Now there is only one way to point at the ignite node in the CLI – `node-url` 
> or `cluster-url` options. They are represented as an URL that sometimes is 
> too annoying to type and remember. It would be much more user-friendly to 
> have the second option here. I think node name could be used as a CLI option. 
> I propose to add `node-name` option to every command that requires 
> `cluster-url` or `node-url`. So, the following user story would be possible:
> {code:bash}
> > ignite
> [disconnected]> connect node2
> [node2]> connect node2
> [node2]> node config show --node-name node1
> {code}



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17489) Packaging: Brew package



 [ 
https://issues.apache.org/jira/browse/IGNITE-17489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Pochatkin updated IGNITE-17489:
---
Component/s: build

> Packaging: Brew package
> ---
>
> Key: IGNITE-17489
> URL: https://issues.apache.org/jira/browse/IGNITE-17489
> Project: Ignite
>  Issue Type: New Feature
>  Components: build
>Reporter: Mikhail Pochatkin
>Priority: Major
>  Labels: ignite-3
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17490) Packaging: SDKman package



 [ 
https://issues.apache.org/jira/browse/IGNITE-17490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Pochatkin updated IGNITE-17490:
---
Component/s: build

> Packaging: SDKman package
> -
>
> Key: IGNITE-17490
> URL: https://issues.apache.org/jira/browse/IGNITE-17490
> Project: Ignite
>  Issue Type: New Feature
>  Components: build
>Reporter: Mikhail Pochatkin
>Priority: Major
>  Labels: ignite-3
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17483) Ignite Packaging improvements



 [ 
https://issues.apache.org/jira/browse/IGNITE-17483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Pochatkin updated IGNITE-17483:
---
Component/s: build

> Ignite Packaging improvements
> -
>
> Key: IGNITE-17483
> URL: https://issues.apache.org/jira/browse/IGNITE-17483
> Project: Ignite
>  Issue Type: Epic
>  Components: build
>Reporter: Mikhail Pochatkin
>Priority: Major
>  Labels: ignite-3, ignite-3-cli-tool
>




--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-17172) Create new command frontend for REPL mode



 [ 
https://issues.apache.org/jira/browse/IGNITE-17172?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Pochatkin updated IGNITE-17172:
---
Component/s: cli

> Create new command frontend for REPL mode
> -
>
> Key: IGNITE-17172
> URL: https://issues.apache.org/jira/browse/IGNITE-17172
> Project: Ignite
>  Issue Type: Improvement
>  Components: cli
>Reporter: Mikhail Pochatkin
>Priority: Major
>  Labels: ignite-3, ignite-3-cli-tool
>
> Currently all commands for both non-REPL and REPL mode has same frontend 
> Picocli. It means that options parsing and mapping to command description is 
> Picocli relationship. 
> Command logic is not related to frontend, relationship of frontend is split 
> incoming command line and put all command option to next layer to process 
> command execution. 
> In reality Picocli frontend for REPL command is not suitable by few reasons:
>  # In plans support interactive fill for required options. For example
> {code:java}
> cli> node connect 
> Q:Do you want to connect last node? (last-node-url) Y/n? 
> A: Y Output: 
> Connected to last-node-url!  {code}
>  Picocli doesn't provide possibility to customize logic about command parsing 
> and spliting to options. 
>  # In current implementation SQL REPL didn't use Picocli frontend because its 
> impossible to map all possible SQL queries to different Picocli CmdDesc but 
> its is not needed. 
>  
>  



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-16973) Add advanced completions to SQL REPL



 [ 
https://issues.apache.org/jira/browse/IGNITE-16973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Pochatkin updated IGNITE-16973:
---
Component/s: cli

> Add advanced completions to SQL REPL
> 
>
> Key: IGNITE-16973
> URL: https://issues.apache.org/jira/browse/IGNITE-16973
> Project: Ignite
>  Issue Type: Task
>  Components: cli
>Reporter: Aleksandr
>Assignee: Mikhail Pochatkin
>Priority: Major
>  Labels: ignite-3, ignite-3-cli-tool
>
> In order to improve the developer experience in SQL REPL mode dynamic 
> autocompletion can be added. For example, a user types {{select * from ta}} 
> and gets the suggestion with the list of tables that are fetched from the 
> JDBC.
> Also, the current list of SQL keywords for autocomplete is taken from the 
> default Calcite parser. Use an actual list of Ignite SQL keywords for 
> auto-complete.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Updated] (IGNITE-16974) Map ignite errors to the command line exit codes



 [ 
https://issues.apache.org/jira/browse/IGNITE-16974?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mikhail Pochatkin updated IGNITE-16974:
---
Component/s: cli

> Map ignite errors to the command line exit codes
> 
>
> Key: IGNITE-16974
> URL: https://issues.apache.org/jira/browse/IGNITE-16974
> Project: Ignite
>  Issue Type: Task
>  Components: cli
>Reporter: Aleksandr
>Assignee: Aleksandr
>Priority: Major
>  Labels: ignite-3, ignite-3-cli-tool
>
> Provide the list of errors that can be produced by REST, for example:
>  * VALIDATION_EXCEPTION
>  * CONFIG_PATH_UNRECOGNIZED
>  * INVALID_CONFIG_FORMAT
> And map them to CLI exit codes.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Comment Edited] (IGNITE-17717) Logging cdc in ignite2ignite mode

2022-09-29 Thread Luchnikov Alexander (Jira)



[ 
https://issues.apache.org/jira/browse/IGNITE-17717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17610820#comment-17610820
 ] 

Luchnikov Alexander edited comment on IGNITE-17717 at 9/29/22 6:20 AM:
---

[~nizhikov]
I'll try to reproduce the problem on the current master.
The problem was related to ${sys:appId}, in the logger configuration, the file 
name was set to fileName="${sys:IGNITE_HOME}/work/log/${sys:appId}.log and when 
running ./ignite-cdc.sh, ${sys:appId} was set to "ignite-cdc" and all messages 
went to ignite-cdc.log. But after the client node started,
appId was set to "ignite" and messages started going to ignite.log.


was (Author: aldoraine):
I'll try to reproduce the problem on the current master.
The problem was related to ${sys:appId}, in the logger configuration, the file 
name was set to fileName="${sys:IGNITE_HOME}/work/log/${sys:appId}.log and when 
running ./ignite-cdc.sh, ${sys:appId} was set to "ignite-cdc" and all messages 
went to ignite-cdc.log. But after the client node started,
appId was set to "ignite" and messages started going to ignite.log.

> Logging cdc in ignite2ignite mode
> -
>
> Key: IGNITE-17717
> URL: https://issues.apache.org/jira/browse/IGNITE-17717
> Project: Ignite
>  Issue Type: Task
>Reporter: Luchnikov Alexander
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: ise
> Attachments: 3b799724-998a-434b-8ca3-eb9877490ce9.png
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> When using cdc in ignite2ignite mode, there is a problem with logging.
> When running ignite-cdc.sh, the log is written to ignite-cdc.log until the 
> ignite client starts, after it starts, the recording continues to ignite.log.
> Probably the problem is related to the replacement of appId at the start of 
> the client node.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (IGNITE-17717) Logging cdc in ignite2ignite mode

2022-09-29 Thread Luchnikov Alexander (Jira)



[ 
https://issues.apache.org/jira/browse/IGNITE-17717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17610820#comment-17610820
 ] 

Luchnikov Alexander commented on IGNITE-17717:
--

I'll try to reproduce the problem on the current master.
The problem was related to ${sys:appId}, in the logger configuration, the file 
name was set to fileName="${sys:IGNITE_HOME}/work/log/${sys:appId}.log and when 
running ./ignite-cdc.sh, ${sys:appId} was set to "ignite-cdc" and all messages 
went to ignite-cdc.log. But after the client node started,
appId was set to "ignite" and messages started going to ignite.log.

> Logging cdc in ignite2ignite mode
> -
>
> Key: IGNITE-17717
> URL: https://issues.apache.org/jira/browse/IGNITE-17717
> Project: Ignite
>  Issue Type: Task
>Reporter: Luchnikov Alexander
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: ise
> Attachments: 3b799724-998a-434b-8ca3-eb9877490ce9.png
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> When using cdc in ignite2ignite mode, there is a problem with logging.
> When running ignite-cdc.sh, the log is written to ignite-cdc.log until the 
> ignite client starts, after it starts, the recording continues to ignite.log.
> Probably the problem is related to the replacement of appId at the start of 
> the client node.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

[jira] [Commented] (IGNITE-17027) Incorrect result of the DML delete operation, in some environment