[jira] [Commented] (IGNITE-15569) Calcite. JOIN with USING fails.
[
https://issues.apache.org/jira/browse/IGNITE-15569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459712#comment-17459712
]
Evgeny Stanilovsky commented on IGNITE-15569:
-
thanks ! looks good.
> Calcite. JOIN with USING fails.
> ---
>
> Key: IGNITE-15569
> URL: https://issues.apache.org/jira/browse/IGNITE-15569
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Evgeny Stanilovsky
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: calcite, calcite2-required, calcite3-required, ignite-3
> Time Spent: 10m
> Remaining Estimate: 0h
>
> {noformat}
> statement ok
> CREATE TABLE t1 (a INTEGER, b INTEGER)
> statement ok
> INSERT INTO t1 VALUES (1, 2)
> statement ok
> CREATE TABLE t2 (b INTEGER, c INTEGER)
> statement ok
> INSERT INTO t2 VALUES (2, 3)
> statement ok
> CREATE TABLE t3 (c INTEGER, d INTEGER)
> statement ok
> INSERT INTO t3 VALUES (3, 4)
> query
> SELECT * FROM t1 JOIN t2 USING (b) JOIN t3 USING (c) ORDER BY 1, 2, 3, 4;
>
> 1 2 3 4
> {noformat}
> fails with
> {noformat}
> java.lang.ArrayIndexOutOfBoundsException: 7
> at
> com.google.common.collect.RegularImmutableList.get(RegularImmutableList.java:60)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl$Permute.permute(SqlValidatorImpl.java:7084)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandStar(SqlValidatorImpl.java:662)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.expandSelectItem(SqlValidatorImpl.java:424)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelectList(SqlValidatorImpl.java:4414)
> at
> org.apache.calcite.sql.validate.SqlValidatorImpl.validateSelect(SqlValidatorImpl.java:3657)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.IgniteSqlValidator.validateSelect(IgniteSqlValidator.java:182)
> {noformat}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16127) Update Ignite dependency log4j
[ https://issues.apache.org/jira/browse/IGNITE-16127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr updated IGNITE-16127: --- Description: Update Ignite dependency: log4j to 2.16 (was: Update Ignite dependency: log4j to 2.160) > Update Ignite dependency log4j > -- > > Key: IGNITE-16127 > URL: https://issues.apache.org/jira/browse/IGNITE-16127 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > > Update Ignite dependency: log4j to 2.16 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-14555) Calcite engine. Create table from query result
[
https://issues.apache.org/jira/browse/IGNITE-14555?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459711#comment-17459711
]
Evgeny Stanilovsky commented on IGNITE-14555:
-
guys, i found in _test_join_types.test_ignored_ we still have such a problem:
{noformat}
class org.apache.ignite.IgniteException: Error at: (test_join_types.test:12).
Statement: Statement [queries=ArrayList [create table a as select i::tinyint AS
i from range(1, 101, 1) t1(i)], expected=OK]
at
org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner$Statement.execute(SqlScriptRunner.java:420)
at
org.apache.ignite.internal.processors.query.calcite.logical.SqlScriptRunner.run(SqlScriptRunner.java:131)
at
org.apache.ignite.internal.processors.query.calcite.logical.ScriptTestRunner$1.run(ScriptTestRunner.java:219)
at java.lang.Thread.run(Thread.java:748)
Caused by: class
org.apache.ignite.internal.processors.query.IgniteSQLException: Failed to parse
query.
{noformat}
> Calcite engine. Create table from query result
> --
>
> Key: IGNITE-14555
> URL: https://issues.apache.org/jira/browse/IGNITE-14555
> Project: Ignite
> Issue Type: Improvement
> Components: sql
>Reporter: Konstantin Orlov
>Assignee: Aleksey Plekhanov
>Priority: Minor
> Labels: calcite3-required, ignite-3
> Time Spent: 2h 20m
> Remaining Estimate: 0h
>
> Provide ability to create table from the result of the query: {{CREATE TABLE
> my_tbl AS }}.
> Affected tests:
> {{modules/calcite/src/test/sql/types/decimal/decimal_aggregates.test_ignore}}
> {{modules/calcite/src/test/sql/insert/test_insert.test}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16127) Update Ignite dependency log4j
[ https://issues.apache.org/jira/browse/IGNITE-16127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-16127: -- Assignee: Aleksandr > Update Ignite dependency log4j > -- > > Key: IGNITE-16127 > URL: https://issues.apache.org/jira/browse/IGNITE-16127 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > > Update Ignite dependency: log4j to 2.160 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16127) Update Ignite dependency log4j
Aleksandr created IGNITE-16127: -- Summary: Update Ignite dependency log4j Key: IGNITE-16127 URL: https://issues.apache.org/jira/browse/IGNITE-16127 Project: Ignite Issue Type: Improvement Reporter: Aleksandr Update Ignite dependency: log4j to 2.160 -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16120) Return real page size if encryption is configured for a cache group even when keys are not injected yet
[ https://issues.apache.org/jira/browse/IGNITE-16120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy updated IGNITE-16120: --- Summary: Return real page size if encryption is configured for a cache group even when keys are not injected yet (was: Return real page size if encryption is configured for a region even when keys are not injected yet) > Return real page size if encryption is configured for a cache group even when > keys are not injected yet > --- > > Key: IGNITE-16120 > URL: https://issues.apache.org/jira/browse/IGNITE-16120 > Project: Ignite > Issue Type: Improvement > Components: cache >Affects Versions: 2.13 >Reporter: Roman Puchkovskiy >Assignee: Roman Puchkovskiy >Priority: Major > > When encryption is enabled for a region in the configuration, > PageMemory#realPageSize(int) returns a value reduced by some > encryption-related data overhead. For instance, currently, when full page > size (returned by PageMemory#pageSize()) is 4096, #realPageSize(int) returns > 4064. > But #realPageSize(int) starts returning the 'real' realPageSize only when it > has some keys for the provided group ID. The injection of keys happens on > node join. The following comment explains why: > //We can't store keys before node join to cluster(on statically configured > cache registration). > //Because, keys should be received from cluster. > //Otherwise, we would generate different keys on each started node. > //So, after starting, coordinator saves locally newly generated encryption > keys. > //And sends that keys to every joining node. > This means that for short period of time (before the keys are injected) > #realPageSize(int) returns full page size (4096); this happens when > allocating pages with metadata for caches preconfigured in the region > configuration, for example. These pages are initialized with wrong page size. > Currently, this page size is not used for these pages during initialization, > but in the future this might cause some problem. > My suggestion is to try remove this gap. > # First of all, for the preconfigured groups (listed in IgniteConfiguration > which is accessible to PageMemoryImpl constructor) we don't need to wait for > keys injection: we just have the list of these groups > # Another option (probably better) would be to employ some event system to > mark a group as encrypted before it gets created. If such a mechanism exists > :) If not, maybe it's not that hard to implement it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15867) Socket shutdown called twice in GridNioServer
[
https://issues.apache.org/jira/browse/IGNITE-15867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459659#comment-17459659
]
Ignite TC Bot commented on IGNITE-15867:
{panel:title=Branch: [pull/9651/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/9651/head] Base: [master] : New Tests
(32)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Basic 1{color} [[tests
2|https://ci.ignite.apache.org/viewLog.html?buildId=6323197]]
* {color:#013220}IgniteBasicTestSuite:
GridNioServerTest.shouldNotLogWarningsOnKeyClose - PASSED{color}
* {color:#013220}IgniteBasicTestSuite:
IgniteUtilsUnitTest.shouldNotProduceWarningsWhenClosingAnAlreadyClosedSocket -
PASSED{color}
{color:#8b}PDS 2{color} [[tests
30|https://ci.ignite.apache.org/viewLog.html?buildId=6323256]]
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReadBeforeGracefulShutdown[specificConsistentId=false,
walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/264767425@5dd903be]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReReadWhenStateWasNotStored[specificConsistentId=false,
walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/264767425@5dd903be]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testMultiNodeConsumption[specificConsistentId=false, walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/264767425@5dd903be]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testCdcSingleton[specificConsistentId=false, walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/264767425@5dd903be]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReReadWhenStateWasNotStored[specificConsistentId=true,
walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/264767425@5dd903be]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testMultiNodeConsumption[specificConsistentId=true, walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/264767425@5dd903be]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testCdcSingleton[specificConsistentId=true, walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/264767425@5dd903be]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReadAllKeys[specificConsistentId=false, walMode=FSYNC,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/264767425@5dd903be]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testReReadWhenStateWasNotStored[specificConsistentId=true,
walMode=BACKGROUND,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/264767425@5dd903be]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testMultiNodeConsumption[specificConsistentId=true,
walMode=BACKGROUND,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/264767425@5dd903be]
- PASSED{color}
* {color:#013220}IgnitePdsTestSuite2:
CdcSelfTest.testCdcSingleton[specificConsistentId=true, walMode=BACKGROUND,
metricExporter=org.apache.ignite.cdc.CdcSelfTest$$Lambda$17/264767425@5dd903be]
- PASSED{color}
... and 19 new tests
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6323282buildTypeId=IgniteTests24Java8_RunAll]
> Socket shutdown called twice in GridNioServer
> -
>
> Key: IGNITE-15867
> URL: https://issues.apache.org/jira/browse/IGNITE-15867
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.11
>Reporter: Ilya Korol
>Assignee: Roman Puchkovskiy
>Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After fixing IGNITE-15367 calling
> {{GridNioServer$AbstractNioClientWorker.closekey(SelectionKey key)}} would
> produce excessive {{java.nio.channels.ClosedChannelException}} because
> {{sock.shutdownInput()}} and {{sock.shutdownInput()}} would be called twice:
> {code:java}
> // GridNioServer$AbstractNioClientWorker
> private void closeKey(SelectionKey key) {
> // Shutdown input and output so that remote client will see correct
> socket close.
> Socket sock = ((SocketChannel)key.channel()).socket();
> try {
> try {
> sock.shutdownInput(); // <-- First time
> }
> catch (IOException ignored) {
> // No-op.
> }
> try {
> sock.shutdownOutput(); // <-- First time
> }
> catch (IOException ignored) {
> // No-op.
> }
> }
> finally {
> U.close(key, log); // <-- Second time
> U.close(sock, log);
[jira] [Updated] (IGNITE-16126) [ignite-extensions] Update dependency: log4j to 2.15.0
[ https://issues.apache.org/jira/browse/IGNITE-16126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergei Ryzhov updated IGNITE-16126: --- Summary: [ignite-extensions] Update dependency: log4j to 2.15.0 (was: [ignite-extensions] Update Ignite dependency: log4j to 2.15.0) > [ignite-extensions] Update dependency: log4j to 2.15.0 > -- > > Key: IGNITE-16126 > URL: https://issues.apache.org/jira/browse/IGNITE-16126 > Project: Ignite > Issue Type: Bug >Reporter: Sergei Ryzhov >Assignee: Sergei Ryzhov >Priority: Major > > Update Ignite dependency: log4j to 2.15.0 > https://www.randori.com/blog/cve-2021-44228/ -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16126) [ignite-extensions] Update dependency: log4j to 2.15.0
[ https://issues.apache.org/jira/browse/IGNITE-16126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergei Ryzhov updated IGNITE-16126: --- Description: Update dependency: log4j to 2.15.0 https://www.randori.com/blog/cve-2021-44228/ was: Update Ignite dependency: log4j to 2.15.0 https://www.randori.com/blog/cve-2021-44228/ > [ignite-extensions] Update dependency: log4j to 2.15.0 > -- > > Key: IGNITE-16126 > URL: https://issues.apache.org/jira/browse/IGNITE-16126 > Project: Ignite > Issue Type: Bug >Reporter: Sergei Ryzhov >Assignee: Sergei Ryzhov >Priority: Major > > Update dependency: log4j to 2.15.0 > https://www.randori.com/blog/cve-2021-44228/ -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16126) [ignite-extensions] Update Ignite dependency: log4j to 2.15.0
[ https://issues.apache.org/jira/browse/IGNITE-16126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sergei Ryzhov updated IGNITE-16126: --- Ignite Flags: (was: Docs Required,Release Notes Required) > [ignite-extensions] Update Ignite dependency: log4j to 2.15.0 > - > > Key: IGNITE-16126 > URL: https://issues.apache.org/jira/browse/IGNITE-16126 > Project: Ignite > Issue Type: Bug >Reporter: Sergei Ryzhov >Assignee: Sergei Ryzhov >Priority: Major > > Update Ignite dependency: log4j to 2.15.0 > https://www.randori.com/blog/cve-2021-44228/ -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16126) [ignite-extensions] Update Ignite dependency: log4j to 2.15.0
Sergei Ryzhov created IGNITE-16126: -- Summary: [ignite-extensions] Update Ignite dependency: log4j to 2.15.0 Key: IGNITE-16126 URL: https://issues.apache.org/jira/browse/IGNITE-16126 Project: Ignite Issue Type: Bug Reporter: Sergei Ryzhov Assignee: Sergei Ryzhov Update Ignite dependency: log4j to 2.15.0 https://www.randori.com/blog/cve-2021-44228/ -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16125) Remove LuckyOrange code from website
Mauricio Stekl created IGNITE-16125: --- Summary: Remove LuckyOrange code from website Key: IGNITE-16125 URL: https://issues.apache.org/jira/browse/IGNITE-16125 Project: Ignite Issue Type: Task Components: website Reporter: Mauricio Stekl Assignee: Erlan Aytpaev We discontinued LuckyOrange for the new website. The tracking code was removed for the main site, but not from the online documentation. Please update the Jekyll templates and rebuild the docs (latest and previous versions). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16124) deleteAllById has wrong signature
[
https://issues.apache.org/jira/browse/IGNITE-16124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Reiche updated IGNITE-16124:
Description:
java: name clash: deleteAllById(java.lang.Iterable) in
org.apache.ignite.springdata20.repository.IgniteRepository and
deleteAllById(java.lang.Iterable) in
org.springframework.data.repository.CrudRepository have the same erasure, yet
neither overrides the other
2.6.0-RC1
2.9.1
org.apache.ignite
ignite-spring-data_2.0
${ignite.version}
org.apache.ignite
ignite-core
${ignite.version}
org.apache.ignite
ignite-indexing
${ignite.version}
org.apache.ignite
ignite-spring
${ignite.version}
org.springframework.data
spring-data-commons
${spring.data.version}
If ignite-spring-data is used instead of ingite-spring-data_2.0, the method
deleteAll is flagged
java: name clash: deleteAll(java.lang.Iterable) in
org.springframework.data.repository.CrudRepository and
deleteAll(java.lang.Iterable) in
org.apache.ignite.springdata.repository.IgniteRepository have the same erasure,
yet neither overrides the other
And 2.2-ext gives the following:
org.apache.ignite
ignite-spring-data-2.2-ext
1.0.0
java: name clash: deleteAllById(java.lang.Iterable) in
org.apache.ignite.springdata22.repository.IgniteRepository and
deleteAllById(java.lang.Iterable) in
org.springframework.data.repository.CrudRepository have the same erasure, yet
neither overrides the other
package com.example.ignite;
import org.apache.ignite.springdata.repository.IgniteRepository;
import org.apache.ignite.springdata.repository.config.RepositoryConfig;
@RepositoryConfig(cacheName = "myCache")
public interface EmployeeRepository extends IgniteRepository
{ EmployeeDTO getEmployeeDTOById(ID id); }
was:
java: name clash: deleteAllById(java.lang.Iterable) in
org.apache.ignite.springdata20.repository.IgniteRepository and
deleteAllById(java.lang.Iterable) in
org.springframework.data.repository.CrudRepository have the same erasure, yet
neither overrides the other
2.6.0-RC1
2.9.1
org.apache.ignite
ignite-spring-data_2.0
${ignite.version}
org.apache.ignite
ignite-core
${ignite.version}
org.apache.ignite
ignite-indexing
${ignite.version}
org.apache.ignite
ignite-spring
${ignite.version}
org.springframework.data
spring-data-commons
${spring.data.version}
If ignite-spring-data is used instead of ingite-spring-data_2.0, the method
deleteAll is flagged
java: name clash: deleteAll(java.lang.Iterable) in
org.springframework.data.repository.CrudRepository and
deleteAll(java.lang.Iterable) in
org.apache.ignite.springdata.repository.IgniteRepository have the same erasure,
yet neither overrides the other
package com.example.ignite;
import org.apache.ignite.springdata.repository.IgniteRepository;
import org.apache.ignite.springdata.repository.config.RepositoryConfig;
@RepositoryConfig(cacheName = "myCache")
public interface EmployeeRepository extends IgniteRepository {
EmployeeDTO getEmployeeDTOById(ID id);
}
> deleteAllById has wrong signature
> -
>
> Key: IGNITE-16124
> URL: https://issues.apache.org/jira/browse/IGNITE-16124
> Project: Ignite
> Issue Type: Bug
>Reporter: Michael Reiche
>Priority: Major
>
> java: name clash: deleteAllById(java.lang.Iterable) in
> org.apache.ignite.springdata20.repository.IgniteRepository and
> deleteAllById(java.lang.Iterable) in
> org.springframework.data.repository.CrudRepository have the same erasure, yet
> neither overrides the other
>
> 2.6.0-RC1
> 2.9.1
>
>
>
> org.apache.ignite
> ignite-spring-data_2.0
> ${ignite.version}
>
>
> org.apache.ignite
> ignite-core
> ${ignite.version}
>
>
> org.apache.ignite
> ignite-indexing
> ${ignite.version}
>
>
> org.apache.ignite
> ignite-spring
> ${ignite.version}
>
>
> org.springframework.data
> spring-data-commons
> ${spring.data.version}
>
>
> If ignite-spring-data is used instead of ingite-spring-data_2.0, the method
> deleteAll is flagged
> java: name clash: deleteAll(java.lang.Iterable com.example.ignite.EmployeeDTO>) in
> org.springframework.data.repository.CrudRepository and
> deleteAll(java.lang.Iterable) in
> org.apache.ignite.springdata.repository.IgniteRepository have the same
> erasure, yet neither overrides the other
> And 2.2-ext gives the following:
> org.apache.ignite
> ignite-spring-data-2.2-ext
> 1.0.0
> java: name clash: deleteAllById(java.lang.Iterable) in
> org.apache.ignite.springdata22.repository.IgniteRepository and
> deleteAllById(java.lang.Iterable) in
> org.springframework.data.repository.CrudRepository have the same erasure, yet
> neither overrides the other
> package com.example.ignite;
> import org.apache.ignite.springdata.repository.IgniteRepository;
> import org.apache.ignite.springdata.repository.config.RepositoryConfig;
>
[jira] [Updated] (IGNITE-16124) deleteAllById has wrong signature
[
https://issues.apache.org/jira/browse/IGNITE-16124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Reiche updated IGNITE-16124:
Description:
java: name clash: deleteAllById(java.lang.Iterable) in
org.apache.ignite.springdata20.repository.IgniteRepository and
deleteAllById(java.lang.Iterable) in
org.springframework.data.repository.CrudRepository have the same erasure, yet
neither overrides the other
2.6.0-RC1
2.9.1
org.apache.ignite
ignite-spring-data_2.0
${ignite.version}
org.apache.ignite
ignite-core
${ignite.version}
org.apache.ignite
ignite-indexing
${ignite.version}
org.apache.ignite
ignite-spring
${ignite.version}
org.springframework.data
spring-data-commons
${spring.data.version}
If ignite-spring-data is used instead of ingite-spring-data_2.0, the method
deleteAll is flagged
java: name clash: deleteAll(java.lang.Iterable) in
org.springframework.data.repository.CrudRepository and
deleteAll(java.lang.Iterable) in
org.apache.ignite.springdata.repository.IgniteRepository have the same erasure,
yet neither overrides the other
package com.example.ignite;
import org.apache.ignite.springdata.repository.IgniteRepository;
import org.apache.ignite.springdata.repository.config.RepositoryConfig;
@RepositoryConfig(cacheName = "myCache")
public interface EmployeeRepository extends IgniteRepository {
EmployeeDTO getEmployeeDTOById(ID id);
}
was:
java: name clash: deleteAllById(java.lang.Iterable) in
org.apache.ignite.springdata20.repository.IgniteRepository and
deleteAllById(java.lang.Iterable) in
org.springframework.data.repository.CrudRepository have the same erasure, yet
neither overrides the other
2.6.0-RC1
2.9.1
org.apache.ignite
ignite-spring-data_2.0
${ignite.version}
org.apache.ignite
ignite-core
${ignite.version}
org.apache.ignite
ignite-indexing
${ignite.version}
org.apache.ignite
ignite-spring
${ignite.version}
org.springframework.data
spring-data-commons
${spring.data.version}
> deleteAllById has wrong signature
> -
>
> Key: IGNITE-16124
> URL: https://issues.apache.org/jira/browse/IGNITE-16124
> Project: Ignite
> Issue Type: Bug
>Reporter: Michael Reiche
>Priority: Major
>
> java: name clash: deleteAllById(java.lang.Iterable) in
> org.apache.ignite.springdata20.repository.IgniteRepository and
> deleteAllById(java.lang.Iterable) in
> org.springframework.data.repository.CrudRepository have the same erasure, yet
> neither overrides the other
>
> 2.6.0-RC1
> 2.9.1
>
>
>
> org.apache.ignite
> ignite-spring-data_2.0
> ${ignite.version}
>
>
> org.apache.ignite
> ignite-core
> ${ignite.version}
>
>
> org.apache.ignite
> ignite-indexing
> ${ignite.version}
>
>
> org.apache.ignite
> ignite-spring
> ${ignite.version}
>
>
> org.springframework.data
> spring-data-commons
> ${spring.data.version}
>
>
> If ignite-spring-data is used instead of ingite-spring-data_2.0, the method
> deleteAll is flagged
> java: name clash: deleteAll(java.lang.Iterable com.example.ignite.EmployeeDTO>) in
> org.springframework.data.repository.CrudRepository and
> deleteAll(java.lang.Iterable) in
> org.apache.ignite.springdata.repository.IgniteRepository have the same
> erasure, yet neither overrides the other
> package com.example.ignite;
> import org.apache.ignite.springdata.repository.IgniteRepository;
> import org.apache.ignite.springdata.repository.config.RepositoryConfig;
> @RepositoryConfig(cacheName = "myCache")
> public interface EmployeeRepository extends
> IgniteRepository {
> EmployeeDTO getEmployeeDTOById(ID id);
> }
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16124) deleteAllById has wrong signature
[
https://issues.apache.org/jira/browse/IGNITE-16124?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Reiche updated IGNITE-16124:
Summary: deleteAllById has wrong signature (was: deleteAllByIds has wrong
signature)
> deleteAllById has wrong signature
> -
>
> Key: IGNITE-16124
> URL: https://issues.apache.org/jira/browse/IGNITE-16124
> Project: Ignite
> Issue Type: Bug
>Reporter: Michael Reiche
>Priority: Major
>
> java: name clash: deleteAllById(java.lang.Iterable) in
> org.apache.ignite.springdata20.repository.IgniteRepository and
> deleteAllById(java.lang.Iterable) in
> org.springframework.data.repository.CrudRepository have the same erasure, yet
> neither overrides the other
>
> 2.6.0-RC1
> 2.9.1
>
>
>
> org.apache.ignite
> ignite-spring-data_2.0
> ${ignite.version}
>
>
> org.apache.ignite
> ignite-core
> ${ignite.version}
>
>
> org.apache.ignite
> ignite-indexing
> ${ignite.version}
>
>
> org.apache.ignite
> ignite-spring
> ${ignite.version}
>
>
> org.springframework.data
> spring-data-commons
> ${spring.data.version}
>
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16124) deleteAllByIds has wrong signature
Michael Reiche created IGNITE-16124:
---
Summary: deleteAllByIds has wrong signature
Key: IGNITE-16124
URL: https://issues.apache.org/jira/browse/IGNITE-16124
Project: Ignite
Issue Type: Bug
Reporter: Michael Reiche
java: name clash: deleteAllById(java.lang.Iterable) in
org.apache.ignite.springdata20.repository.IgniteRepository and
deleteAllById(java.lang.Iterable) in
org.springframework.data.repository.CrudRepository have the same erasure, yet
neither overrides the other
2.6.0-RC1
2.9.1
org.apache.ignite
ignite-spring-data_2.0
${ignite.version}
org.apache.ignite
ignite-core
${ignite.version}
org.apache.ignite
ignite-indexing
${ignite.version}
org.apache.ignite
ignite-spring
${ignite.version}
org.springframework.data
spring-data-commons
${spring.data.version}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-15940) Class parsing API and simple class descriptor format
[ https://issues.apache.org/jira/browse/IGNITE-15940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459321#comment-17459321 ] Semyon Danilov commented on IGNITE-15940: - Merged to main > Class parsing API and simple class descriptor format > > > Key: IGNITE-15940 > URL: https://issues.apache.org/jira/browse/IGNITE-15940 > Project: Ignite > Issue Type: Task > Components: networking >Reporter: Sergey Chugunov >Assignee: Semyon Danilov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha4 > > Time Spent: 8h 50m > Remaining Estimate: 0h > > To enable User Object Serialization we need to define class descriptor format > and API for parsing java classes into this format. > As the first step, we consider simple cases - Serializable/Externalizable > classes with primitive or Serializable/Externalizable fields. > Look here for reference: > https://github.com/gridgain/gridgain-9-ce/blob/iep-67/modules/network/README.md#class-descriptor -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15940) Class parsing API and simple class descriptor format
[ https://issues.apache.org/jira/browse/IGNITE-15940?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459308#comment-17459308 ] Aleksandr Polovtcev commented on IGNITE-15940: -- Looks very good to me! > Class parsing API and simple class descriptor format > > > Key: IGNITE-15940 > URL: https://issues.apache.org/jira/browse/IGNITE-15940 > Project: Ignite > Issue Type: Task > Components: networking >Reporter: Sergey Chugunov >Assignee: Semyon Danilov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha4 > > Time Spent: 8h 40m > Remaining Estimate: 0h > > To enable User Object Serialization we need to define class descriptor format > and API for parsing java classes into this format. > As the first step, we consider simple cases - Serializable/Externalizable > classes with primitive or Serializable/Externalizable fields. > Look here for reference: > https://github.com/gridgain/gridgain-9-ce/blob/iep-67/modules/network/README.md#class-descriptor -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (IGNITE-16123) Broken LazyOnDmlTest for MVCC due to incorrect check in InlineFilterClosure
[ https://issues.apache.org/jira/browse/IGNITE-16123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Maksim Timonin resolved IGNITE-16123. - Resolution: Fixed > Broken LazyOnDmlTest for MVCC due to incorrect check in InlineFilterClosure > --- > > Key: IGNITE-16123 > URL: https://issues.apache.org/jira/browse/IGNITE-16123 > Project: Ignite > Issue Type: Bug >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Time Spent: 20m > Remaining Estimate: 0h > > LazyOnDmlTest failed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Resolved] (IGNITE-16122) Fix compilation after IGNITE-15885
[ https://issues.apache.org/jira/browse/IGNITE-16122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semyon Danilov resolved IGNITE-16122. - Fix Version/s: 3.0.0-alpha4 Reviewer: Semyon Danilov Resolution: Resolved LGTM! Thanks for the quick fix, merged to the main branch > Fix compilation after IGNITE-15885 > -- > > Key: IGNITE-16122 > URL: https://issues.apache.org/jira/browse/IGNITE-16122 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr Polovtcev >Assignee: Aleksandr Polovtcev >Priority: Blocker > Labels: ignite-3 > Fix For: 3.0.0-alpha4 > > Time Spent: 0.5h > Remaining Estimate: 0h > > There were some merge conflicts that broke the compilation -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16123) Broken LazyOnDmlTest for MVCC due to incorrect check in InlineFilterClosure
Maksim Timonin created IGNITE-16123: --- Summary: Broken LazyOnDmlTest for MVCC due to incorrect check in InlineFilterClosure Key: IGNITE-16123 URL: https://issues.apache.org/jira/browse/IGNITE-16123 Project: Ignite Issue Type: Bug Reporter: Maksim Timonin Assignee: Maksim Timonin LazyOnDmlTest failed. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16122) Fix compilation after IGNITE-15885
Aleksandr Polovtcev created IGNITE-16122: Summary: Fix compilation after IGNITE-15885 Key: IGNITE-16122 URL: https://issues.apache.org/jira/browse/IGNITE-16122 Project: Ignite Issue Type: Task Reporter: Aleksandr Polovtcev Assignee: Aleksandr Polovtcev There were some merge conflicts that broke the compilation -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16121) Implement key-value API for java thin client for 3.0
Igor Sapego created IGNITE-16121: Summary: Implement key-value API for java thin client for 3.0 Key: IGNITE-16121 URL: https://issues.apache.org/jira/browse/IGNITE-16121 Project: Ignite Issue Type: New Feature Components: thin client Reporter: Igor Sapego Fix For: 3.0.0-alpha4 Implement KeyValueView for Java thin client. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-15885) Create SortedIndexStorage based on RocksDB
[
https://issues.apache.org/jira/browse/IGNITE-15885?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459245#comment-17459245
]
Semyon Danilov commented on IGNITE-15885:
-
LGTM! Thanks for the contribution, merged to the main branch.
> Create SortedIndexStorage based on RocksDB
> --
>
> Key: IGNITE-15885
> URL: https://issues.apache.org/jira/browse/IGNITE-15885
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
> Time Spent: 7.5h
> Remaining Estimate: 0h
>
> h1. API
> * Add {{SortedIndexStorage}} interface:
> {code:java}
> public interface SortedIndexStorage extends AutoCloseable {
> /** Index key factory */
> IndexKeyFactory indexKeyFactory();
> /** Index descriptor */
> SortedIndexDescriptor indexDescriptor();
> /** Adds a value */
> void put(IndexKey key, SearchRow value);
> /** Removes a value */
> void remove(IndexKey key);
> /** Range scan */
> Cursor range(IndexKeyPrefix lowerBound, IndexKeyPrefix
> upperBound);
> /** Removes all values */
> void destroy();
> }
> {code}
> * {{IndexKeyPrefix}} can contain a smaller number of columns, than the
> {{IndexKey}}, needed for the prefix search.
> {code:java}
> public interface IndexKey {
> byte[] asBytes();
> }
> public interface IndexKeyPrefix {
> Object[] prefixColumnValues();
> }
> {code}
> * {{SearchRow}} is a class from the {{storage-api}} that represents a key
> from the partition storage.
> h1. Implementation details
> For the initial implementation it is suggested to use {{BinaryRow}}
> serialization mechanism (it is proposed to implement the {{IndexKey}} on top
> of it, simply ignoring the value bytes) to store it in RocksDB. First
> implementation will also use a naive comparator, that will convert each
> {{BinaryRow}} into a {{Row}} and compare individual deserialized columns.
> It is also proposed to store partition storage keys as values in the index
> storage.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16120) Return real page size if encryption is configured for a region even when keys are not injected yet
Roman Puchkovskiy created IGNITE-16120: -- Summary: Return real page size if encryption is configured for a region even when keys are not injected yet Key: IGNITE-16120 URL: https://issues.apache.org/jira/browse/IGNITE-16120 Project: Ignite Issue Type: Improvement Components: cache Affects Versions: 2.13 Reporter: Roman Puchkovskiy Assignee: Roman Puchkovskiy When encryption is enabled for a region in the configuration, PageMemory#realPageSize(int) returns a value reduced by some encryption-related data overhead. For instance, currently, when full page size (returned by PageMemory#pageSize()) is 4096, #realPageSize(int) returns 4064. But #realPageSize(int) starts returning the 'real' realPageSize only when it has some keys for the provided group ID. The injection of keys happens on node join. The following comment explains why: //We can't store keys before node join to cluster(on statically configured cache registration). //Because, keys should be received from cluster. //Otherwise, we would generate different keys on each started node. //So, after starting, coordinator saves locally newly generated encryption keys. //And sends that keys to every joining node. This means that for short period of time (before the keys are injected) #realPageSize(int) returns full page size (4096); this happens when allocating pages with metadata for caches preconfigured in the region configuration, for example. These pages are initialized with wrong page size. Currently, this page size is not used for these pages during initialization, but in the future this might cause some problem. My suggestion is to try remove this gap. # First of all, for the preconfigured groups (listed in IgniteConfiguration which is accessible to PageMemoryImpl constructor) we don't need to wait for keys injection: we just have the list of these groups # Another option (probably better) would be to employ some event system to mark a group as encrypted before it gets created. If such a mechanism exists :) If not, maybe it's not that hard to implement it. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-14945) IndexQuery should use inline IO for internal filtering.
[ https://issues.apache.org/jira/browse/IGNITE-14945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459185#comment-17459185 ] Maksim Timonin commented on IGNITE-14945: - A lot of thanks to [~ibessonov] for suggestions related to IO part. Merged to master. > IndexQuery should use inline IO for internal filtering. > --- > > Key: IGNITE-14945 > URL: https://issues.apache.org/jira/browse/IGNITE-14945 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-71 > Time Spent: 20m > Remaining Estimate: 0h > > For comparison of index keys it's required: > # to init cache data row > # access fields with BinaryObject API > So, it's possible to use inline IO for filtering. It can help: > # speed up comparison (Inline IO access is faster than BinaryObject API). > # to avoid init cache data rows for filtered items (in case there are more > filtered items). -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16119) Caclite engine. Refactor IgniteBuiltInMethod and IgniteMethod classes
Aleksey Plekhanov created IGNITE-16119:
--
Summary: Caclite engine. Refactor IgniteBuiltInMethod and
IgniteMethod classes
Key: IGNITE-16119
URL: https://issues.apache.org/jira/browse/IGNITE-16119
Project: Ignite
Issue Type: Improvement
Reporter: Aleksey Plekhanov
Looks like {{IgniteBuiltInMethod}} and {{IgniteMethod}} classes have the same
purpose. We should choose and leave one of them.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Resolved] (IGNITE-15994) Create NUMA allocator test suite.
[
https://issues.apache.org/jira/browse/IGNITE-15994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ivan Daschinsky resolved IGNITE-15994.
--
Resolution: Fixed
> Create NUMA allocator test suite.
> -
>
> Key: IGNITE-15994
> URL: https://issues.apache.org/jira/browse/IGNITE-15994
> Project: Ignite
> Issue Type: Task
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
>
> Need to create specific suite on TC 1, link to existing suite in TC 2 is in
> links.
> Suite should be excluded from {{Run All}} until merge of IGNITE-15922
> [PR|https://github.com/apache/ignite/pull/9569] for testing
> Module name: {{:ignite-numa-allocator}}
> Test suite name: {{NumaAllocatorTestSuite}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16118) GridCacheEntryRemovedException appears in server log when performing concurrent cache read with expiry policy.
[
https://issues.apache.org/jira/browse/IGNITE-16118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-16118:
--
Description:
In a rare case, you might observe a confusing {{GridCacheEntryRemovedException
"Failed to send TTL update request"}} in logs while *reading a non-expired*
cache value.
{noformat}
[ERROR][sys-#258%expiry.EntryRemovedOnReadTest2%][root] Failed to
send TTL update request.
org.apache.ignite.internal.processors.cache.GridCacheEntryRemovedException
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkObsolete(GridCacheMapEntry.java:3052)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReadersLocked(GridDhtCacheEntry.java:732)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReaders(GridDhtCacheEntry.java:708)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.readers(GridDhtCacheEntry.java:416)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$8.run(GridDhtCacheAdapter.java:1122)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7329)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
It looks like there is a race between {{sendTtlUpdateRequest(UUID,
GridCacheTtlUpdateRequest)}} and heap entry eviction. In this case, the
keys-loop is interrupted by the NPE ( which is currently not outputting
anywhere).
Since ttl updates are not ordered (see IGNITE-305), it is difficult to
reproduce the real-world problem that this issue could cause, but we shouldn't
log a weird exception anyway and continue the loop without NPE.
Reproducer:
{code:java}
public class EntryRemovedOnReadTest extends GridCommonAbstractTest {
private final ListeningTestLogger log = new
ListeningTestLogger(GridAbstractTest.log);
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
return super.getConfiguration(igniteInstanceName)
.setGridLogger(log)
.setCacheConfiguration(new CacheConfiguration(DEFAULT_CACHE_NAME)
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setCacheMode(REPLICATED)
);
}
@Test
public void test() throws Exception {
LogListener lsnr = LogListener.matches("Failed to send TTL update
request").build();
log.registerListener(lsnr);
startGridsMultiThreaded(4);
Map vals = new TreeMap<>();
for (int i = 1; i < 10; i++)
vals.put(i, i);
jcache(0).putAll(vals);
assertFalse(lsnr.check());
long timeout = 20_000L;
long stopTime = System.currentTimeMillis() + timeout;
int iter = 0;
IgniteCache cache = jcache(1).withExpiryPolicy(new
ExpiryPolicy() {
@Override public Duration getExpiryForAccess() {
return new Duration(TimeUnit.MILLISECONDS, timeout);
}
@Override public Duration getExpiryForCreation() { return null; }
@Override public Duration getExpiryForUpdate() { return null; }
});
while (System.currentTimeMillis() < stopTime) {
cache.getAll(vals.keySet());
assertFalse("iter=" + ++iter, lsnr.check());
}
}
}
{code}
was:
In a rare case, you might observe a confusing {{GridCacheEntryRemovedException
"Failed to send TTL update request"}} in logs while *reading a non-expired*
cache value.
{noformat}
[ERROR][sys-#258%expiry.EntryRemovedOnReadTest2%][root] Failed to
send TTL update request.
org.apache.ignite.internal.processors.cache.GridCacheEntryRemovedException
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkObsolete(GridCacheMapEntry.java:3052)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReadersLocked(GridDhtCacheEntry.java:732)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReaders(GridDhtCacheEntry.java:708)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.readers(GridDhtCacheEntry.java:416)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$8.run(GridDhtCacheAdapter.java:1122)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7329)
at
[jira] [Updated] (IGNITE-16118) GridCacheEntryRemovedException appears in server log when performing concurrent cache read with expiry policy.
[
https://issues.apache.org/jira/browse/IGNITE-16118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-16118:
--
Description:
In a rare case, you might observe a confusing {{GridCacheEntryRemovedException
"Failed to send TTL update request"}} in logs while *reading a non-expired*
cache value.
{noformat}
[ERROR][sys-#258%expiry.EntryRemovedOnReadTest2%][root] Failed to
send TTL update request.
org.apache.ignite.internal.processors.cache.GridCacheEntryRemovedException
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkObsolete(GridCacheMapEntry.java:3052)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReadersLocked(GridDhtCacheEntry.java:732)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReaders(GridDhtCacheEntry.java:708)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.readers(GridDhtCacheEntry.java:416)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$8.run(GridDhtCacheAdapter.java:1122)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7329)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
It looks like there is a race between {{sendTtlUpdateRequest(UUID,
GridCacheTtlUpdateRequest)}} and heap entry eviction, in this case, the
keys-loop is interrupted by the NPE ( which is currently not outputting
anywhere).
Since ttl updates are not ordered (see IGNITE-305), it is difficult to
reproduce the real-world problem that this issue could cause, but we shouldn't
log a weird exception anyway and continue the loop without NPE.
Reproducer:
{code:java}
public class EntryRemovedOnReadTest extends GridCommonAbstractTest {
private final ListeningTestLogger log = new
ListeningTestLogger(GridAbstractTest.log);
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
return super.getConfiguration(igniteInstanceName)
.setGridLogger(log)
.setCacheConfiguration(new CacheConfiguration(DEFAULT_CACHE_NAME)
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setCacheMode(REPLICATED)
);
}
@Test
public void test() throws Exception {
LogListener lsnr = LogListener.matches("Failed to send TTL update
request").build();
log.registerListener(lsnr);
startGridsMultiThreaded(4);
Map vals = new TreeMap<>();
for (int i = 1; i < 10; i++)
vals.put(i, i);
jcache(0).putAll(vals);
assertFalse(lsnr.check());
long timeout = 20_000L;
long stopTime = System.currentTimeMillis() + timeout;
int iter = 0;
IgniteCache cache = jcache(1).withExpiryPolicy(new
ExpiryPolicy() {
@Override public Duration getExpiryForAccess() {
return new Duration(TimeUnit.MILLISECONDS, timeout);
}
@Override public Duration getExpiryForCreation() { return null; }
@Override public Duration getExpiryForUpdate() { return null; }
});
while (System.currentTimeMillis() < stopTime) {
cache.getAll(vals.keySet());
assertFalse("iter=" + ++iter, lsnr.check());
}
}
}
{code}
was:
In a rare case, you might observe a confusing {{GridCacheEntryRemovedException
"Failed to send TTL update request"}} in logs while concurrently *reading a
non-expired* cache value.
{noformat}
[ERROR][sys-#258%expiry.EntryRemovedOnReadTest2%][root] Failed to
send TTL update request.
org.apache.ignite.internal.processors.cache.GridCacheEntryRemovedException
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkObsolete(GridCacheMapEntry.java:3052)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReadersLocked(GridDhtCacheEntry.java:732)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReaders(GridDhtCacheEntry.java:708)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.readers(GridDhtCacheEntry.java:416)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$8.run(GridDhtCacheAdapter.java:1122)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7329)
[jira] [Updated] (IGNITE-16118) GridCacheEntryRemovedException appears in server log when performing concurrent cache read with expiry policy.
[
https://issues.apache.org/jira/browse/IGNITE-16118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-16118:
--
Description:
In a rare case, you might observe a confusing {{GridCacheEntryRemovedException
"Failed to send TTL update request"}} in logs while concurrently *reading a
non-expired* cache value.
{noformat}
[ERROR][sys-#258%expiry.EntryRemovedOnReadTest2%][root] Failed to
send TTL update request.
org.apache.ignite.internal.processors.cache.GridCacheEntryRemovedException
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkObsolete(GridCacheMapEntry.java:3052)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReadersLocked(GridDhtCacheEntry.java:732)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReaders(GridDhtCacheEntry.java:708)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.readers(GridDhtCacheEntry.java:416)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$8.run(GridDhtCacheAdapter.java:1122)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7329)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
It looks like there is a race between {{sendTtlUpdateRequest(UUID,
GridCacheTtlUpdateRequest)}} and heap entry eviction, in this case, the
keys-loop is interrupted by the NPE ( which is currently not outputting
anywhere).
Since ttl updates are not ordered (see IGNITE-305), it is difficult to
reproduce the real-world problem that this issue could cause, but we shouldn't
log a weird exception anyway and continue the loop without NPE.
Reproducer:
{code:java}
public class EntryRemovedOnReadTest extends GridCommonAbstractTest {
private final ListeningTestLogger log = new
ListeningTestLogger(GridAbstractTest.log);
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
return super.getConfiguration(igniteInstanceName)
.setGridLogger(log)
.setCacheConfiguration(new CacheConfiguration(DEFAULT_CACHE_NAME)
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setCacheMode(REPLICATED)
);
}
@Test
public void test() throws Exception {
LogListener lsnr = LogListener.matches("Failed to send TTL update
request").build();
log.registerListener(lsnr);
startGridsMultiThreaded(4);
Map vals = new TreeMap<>();
for (int i = 1; i < 10; i++)
vals.put(i, i);
jcache(0).putAll(vals);
assertFalse(lsnr.check());
long timeout = 20_000L;
long stopTime = System.currentTimeMillis() + timeout;
int iter = 0;
IgniteCache cache = jcache(1).withExpiryPolicy(new
ExpiryPolicy() {
@Override public Duration getExpiryForAccess() {
return new Duration(TimeUnit.MILLISECONDS, timeout);
}
@Override public Duration getExpiryForCreation() { return null; }
@Override public Duration getExpiryForUpdate() { return null; }
});
while (System.currentTimeMillis() < stopTime) {
cache.getAll(vals.keySet());
assertFalse("iter=" + ++iter, lsnr.check());
}
}
}
{code}
was:
In a rare case, you might observe a confusing {{GridCacheEntryRemovedException
"Failed to send TTL update request"}} in logs while concurrently *reading a
non-expired* cache value.
{noformat}
[ERROR][sys-#258%expiry.EntryRemovedOnReadTest2%][root] Failed to
send TTL update request.
org.apache.ignite.internal.processors.cache.GridCacheEntryRemovedException
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkObsolete(GridCacheMapEntry.java:3052)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReadersLocked(GridDhtCacheEntry.java:732)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReaders(GridDhtCacheEntry.java:708)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.readers(GridDhtCacheEntry.java:416)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$8.run(GridDhtCacheAdapter.java:1122)
at
[jira] [Updated] (IGNITE-16118) GridCacheEntryRemovedException appears in server log when performing concurrent cache read with expiry policy.
[
https://issues.apache.org/jira/browse/IGNITE-16118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-16118:
--
Ignite Flags: (was: Docs Required,Release Notes Required)
> GridCacheEntryRemovedException appears in server log when performing
> concurrent cache read with expiry policy.
> --
>
> Key: IGNITE-16118
> URL: https://issues.apache.org/jira/browse/IGNITE-16118
> Project: Ignite
> Issue Type: Bug
>Reporter: Pavel Pereslegin
>Assignee: Pavel Pereslegin
>Priority: Minor
>
> In a rare case, you might observe a confusing
> {{GridCacheEntryRemovedException "Failed to send TTL update request"}} in
> logs while concurrently *reading a non-expired* cache value.
> {noformat}
> [ERROR][sys-#258%expiry.EntryRemovedOnReadTest2%][root] Failed to
> send TTL update request.
> org.apache.ignite.internal.processors.cache.GridCacheEntryRemovedException
> at
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkObsolete(GridCacheMapEntry.java:3052)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReadersLocked(GridDhtCacheEntry.java:732)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReaders(GridDhtCacheEntry.java:708)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.readers(GridDhtCacheEntry.java:416)
> at
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$8.run(GridDhtCacheAdapter.java:1122)
> at
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7329)
> at
> org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
> at
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> {noformat}
> It looks like there is a race between {{sendTtlUpdateRequest(UUID,
> GridCacheTtlUpdateRequest)}} and heap entry eviction, in this case, the
> keys-loop is interrupted by the NPE ( which is currently not outputting
> anywhere).
> Since ttl updates are not ordered (see IGNITE-305), it is difficult to
> reproduce the real-world problem that this issue could cause, but we
> shouldn't log a weird exception anyway and continue the loop without NPE.
> Reproducer:
> {code:java}
> public class EntryRemovedOnReadTest extends GridCommonAbstractTest {
> private final ListeningTestLogger log = new
> ListeningTestLogger(GridAbstractTest.log);
> @Override protected IgniteConfiguration getConfiguration(String
> igniteInstanceName) throws Exception {
> return super.getConfiguration(igniteInstanceName)
> .setGridLogger(log)
> .setCacheConfiguration(new CacheConfiguration Integer>(DEFAULT_CACHE_NAME)
> .setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
> .setCacheMode(REPLICATED)
> );
> }
> @Test
> public void test() throws Exception {
> LogListener lsnr = LogListener.matches("Failed to send TTL update
> request").build();
> log.registerListener(lsnr);
> startGridsMultiThreaded(4);
> Map vals = new TreeMap<>();
> for (int i = 1; i < 10; i++)
> vals.put(i, i);
> jcache(0).putAll(vals);
> assertFalse(lsnr.check());
> long timeout = 20_000L;
> long stopTime = System.currentTimeMillis() + timeout;
> int iter = 0;
> IgniteCache cache = jcache(1).withExpiryPolicy(new
> ExpiryPolicy() {
> @Override public Duration getExpiryForAccess() {
> return new Duration(TimeUnit.MILLISECONDS, timeout);
> }
> @Override public Duration getExpiryForCreation() { return null; }
> @Override public Duration getExpiryForUpdate() { return null; }
> });
> while (System.currentTimeMillis() < stopTime) {
> cache.getAll(vals.keySet());
> assertFalse("iter=" + ++iter, lsnr.check());
> }
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16118) GridCacheEntryRemovedException appears in server log when performing concurrent cache read with expiry policy.
Pavel Pereslegin created IGNITE-16118:
-
Summary: GridCacheEntryRemovedException appears in server log when
performing concurrent cache read with expiry policy.
Key: IGNITE-16118
URL: https://issues.apache.org/jira/browse/IGNITE-16118
Project: Ignite
Issue Type: Bug
Reporter: Pavel Pereslegin
Assignee: Pavel Pereslegin
In a rare case, you might observe a confusing {{GridCacheEntryRemovedException
"Failed to send TTL update request"}} in logs while concurrently *reading a
non-expired* cache value.
{noformat}
[ERROR][sys-#258%expiry.EntryRemovedOnReadTest2%][root] Failed to
send TTL update request.
org.apache.ignite.internal.processors.cache.GridCacheEntryRemovedException
at
org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkObsolete(GridCacheMapEntry.java:3052)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReadersLocked(GridDhtCacheEntry.java:732)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.checkReaders(GridDhtCacheEntry.java:708)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheEntry.readers(GridDhtCacheEntry.java:416)
at
org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtCacheAdapter$8.run(GridDhtCacheAdapter.java:1122)
at
org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7329)
at
org.apache.ignite.internal.processors.closure.GridClosureProcessor$1.body(GridClosureProcessor.java:827)
at
org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
{noformat}
It looks like there is a race between {{sendTtlUpdateRequest(UUID,
GridCacheTtlUpdateRequest)}} and heap entry eviction, in this case, the
keys-loop is interrupted by the NPE, which is currently not outputting
anywhere.
Since ttl updates are not ordered (see IGNITE-305), it is difficult to
reproduce the real-world problem that this issue could cause, but we shouldn't
log a weird exception anyway and continue the loop without NPE.
Reproducer:
{code:java}
public class EntryRemovedOnReadTest extends GridCommonAbstractTest {
private final ListeningTestLogger log = new
ListeningTestLogger(GridAbstractTest.log);
@Override protected IgniteConfiguration getConfiguration(String
igniteInstanceName) throws Exception {
return super.getConfiguration(igniteInstanceName)
.setGridLogger(log)
.setCacheConfiguration(new CacheConfiguration(DEFAULT_CACHE_NAME)
.setAtomicityMode(CacheAtomicityMode.TRANSACTIONAL)
.setCacheMode(REPLICATED)
);
}
@Test
public void test() throws Exception {
LogListener lsnr = LogListener.matches("Failed to send TTL update
request").build();
log.registerListener(lsnr);
startGridsMultiThreaded(4);
Map vals = new TreeMap<>();
for (int i = 1; i < 10; i++)
vals.put(i, i);
jcache(0).putAll(vals);
assertFalse(lsnr.check());
long timeout = 20_000L;
long stopTime = System.currentTimeMillis() + timeout;
int iter = 0;
IgniteCache cache = jcache(1).withExpiryPolicy(new
ExpiryPolicy() {
@Override public Duration getExpiryForAccess() {
return new Duration(TimeUnit.MILLISECONDS, timeout);
}
@Override public Duration getExpiryForCreation() { return null; }
@Override public Duration getExpiryForUpdate() { return null; }
});
while (System.currentTimeMillis() < stopTime) {
cache.getAll(vals.keySet());
assertFalse("iter=" + ++iter, lsnr.check());
}
}
}
{code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-16108) Investigate of Storage Bridge Interface
[ https://issues.apache.org/jira/browse/IGNITE-16108?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Konstantin Orlov reassigned IGNITE-16108: - Assignee: Konstantin Orlov > Investigate of Storage Bridge Interface > --- > > Key: IGNITE-16108 > URL: https://issues.apache.org/jira/browse/IGNITE-16108 > Project: Ignite > Issue Type: Task > Components: sql >Reporter: Yury Gerzhedovich >Assignee: Konstantin Orlov >Priority: Major > Labels: ignite-3 > > As the Apache Ignite 3.x supports different storage engines will be good to > have unified interaction with them through some Storage Engine Bridge > Interface. Let's write some POCs to understand deeper what we need to do in > this direction. > Result of the task should be set of tickets for realization the bridge. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16089) ItMetadataTest.columnNames fails with AssertionError
[
https://issues.apache.org/jira/browse/IGNITE-16089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459125#comment-17459125
]
Taras Ledkov commented on IGNITE-16089:
---
[~korlov], the patch is OK with me.
> ItMetadataTest.columnNames fails with AssertionError
>
>
> Key: IGNITE-16089
> URL: https://issues.apache.org/jira/browse/IGNITE-16089
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-alpha3
>Reporter: Vyacheslav Koptilin
>Assignee: Konstantin Orlov
>Priority: Blocker
> Labels: ignite-3
>
> _ItMetadataTest.columnNames_ fails with the following exception:
> {noformat}
> java.lang.AssertionError: Unexpected type of result: RecordType() MULTISET
> at
> org.apache.ignite.internal.processors.query.calcite.util.TypeUtils.nativeType(TypeUtils.java:388)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.ResultSetMetadataImpl.fields(ResultSetMetadataImpl.java:60)
> at
> org.apache.ignite.internal.calcite.util.QueryChecker.check(QueryChecker.java:364)
> at
> org.apache.ignite.internal.calcite.ItMetadataTest.columnNames(ItMetadataTest.java:67)
> {noformat}
> Looks like the support of _SqlTypeName#Multiset_ should be added.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16110) Enrich GetLeaderResponse with term field
[ https://issues.apache.org/jira/browse/IGNITE-16110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16110: - Labels: ignite-3 (was: ) > Enrich GetLeaderResponse with term field > > > Key: IGNITE-16110 > URL: https://issues.apache.org/jira/browse/IGNITE-16110 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Priority: Major > Labels: ignite-3 > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16109) Add listeners to raft module
[
https://issues.apache.org/jira/browse/IGNITE-16109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-16109:
-
Labels: ignite-3 (was: )
> Add listeners to raft module
>
>
> Key: IGNITE-16109
> URL: https://issues.apache.org/jira/browse/IGNITE-16109
> Project: Ignite
> Issue Type: Task
>Reporter: Kirill Gusakov
>Priority: Major
> Labels: ignite-3
>
> For handle rebalance feature safe and correct we need to add the following
> listeners on the start of new Raft node:
> - {{onLeaderChanged()}} - must be executed from the new leader when raft
> group changes the leader.
> - {{onChangePeersError(errorContext)}} - must be executed when any errors
> during changePeers occurred
> - {{onChangePeersCommitted(peers)}} - must be executed with the list of new
> peers when changePeers has successfully done.
> Also, maybe we will need additional listener method
> - {{onStableUpdate(peers)}}, which must be invoked together with applying
> configuration (oldQuorum, newQuorum) -> (newQuorum)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16097) Some tests are flaky in ItNodeTest
[ https://issues.apache.org/jira/browse/IGNITE-16097?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-16097: - Labels: ignite-3 (was: ) > Some tests are flaky in ItNodeTest > -- > > Key: IGNITE-16097 > URL: https://issues.apache.org/jira/browse/IGNITE-16097 > Project: Ignite > Issue Type: Task >Reporter: Sergey Uttsel >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3 > > Some tests are flaky in org.apache.ignite.raft.jraft.core.ItNodeTest: > # testLeaderTransferWithReplicatorStateListener > # testTripleNodesWithReplicatorStateListener > # testResetLearners > # testLeaderTransfer > # testLeaderTransferBeforeLogIsCompleted > # testLeaderTransferResumeOnFailure > -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-16079) Rename search and data keys for the Partition Storage
[
https://issues.apache.org/jira/browse/IGNITE-16079?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-16079:
-
Labels: ignite-3 (was: )
> Rename search and data keys for the Partition Storage
> -
>
> Key: IGNITE-16079
> URL: https://issues.apache.org/jira/browse/IGNITE-16079
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
> Labels: ignite-3
>
> There are currently the following classes in the {{PartitionStorage}} that
> act as data and search keys: {{SearchRow}} and {{DataRow}}. This makes the
> {{SortedIndexStorage}} interface hard to understand, because it stores
> {{SearchRows}} as values. It is proposed to rename these classes:
> {{SearchRow}} -> {{PartitionKey}}
> {{DataRow}} -> {{PartitionData}}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Commented] (IGNITE-16087) Thin 3.0: Implement all ClientRecordView operations
[ https://issues.apache.org/jira/browse/IGNITE-16087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459099#comment-17459099 ] Pavel Tupitsyn commented on IGNITE-16087: - Merged to main: f17b8cbaa2385ba64492221fefb28080420c62d8 > Thin 3.0: Implement all ClientRecordView operations > --- > > Key: IGNITE-16087 > URL: https://issues.apache.org/jira/browse/IGNITE-16087 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-alpha4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha4 > > Time Spent: 10m > Remaining Estimate: 0h > > Finish the ClientRecordView implementation. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-16087) Thin 3.0: Implement all ClientRecordView operations
[ https://issues.apache.org/jira/browse/IGNITE-16087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17459098#comment-17459098 ] Igor Sapego commented on IGNITE-16087: -- [~ptupitsyn] looks good > Thin 3.0: Implement all ClientRecordView operations > --- > > Key: IGNITE-16087 > URL: https://issues.apache.org/jira/browse/IGNITE-16087 > Project: Ignite > Issue Type: Improvement > Components: thin client >Affects Versions: 3.0.0-alpha4 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha4 > > > Finish the ClientRecordView implementation. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16117) Thin 3.0: Convert async exceptions in sync APIs
Pavel Tupitsyn created IGNITE-16117:
---
Summary: Thin 3.0: Convert async exceptions in sync APIs
Key: IGNITE-16117
URL: https://issues.apache.org/jira/browse/IGNITE-16117
Project: Ignite
Issue Type: Improvement
Components: thin client
Affects Versions: 3.0.0-alpha3
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
Fix For: 3.0.0-alpha4
Currently, synchronous APIs delegate to async variants like this:
{code:java}
public Collection deleteAllExact(@NotNull Collection recs) {
return deleteAllExactAsync(recs).join();
}
{code}
However, *join()* throws *CompletionException* so users have to unwrap the
actual exception manually.
Implement exception unwrapping in all synchronous client APIs. See how
server-side APIs deal with this in *AbstractTableView#sync*.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] (IGNITE-16090) ItMetadataTest.columnOrder cannot be run twice in the same JVM
[ https://issues.apache.org/jira/browse/IGNITE-16090 ]
Konstantin Orlov deleted comment on IGNITE-16090:
---
was (Author: korlov):
[~tledkov-gridgain], could you please do a review?
> ItMetadataTest.columnOrder cannot be run twice in the same JVM
> --
>
> Key: IGNITE-16090
> URL: https://issues.apache.org/jira/browse/IGNITE-16090
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-alpha3
>Reporter: Vyacheslav Koptilin
>Assignee: Konstantin Orlov
>Priority: Blocker
> Labels: ignite-3
>
> The attempt to run the _ItMetadataTest.columnOrder_ test twice in the same
> JVM results in the following exception:
> {noformat}
> class org.apache.ignite.lang.IgniteException: An error occurred while query
> executing.
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.RootNode.checkException(RootNode.java:278)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.RootNode.exchangeBuffers(RootNode.java:265)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.RootNode.hasNext(RootNode.java:189)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ClosableIteratorsHolder$DelegatingIterator.hasNext(ClosableIteratorsHolder.java:132)
> at
> org.apache.ignite.internal.processors.query.calcite.util.TransformingIterator.hasNext(TransformingIterator.java:44)
> at java.base/java.util.Iterator.forEachRemaining(Iterator.java:132)
> at
> java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> at
> java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
> at
> org.apache.ignite.internal.calcite.util.Commons.getAllFromCursor(Commons.java:31)
> at
> org.apache.ignite.internal.calcite.util.QueryChecker.check(QueryChecker.java:380)
> at
> org.apache.ignite.internal.calcite.ItMetadataTest.columnOrder(ItMetadataTest.java:106)
> ...
> Caused by: java.lang.NullPointerException: table
> at java.base/java.util.Objects.requireNonNull(Objects.java:246)
> at org.apache.calcite.rel.core.TableScan.(TableScan.java:72)
> at org.apache.calcite.rel.core.TableScan.(TableScan.java:90)
> at
> org.apache.ignite.internal.processors.query.calcite.rel.ProjectableFilterableTableScan.(ProjectableFilterableTableScan.java:89)
> at
> org.apache.ignite.internal.processors.query.calcite.rel.IgniteTableScan.(IgniteTableScan.java:44)
> at SC.apply(Unknown Source)
> at
> org.apache.ignite.internal.processors.query.calcite.externalize.RelJson$RelFactory.apply(RelJson.java:117)
> at
> org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader.readRel(RelJsonReader.java:126)
> at
> org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader.readRels(RelJsonReader.java:117)
> at
> org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader.read(RelJsonReader.java:108)
> at
> org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader.fromJson(RelJsonReader.java:81)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareFragment(ExecutionServiceImpl.java:404)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.lambda$onMessage$6(ExecutionServiceImpl.java:582)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.lambda$queryPlan$0(QueryPlanCacheImpl.java:47)
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.lambda$doComputeIfAbsent$13(BoundedLocalCache.java:2457)
> at
> java.base/java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1908)
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.doComputeIfAbsent(BoundedLocalCache.java:2455)
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.computeIfAbsent(BoundedLocalCache.java:2438)
> at
> com.github.benmanes.caffeine.cache.LocalCache.computeIfAbsent(LocalCache.java:107)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.queryPlan(QueryPlanCacheImpl.java:47)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.onMessage(ExecutionServiceImpl.java:580)
> at
>
[jira] [Assigned] (IGNITE-16089) ItMetadataTest.columnNames fails with AssertionError
[
https://issues.apache.org/jira/browse/IGNITE-16089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov reassigned IGNITE-16089:
-
Assignee: Konstantin Orlov
> ItMetadataTest.columnNames fails with AssertionError
>
>
> Key: IGNITE-16089
> URL: https://issues.apache.org/jira/browse/IGNITE-16089
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-alpha3
>Reporter: Vyacheslav Koptilin
>Assignee: Konstantin Orlov
>Priority: Blocker
> Labels: ignite-3
>
> _ItMetadataTest.columnNames_ fails with the following exception:
> {noformat}
> java.lang.AssertionError: Unexpected type of result: RecordType() MULTISET
> at
> org.apache.ignite.internal.processors.query.calcite.util.TypeUtils.nativeType(TypeUtils.java:388)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.ResultSetMetadataImpl.fields(ResultSetMetadataImpl.java:60)
> at
> org.apache.ignite.internal.calcite.util.QueryChecker.check(QueryChecker.java:364)
> at
> org.apache.ignite.internal.calcite.ItMetadataTest.columnNames(ItMetadataTest.java:67)
> {noformat}
> Looks like the support of _SqlTypeName#Multiset_ should be added.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16116) Support user mapping functions.
Andrey Mashenkov created IGNITE-16116:
-
Summary: Support user mapping functions.
Key: IGNITE-16116
URL: https://issues.apache.org/jira/browse/IGNITE-16116
Project: Ignite
Issue Type: Improvement
Reporter: Andrey Mashenkov
Let's allow users to implement their own strategy of marshaling objects.
The {{Tuple}} interface looks good candidate for representing a row, rather
than exposing any internals to the user.
Start point is {{Mapper.of(Function objectToRow, Function
rowToObject) }}.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16115) Implement getNullable and getOrDefault operations.
[ https://issues.apache.org/jira/browse/IGNITE-16115?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andrey Mashenkov updated IGNITE-16115: -- Labels: ignite-3 (was: ) > Implement getNullable and getOrDefault operations. > -- > > Key: IGNITE-16115 > URL: https://issues.apache.org/jira/browse/IGNITE-16115 > Project: Ignite > Issue Type: Improvement >Reporter: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > > It is allowed to map an object to a single nullable column, which makes > 'null' values legal in the KeyValue view. > Once the 'null' value is possible there is no way to distinguish, if there is > no row in a table for the given key, or the row exists and the mapped column > contains the 'null' value. > Let's introduce NullableValue class-wrapper for a value and implement > getNullable, and getOrDefault methods for that purpose. > The first is useful for cases, when it's not possible to use a "default", but > creates an additional wrapper. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Assigned] (IGNITE-16090) ItMetadataTest.columnOrder cannot be run twice in the same JVM
[
https://issues.apache.org/jira/browse/IGNITE-16090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Konstantin Orlov reassigned IGNITE-16090:
-
Assignee: Konstantin Orlov
> ItMetadataTest.columnOrder cannot be run twice in the same JVM
> --
>
> Key: IGNITE-16090
> URL: https://issues.apache.org/jira/browse/IGNITE-16090
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-alpha3
>Reporter: Vyacheslav Koptilin
>Assignee: Konstantin Orlov
>Priority: Blocker
> Labels: ignite-3
>
> The attempt to run the _ItMetadataTest.columnOrder_ test twice in the same
> JVM results in the following exception:
> {noformat}
> class org.apache.ignite.lang.IgniteException: An error occurred while query
> executing.
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.RootNode.checkException(RootNode.java:278)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.RootNode.exchangeBuffers(RootNode.java:265)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.RootNode.hasNext(RootNode.java:189)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ClosableIteratorsHolder$DelegatingIterator.hasNext(ClosableIteratorsHolder.java:132)
> at
> org.apache.ignite.internal.processors.query.calcite.util.TransformingIterator.hasNext(TransformingIterator.java:44)
> at java.base/java.util.Iterator.forEachRemaining(Iterator.java:132)
> at
> java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> at
> java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
> at
> org.apache.ignite.internal.calcite.util.Commons.getAllFromCursor(Commons.java:31)
> at
> org.apache.ignite.internal.calcite.util.QueryChecker.check(QueryChecker.java:380)
> at
> org.apache.ignite.internal.calcite.ItMetadataTest.columnOrder(ItMetadataTest.java:106)
> ...
> Caused by: java.lang.NullPointerException: table
> at java.base/java.util.Objects.requireNonNull(Objects.java:246)
> at org.apache.calcite.rel.core.TableScan.(TableScan.java:72)
> at org.apache.calcite.rel.core.TableScan.(TableScan.java:90)
> at
> org.apache.ignite.internal.processors.query.calcite.rel.ProjectableFilterableTableScan.(ProjectableFilterableTableScan.java:89)
> at
> org.apache.ignite.internal.processors.query.calcite.rel.IgniteTableScan.(IgniteTableScan.java:44)
> at SC.apply(Unknown Source)
> at
> org.apache.ignite.internal.processors.query.calcite.externalize.RelJson$RelFactory.apply(RelJson.java:117)
> at
> org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader.readRel(RelJsonReader.java:126)
> at
> org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader.readRels(RelJsonReader.java:117)
> at
> org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader.read(RelJsonReader.java:108)
> at
> org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader.fromJson(RelJsonReader.java:81)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareFragment(ExecutionServiceImpl.java:404)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.lambda$onMessage$6(ExecutionServiceImpl.java:582)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.lambda$queryPlan$0(QueryPlanCacheImpl.java:47)
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.lambda$doComputeIfAbsent$13(BoundedLocalCache.java:2457)
> at
> java.base/java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1908)
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.doComputeIfAbsent(BoundedLocalCache.java:2455)
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.computeIfAbsent(BoundedLocalCache.java:2438)
> at
> com.github.benmanes.caffeine.cache.LocalCache.computeIfAbsent(LocalCache.java:107)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.queryPlan(QueryPlanCacheImpl.java:47)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.onMessage(ExecutionServiceImpl.java:580)
> at
[jira] [Updated] (IGNITE-16089) ItMetadataTest.columnNames fails with AssertionError
[
https://issues.apache.org/jira/browse/IGNITE-16089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-16089:
---
Priority: Blocker (was: Major)
> ItMetadataTest.columnNames fails with AssertionError
>
>
> Key: IGNITE-16089
> URL: https://issues.apache.org/jira/browse/IGNITE-16089
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-alpha3
>Reporter: Vyacheslav Koptilin
>Priority: Blocker
> Labels: ignite-3
>
> _ItMetadataTest.columnNames_ fails with the following exception:
> {noformat}
> java.lang.AssertionError: Unexpected type of result: RecordType() MULTISET
> at
> org.apache.ignite.internal.processors.query.calcite.util.TypeUtils.nativeType(TypeUtils.java:388)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.ResultSetMetadataImpl.fields(ResultSetMetadataImpl.java:60)
> at
> org.apache.ignite.internal.calcite.util.QueryChecker.check(QueryChecker.java:364)
> at
> org.apache.ignite.internal.calcite.ItMetadataTest.columnNames(ItMetadataTest.java:67)
> {noformat}
> Looks like the support of _SqlTypeName#Multiset_ should be added.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16089) ItMetadataTest.columnNames fails with AssertionError
[
https://issues.apache.org/jira/browse/IGNITE-16089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-16089:
---
Priority: Major (was: Blocker)
> ItMetadataTest.columnNames fails with AssertionError
>
>
> Key: IGNITE-16089
> URL: https://issues.apache.org/jira/browse/IGNITE-16089
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-alpha3
>Reporter: Vyacheslav Koptilin
>Priority: Major
> Labels: ignite-3
>
> _ItMetadataTest.columnNames_ fails with the following exception:
> {noformat}
> java.lang.AssertionError: Unexpected type of result: RecordType() MULTISET
> at
> org.apache.ignite.internal.processors.query.calcite.util.TypeUtils.nativeType(TypeUtils.java:388)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.ResultSetMetadataImpl.fields(ResultSetMetadataImpl.java:60)
> at
> org.apache.ignite.internal.calcite.util.QueryChecker.check(QueryChecker.java:364)
> at
> org.apache.ignite.internal.calcite.ItMetadataTest.columnNames(ItMetadataTest.java:67)
> {noformat}
> Looks like the support of _SqlTypeName#Multiset_ should be added.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16089) ItMetadataTest.columnNames fails with AssertionError
[
https://issues.apache.org/jira/browse/IGNITE-16089?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vyacheslav Koptilin updated IGNITE-16089:
-
Priority: Blocker (was: Major)
> ItMetadataTest.columnNames fails with AssertionError
>
>
> Key: IGNITE-16089
> URL: https://issues.apache.org/jira/browse/IGNITE-16089
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-alpha3
>Reporter: Vyacheslav Koptilin
>Priority: Blocker
> Labels: ignite-3
>
> _ItMetadataTest.columnNames_ fails with the following exception:
> {noformat}
> java.lang.AssertionError: Unexpected type of result: RecordType() MULTISET
> at
> org.apache.ignite.internal.processors.query.calcite.util.TypeUtils.nativeType(TypeUtils.java:388)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.ResultSetMetadataImpl.fields(ResultSetMetadataImpl.java:60)
> at
> org.apache.ignite.internal.calcite.util.QueryChecker.check(QueryChecker.java:364)
> at
> org.apache.ignite.internal.calcite.ItMetadataTest.columnNames(ItMetadataTest.java:67)
> {noformat}
> Looks like the support of _SqlTypeName#Multiset_ should be added.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Updated] (IGNITE-16090) ItMetadataTest.columnOrder cannot be run twice in the same JVM
[
https://issues.apache.org/jira/browse/IGNITE-16090?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-16090:
---
Priority: Blocker (was: Major)
> ItMetadataTest.columnOrder cannot be run twice in the same JVM
> --
>
> Key: IGNITE-16090
> URL: https://issues.apache.org/jira/browse/IGNITE-16090
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Affects Versions: 3.0.0-alpha3
>Reporter: Vyacheslav Koptilin
>Priority: Blocker
> Labels: ignite-3
>
> The attempt to run the _ItMetadataTest.columnOrder_ test twice in the same
> JVM results in the following exception:
> {noformat}
> class org.apache.ignite.lang.IgniteException: An error occurred while query
> executing.
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.RootNode.checkException(RootNode.java:278)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.RootNode.exchangeBuffers(RootNode.java:265)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.rel.RootNode.hasNext(RootNode.java:189)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ClosableIteratorsHolder$DelegatingIterator.hasNext(ClosableIteratorsHolder.java:132)
> at
> org.apache.ignite.internal.processors.query.calcite.util.TransformingIterator.hasNext(TransformingIterator.java:44)
> at java.base/java.util.Iterator.forEachRemaining(Iterator.java:132)
> at
> java.base/java.util.Spliterators$IteratorSpliterator.forEachRemaining(Spliterators.java:1801)
> at
> java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:484)
> at
> java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
> at
> java.base/java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:913)
> at
> java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
> at
> java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:578)
> at
> org.apache.ignite.internal.calcite.util.Commons.getAllFromCursor(Commons.java:31)
> at
> org.apache.ignite.internal.calcite.util.QueryChecker.check(QueryChecker.java:380)
> at
> org.apache.ignite.internal.calcite.ItMetadataTest.columnOrder(ItMetadataTest.java:106)
> ...
> Caused by: java.lang.NullPointerException: table
> at java.base/java.util.Objects.requireNonNull(Objects.java:246)
> at org.apache.calcite.rel.core.TableScan.(TableScan.java:72)
> at org.apache.calcite.rel.core.TableScan.(TableScan.java:90)
> at
> org.apache.ignite.internal.processors.query.calcite.rel.ProjectableFilterableTableScan.(ProjectableFilterableTableScan.java:89)
> at
> org.apache.ignite.internal.processors.query.calcite.rel.IgniteTableScan.(IgniteTableScan.java:44)
> at SC.apply(Unknown Source)
> at
> org.apache.ignite.internal.processors.query.calcite.externalize.RelJson$RelFactory.apply(RelJson.java:117)
> at
> org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader.readRel(RelJsonReader.java:126)
> at
> org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader.readRels(RelJsonReader.java:117)
> at
> org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader.read(RelJsonReader.java:108)
> at
> org.apache.ignite.internal.processors.query.calcite.externalize.RelJsonReader.fromJson(RelJsonReader.java:81)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.prepareFragment(ExecutionServiceImpl.java:404)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.lambda$onMessage$6(ExecutionServiceImpl.java:582)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.lambda$queryPlan$0(QueryPlanCacheImpl.java:47)
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.lambda$doComputeIfAbsent$13(BoundedLocalCache.java:2457)
> at
> java.base/java.util.concurrent.ConcurrentHashMap.compute(ConcurrentHashMap.java:1908)
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.doComputeIfAbsent(BoundedLocalCache.java:2455)
> at
> com.github.benmanes.caffeine.cache.BoundedLocalCache.computeIfAbsent(BoundedLocalCache.java:2438)
> at
> com.github.benmanes.caffeine.cache.LocalCache.computeIfAbsent(LocalCache.java:107)
> at
> org.apache.ignite.internal.processors.query.calcite.prepare.QueryPlanCacheImpl.queryPlan(QueryPlanCacheImpl.java:47)
> at
> org.apache.ignite.internal.processors.query.calcite.exec.ExecutionServiceImpl.onMessage(ExecutionServiceImpl.java:580)
> at
>
[jira] [Commented] (IGNITE-15784) Support custom mapping for fields and column of arbitrary types.
[ https://issues.apache.org/jira/browse/IGNITE-15784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17458999#comment-17458999 ] Yury Gerzhedovich commented on IGNITE-15784: [~amashenkov] , LGTM in general. Let's add JIRA links for TODOs and may be we should think out the possibility ignore case mode for column names at mappers (as a separate ticket). > Support custom mapping for fields and column of arbitrary types. > > > Key: IGNITE-15784 > URL: https://issues.apache.org/jira/browse/IGNITE-15784 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Andrey Mashenkov >Assignee: Andrey Mashenkov >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha4 > > Time Spent: 2h 10m > Remaining Estimate: 0h > > h3. Motivation. > A user may want to operate with user objects, which types may differ from or > incompatible with a column type. > As a special case, a user may want to transparently serialize an arbitrary > object to byte[] (BLOB) column. > h3. Description. > To achieve this we can provide an interface for the converter and allow > passing custom converters to a mapper. > The converter acts as an interceptor and transforms a value before writing > to/after reading from the column. > Mapper API should be refactored as well to support this. > As a PoC, let's add a test with a converter that performs transparent Java > serialization arbitrary object to byte[] column. > Converters and automatic typecasting is out of the scope, > the goal is to create API and infrastructure for further extension, e.g. > * provide a standard converter component for cross-platform serialization > (based on MessagePack or on IGNITE-15944 ticket ideas) > * optionally add JSON/BSON format support. > * add simple converters for supported native types, e.g. Integer<-->String, > and possibly, support implicit typecasting. > * support unsigned types via implicit typecasting mechanics. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Created] (IGNITE-16115) Implement getNullable and getOrDefault operations.
Andrey Mashenkov created IGNITE-16115: - Summary: Implement getNullable and getOrDefault operations. Key: IGNITE-16115 URL: https://issues.apache.org/jira/browse/IGNITE-16115 Project: Ignite Issue Type: Improvement Reporter: Andrey Mashenkov It is allowed to map an object to a single nullable column, which makes 'null' values legal in the KeyValue view. Once the 'null' value is possible there is no way to distinguish, if there is no row in a table for the given key, or the row exists and the mapped column contains the 'null' value. Let's introduce NullableValue class-wrapper for a value and implement getNullable, and getOrDefault methods for that purpose. The first is useful for cases, when it's not possible to use a "default", but creates an additional wrapper. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Commented] (IGNITE-14945) IndexQuery should use inline IO for internal filtering.
[
https://issues.apache.org/jira/browse/IGNITE-14945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17458998#comment-17458998
]
Ignite TC Bot commented on IGNITE-14945:
{panel:title=Branch: [pull/9631/head] Base: [master] : Possible Blockers
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}NUMA Allocator{color} [[tests 0 Exit Code
|https://ci.ignite.apache.org/viewLog.html?buildId=6322271]]
{panel}
{panel:title=Branch: [pull/9631/head] Base: [master] : New Tests
(120)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Index Query API{color} [[tests
120|https://ci.ignite.apache.org/viewLog.html?buildId=6321803]]
* {color:#013220}IndexQueryTestSuite:
IndexQueryInlineSizesTest.testVarInlineKeys[inlineSize=5] - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInlineSizesTest.testVarInlineKeysFirst[inlineSize=5] - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInlineSizesTest.testFixedInlineKeys[inlineSize=5] - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInlineSizesTest.testVarlenAndNonInlined[inlineSize=5] - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInlineSizesTest.testFixedInlineKeys[inlineSize=6] - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInlineSizesTest.testVarlenAndNonInlined[inlineSize=6] - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInlineSizesTest.testNonInlinedKeysFirst[inlineSize=6] - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInlineSizesTest.testNonInlinedKeys[inlineSize=5] - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInlineSizesTest.testFixedInlineKeys[inlineSize=4] - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInlineSizesTest.testVarlenAndNonInlined[inlineSize=4] - PASSED{color}
* {color:#013220}IndexQueryTestSuite:
IndexQueryInlineSizesTest.testNonInlinedKeysFirst[inlineSize=4] - PASSED{color}
... and 109 new tests
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6321848buildTypeId=IgniteTests24Java8_RunAll]
> IndexQuery should use inline IO for internal filtering.
> ---
>
> Key: IGNITE-14945
> URL: https://issues.apache.org/jira/browse/IGNITE-14945
> Project: Ignite
> Issue Type: New Feature
>Reporter: Maksim Timonin
>Assignee: Maksim Timonin
>Priority: Major
> Labels: IEP-71
> Time Spent: 10m
> Remaining Estimate: 0h
>
> For comparison of index keys it's required:
> # to init cache data row
> # access fields with BinaryObject API
> So, it's possible to use inline IO for filtering. It can help:
> # speed up comparison (Inline IO access is faster than BinaryObject API).
> # to avoid init cache data rows for filtered items (in case there are more
> filtered items).
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Created] (IGNITE-16114) Flaky test FailureProcessorThreadDumpThrottlingTest.testThrottlingPerFailureType
Andrey N. Gura created IGNITE-16114:
---
Summary: Flaky test
FailureProcessorThreadDumpThrottlingTest.testThrottlingPerFailureType
Key: IGNITE-16114
URL: https://issues.apache.org/jira/browse/IGNITE-16114
Project: Ignite
Issue Type: Test
Reporter: Andrey N. Gura
Assignee: Andrey N. Gura
The test
{{FailureProcessorThreadDumpThrottlingTest.testThrottlingPerFailureType}} is
still flaky. Fix of IGNITE-15941 does not solve problem. There is still some
race. May be it is race between main thread and loggers because test is built
on test logger.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
[jira] [Assigned] (IGNITE-15867) Socket shutdown called twice in GridNioServer
[
https://issues.apache.org/jira/browse/IGNITE-15867?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy reassigned IGNITE-15867:
--
Assignee: Roman Puchkovskiy
> Socket shutdown called twice in GridNioServer
> -
>
> Key: IGNITE-15867
> URL: https://issues.apache.org/jira/browse/IGNITE-15867
> Project: Ignite
> Issue Type: Bug
> Components: general
>Affects Versions: 2.11
>Reporter: Ilya Korol
>Assignee: Roman Puchkovskiy
>Priority: Major
>
> After fixing IGNITE-15367 calling
> {{GridNioServer$AbstractNioClientWorker.closekey(SelectionKey key)}} would
> produce excessive {{java.nio.channels.ClosedChannelException}} because
> {{sock.shutdownInput()}} and {{sock.shutdownInput()}} would be called twice:
> {code:java}
> // GridNioServer$AbstractNioClientWorker
> private void closeKey(SelectionKey key) {
> // Shutdown input and output so that remote client will see correct
> socket close.
> Socket sock = ((SocketChannel)key.channel()).socket();
> try {
> try {
> sock.shutdownInput(); // <-- First time
> }
> catch (IOException ignored) {
> // No-op.
> }
> try {
> sock.shutdownOutput(); // <-- First time
> }
> catch (IOException ignored) {
> // No-op.
> }
> }
> finally {
> U.close(key, log); // <-- Second time
> U.close(sock, log); // <-- Second time
> }
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
