from:"Andrey Khitrin \(Jira\)"

[jira] [Resolved] (IGNITE-22167) RocksDB: cannot create a default zone just twice

2024-05-06 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin resolved IGNITE-22167.
-
Resolution: Invalid

> RocksDB: cannot create a default zone just twice
> 
>
> Key: IGNITE-22167
> URL: https://issues.apache.org/jira/browse/IGNITE-22167
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Priority: Critical
>  Labels: 3.0.0, rocksdb
>
> Steps to reproduce:
>  # Start AI3 cluster of 1 node
>  # Run few simple SQL queries:
> {code:sql}
> create zone if not exists "ROCKSDB" with storage_profiles='default_rocksdb';
> create table ...  with PRIMARY_ZONE='ROCKSDB';
> insert into table ... values(); -- probably, unneeded
> create zone if not exists "ROCKSDB" with storage_profiles='default_rocksdb'; 
> -- absolutely the same query as the 1st one
> {code}
> Expected behavior: the 2nd "create zone" query must be executed successfully 
> (because a zone is already created).
> Actual behavior: the 2nd "create zone" query simply {*}hangs{*}.
> Found on commit 654a11a4a00919ce2b3ff4ca0e59e83377124dea (recent AI3 at the 
> time).



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

[jira] [Commented] (IGNITE-22167) RocksDB: cannot create a default zone just twice

2024-05-06 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin commented on IGNITE-22167:
-

Caused by a configuration error in `ignite3-tests.conf` (empty profile list):
{code}
storage {
    ...
    profiles=[]
}
{code}

> RocksDB: cannot create a default zone just twice
> 
>
> Key: IGNITE-22167
> URL: https://issues.apache.org/jira/browse/IGNITE-22167
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Priority: Critical
>  Labels: 3.0.0, rocksdb
>
> Steps to reproduce:
>  # Start AI3 cluster of 1 node
>  # Run few simple SQL queries:
> {code:sql}
> create zone if not exists "ROCKSDB" with storage_profiles='default_rocksdb';
> create table ...  with PRIMARY_ZONE='ROCKSDB';
> insert into table ... values(); -- probably, unneeded
> create zone if not exists "ROCKSDB" with storage_profiles='default_rocksdb'; 
> -- absolutely the same query as the 1st one
> {code}
> Expected behavior: the 2nd "create zone" query must be executed successfully 
> (because a zone is already created).
> Actual behavior: the 2nd "create zone" query simply {*}hangs{*}.
> Found on commit 654a11a4a00919ce2b3ff4ca0e59e83377124dea (recent AI3 at the 
> time).



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

[jira] [Resolved] (IGNITE-22169) RocksDb: NPE on index creation

2024-05-06 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin resolved IGNITE-22169.
-
Resolution: Invalid

> RocksDb: NPE on index creation
> --
>
> Key: IGNITE-22169
> URL: https://issues.apache.org/jira/browse/IGNITE-22169
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Assignee: Kirill Tkalenko
>Priority: Blocker
>  Labels: 3.0.0, ignite-3, rocksdb
>
> Steps to reproduce:
> 1. Start a single 1-node cluster of AI3
> 2. Create a table in RocksDB storage:
> {code:sql}
> create zone if not exists "ROCKSDB" with storage_profiles='default_rocksdb';
> create table table_8214(id INTEGER not null, int_field_1 INTEGER not null, 
> str_field_1 VARCHAR(50) not null, primary key (id)) with 
> PRIMARY_ZONE='ROCKSDB';
> {code}
> 3. Try to create an index on this table:
> {code:sql}
> create index temp on table_8214 using SORTED (int_field_1);
> {code}
> Expected result: an index is created successfully (the same actions work on 
> ai3persist).
> Actual result: index not created, no response from server to client (query 
> hangs), NPE in AI3 log:
> {code}
> 2024-05-06 05:02:51:943 + 
> [WARNING][%IndexTests_cluster_0%tableManager-io-0][CatalogManagerImpl] Failed 
> to apply catalog update.
> java.util.concurrent.CompletionException: java.lang.NullPointerException: 
> Cannot invoke "Object.hashCode()" because "pk" is null
>   at 
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:332)
>   at 
> java.base/java.util.concurrent.CompletableFuture.uniApplyNow(CompletableFuture.java:674)
>   at 
> java.base/java.util.concurrent.CompletableFuture.uniApplyStage(CompletableFuture.java:662)
>   at 
> java.base/java.util.concurrent.CompletableFuture.thenApply(CompletableFuture.java:2168)
>   at 
> org.apache.ignite.internal.table.distributed.TableManager.onTableCreate(TableManager.java:693)
>   at 
> org.apache.ignite.internal.table.distributed.TableManager.lambda$startAsync$2(TableManager.java:614)
>   at 
> org.apache.ignite.internal.event.AbstractEventProducer.fireEvent(AbstractEventProducer.java:88)
>   at 
> org.apache.ignite.internal.catalog.CatalogManagerImpl.access$000(CatalogManagerImpl.java:91)
>   at 
> org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:562)
>   at 
> org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:529)
>   at 
> org.apache.ignite.internal.catalog.storage.UpdateLogImpl$UpdateListener.onUpdate(UpdateLogImpl.java:314)
>   at 
> org.apache.ignite.internal.metastorage.server.Watch.onUpdate(Watch.java:67)
>   at 
> org.apache.ignite.internal.metastorage.server.WatchProcessor.notifyWatches(WatchProcessor.java:233)
>   at 
> org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$notifyWatches$3(WatchProcessor.java:181)
>   at 
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1150)
>   at 
> java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:482)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
>   at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.lang.NullPointerException: Cannot invoke "Object.hashCode()" 
> because "pk" is null
>   at 
> java.base/java.util.ImmutableCollections$MapN.probe(ImmutableCollections.java:1321)
>   at 
> java.base/java.util.ImmutableCollections$MapN.get(ImmutableCollections.java:1235)
>   at 
> org.apache.ignite.internal.storage.DataStorageManager.engineByStorageProfile(DataStorageManager.java:91)
>   at 
> org.apache.ignite.internal.table.distributed.TableManager.createTableStorage(TableManager.java:1452)
>   at 
> org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:1315)
>   at 
> org.apache.ignite.internal.table.distributed.TableManager.lambda$createTableLocally$50(TableManager.java:1283)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.inBusyLockAsync(IgniteUtils.java:890)
>   at 
> org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:1267)
>   at 
> org.apache.ignite.internal.table.distributed.TableManager.onTableCreate(TableManager.java:692)
>   ... 14 more
> 2024-05-06 05:02:51:945 + 
> [ERROR][%IndexTests_cluster_0%tableManager-io-0][FailureProcessor] Critical 
> system error detected. Will be handled accordingly to configured

[jira] [Commented] (IGNITE-22169) RocksDb: NPE on index creation

2024-05-06 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin commented on IGNITE-22169:
-

Caused by a configuration error in `ignite3-tests.conf` (empty profile list):
{code}
storage {
...
profiles=[]
}
{code}

> RocksDb: NPE on index creation
> --
>
> Key: IGNITE-22169
> URL: https://issues.apache.org/jira/browse/IGNITE-22169
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Assignee: Kirill Tkalenko
>Priority: Blocker
>  Labels: 3.0.0, ignite-3, rocksdb
>
> Steps to reproduce:
> 1. Start a single 1-node cluster of AI3
> 2. Create a table in RocksDB storage:
> {code:sql}
> create zone if not exists "ROCKSDB" with storage_profiles='default_rocksdb';
> create table table_8214(id INTEGER not null, int_field_1 INTEGER not null, 
> str_field_1 VARCHAR(50) not null, primary key (id)) with 
> PRIMARY_ZONE='ROCKSDB';
> {code}
> 3. Try to create an index on this table:
> {code:sql}
> create index temp on table_8214 using SORTED (int_field_1);
> {code}
> Expected result: an index is created successfully (the same actions work on 
> ai3persist).
> Actual result: index not created, no response from server to client (query 
> hangs), NPE in AI3 log:
> {code}
> 2024-05-06 05:02:51:943 + 
> [WARNING][%IndexTests_cluster_0%tableManager-io-0][CatalogManagerImpl] Failed 
> to apply catalog update.
> java.util.concurrent.CompletionException: java.lang.NullPointerException: 
> Cannot invoke "Object.hashCode()" because "pk" is null
>   at 
> java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:332)
>   at 
> java.base/java.util.concurrent.CompletableFuture.uniApplyNow(CompletableFuture.java:674)
>   at 
> java.base/java.util.concurrent.CompletableFuture.uniApplyStage(CompletableFuture.java:662)
>   at 
> java.base/java.util.concurrent.CompletableFuture.thenApply(CompletableFuture.java:2168)
>   at 
> org.apache.ignite.internal.table.distributed.TableManager.onTableCreate(TableManager.java:693)
>   at 
> org.apache.ignite.internal.table.distributed.TableManager.lambda$startAsync$2(TableManager.java:614)
>   at 
> org.apache.ignite.internal.event.AbstractEventProducer.fireEvent(AbstractEventProducer.java:88)
>   at 
> org.apache.ignite.internal.catalog.CatalogManagerImpl.access$000(CatalogManagerImpl.java:91)
>   at 
> org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:562)
>   at 
> org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:529)
>   at 
> org.apache.ignite.internal.catalog.storage.UpdateLogImpl$UpdateListener.onUpdate(UpdateLogImpl.java:314)
>   at 
> org.apache.ignite.internal.metastorage.server.Watch.onUpdate(Watch.java:67)
>   at 
> org.apache.ignite.internal.metastorage.server.WatchProcessor.notifyWatches(WatchProcessor.java:233)
>   at 
> org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$notifyWatches$3(WatchProcessor.java:181)
>   at 
> java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1150)
>   at 
> java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:482)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
>   at java.base/java.lang.Thread.run(Thread.java:833)
> Caused by: java.lang.NullPointerException: Cannot invoke "Object.hashCode()" 
> because "pk" is null
>   at 
> java.base/java.util.ImmutableCollections$MapN.probe(ImmutableCollections.java:1321)
>   at 
> java.base/java.util.ImmutableCollections$MapN.get(ImmutableCollections.java:1235)
>   at 
> org.apache.ignite.internal.storage.DataStorageManager.engineByStorageProfile(DataStorageManager.java:91)
>   at 
> org.apache.ignite.internal.table.distributed.TableManager.createTableStorage(TableManager.java:1452)
>   at 
> org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:1315)
>   at 
> org.apache.ignite.internal.table.distributed.TableManager.lambda$createTableLocally$50(TableManager.java:1283)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.inBusyLockAsync(IgniteUtils.java:890)
>   at 
> org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:1267)
>   at 
> org.apache.ignite.internal.table.distributed.TableManager.onTableCreate(TableManager.java:692)
>   ... 14 more
> 2024-05-06 05:02:51:945 + 
>

[jira] [Updated] (IGNITE-22169) RocksDb: NPE on index creation

2024-05-06 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin updated IGNITE-22169:

Description: 
Steps to reproduce:

1. Start a single 1-node cluster of AI3
2. Create a table in RocksDB storage:
{code:sql}
create zone if not exists "ROCKSDB" with storage_profiles='default_rocksdb';
create table table_8214(id INTEGER not null, int_field_1 INTEGER not null, 
str_field_1 VARCHAR(50) not null, primary key (id)) with PRIMARY_ZONE='ROCKSDB';
{code}
3. Try to create an index on this table:
{code:sql}
create index temp on table_8214 using SORTED (int_field_1);
{code}

Expected result: an index is created successfully (the same actions work on 
ai3persist).
Actual result: index not created, no response from server to client (query 
hangs), NPE in AI3 log:

{code}
2024-05-06 05:02:51:943 + 
[WARNING][%IndexTests_cluster_0%tableManager-io-0][CatalogManagerImpl] Failed 
to apply catalog update.
java.util.concurrent.CompletionException: java.lang.NullPointerException: 
Cannot invoke "Object.hashCode()" because "pk" is null
at 
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:332)
at 
java.base/java.util.concurrent.CompletableFuture.uniApplyNow(CompletableFuture.java:674)
at 
java.base/java.util.concurrent.CompletableFuture.uniApplyStage(CompletableFuture.java:662)
at 
java.base/java.util.concurrent.CompletableFuture.thenApply(CompletableFuture.java:2168)
at 
org.apache.ignite.internal.table.distributed.TableManager.onTableCreate(TableManager.java:693)
at 
org.apache.ignite.internal.table.distributed.TableManager.lambda$startAsync$2(TableManager.java:614)
at 
org.apache.ignite.internal.event.AbstractEventProducer.fireEvent(AbstractEventProducer.java:88)
at 
org.apache.ignite.internal.catalog.CatalogManagerImpl.access$000(CatalogManagerImpl.java:91)
at 
org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:562)
at 
org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:529)
at 
org.apache.ignite.internal.catalog.storage.UpdateLogImpl$UpdateListener.onUpdate(UpdateLogImpl.java:314)
at 
org.apache.ignite.internal.metastorage.server.Watch.onUpdate(Watch.java:67)
at 
org.apache.ignite.internal.metastorage.server.WatchProcessor.notifyWatches(WatchProcessor.java:233)
at 
org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$notifyWatches$3(WatchProcessor.java:181)
at 
java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1150)
at 
java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:482)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:833)
Caused by: java.lang.NullPointerException: Cannot invoke "Object.hashCode()" 
because "pk" is null
at 
java.base/java.util.ImmutableCollections$MapN.probe(ImmutableCollections.java:1321)
at 
java.base/java.util.ImmutableCollections$MapN.get(ImmutableCollections.java:1235)
at 
org.apache.ignite.internal.storage.DataStorageManager.engineByStorageProfile(DataStorageManager.java:91)
at 
org.apache.ignite.internal.table.distributed.TableManager.createTableStorage(TableManager.java:1452)
at 
org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:1315)
at 
org.apache.ignite.internal.table.distributed.TableManager.lambda$createTableLocally$50(TableManager.java:1283)
at 
org.apache.ignite.internal.util.IgniteUtils.inBusyLockAsync(IgniteUtils.java:890)
at 
org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:1267)
at 
org.apache.ignite.internal.table.distributed.TableManager.onTableCreate(TableManager.java:692)
... 14 more
2024-05-06 05:02:51:945 + 
[ERROR][%IndexTests_cluster_0%tableManager-io-0][FailureProcessor] Critical 
system error detected. Will be handled accordingly to configured handler 
[hnd=NoOpFailureHandler [], failureCtx=FailureContext [type=CRITICAL_ERROR, 
err=java.lang.NullPointerException: Cannot invoke "Object.hashCode()" because 
"pk" is null]]
java.lang.NullPointerException: Cannot invoke "Object.hashCode()" because "pk" 
is null
at 
java.base/java.util.ImmutableCollections$MapN.probe(ImmutableCollections.java:1321)
at 
java.base/java.util.ImmutableCollections$MapN.get(ImmutableCollections.java:1235)
at 
org.apache.ignite.internal.storage.DataStorageManager.engineByStorageProfile(DataStorageManager.java:91)

[jira] [Updated] (IGNITE-22169) RocbsRB: NPE on index creation

2024-05-06 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin updated IGNITE-22169:

Description: 
Steps to reproduce:

1. Start a single 1-node cluster of AI3
2. Create a table in RocksDB storage:
{code:sql}
create zone if not exists "ROCKSDB" with storage_profiles='default_rocksdb';
create table table_8214(id INTEGER not null, int_field_1 INTEGER not null, 
str_field_1 VARCHAR(50) not null, primary key (id)) with PRIMARY_ZONE='ROCKSDB';
{code}
3. Try to create an index on this table:
{code:sql}
create index temp on table_8214 using SORTED (int_field_1);
{code}

Expected result: an index is created successfully (the same actions work on 
ai3persist).
Actual result: index not created, no response from server to client (query 
hangs), NPE in AI3 log:

{code}
2024-05-06 12:11:17:567 +0500 
[INFO][%DeleteFromWhereTests_cluster_0%metastorage-watch-executor-3][IndexManager]
 Creating local index: name=TABLE_8214_PK, id=9, tableId=8, token=23
2024-05-06 12:11:17:585 +0500 
[INFO][%DeleteFromWhereTests_cluster_0%metastorage-watch-executor-3][TableManager]
 Assignments calculated from data nodes [table=TABLE_8214, tableId=8, 
assignments= 
[0=[],1=[],2=[],3=[],4=[],5=[],6=[],7=[],8=[],9=[],10=[],11=[],12=[],13=[],14=[],15=[],16=[],17=[],18=[],19=[],20=[],21=[],22=[],23=[],24=[]],
 revision=23]
2024-05-06 12:11:17:592 +0500 
[WARNING][%DeleteFromWhereTests_cluster_0%tableManager-io-0][CatalogManagerImpl]
 Failed to apply catalog update.
java.util.concurrent.CompletionException: java.lang.NullPointerException
at 
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
at 
java.base/java.util.concurrent.CompletableFuture.uniApplyNow(CompletableFuture.java:670)
at 
java.base/java.util.concurrent.CompletableFuture.uniApplyStage(CompletableFuture.java:658)
at 
java.base/java.util.concurrent.CompletableFuture.thenApply(CompletableFuture.java:2094)
at 
org.apache.ignite.internal.table.distributed.TableManager.onTableCreate(TableManager.java:689)
at 
org.apache.ignite.internal.table.distributed.TableManager.lambda$start$2(TableManager.java:613)
at 
org.apache.ignite.internal.event.AbstractEventProducer.fireEvent(AbstractEventProducer.java:88)
at 
org.apache.ignite.internal.catalog.CatalogManagerImpl.access$000(CatalogManagerImpl.java:83)
at 
org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:534)
at 
org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:501)
at 
org.apache.ignite.internal.catalog.storage.UpdateLogImpl$UpdateListener.onUpdate(UpdateLogImpl.java:308)
at 
org.apache.ignite.internal.metastorage.server.Watch.onUpdate(Watch.java:67)
at 
org.apache.ignite.internal.metastorage.server.WatchProcessor.notifyWatches(WatchProcessor.java:233)
at 
org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$notifyWatches$3(WatchProcessor.java:181)
at 
java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
at 
java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.lang.NullPointerException
at 
java.base/java.util.ImmutableCollections$MapN.probe(ImmutableCollections.java:956)
at 
java.base/java.util.ImmutableCollections$MapN.get(ImmutableCollections.java:876)
at 
org.apache.ignite.internal.storage.DataStorageManager.engineByStorageProfile(DataStorageManager.java:84)
at 
org.apache.ignite.internal.table.distributed.TableManager.createTableStorage(TableManager.java:1450)
at 
org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:1313)
at 
org.apache.ignite.internal.table.distributed.TableManager.lambda$createTableLocally$48(TableManager.java:1281)
at 
org.apache.ignite.internal.util.IgniteUtils.inBusyLockAsync(IgniteUtils.java:889)
at 
org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:1265)
at 
org.apache.ignite.internal.table.distributed.TableManager.onTableCreate(TableManager.java:688)
... 14 more
2024-05-06 12:11:17:592 +0500 
[INFO][%DeleteFromWhereTests_cluster_0%JRaft-FSMCaller-Disruptor-metastorage_stripe_0-0][TableManager]
 Assignments calculated from data nodes are successfully written to meta 
storage [tableId=8, assignments=

[jira] [Created] (IGNITE-22169) RocbsRB: NPE on index creation

2024-05-06 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-22169:
---

 Summary: RocbsRB: NPE on index creation
 Key: IGNITE-22169
 URL: https://issues.apache.org/jira/browse/IGNITE-22169
 Project: Ignite
  Issue Type: Bug
  Components: persistence
Affects Versions: 3.0.0-beta2
Reporter: Andrey Khitrin


Steps to reproduce:

1. Start a single 1-node cluster of AI3
2. Create a table in RocksDB storage:
{code:sql}
create zone if not exists "ROCKSDB" with storage_profiles='default_rocksdb';
create table table_8214(id INTEGER not null, int_field_1 INTEGER not null, 
str_field_1 VARCHAR(50) not null, primary key (id)) with PRIMARY_ZONE='ROCKSDB';
{code}
3. Try to create an index on this table:
{code:sql}
create index temp on table_8214 using SORTED (int_field_1);
{code}

Expected result: an index is created successfully (the same actions work on 
ai3persist).
Actual result: index not created, no response from server to client (query 
"hangs"), NPE in AI3 log:

{code}
2024-05-06 12:11:17:567 +0500 
[INFO][%DeleteFromWhereTests_cluster_0%metastorage-watch-executor-3][IndexManager]
 Creating local index: name=TABLE_8214_PK, id=9, tableId=8, token=23
2024-05-06 12:11:17:585 +0500 
[INFO][%DeleteFromWhereTests_cluster_0%metastorage-watch-executor-3][TableManager]
 Assignments calculated from data nodes [table=TABLE_8214, tableId=8, 
assignments= 
[0=[],1=[],2=[],3=[],4=[],5=[],6=[],7=[],8=[],9=[],10=[],11=[],12=[],13=[],14=[],15=[],16=[],17=[],18=[],19=[],20=[],21=[],22=[],23=[],24=[]],
 revision=23]
2024-05-06 12:11:17:592 +0500 
[WARNING][%DeleteFromWhereTests_cluster_0%tableManager-io-0][CatalogManagerImpl]
 Failed to apply catalog update.
java.util.concurrent.CompletionException: java.lang.NullPointerException
at 
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:331)
at 
java.base/java.util.concurrent.CompletableFuture.uniApplyNow(CompletableFuture.java:670)
at 
java.base/java.util.concurrent.CompletableFuture.uniApplyStage(CompletableFuture.java:658)
at 
java.base/java.util.concurrent.CompletableFuture.thenApply(CompletableFuture.java:2094)
at 
org.apache.ignite.internal.table.distributed.TableManager.onTableCreate(TableManager.java:689)
at 
org.apache.ignite.internal.table.distributed.TableManager.lambda$start$2(TableManager.java:613)
at 
org.apache.ignite.internal.event.AbstractEventProducer.fireEvent(AbstractEventProducer.java:88)
at 
org.apache.ignite.internal.catalog.CatalogManagerImpl.access$000(CatalogManagerImpl.java:83)
at 
org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:534)
at 
org.apache.ignite.internal.catalog.CatalogManagerImpl$OnUpdateHandlerImpl.handle(CatalogManagerImpl.java:501)
at 
org.apache.ignite.internal.catalog.storage.UpdateLogImpl$UpdateListener.onUpdate(UpdateLogImpl.java:308)
at 
org.apache.ignite.internal.metastorage.server.Watch.onUpdate(Watch.java:67)
at 
org.apache.ignite.internal.metastorage.server.WatchProcessor.notifyWatches(WatchProcessor.java:233)
at 
org.apache.ignite.internal.metastorage.server.WatchProcessor.lambda$notifyWatches$3(WatchProcessor.java:181)
at 
java.base/java.util.concurrent.CompletableFuture$UniCompose.tryFire(CompletableFuture.java:1072)
at 
java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.lang.NullPointerException
at 
java.base/java.util.ImmutableCollections$MapN.probe(ImmutableCollections.java:956)
at 
java.base/java.util.ImmutableCollections$MapN.get(ImmutableCollections.java:876)
at 
org.apache.ignite.internal.storage.DataStorageManager.engineByStorageProfile(DataStorageManager.java:84)
at 
org.apache.ignite.internal.table.distributed.TableManager.createTableStorage(TableManager.java:1450)
at 
org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:1313)
at 
org.apache.ignite.internal.table.distributed.TableManager.lambda$createTableLocally$48(TableManager.java:1281)
at 
org.apache.ignite.internal.util.IgniteUtils.inBusyLockAsync(IgniteUtils.java:889)
at 
org.apache.ignite.internal.table.distributed.TableManager.createTableLocally(TableManager.java:1265)
at 
org.apache.ignite.internal.table.distributed.TableManager.onTableCreate(TableManager.java:688)
... 14 more
2024-05-06 12:11:17:592 +0500 
[INFO][%DeleteFromWhereTests_cluster_0%JRaft-FSMCaller-Disruptor-metastorage_stripe_0-0][TableManager]

[jira] [Updated] (IGNITE-22167) RocksDB: cannot create a default zone just twice

2024-05-06 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin updated IGNITE-22167:

Priority: Critical  (was: Major)

> RocksDB: cannot create a default zone just twice
> 
>
> Key: IGNITE-22167
> URL: https://issues.apache.org/jira/browse/IGNITE-22167
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Priority: Critical
>  Labels: 3.0.0, rocksdb
>
> Steps to reproduce:
>  # Start AI3 cluster of 1 node
>  # Run few simple SQL queries:
> {code:sql}
> create zone if not exists "ROCKSDB" with storage_profiles='default_rocksdb';
> create table ...  with PRIMARY_ZONE='ROCKSDB';
> insert into table ... values(); -- probably, unneeded
> create zone if not exists "ROCKSDB" with storage_profiles='default_rocksdb'; 
> -- absolutely the same query as the 1st one
> {code}
> Expected behavior: the 2nd "create zone" query must be executed successfully 
> (because a zone is already created).
> Actual behavior: the 2nd "create zone" query simply {*}hangs{*}.
> Found on commit 654a11a4a00919ce2b3ff4ca0e59e83377124dea (recent AI3 at the 
> time).



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

[jira] [Created] (IGNITE-22167) RocksDB: cannot create a default zone just twice

2024-05-06 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-22167:
---

 Summary: RocksDB: cannot create a default zone just twice
 Key: IGNITE-22167
 URL: https://issues.apache.org/jira/browse/IGNITE-22167
 Project: Ignite
  Issue Type: Bug
  Components: persistence
Affects Versions: 3.0.0-beta2
Reporter: Andrey Khitrin


Steps to reproduce:
 # Start AI3 cluster of 1 node
 # Run few simple SQL queries:

{code:sql}
create zone if not exists "ROCKSDB" with storage_profiles='default_rocksdb';
create table ...  with PRIMARY_ZONE='ROCKSDB';
insert into table ... values(); -- probably, unneeded
create zone if not exists "ROCKSDB" with storage_profiles='default_rocksdb'; -- 
absolutely the same query as the 1st one
{code}
Expected behavior: the 2nd "create zone" query must be executed successfully 
(because a zone is already created).
Actual behavior: the 2nd "create zone" query simply {*}hangs{*}.

Found on commit 654a11a4a00919ce2b3ff4ca0e59e83377124dea (recent AI3 at the 
time).



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

[jira] [Created] (IGNITE-22114) NullPointerException when restarting a node few times in a row

2024-04-25 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-22114:
---

 Summary: NullPointerException when restarting a node few times in 
a row
 Key: IGNITE-22114
 URL: https://issues.apache.org/jira/browse/IGNITE-22114
 Project: Ignite
  Issue Type: Bug
  Components: general
Affects Versions: 3.0.0-beta2
Reporter: Andrey Khitrin


Steps to reproduce:

1. Start a 3-node cluster (`node-1`, `node-2`, `node-3`)
2. Run some load on it (read and write)
3. Shutdown a single node, wait some time, start it again
4. After a little time (say, 30 seconds) shutdown the same node again, wait 
some time, start it again

In my case, an issue was reproduced on commit 
`d593e6487aa36a806bab075d19c8b831ca096a28` (2024-04-24 IGNITE-2124) on the 2nd 
restart of `node-3`.

Expected results: node starts without error.
Actual results: NPE in `ignite3-startup.log`.

{code}
Error when starting the node: org.apache.ignite.lang.IgniteException: 
IGN-CMN-65535 TraceId:c7b27181-0977-4925-b0ba-fa07d8a3bebe 
org.apache.ignite.lang.IgniteException: IGN-CMN-65535 
TraceId:c7b27181-0977-4925-b0ba-fa07d8a3bebe Unable to start [node=node-3]
java.util.concurrent.ExecutionException: 
org.apache.ignite.lang.IgniteException: IGN-CMN-65535 
TraceId:c7b27181-0977-4925-b0ba-fa07d8a3bebe 
org.apache.ignite.lang.IgniteException: IGN-CMN-65535 
TraceId:c7b27181-0977-4925-b0ba-fa07d8a3bebe Unable to start [node=node-3]
at 
java.base/java.util.concurrent.CompletableFuture.reportGet(CompletableFuture.java:395)
at 
java.base/java.util.concurrent.CompletableFuture.get(CompletableFuture.java:1999)
at 
org.apache.ignite.internal.app.IgniteRunner.main(IgniteRunner.java:74)
Caused by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535 
TraceId:c7b27181-0977-4925-b0ba-fa07d8a3bebe 
org.apache.ignite.lang.IgniteException: IGN-CMN-65535 
TraceId:c7b27181-0977-4925-b0ba-fa07d8a3bebe Unable to start [node=node-3]
at 
org.apache.ignite.internal.app.IgnitionImpl.handleStartException(IgnitionImpl.java:224)
at 
org.apache.ignite.internal.app.IgnitionImpl.lambda$doStart$1(IgnitionImpl.java:205)
at 
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at 
java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
at 
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at 
java.base/java.util.concurrent.CompletableFuture.postFire(CompletableFuture.java:610)
at 
java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:840)
at 
java.base/java.util.concurrent.CompletableFuture$Completion.exec(CompletableFuture.java:479)
at 
java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
at 
java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
at 
java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
at 
java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
at 
java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)
Caused by: java.util.concurrent.CompletionException: 
org.apache.ignite.lang.IgniteException: IGN-CMN-65535 
TraceId:c7b27181-0977-4925-b0ba-fa07d8a3bebe Unable to start [node=node-3]
at 
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
at 
java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
at 
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:932)
at 
java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
at 
java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535 
TraceId:c7b27181-0977-4925-b0ba-fa07d8a3bebe Unable to start [node=node-3]
at 
org.apache.ignite.internal.app.IgniteImpl.handleStartException(IgniteImpl.java:1185)
at 
org.apache.ignite.internal.app.IgniteImpl.lambda$start$27(IgniteImpl.java:1129)
at 
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
... 5 more
Caused by: java.util.concurrent.CompletionException: 
java.lang.NullPointerException
at 
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
at

[jira] [Resolved] (IGNITE-17996) Strange behavior of SQL CASE expression

2024-04-24 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin resolved IGNITE-17996.
-
Resolution: Not A Bug

> Strange behavior of SQL CASE expression
> ---
>
> Key: IGNITE-17996
> URL: https://issues.apache.org/jira/browse/IGNITE-17996
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
>  Labels: ignite-3
>
> I observe strange behavior in the next scenario:
>  
> {code:java}
> sql-cli> create table xx (f1 int primary key);
> Updated 0 rows.
> sql-cli> insert into xx values (1);
> Updated 1 rows.
> sql-cli> insert into xx values (2);
> Updated 1 rows.
> sql-cli> select f1, case when f1 < 2 then 'foo' else 'barbar' end as s, 
> length(case when f1 < 2 then 'foo' else 'barbar' end) as ls from xx;
> ╔╤╤╗
> ║ F1 │ S      │ LS ║
> ╠╪╪╣
> ║ 2  │ barbar │ 6  ║
> ╟┼┼╢
> ║ 1  │ foo    │ 6  ║
> ╚╧╧╝
>  {code}
> I expect `CASE` to return 'foo' value, but de-facto it returns 'foo   ' 
> ('foo' with 3 whitespaces at the end).  Seems like this should be fixed.
>  



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

[jira] [Resolved] (IGNITE-17997) Whitespaces at the end are ignored during string comparison

2024-04-24 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin resolved IGNITE-17997.
-
Resolution: Not A Bug

> Whitespaces at the end are ignored during string comparison
> ---
>
> Key: IGNITE-17997
> URL: https://issues.apache.org/jira/browse/IGNITE-17997
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
>  Labels: ignite-3
>
> In 3.0.0-Beta-1:
> {code:java}
> sql-cli> select 'a' = 'a' as t1, 'a' = 'b' as t2, 'a' = 'a   ' as t3, 'a' = ' 
>   a' as t4;
> ╔══╤═══╤══╤═══╗
> ║ T1   │ T2    │ T3   │ T4    ║
> ╠══╪═══╪══╪═══╣
> ║ true │ false │ true │ false ║
> ╚══╧═══╧══╧═══╝
> {code}
> Tests T1, T2, and T4 show correct behavior. But in test T2 we see that string 
> 'a' is considered being equal to string 'a   '  (same string but with 
> arbitrary amount of whitespaces at the end). This is incorrect behavior.
> This issue may have the same nature as IGNITE-17996, but it's just a 
> hypothesis.



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

[jira] [Commented] (IGNITE-21662) Sql: Data may be unavailable after creation of index

2024-03-15 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin commented on IGNITE-21662:
-

Looks like it's working now. Thank you!

> Sql: Data may be unavailable after creation of index
> 
>
> Key: IGNITE-21662
> URL: https://issues.apache.org/jira/browse/IGNITE-21662
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Assignee: Konstantin Orlov
>Priority: Major
>  Labels: ignite-3, sql
>
> Steps to reproduce:
> {code:sql}
> create table index_test_table_2(id INTEGER not null, field_1 TINYINT not 
> null, field_2 SMALLINT not null, field_3 INTEGER not null, field_4 FLOAT not 
> null, field_5 VARCHAR(50) not null, primary key (id));
> create index index_test_index_2_1 on index_test_table_2 using TREE (field_2, 
> field_3, field_5);
> insert into index_test_table_2(...)
> -- try to select one of inserted values
> select * from index_test_table_2 where  WHERE field_2 = .. AND field_3 = .. 
> AND field_5 = '..';
> {code}
> Expected result: a row is selected.
> Actual result: no rows are selected.
> The issue is flaky and sometimes is masked by IGNITE-19976.



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

[jira] [Resolved] (IGNITE-19461) The composite index is used when single column index expected to be used

2024-03-15 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin resolved IGNITE-19461.
-
Release Note: Cannot reproduce on fresh AI3.
  Resolution: Cannot Reproduce

> The composite index is used when single column index expected to be used
> 
>
> Key: IGNITE-19461
> URL: https://issues.apache.org/jira/browse/IGNITE-19461
> Project: Ignite
>  Issue Type: Bug
>  Components: jdbc, sql, thin client
>Reporter: Igor
>Priority: Minor
>  Labels: ignite-3
>
> h1. Steps to reproduce:
> 1. Create table.
> {code:java}
> CREATE TABLE index_test_table_5(id INT PRIMARY KEY, field_1 TINYINT, field_2 
> SMALLINT, field_3 INT, field_4 FLOAT, field_5 VARCHAR){code}
> 2. Create index:
> {code:java}
> CREATE INDEX index_test_index_5_1 ON index_test_table_5(field_2){code}
> 3. Create composite index:
> {code:java}
> CREATE INDEX index_test_index_5_2 ON index_test_table_5(field_2, field_3, 
> field_5){code}
> 4. Insert some rows.
> 5. Explain plan for query with filter by column contained in both indexes:
> {code:java}
> EXPLAIN PLAN FOR SELECT * FROM index_test_table_5 WHERE field_2 = 50{code}
> h1. Expected result:
> The index for single column is used (index_test_index_5_1)
> h1. Actual result:
> Randonly can be used either single column index (index_test_index_5_1) or 
> composite index (index_test_index_5_2).



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

[jira] [Created] (IGNITE-21662) Sql: Data may be unavailable after creation of index

2024-03-04 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-21662:
---

 Summary: Sql: Data may be unavailable after creation of index
 Key: IGNITE-21662
 URL: https://issues.apache.org/jira/browse/IGNITE-21662
 Project: Ignite
  Issue Type: Bug
Affects Versions: 3.0.0-beta2
Reporter: Andrey Khitrin


Steps to reproduce:

{code:sql}
create table index_test_table_2(id INTEGER not null, field_1 TINYINT not null, 
field_2 SMALLINT not null, field_3 INTEGER not null, field_4 FLOAT not null, 
field_5 VARCHAR(50) not null, primary key (id));
create index index_test_index_2_1 on index_test_table_2 using TREE (field_2, 
field_3, field_5);
insert into index_test_table_2(...)
-- try to select one of inserted values
select * from index_test_table_2 where  WHERE field_2 = .. AND field_3 = .. AND 
field_5 = '..';
{code}

Expected result: a row is selected.
Actual result: no rows are selected.

The issue is flaky and sometimes is masked by IGNITE-19976.



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

[jira] [Updated] (IGNITE-19976) Sql: ClassCastException when trying to select from indexed smallint column

2024-03-04 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin updated IGNITE-19976:

Affects Version/s: 3.0.0-beta2

> Sql: ClassCastException when trying to select from indexed smallint column
> --
>
> Key: IGNITE-19976
> URL: https://issues.apache.org/jira/browse/IGNITE-19976
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-beta1, 3.0.0-beta2
>Reporter: Andrey Khitrin
>Priority: Major
>  Labels: ignite-3, sql
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Steps to reproduce:
> {code:sql}
> sql-cli> create table tt(id INTEGER not null, field_1 TINYINT, field_2 
> SMALLINT, primary key (id));
> Updated 0 rows.
> sql-cli> SELECT * FROM tt WHERE field_2 = 50;
> ╔╤═╤═╗
> ║ ID │ FIELD_1 │ FIELD_2 ║
> ╠╧═╧═╣
> ║ (empty)║
> ╚╝
> -- select over field_2 works fine until we create an index on it!
> sql-cli> CREATE INDEX tt_idx ON tt (field_2);
> Updated 0 rows.
> sql-cli> SELECT * FROM tt WHERE field_2 = 50;
> SQL query execution error
> Exception while executing query [query=SELECT * FROM tt WHERE field_2 = 50;]. 
> Error message:Query remote fragment execution failed: nodeName=defaultNode, 
> queryId=15a68600-41bc-46c5-b20d-7a96aad15477, fragmentId=4, 
> originalMessage=class java.lang.Integer cannot be cast to class 
> java.lang.Short (java.lang.Integer and java.lang.Short are in module 
> java.base of loader 'bootstrap')
> {code}
> This doesn't look good. A created index must not cause casting exception.
> Reproduced on commit `fef7a24c2a029cac720d2fea3815c2a70a86b72f` (2023-07-12)



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

[jira] [Created] (IGNITE-21619) "Failed to get the primary replica" after massive data insert and node restart

2024-02-27 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-21619:
---

 Summary: "Failed to get the primary replica" after massive data 
insert and node restart
 Key: IGNITE-21619
 URL: https://issues.apache.org/jira/browse/IGNITE-21619
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 3.0.0-beta2
Reporter: Andrey Khitrin
 Attachments: ignite-config.conf, ignite3db-0.log

Steps to reproduce:

1. Start a 1-node cluster.
2 Create several tables (5, for example) in aipersist zone.
3. Fill these tables with some data (1000 rows each, for example).
4. Verify that data is accessible via SQL.
5. Restart a node.
6. Try to fetch the same data again.

Expected result: we could fetch data.

Actual result: data is inaccessible.

Trace on the client side:
{code}
java.sql.SQLException: Failed to get the primary replica 
[tablePartitionId=6_part_1]
at 
org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
at 
org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:154)
at 
org.apache.ignite.internal.jdbc.JdbcStatement.executeQuery(JdbcStatement.java:111)
   ...
{code}

Trace in node log (attached):
{code}
2024-02-28 12:36:34:807 +0500 
[INFO][%ClusterFailoverTest_cluster_0%sql-execution-pool-0][JdbcQueryEventHandlerImpl]
 Exception while executing query [query=select sum(k1) from failoverTest00]
org.apache.ignite.sql.SqlException: IGN-CMN-65535 
TraceId:8d366905-a4bb-4333-b0b3-c647a1cf943f Failed to get the primary replica 
[tablePartitionId=6_part_1]
at 
org.apache.ignite.internal.lang.SqlExceptionMapperUtil.mapToPublicSqlException(SqlExceptionMapperUtil.java:61)
at 
org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.wrapIfNecessary(AsyncSqlCursorImpl.java:180)
at 
org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.handleError(AsyncSqlCursorImpl.java:157)
at 
org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$2(AsyncSqlCursorImpl.java:96)
at 
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at 
java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
at 
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at 
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at 
org.apache.ignite.internal.sql.engine.exec.ExecutionServiceImpl$DistributedQueryManager.lambda$execute$18(ExecutionServiceImpl.java:864)
at 
java.base/java.util.concurrent.CompletableFuture.uniWhenComplete(CompletableFuture.java:859)
at 
java.base/java.util.concurrent.CompletableFuture$UniWhenComplete.tryFire(CompletableFuture.java:837)
at 
java.base/java.util.concurrent.CompletableFuture$Completion.run(CompletableFuture.java:478)
at 
org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:83)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: org.apache.ignite.lang.IgniteException: IGN-CMN-65535 
TraceId:8d366905-a4bb-4333-b0b3-c647a1cf943f Failed to get the primary replica 
[tablePartitionId=6_part_1]
at 
org.apache.ignite.internal.lang.IgniteExceptionMapperUtil.mapToPublicException(IgniteExceptionMapperUtil.java:117)
at 
org.apache.ignite.internal.lang.SqlExceptionMapperUtil.mapToPublicSqlException(SqlExceptionMapperUtil.java:51)
... 15 more
Caused by: org.apache.ignite.internal.lang.IgniteInternalException: 
IGN-PLACEMENTDRIVER-1 TraceId:8d366905-a4bb-4333-b0b3-c647a1cf943f Failed to 
get the primary replica [tablePartitionId=6_part_1]
at 
org.apache.ignite.internal.util.ExceptionUtils.lambda$withCause$1(ExceptionUtils.java:384)
at 
org.apache.ignite.internal.util.ExceptionUtils.withCauseInternal(ExceptionUtils.java:446)
at 
org.apache.ignite.internal.util.ExceptionUtils.withCause(ExceptionUtils.java:384)
at 
org.apache.ignite.internal.sql.engine.SqlQueryProcessor.lambda$primaryReplicas$2(SqlQueryProcessor.java:402)
at 
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
at 
java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
at 
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at 
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at

[jira] [Updated] (IGNITE-18166) SQL: LIKE predicate is not supported for BINARY data

2024-02-05 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin updated IGNITE-18166:

Description: 
A 'T022' feature in SQL standard allows to use LIKE predicate for BINARY data. 
Unfortunately, it is not supported in AI3 beta1:
{code:sql}
create table tmp_table_binary (key_field INT PRIMARY KEY,field1 BINARY);
INSERT INTO tmp_table_binary (key_field, field1) values(1, x'00ffaa');
INSERT INTO tmp_table_binary (key_field, field1) values(2, x'ffcc');
select * from tmp_table_binary where field1 like '%ff%'; -- 
expected to return both rows
select * from tmp_table_binary where field1 like '_f%';  -- 
expected to return 'ffcc'
select * from tmp_table_binary where field1 like '_fc_'; -- 
expected to return 'ffcc'
{code}
Instead of returning data, all queries show the following error:
{code:java}
Error: Exception while executing query [query=select * from tmp_table_binary 
where field1 like '%ff%']. Error message:From line 1, column 38 to line 1, 
column 55: Cannot apply 'LIKE' to arguments of type 'LIKE(, 
)'. Supported form(s): 'LIKE(, , )' 
(state=5,code=0)
java.sql.SQLException: Exception while executing query [query=select * from 
tmp_table_binary where field1 like '%ff%']. Error message:From line 1, column 
38 to line 1, column 55: Cannot apply 'LIKE' to arguments of type 
'LIKE(, )'. Supported form(s): 'LIKE(, , 
)'
at 
org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
at 
org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:148)
at 
org.apache.ignite.internal.jdbc.JdbcStatement.execute(JdbcStatement.java:341)
...
{code}

  was:
A 'T022' feature in SQL standard allows to use LIKE predicate for BINARY data. 
Unfortunately, it is not supported in AI3 beta1:
{code:sql}
create table tmp_table_binary (key_field INT PRIMARY KEY,field1 BINARY);
INSERT INTO tmp_table_binary (key_field, field1) values(1, '00ffaa');
INSERT INTO tmp_table_binary (key_field, field1) values(2, 'ffcc');
select * from tmp_table_binary where field1 like '%ff%'; -- 
expected to return both rows
select * from tmp_table_binary where field1 like '_f%';  -- 
expected to return 'ffcc'
select * from tmp_table_binary where field1 like '_fc_'; -- 
expected to return 'ffcc'
{code}
Instead of returning data, all queries show the following error:
{code:java}
Error: Exception while executing query [query=select * from tmp_table_binary 
where field1 like '%ff%']. Error message:From line 1, column 38 to line 1, 
column 55: Cannot apply 'LIKE' to arguments of type 'LIKE(, 
)'. Supported form(s): 'LIKE(, , )' 
(state=5,code=0)
java.sql.SQLException: Exception while executing query [query=select * from 
tmp_table_binary where field1 like '%ff%']. Error message:From line 1, column 
38 to line 1, column 55: Cannot apply 'LIKE' to arguments of type 
'LIKE(, )'. Supported form(s): 'LIKE(, , 
)'
at 
org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
at 
org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:148)
at 
org.apache.ignite.internal.jdbc.JdbcStatement.execute(JdbcStatement.java:341)
...
{code}


> SQL: LIKE predicate is not supported for BINARY data
> 
>
> Key: IGNITE-18166
> URL: https://issues.apache.org/jira/browse/IGNITE-18166
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
>  Labels: calcite, calcite2-required, calcite3-required, ignite-3
>
> A 'T022' feature in SQL standard allows to use LIKE predicate for BINARY 
> data. Unfortunately, it is not supported in AI3 beta1:
> {code:sql}
> create table tmp_table_binary (key_field INT PRIMARY KEY,field1 BINARY);
> INSERT INTO tmp_table_binary (key_field, field1) values(1, x'00ffaa');
> INSERT INTO tmp_table_binary (key_field, field1) values(2, x'ffcc');
> select * from tmp_table_binary where field1 like '%ff%'; -- 
> expected to return both rows
> select * from tmp_table_binary where field1 like '_f%';  -- 
> expected to return 'ffcc'
> select * from tmp_table_binary where field1 like '_fc_'; -- 
> expected to return 'ffcc'
> {code}
> Instead of returning data, all queries show the following error:
> {code:java}
> Error: Exception while executing query [query=select * from tmp_table_binary 
> where field1 like '%ff%']. Error message:From line 1, column 38 to line 1, 
> column 55: Cannot apply 'LIKE' to arguments of type 'LIKE(, 
> )'. Supported form(s): 'LIKE(, , )' 
>

[jira] [Resolved] (IGNITE-18175) SQL: value out of type bounds is converted into 0 during implicit casting

2024-02-05 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin resolved IGNITE-18175.
-
Resolution: Fixed

> SQL: value out of type bounds is converted into 0 during implicit casting
> -
>
> Key: IGNITE-18175
> URL: https://issues.apache.org/jira/browse/IGNITE-18175
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
>  Labels: calcite2-required, calcite3-required, ignite-3
>
> A simple scenario:
> {code:sql}
> create table test_e011_INTEGER_from (key_field INT PRIMARY KEY, field1 
> INTEGER);
> insert into test_e011_INTEGER_from (key_field, field1) values (1, 
> -2147483648);
> create table test_e011_SMALLINT (key_field INT PRIMARY KEY, field1_SMALLINT 
> SMALLINT);
> insert into test_e011_SMALLINT (key_field, field1_SMALLINT) values (1, 
> (select field1 from test_e011_INTEGER_from where key_field=1));
> select * from test_e011_SMALLINT;
> {code}
> I expect it either  to return '1, null' (like in postrgres or sqlite3) or to 
> raise an error on insert (like in GG8) as value of -2147483648 is out of 
> bounds for SMALLINT data type.
> Instead, '1, 0' is stored within test_e011_SMALLINT table and returned from 
> select. In other words, -2147483648 was converted into 0. Such behavior seems 
> as incorrect.



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

[jira] [Commented] (IGNITE-18175) SQL: value out of type bounds is converted into 0 during implicit casting

2024-02-05 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin commented on IGNITE-18175:
-

In the recent AI3:
{code:sql}
sql-cli>  insert into test_e011_SMALLINT (key_field, field1_SMALLINT) values 
(1, (select field1 from test_e011_INTEGER_from where key_field=1));
SQL query execution error
SMALLINT out of range
{code}
Consider it as fixed.

> SQL: value out of type bounds is converted into 0 during implicit casting
> -
>
> Key: IGNITE-18175
> URL: https://issues.apache.org/jira/browse/IGNITE-18175
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
>  Labels: calcite2-required, calcite3-required, ignite-3
>
> A simple scenario:
> {code:sql}
> create table test_e011_INTEGER_from (key_field INT PRIMARY KEY, field1 
> INTEGER);
> insert into test_e011_INTEGER_from (key_field, field1) values (1, 
> -2147483648);
> create table test_e011_SMALLINT (key_field INT PRIMARY KEY, field1_SMALLINT 
> SMALLINT);
> insert into test_e011_SMALLINT (key_field, field1_SMALLINT) values (1, 
> (select field1 from test_e011_INTEGER_from where key_field=1));
> select * from test_e011_SMALLINT;
> {code}
> I expect it either  to return '1, null' (like in postrgres or sqlite3) or to 
> raise an error on insert (like in GG8) as value of -2147483648 is out of 
> bounds for SMALLINT data type.
> Instead, '1, 0' is stored within test_e011_SMALLINT table and returned from 
> select. In other words, -2147483648 was converted into 0. Such behavior seems 
> as incorrect.



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

[jira] [Updated] (IGNITE-19608) Startup errors are ignored in ignite3db script

2024-01-25 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin updated IGNITE-19608:

Labels: cli ignite-3  (was: ignite-3)

> Startup errors are ignored in ignite3db script
> --
>
> Key: IGNITE-19608
> URL: https://issues.apache.org/jira/browse/IGNITE-19608
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 3.0.0-beta1, 3.0.0-beta2
>Reporter: Andrey Khitrin
>Priority: Major
>  Labels: cli, ignite-3
>
> Ignite3 node is started by `bin/ignite3db` shell script. Unfortunately, this 
> script follows some shell scripting bad practices that makes troubleshooting 
> harder when something goes wrong.
> Particullary, there are following issues:
> 1. No guarding bash options (like `nounset`, `errexit`, or `pipefile`) is set.
> 2. When starting Java application, its stderr and stdout are redirected into 
> `/dev/null`.
> {code:bash}
>   CMD="${JAVA_CMD_WITH_ARGS} ${APPLICATION_ARGS}"
>   $CMD >>/dev/null 2>&1 ${IGNITE_HOME}/pid
> {code}
> Just for comparison: [control.sh in 
> AI2|https://github.com/apache/ignite/blob/master/bin/control.sh] do not 
> suffer from such behavior. This should be fixed in AI3 too.



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

[jira] [Updated] (IGNITE-19608) Startup errors are ignored in ignite3db script

2024-01-25 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin updated IGNITE-19608:

Affects Version/s: 3.0.0-beta2

> Startup errors are ignored in ignite3db script
> --
>
> Key: IGNITE-19608
> URL: https://issues.apache.org/jira/browse/IGNITE-19608
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 3.0.0-beta1, 3.0.0-beta2
>Reporter: Andrey Khitrin
>Priority: Major
>  Labels: ignite-3
>
> Ignite3 node is started by `bin/ignite3db` shell script. Unfortunately, this 
> script follows some shell scripting bad practices that makes troubleshooting 
> harder when something goes wrong.
> Particullary, there are following issues:
> 1. No guarding bash options (like `nounset`, `errexit`, or `pipefile`) is set.
> 2. When starting Java application, its stderr and stdout are redirected into 
> `/dev/null`.
> {code:bash}
>   CMD="${JAVA_CMD_WITH_ARGS} ${APPLICATION_ARGS}"
>   $CMD >>/dev/null 2>&1 ${IGNITE_HOME}/pid
> {code}
> Just for comparison: [control.sh in 
> AI2|https://github.com/apache/ignite/blob/master/bin/control.sh] do not 
> suffer from such behavior. This should be fixed in AI3 too.



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

[jira] [Commented] (IGNITE-21143) SQL: Backslash cannot be escaped in LIKE ESCAPE operator

2023-12-28 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin commented on IGNITE-21143:
-

Good, thank you!

> SQL: Backslash cannot be escaped in LIKE ESCAPE operator
> 
>
> Key: IGNITE-21143
> URL: https://issues.apache.org/jira/browse/IGNITE-21143
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Assignee: Evgeny Stanilovsky
>Priority: Major
>  Labels: ignite-3, sql
>
> When using custom escape symbol in LIKE operator, we cannot escape backslash. 
> A error is raised here:
> {code:sql}
> sql-cli> select 'Dev_ops' like 'Dev#_ops' escape '#';  -- works as 
> expected
> ╔═╗
> ║ EXPR$0  ║
> ╠═╣
> ║ true║
> ╚═╝
> sql-cli> select 'Dev\ops' like 'Dev#\ops' escape '#';  -- doesn't work
> SQL query execution error
> Invalid escape sequence 'Dev#\ops', 3
> {code}
> In AI2 or some other DBMS, the latter query works without error:
> {code}
> select 'Dev\ops' like 'Dev#\ops' escape '#' -> true
> {code}



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

[jira] [Created] (IGNITE-21143) SQL: Backslash cannot be escaped in LIKE ESCAPE operator

2023-12-22 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-21143:
---

 Summary: SQL: Backslash cannot be escaped in LIKE ESCAPE operator
 Key: IGNITE-21143
 URL: https://issues.apache.org/jira/browse/IGNITE-21143
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 3.0.0-beta2
Reporter: Andrey Khitrin


When using custom escape symbol in LIKE operator, we cannot escape backslash. A 
error is raised here:

{code:sql}
sql-cli> select 'Dev_ops' like 'Dev#_ops' escape '#';  -- works as 
expected
╔═╗
║ EXPR$0  ║
╠═╣
║ true║
╚═╝

sql-cli> select 'Dev\ops' like 'Dev#\ops' escape '#';  -- doesn't work
SQL query execution error
Invalid escape sequence 'Dev#\ops', 3
{code}

In AI2 or some other DBMS, the latter query works without error:
{code}
select 'Dev\ops' like 'Dev#\ops' escape '#' -> true
{code}



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

[jira] [Commented] (IGNITE-20834) SQL query may hang forerver after node restart

2023-12-22 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin commented on IGNITE-20834:
-

Fixed

> SQL query may hang forerver after node restart
> --
>
> Key: IGNITE-20834
> URL: https://issues.apache.org/jira/browse/IGNITE-20834
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Priority: Major
>  Labels: ignite-3, sql
>
> How to reproduce:
> 1. Start a 1-node cluster
> 2. Create several simple tables (usually 5-10 is enough to reproduce):
> {code:sql}
> create table failoverTest00(k1 INTEGER not null, k2 INTEGER not null, v1 
> VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null, primary key (k1, k2));
> create table failoverTest01(k1 INTEGER not null, k2 INTEGER not null, v1 
> VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null, primary key (k1, k2));
> ...
> {code}
> 3. Fill every table with 1000 rows.
> 4. Ensure that every table contains 1000 rows:
> {code:sql}
> SELECT COUNT(*) FROM failoverTest00;
> ...
> {code}
> 5. Restart node (kill a Java process and start node again).
> 6. Check all tables again.
> Expected behavior: after restart, all tables still contains the same data as 
> before.
> Actual behavior: cannot perform SQL query after restart. It hangs for a long 
> time. Ignite log is overwhelmed with "Primary replica expired" messages.
> This bug was first observed soon after fixes in 
> https://issues.apache.org/jira/browse/IGNITE-20116.



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

[jira] [Resolved] (IGNITE-20834) SQL query may hang forerver after node restart

2023-12-22 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin resolved IGNITE-20834.
-
Resolution: Fixed

> SQL query may hang forerver after node restart
> --
>
> Key: IGNITE-20834
> URL: https://issues.apache.org/jira/browse/IGNITE-20834
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Priority: Major
>  Labels: ignite-3, sql
>
> How to reproduce:
> 1. Start a 1-node cluster
> 2. Create several simple tables (usually 5-10 is enough to reproduce):
> {code:sql}
> create table failoverTest00(k1 INTEGER not null, k2 INTEGER not null, v1 
> VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null, primary key (k1, k2));
> create table failoverTest01(k1 INTEGER not null, k2 INTEGER not null, v1 
> VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null, primary key (k1, k2));
> ...
> {code}
> 3. Fill every table with 1000 rows.
> 4. Ensure that every table contains 1000 rows:
> {code:sql}
> SELECT COUNT(*) FROM failoverTest00;
> ...
> {code}
> 5. Restart node (kill a Java process and start node again).
> 6. Check all tables again.
> Expected behavior: after restart, all tables still contains the same data as 
> before.
> Actual behavior: cannot perform SQL query after restart. It hangs for a long 
> time. Ignite log is overwhelmed with "Primary replica expired" messages.
> This bug was first observed soon after fixes in 
> https://issues.apache.org/jira/browse/IGNITE-20116.



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

[jira] [Closed] (IGNITE-20834) SQL query may hang forerver after node restart

2023-12-22 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin closed IGNITE-20834.
---

> SQL query may hang forerver after node restart
> --
>
> Key: IGNITE-20834
> URL: https://issues.apache.org/jira/browse/IGNITE-20834
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Priority: Major
>  Labels: ignite-3, sql
>
> How to reproduce:
> 1. Start a 1-node cluster
> 2. Create several simple tables (usually 5-10 is enough to reproduce):
> {code:sql}
> create table failoverTest00(k1 INTEGER not null, k2 INTEGER not null, v1 
> VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null, primary key (k1, k2));
> create table failoverTest01(k1 INTEGER not null, k2 INTEGER not null, v1 
> VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null, primary key (k1, k2));
> ...
> {code}
> 3. Fill every table with 1000 rows.
> 4. Ensure that every table contains 1000 rows:
> {code:sql}
> SELECT COUNT(*) FROM failoverTest00;
> ...
> {code}
> 5. Restart node (kill a Java process and start node again).
> 6. Check all tables again.
> Expected behavior: after restart, all tables still contains the same data as 
> before.
> Actual behavior: cannot perform SQL query after restart. It hangs for a long 
> time. Ignite log is overwhelmed with "Primary replica expired" messages.
> This bug was first observed soon after fixes in 
> https://issues.apache.org/jira/browse/IGNITE-20116.



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

[jira] [Created] (IGNITE-21136) SQL: implement functions for date/time formatting

2023-12-22 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-21136:
---

 Summary: SQL: implement functions for date/time formatting
 Key: IGNITE-21136
 URL: https://issues.apache.org/jira/browse/IGNITE-21136
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Affects Versions: 3.0.0-beta2
Reporter: Andrey Khitrin


SQL functions for date/time formatting are useful in many cases. In AI2, we 
have an universal FORMATDATETIME function for such purposes:

{code:sql}
SELECT FORMATDATETIME(CREATION_DATE, '-MM') AS CREATION_MONTH FROM ...
{code}

Please imlpement simliar functions in AI3.



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

[jira] [Updated] (IGNITE-21134) Sql. UPPER, LOWER and SUBSTRING functions must support NULL values

2023-12-21 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin updated IGNITE-21134:

Summary: Sql. UPPER, LOWER and SUBSTRING functions must support NULL values 
 (was: Sql. UPPER and LOWER functions must support NULL values)

> Sql. UPPER, LOWER and SUBSTRING functions must support NULL values
> --
>
> Key: IGNITE-21134
> URL: https://issues.apache.org/jira/browse/IGNITE-21134
> Project: Ignite
>  Issue Type: Bug
>  Components: clients, sql
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Priority: Major
>  Labels: ignite-3
>
> As described in ANSI99 specification, functions UPPER and LOWER must return 
> NULL values for NULL argument:
>  
> ??5) If  is specified, then:??
> ?? .. b) if S is the null value, then the result of the  is the null 
> value.??
> In the recent AI3 (commit c2ac5850973ae3bfd44b06fc6e3b5880f9f292f1) an error 
> is shown instead:
> {code:sql}
> sql-cli> SELECT UPPER(NULL);
> Unknown error
> Unsupported Column type NULL
> sql-cli> SELECT LOWER(NULL);
> Unknown error
> Unsupported Column type NULL
> {code}
> {*}NOTE{*}: Most probably, it may be caused by client module, not sql module 
> because a text of error is located in client-common module:
> {code:java}
> $ grep -r 'Unsupported Column type' modules/*/src/main
> modules/client-common/src/main/java/org/apache/ignite/internal/jdbc/JdbcConverterUtils.java:
> throw new IllegalArgumentException("Unsupported Column type " 
> + columnType);
> {code}
> And when I add the following assertion to some test in ItFunctionsTest, it 
> passes:
> {code:java}
> assertQuery("SELECT LOWER(NULL)").returns(null).check();
> {code}
> Previous AI3 versions allowed using NULL values in UPPER and LOWER functions, 
> hence it's a degradation.



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

[jira] [Updated] (IGNITE-21134) Sql. UPPER, LOWER and SUBSTRING functions must support NULL values

2023-12-21 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin updated IGNITE-21134:

Description: 
As described in ANSI99 specification, functions UPPER and LOWER must return 
NULL values for NULL argument:

 

??5) If  is specified, then:??

?? .. b) if S is the null value, then the result of the  is the null 
value.??

In the recent AI3 (commit c2ac5850973ae3bfd44b06fc6e3b5880f9f292f1) an error is 
shown instead:
{code:sql}
sql-cli> SELECT UPPER(NULL);
Unknown error
Unsupported Column type NULL

sql-cli> SELECT LOWER(NULL);
Unknown error
Unsupported Column type NULL

sql-cli> SELECT SUBSTRING(NULL FROM 1 FOR 2);
Unknown error
Unsupported Column type NULL{code}
{*}NOTE{*}: Most probably, it may be caused by client module, not sql module 
because a text of error is located in client-common module:
{code:java}
$ grep -r 'Unsupported Column type' modules/*/src/main

modules/client-common/src/main/java/org/apache/ignite/internal/jdbc/JdbcConverterUtils.java:
throw new IllegalArgumentException("Unsupported Column type " + 
columnType);
{code}
And when I add the following assertion to some test in ItFunctionsTest, it 
passes:
{code:java}
assertQuery("SELECT LOWER(NULL)").returns(null).check();
{code}
Previous AI3 versions allowed using NULL values in UPPER and LOWER functions, 
hence it's a degradation.

  was:
As described in ANSI99 specification, functions UPPER and LOWER must return 
NULL values for NULL argument:

 

??5) If  is specified, then:??

?? .. b) if S is the null value, then the result of the  is the null 
value.??

In the recent AI3 (commit c2ac5850973ae3bfd44b06fc6e3b5880f9f292f1) an error is 
shown instead:
{code:sql}
sql-cli> SELECT UPPER(NULL);
Unknown error
Unsupported Column type NULL

sql-cli> SELECT LOWER(NULL);
Unknown error
Unsupported Column type NULL
{code}
{*}NOTE{*}: Most probably, it may be caused by client module, not sql module 
because a text of error is located in client-common module:
{code:java}
$ grep -r 'Unsupported Column type' modules/*/src/main

modules/client-common/src/main/java/org/apache/ignite/internal/jdbc/JdbcConverterUtils.java:
throw new IllegalArgumentException("Unsupported Column type " + 
columnType);
{code}
And when I add the following assertion to some test in ItFunctionsTest, it 
passes:
{code:java}
assertQuery("SELECT LOWER(NULL)").returns(null).check();
{code}
Previous AI3 versions allowed using NULL values in UPPER and LOWER functions, 
hence it's a degradation.


> Sql. UPPER, LOWER and SUBSTRING functions must support NULL values
> --
>
> Key: IGNITE-21134
> URL: https://issues.apache.org/jira/browse/IGNITE-21134
> Project: Ignite
>  Issue Type: Bug
>  Components: clients, sql
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Priority: Major
>  Labels: ignite-3
>
> As described in ANSI99 specification, functions UPPER and LOWER must return 
> NULL values for NULL argument:
>  
> ??5) If  is specified, then:??
> ?? .. b) if S is the null value, then the result of the  is the null 
> value.??
> In the recent AI3 (commit c2ac5850973ae3bfd44b06fc6e3b5880f9f292f1) an error 
> is shown instead:
> {code:sql}
> sql-cli> SELECT UPPER(NULL);
> Unknown error
> Unsupported Column type NULL
> sql-cli> SELECT LOWER(NULL);
> Unknown error
> Unsupported Column type NULL
> sql-cli> SELECT SUBSTRING(NULL FROM 1 FOR 2);
> Unknown error
> Unsupported Column type NULL{code}
> {*}NOTE{*}: Most probably, it may be caused by client module, not sql module 
> because a text of error is located in client-common module:
> {code:java}
> $ grep -r 'Unsupported Column type' modules/*/src/main
> modules/client-common/src/main/java/org/apache/ignite/internal/jdbc/JdbcConverterUtils.java:
> throw new IllegalArgumentException("Unsupported Column type " 
> + columnType);
> {code}
> And when I add the following assertion to some test in ItFunctionsTest, it 
> passes:
> {code:java}
> assertQuery("SELECT LOWER(NULL)").returns(null).check();
> {code}
> Previous AI3 versions allowed using NULL values in UPPER and LOWER functions, 
> hence it's a degradation.



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

[jira] [Created] (IGNITE-21134) Sql. UPPER and LOWER functions must support NULL values

2023-12-21 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-21134:
---

 Summary: Sql. UPPER and LOWER functions must support NULL values
 Key: IGNITE-21134
 URL: https://issues.apache.org/jira/browse/IGNITE-21134
 Project: Ignite
  Issue Type: Bug
  Components: clients, sql
Affects Versions: 3.0.0-beta2
Reporter: Andrey Khitrin


As described in ANSI99 specification, functions UPPER and LOWER must return 
NULL values for NULL argument:

 

??5) If  is specified, then:??

?? .. b) if S is the null value, then the result of the  is the null 
value.??

In the recent AI3 (commit c2ac5850973ae3bfd44b06fc6e3b5880f9f292f1) an error is 
shown instead:
{code:sql}
sql-cli> SELECT UPPER(NULL);
Unknown error
Unsupported Column type NULL

sql-cli> SELECT LOWER(NULL);
Unknown error
Unsupported Column type NULL
{code}
{*}NOTE{*}: Most probably, it may be caused by client module, not sql module 
because a text of error is located in client-common module:
{code:java}
$ grep -r 'Unsupported Column type' modules/*/src/main

modules/client-common/src/main/java/org/apache/ignite/internal/jdbc/JdbcConverterUtils.java:
throw new IllegalArgumentException("Unsupported Column type " + 
columnType);
{code}
And when I add the following assertion to some test in ItFunctionsTest, it 
passes:
{code:java}
assertQuery("SELECT LOWER(NULL)").returns(null).check();
{code}
Previous AI3 versions allowed using NULL values in UPPER and LOWER functions, 
hence it's a degradation.



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

[jira] [Updated] (IGNITE-21090) "IllegalReferenceCountException: refCnt: 0" in SQL query

2023-12-15 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin updated IGNITE-21090:

Description: 
We have a simple automated test that creates 1000 tables of the same structure 
and insert few rows into each one. Recently, it started to fail after creating 
several tens of tables. An exception is always the same:
{code:java}
12:05:40.687 [junit-timeout-thread-51] INFO  o.g.q.s.g.TableGeneratorHelper - 
Update: create table test_table_49(id INTEGER not null, column_1 VARCHAR(50) 
not null, column_2 VARCHAR(50) not null, column_3 VARCHAR(50) not null, 
column_4 VARCHAR(50) not null, primary key (id))
Dec 15, 2023 12:05:42 PM org.apache.ignite.internal.logger.IgniteLogger 
logInternal
INFO: Partition assignment change notification received 
[remoteAddress=localhost:10800]
12:05:42.699 [junit-timeout-thread-51] INFO  o.g.q.s.g.TableGeneratorHelper - 
Creation of table: test_table_49 took 2012 ms
12:05:42.700 [junit-timeout-thread-1] INFO  
o.g.a.tests.TablesAmountCapacityTest - Creation of 50 tables took 101686 ms
Dec 15, 2023 12:05:42 PM org.apache.ignite.internal.logger.IgniteLogger 
logInternal
INFO: Partition assignment change notification received 
[remoteAddress=localhost:10800]
12:05:45.539 [junit-timeout-thread-1] INFO  
o.g.a.tests.TablesAmountCapacityTest - Table test_table_0 contains 1 rows
12:05:45.591 [junit-timeout-thread-1] INFO  
o.g.a.tests.TablesAmountCapacityTest - Table test_table_1 contains 1 rows
Dec 15, 2023 12:05:45 PM org.apache.ignite.internal.logger.IgniteLogger error
SEVERE: Failed to deserialize server response [remoteAddress=localhost:10800]: 
refCnt: 0
io.netty.util.IllegalReferenceCountException: refCnt: 0
at 
io.netty.buffer.AbstractByteBuf.ensureAccessible(AbstractByteBuf.java:1454)
at 
io.netty.buffer.AbstractByteBuf.checkReadableBytes0(AbstractByteBuf.java:1440)
at io.netty.buffer.AbstractByteBuf.readByte(AbstractByteBuf.java:730)
at 
org.apache.ignite.internal.client.proto.ClientMessageUnpacker.unpackBoolean(ClientMessageUnpacker.java:209)
at 
org.apache.ignite.internal.jdbc.proto.event.Response.readBinary(Response.java:81)
at 
org.apache.ignite.internal.jdbc.JdbcClientQueryCursorHandler.lambda$closeAsync$3(JdbcClientQueryCursorHandler.java:65)
at 
org.apache.ignite.internal.client.TcpClientChannel.lambda$receiveAsync$5(TcpClientChannel.java:368)
at 
java.base/java.util.concurrent.CompletableFuture.uniApplyNow(CompletableFuture.java:680)
at 
java.base/java.util.concurrent.CompletableFuture.uniApplyStage(CompletableFuture.java:658)
at 
java.base/java.util.concurrent.CompletableFuture.thenApply(CompletableFuture.java:2094)
at 
org.apache.ignite.internal.client.TcpClientChannel.receiveAsync(TcpClientChannel.java:362)
at 
org.apache.ignite.internal.client.TcpClientChannel.serviceAsync(TcpClientChannel.java:283)
at 
org.apache.ignite.internal.client.ClientChannel.serviceAsync(ClientChannel.java:59)
at 
org.apache.ignite.internal.jdbc.JdbcClientQueryCursorHandler.closeAsync(JdbcClientQueryCursorHandler.java:62)
at 
org.apache.ignite.internal.jdbc.JdbcResultSet.close0(JdbcResultSet.java:287)
at 
org.apache.ignite.internal.jdbc.JdbcResultSet.close(JdbcResultSet.java:268)
at 
org.gridgain.ai3tests.tests.TablesAmountCapacityTest.assertTableContains1RowAndColumnsValuesAreCorrect(TablesAmountCapacityTest.java:172)
at 
org.gridgain.ai3tests.tests.TablesAmountCapacityTest.assertTablesAreValid(TablesAmountCapacityTest.java:285)
at 
org.gridgain.ai3tests.tests.TablesAmountCapacityTest.create1000EmptyTablesAmountOfColumnsEachAndMakeSimpleQueries(TablesAmountCapacityTest.java:102)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:728)
at 
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at 
io.qameta.allure.junit5.AllureJunit5.interceptTestTemplateMethod(AllureJunit5.java:59)
at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker$ReflectiveInterceptorCall.lambda$ofVoidMethod$0(InterceptingExecutableInvoker.java:103)
at 
org.junit.jupiter.engine.execution.InterceptingExecutableInvoker.lambda$invoke$0(InterceptingExecutableInvoker.java:93)
at

[jira] [Created] (IGNITE-21090) "IllegalReferenceCountException: refCnt: 0" in SQL query

2023-12-15 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-21090:
---

 Summary: "IllegalReferenceCountException: refCnt: 0" in SQL query
 Key: IGNITE-21090
 URL: https://issues.apache.org/jira/browse/IGNITE-21090
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 3.0.0-beta2
Reporter: Andrey Khitrin


We have a simple automated test that creates 1000 tables of the same structure 
and insert few rows into each one. Recently, it started to fail after creating 
several tens of tables. An exception is always the same:
{code:java}
12:05:40.687 [junit-timeout-thread-51] INFO  o.g.q.s.g.TableGeneratorHelper - 
Update: create table test_table_49(id INTEGER not null, column_1 VARCHAR(50) 
not null, column_2 VARCHAR(50) not null, column_3 VARCHAR(50) not null, 
column_4 VARCHAR(50) not null, primary key (id))
Dec 15, 2023 12:05:42 PM org.apache.ignite.internal.logger.IgniteLogger 
logInternal
INFO: Partition assignment change notification received 
[remoteAddress=localhost:10800]
12:05:42.699 [junit-timeout-thread-51] INFO  o.g.q.s.g.TableGeneratorHelper - 
Creation of table: test_table_49 took 2012 ms
12:05:42.700 [junit-timeout-thread-1] INFO  
o.g.a.tests.TablesAmountCapacityTest - Creation of 50 tables took 101686 ms
Dec 15, 2023 12:05:42 PM org.apache.ignite.internal.logger.IgniteLogger 
logInternal
INFO: Partition assignment change notification received 
[remoteAddress=localhost:10800]
12:05:45.539 [junit-timeout-thread-1] INFO  
o.g.a.tests.TablesAmountCapacityTest - Table test_table_0 contains 1 rows
12:05:45.591 [junit-timeout-thread-1] INFO  
o.g.a.tests.TablesAmountCapacityTest - Table test_table_1 contains 1 rows
Dec 15, 2023 12:05:45 PM org.apache.ignite.internal.logger.IgniteLogger error
SEVERE: Failed to deserialize server response [remoteAddress=localhost:10800]: 
refCnt: 0
io.netty.util.IllegalReferenceCountException: refCnt: 0
at 
io.netty.buffer.AbstractByteBuf.ensureAccessible(AbstractByteBuf.java:1454)
at 
io.netty.buffer.AbstractByteBuf.checkReadableBytes0(AbstractByteBuf.java:1440)
at io.netty.buffer.AbstractByteBuf.readByte(AbstractByteBuf.java:730)
at 
org.apache.ignite.internal.client.proto.ClientMessageUnpacker.unpackBoolean(ClientMessageUnpacker.java:209)
at 
org.apache.ignite.internal.jdbc.proto.event.Response.readBinary(Response.java:81)
at 
org.apache.ignite.internal.jdbc.JdbcClientQueryCursorHandler.lambda$closeAsync$3(JdbcClientQueryCursorHandler.java:65)
at 
org.apache.ignite.internal.client.TcpClientChannel.lambda$receiveAsync$5(TcpClientChannel.java:368)
at 
java.base/java.util.concurrent.CompletableFuture.uniApplyNow(CompletableFuture.java:680)
at 
java.base/java.util.concurrent.CompletableFuture.uniApplyStage(CompletableFuture.java:658)
at 
java.base/java.util.concurrent.CompletableFuture.thenApply(CompletableFuture.java:2094)
at 
org.apache.ignite.internal.client.TcpClientChannel.receiveAsync(TcpClientChannel.java:362)
at 
org.apache.ignite.internal.client.TcpClientChannel.serviceAsync(TcpClientChannel.java:283)
at 
org.apache.ignite.internal.client.ClientChannel.serviceAsync(ClientChannel.java:59)
at 
org.apache.ignite.internal.jdbc.JdbcClientQueryCursorHandler.closeAsync(JdbcClientQueryCursorHandler.java:62)
at 
org.apache.ignite.internal.jdbc.JdbcResultSet.close0(JdbcResultSet.java:287)
at 
org.apache.ignite.internal.jdbc.JdbcResultSet.close(JdbcResultSet.java:268)
at 
org.gridgain.ai3tests.tests.TablesAmountCapacityTest.assertTableContains1RowAndColumnsValuesAreCorrect(TablesAmountCapacityTest.java:172)
at 
org.gridgain.ai3tests.tests.TablesAmountCapacityTest.assertTablesAreValid(TablesAmountCapacityTest.java:285)
at 
org.gridgain.ai3tests.tests.TablesAmountCapacityTest.create1000EmptyTablesAmountOfColumnsEachAndMakeSimpleQueries(TablesAmountCapacityTest.java:102)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at 
java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:566)
at 
org.junit.platform.commons.util.ReflectionUtils.invokeMethod(ReflectionUtils.java:728)
at 
org.junit.jupiter.engine.execution.MethodInvocation.proceed(MethodInvocation.java:60)
at 
org.junit.jupiter.engine.execution.InvocationInterceptorChain$ValidatingInvocation.proceed(InvocationInterceptorChain.java:131)
at 
io.qameta.allure.junit5.AllureJunit5.interceptTestTemplateMethod(AllureJunit5.java:59)
at

[jira] [Updated] (IGNITE-20834) SQL query may hang forerver after node restart

2023-11-13 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin updated IGNITE-20834:

Labels: ignite-3 sql  (was: ignite-3)

> SQL query may hang forerver after node restart
> --
>
> Key: IGNITE-20834
> URL: https://issues.apache.org/jira/browse/IGNITE-20834
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Priority: Major
>  Labels: ignite-3, sql
>
> How to reproduce:
> 1. Start a 1-node cluster
> 2. Create several simple tables (usually 5-10 is enough to reproduce):
> {code:sql}
> create table failoverTest00(k1 INTEGER not null, k2 INTEGER not null, v1 
> VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null, primary key (k1, k2));
> create table failoverTest01(k1 INTEGER not null, k2 INTEGER not null, v1 
> VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null, primary key (k1, k2));
> ...
> {code}
> 3. Fill every table with 1000 rows.
> 4. Ensure that every table contains 1000 rows:
> {code:sql}
> SELECT COUNT(*) FROM failoverTest00;
> ...
> {code}
> 5. Restart node (kill a Java process and start node again).
> 6. Check all tables again.
> Expected behavior: after restart, all tables still contains the same data as 
> before.
> Actual behavior: cannot perform SQL query after restart. It hangs for a long 
> time. Ignite log is overwhelmed with "Primary replica expired" messages.
> This bug was first observed soon after fixes in 
> https://issues.apache.org/jira/browse/IGNITE-20116.



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

[jira] [Updated] (IGNITE-20834) SQL query may hang forerver after node restart

2023-11-13 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin updated IGNITE-20834:

Fix Version/s: (was: 3.0.0-beta2)
Affects Version/s: 3.0.0-beta2

> SQL query may hang forerver after node restart
> --
>
> Key: IGNITE-20834
> URL: https://issues.apache.org/jira/browse/IGNITE-20834
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 3.0.0-beta2
>Reporter: Andrey Khitrin
>Priority: Major
>  Labels: ignite-3
>
> How to reproduce:
> 1. Start a 1-node cluster
> 2. Create several simple tables (usually 5-10 is enough to reproduce):
> {code:sql}
> create table failoverTest00(k1 INTEGER not null, k2 INTEGER not null, v1 
> VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null, primary key (k1, k2));
> create table failoverTest01(k1 INTEGER not null, k2 INTEGER not null, v1 
> VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null, primary key (k1, k2));
> ...
> {code}
> 3. Fill every table with 1000 rows.
> 4. Ensure that every table contains 1000 rows:
> {code:sql}
> SELECT COUNT(*) FROM failoverTest00;
> ...
> {code}
> 5. Restart node (kill a Java process and start node again).
> 6. Check all tables again.
> Expected behavior: after restart, all tables still contains the same data as 
> before.
> Actual behavior: cannot perform SQL query after restart. It hangs for a long 
> time. Ignite log is overwhelmed with "Primary replica expired" messages.
> This bug was first observed soon after fixes in 
> https://issues.apache.org/jira/browse/IGNITE-20116.



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

[jira] [Updated] (IGNITE-20834) SQL query may hang forerver after node restart

2023-11-12 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin updated IGNITE-20834:

Description: 
How to reproduce:

1. Start a 1-node cluster
2. Create several simple tables (usually 5-10 is enough to reproduce):
{code:sql}
create table failoverTest00(k1 INTEGER not null, k2 INTEGER not null, v1 
VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null, primary key (k1, k2));
create table failoverTest01(k1 INTEGER not null, k2 INTEGER not null, v1 
VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null, primary key (k1, k2));
...
{code}
3. Fill every table with 1000 rows.
4. Ensure that every table contains 1000 rows:
{code:sql}
SELECT COUNT(*) FROM failoverTest00;
...
{code}
5. Restart node (kill a Java process and start node again).
6. Check all tables again.

Expected behavior: after restart, all tables still contains the same data as 
before.

Actual behavior: cannot perform SQL query after restart. It hangs for a long 
time. Ignite log is overwhelmed with "Primary replica expired" messages.

This bug was first observed soon after fixes in 
https://issues.apache.org/jira/browse/IGNITE-20116.

  was:
How to reproduce:

1. Start a 1-node cluster
2. Create several simple tables (usually 5 is enough to reproduce):
{code:sql}
create table failoverTest00(k1 INTEGER not null, k2 INTEGER not null, v1 
VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null, primary key (k1, k2));
create table failoverTest01(k1 INTEGER not null, k2 INTEGER not null, v1 
VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null, primary key (k1, k2));
...
{code}
3. Fill every table with 1000 rows.
4. Ensure that every table contains 1000 rows:
{code:sql}
SELECT COUNT(*) FROM failoverTest00;
...
{code}
5. Restart node (kill a Java process and start node again).
6. Check all tables again.

Expected behavior: after restart, all tables still contains the same data as 
before.

Actual behavior: for some tables, 1 or 2 rows may be missing, if we're fast 
enough on steps 3-4-5. Some contains 1000 rows, some contains 999 or 998.

This bug was first observed only near Sep 15, 2023. Most probably, it was 
introduced somewhere near that date. Probably, it's an another face of 
IGNITE-20425 (I'm not sure though). No errors in logs observed.

*UPD*: The problem is caused by 
https://issues.apache.org/jira/browse/IGNITE-20116, current issue will be 
solved once https://issues.apache.org/jira/browse/IGNITE-20116 will be done


> SQL query may hang forerver after node restart
> --
>
> Key: IGNITE-20834
> URL: https://issues.apache.org/jira/browse/IGNITE-20834
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey Khitrin
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> How to reproduce:
> 1. Start a 1-node cluster
> 2. Create several simple tables (usually 5-10 is enough to reproduce):
> {code:sql}
> create table failoverTest00(k1 INTEGER not null, k2 INTEGER not null, v1 
> VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null, primary key (k1, k2));
> create table failoverTest01(k1 INTEGER not null, k2 INTEGER not null, v1 
> VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null, primary key (k1, k2));
> ...
> {code}
> 3. Fill every table with 1000 rows.
> 4. Ensure that every table contains 1000 rows:
> {code:sql}
> SELECT COUNT(*) FROM failoverTest00;
> ...
> {code}
> 5. Restart node (kill a Java process and start node again).
> 6. Check all tables again.
> Expected behavior: after restart, all tables still contains the same data as 
> before.
> Actual behavior: cannot perform SQL query after restart. It hangs for a long 
> time. Ignite log is overwhelmed with "Primary replica expired" messages.
> This bug was first observed soon after fixes in 
> https://issues.apache.org/jira/browse/IGNITE-20116.



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

[jira] [Created] (IGNITE-20834) SQL query may hang forerver after node restart

2023-11-12 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-20834:
---

 Summary: SQL query may hang forerver after node restart
 Key: IGNITE-20834
 URL: https://issues.apache.org/jira/browse/IGNITE-20834
 Project: Ignite
  Issue Type: Bug
Reporter: Andrey Khitrin
 Fix For: 3.0.0-beta2


How to reproduce:

1. Start a 1-node cluster
2. Create several simple tables (usually 5 is enough to reproduce):
{code:sql}
create table failoverTest00(k1 INTEGER not null, k2 INTEGER not null, v1 
VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null, primary key (k1, k2));
create table failoverTest01(k1 INTEGER not null, k2 INTEGER not null, v1 
VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null, primary key (k1, k2));
...
{code}
3. Fill every table with 1000 rows.
4. Ensure that every table contains 1000 rows:
{code:sql}
SELECT COUNT(*) FROM failoverTest00;
...
{code}
5. Restart node (kill a Java process and start node again).
6. Check all tables again.

Expected behavior: after restart, all tables still contains the same data as 
before.

Actual behavior: for some tables, 1 or 2 rows may be missing, if we're fast 
enough on steps 3-4-5. Some contains 1000 rows, some contains 999 or 998.

This bug was first observed only near Sep 15, 2023. Most probably, it was 
introduced somewhere near that date. Probably, it's an another face of 
IGNITE-20425 (I'm not sure though). No errors in logs observed.

*UPD*: The problem is caused by 
https://issues.apache.org/jira/browse/IGNITE-20116, current issue will be 
solved once https://issues.apache.org/jira/browse/IGNITE-20116 will be done



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

[jira] [Closed] (IGNITE-20577) Partial data loss after node restart

2023-11-12 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin closed IGNITE-20577.
---

> Partial data loss after node restart
> 
>
> Key: IGNITE-20577
> URL: https://issues.apache.org/jira/browse/IGNITE-20577
> Project: Ignite
>  Issue Type: Bug
>Reporter: Andrey Khitrin
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> How to reproduce:
> 1. Start a 1-node cluster
> 2. Create several simple tables (usually 5 is enough to reproduce):
> {code:sql}
> create table failoverTest00(k1 INTEGER not null, k2 INTEGER not null, v1 
> VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null, primary key (k1, k2));
> create table failoverTest01(k1 INTEGER not null, k2 INTEGER not null, v1 
> VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null, primary key (k1, k2));
> ...
> {code}
> 3. Fill every table with 1000 rows.
> 4. Ensure that every table contains 1000 rows:
> {code:sql}
> SELECT COUNT(*) FROM failoverTest00;
> ...
> {code}
> 5. Restart node (kill a Java process and start node again).
> 6. Check all tables again.
> Expected behavior: after restart, all tables still contains the same data as 
> before.
> Actual behavior: for some tables, 1 or 2 rows may be missing, if we're fast 
> enough on steps 3-4-5. Some contains 1000 rows, some contains 999 or 998.
> This bug was first observed only near Sep 15, 2023. Most probably, it was 
> introduced somewhere near that date. Probably, it's an another face of 
> IGNITE-20425 (I'm not sure though). No errors in logs observed.
> *UPD*: The problem is caused by 
> https://issues.apache.org/jira/browse/IGNITE-20116, current issue will be 
> solved once https://issues.apache.org/jira/browse/IGNITE-20116 will be done



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

[jira] [Created] (IGNITE-20660) SQL: broken behavior of OCTET_LENGTH function

2023-10-16 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-20660:
---

 Summary: SQL: broken behavior of OCTET_LENGTH function
 Key: IGNITE-20660
 URL: https://issues.apache.org/jira/browse/IGNITE-20660
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 3.0.0-beta2
Reporter: Andrey Khitrin


Recently, `OCTET_LENGTH` function acted like a synonym for `LENGTH` function. 
But in the latest AI3 versions, it started to decline usual strings:
{code:sql}
sql-cli> select OCTET_LENGTH('Some Text');
SQL query execution error
Failed to validate query. From line 0, column 0 to line 1, column 31: Cast 
function cannot convert value of type CHAR(9) to type VARBINARY
{code}

Looks like it only accepts a very specific type of strings:
{code:sql}
sql-cli> select OCTET_LENGTH(x'0123');
╔═══╗
║ OCTET_LENGTH(X'0123') ║
╠═══╣
║ 2 ║
╚═══╝
{code}

But as it said in ANSI99 specification, this function must be able to work with 
any correct string.



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

[jira] [Created] (IGNITE-20649) SQL: class cast exception in EXCEPT SELECT with different column types

2023-10-13 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-20649:
---

 Summary: SQL: class cast exception in EXCEPT SELECT with different 
column types
 Key: IGNITE-20649
 URL: https://issues.apache.org/jira/browse/IGNITE-20649
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 3.0.0-beta2
Reporter: Andrey Khitrin


Steps to reproduce:

1. Create two tables, one with `INT` column and one with `NUMERIC`. Add some 
sample data into both.

{code:sql}
-- first table
drop table if exists tmp_table_age_name_wage;
create table tmp_table_age_name_wage (key_field INT PRIMARY KEY,AGE INT,field1 
VARCHAR,field2 INT);
insert into tmp_table_age_name_wage (key_field,AGE,field1,field2) values (1, 
42,'John',10);
insert into tmp_table_age_name_wage (key_field,AGE,field1,field2) values (2, 
43,'Jack',5);
-- second table
drop table if exists tmp_table_age_name_wage_2;
create table tmp_table_age_name_wage_2 (key_field INT PRIMARY KEY,AGE 
DECIMAL,field1 VARCHAR,field2 DECIMAL);
insert into tmp_table_age_name_wage_2 (key_field,AGE,field1,field2) values (1, 
42,'John',10);
{code}

2. `UNION SELECT` for columns with different types works fine:

{code:sql}
sql-cli> SELECT AGE,field1,field2 FROM tmp_table_age_name_wage UNION SELECT 
AGE,field1,field2 FROM tmp_table_age_name_wage_2;
╔═╤╤╗
║ AGE │ FIELD1 │ FIELD2 ║
╠═╪╪╣
║ 42  │ John   │ 10 ║
╟─┼┼╢
║ 42  │ John   │ 10 ║
╟─┼┼╢
║ 43  │ Jack   │ 5  ║
╚═╧╧╝
{code}

3. Nevertheless, `EXCEPT SELECT` leads to class casting exception:

{code:sql}
sql-cli> SELECT AGE,field1,field2 FROM tmp_table_age_name_wage EXCEPT SELECT 
AGE,field1,field2 FROM tmp_table_age_name_wage_2;
SQL query execution error
class java.math.BigDecimal cannot be cast to class java.lang.Integer 
(java.math.BigDecimal and java.lang.Integer are in module java.base of loader 
'bootstrap')
{code}

The query above worked in AI3 some time ago (e.g., in 3.0.0-beta1), but not 
now. Looks like a degradation.



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

[jira] [Created] (IGNITE-20577) Partial data loss after node restart

2023-10-05 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-20577:
---

 Summary: Partial data loss after node restart
 Key: IGNITE-20577
 URL: https://issues.apache.org/jira/browse/IGNITE-20577
 Project: Ignite
  Issue Type: Bug
Reporter: Andrey Khitrin
 Fix For: 3.0.0-beta2


How to reproduce:

1. Start a 1-node cluster
2. Create several simple tables (usually 5 is enough to reproduce):
{code:sql}
create table failoverTest00(k1 INTEGER not null, k2 INTEGER not null, v1 
VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null, primary key (k1, k2));
create table failoverTest01(k1 INTEGER not null, k2 INTEGER not null, v1 
VARCHAR(100), v2 VARCHAR(255), v3 TIMESTAMP not null, primary key (k1, k2));
...
{code}
3. Fill every table with 1000 rows.
4. Ensure that every table contains 1000 rows:
{code:sql}
SELECT COUNT(*) FROM failoverTest00;
...
{code}
5. Restart node (kill a Java process and start node again).
6. Check all tables again.

Expected behavior: after restart, all tables still contains the same data as 
before.

Actual behavior: for some tables, 1 or 2 rows may be missing, if we're fast 
enough on steps 3-4-5. Some contains 1000 rows, some contains 999 or 998.

This bug was first observed only near Sep 15, 2023. Most probably, it was 
introduced somewhere near that date. Probably, it's an another face of 
IGNITE-20425 (I'm not sure though). No errors in logs observed.



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

[jira] [Closed] (IGNITE-20329) Cannot build ODBC modules on MacOS

2023-09-04 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin closed IGNITE-20329.
---

Now compilation works for me.
[~isapego] thank you for collaboration and help!

> Cannot build ODBC modules on MacOS
> --
>
> Key: IGNITE-20329
> URL: https://issues.apache.org/jira/browse/IGNITE-20329
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Reporter: Andrey Khitrin
>Assignee: Andrey Khitrin
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> I tried to build AI3 from master (hash: 59107180b) on my MacBook and faced an 
> obstacle with compiling ODBC driver:
> {code}
> ./gradlew clean build -x check
> ...
> > Task :platforms:cmakeBuildOdbc FAILED
>   CMakePlugin.cmakeConfigure - ERRORS: 
> In file included from 
> /Users/zloddey/work/apache/ignite-3/modules/platforms/cpp/ignite/odbc/app/application_data_buffer.cpp:18:
> In file included from 
> /Users/zloddey/work/apache/ignite-3/modules/platforms/cpp/ignite/odbc/app/application_data_buffer.h:20:
> In file included from 
> /Users/zloddey/work/apache/ignite-3/modules/platforms/cpp/ignite/odbc/common_types.h:20:
> /Users/zloddey/work/apache/ignite-3/modules/platforms/cpp/ignite/odbc/system/odbc_constants.h:29:10:
>  fatal error: 'odbcinst.h' file not found
> #include 
>  ^~~~
> 1 error generated.
> make[2]: *** 
> [ignite/odbc/CMakeFiles/ignite3-odbc-obj.dir/app/application_data_buffer.cpp.o]
>  Error 1
> make[1]: *** [ignite/odbc/CMakeFiles/ignite3-odbc-obj.dir/all] Error 2
> make: *** [all] Error 2
> {code}
> I have an unixODBC package installed in my system, and odbcinst.h located in 
> /opt/local/include. My problem here is that this header is not found by build 
> scripts.



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

[jira] [Commented] (IGNITE-20329) Cannot build ODBC modules on MacOS

2023-09-01 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin commented on IGNITE-20329:
-

[~isapego] Take a look at PR please

> Cannot build ODBC modules on MacOS
> --
>
> Key: IGNITE-20329
> URL: https://issues.apache.org/jira/browse/IGNITE-20329
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Reporter: Andrey Khitrin
>Assignee: Andrey Khitrin
>Priority: Major
>  Labels: ignite-3
>
> I tried to build AI3 from master (hash: 59107180b) on my MacBook and faced an 
> obstacle with compiling ODBC driver:
> {code}
> ./gradlew clean build -x check
> ...
> > Task :platforms:cmakeBuildOdbc FAILED
>   CMakePlugin.cmakeConfigure - ERRORS: 
> In file included from 
> /Users/zloddey/work/apache/ignite-3/modules/platforms/cpp/ignite/odbc/app/application_data_buffer.cpp:18:
> In file included from 
> /Users/zloddey/work/apache/ignite-3/modules/platforms/cpp/ignite/odbc/app/application_data_buffer.h:20:
> In file included from 
> /Users/zloddey/work/apache/ignite-3/modules/platforms/cpp/ignite/odbc/common_types.h:20:
> /Users/zloddey/work/apache/ignite-3/modules/platforms/cpp/ignite/odbc/system/odbc_constants.h:29:10:
>  fatal error: 'odbcinst.h' file not found
> #include 
>  ^~~~
> 1 error generated.
> make[2]: *** 
> [ignite/odbc/CMakeFiles/ignite3-odbc-obj.dir/app/application_data_buffer.cpp.o]
>  Error 1
> make[1]: *** [ignite/odbc/CMakeFiles/ignite3-odbc-obj.dir/all] Error 2
> make: *** [all] Error 2
> {code}
> I have an unixODBC package installed in my system, and odbcinst.h located in 
> /opt/local/include. My problem here is that this header is not found by build 
> scripts.



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

[jira] [Assigned] (IGNITE-20329) Cannot build ODBC modules on MacOS

2023-09-01 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin reassigned IGNITE-20329:
---

Assignee: Andrey Khitrin

> Cannot build ODBC modules on MacOS
> --
>
> Key: IGNITE-20329
> URL: https://issues.apache.org/jira/browse/IGNITE-20329
> Project: Ignite
>  Issue Type: Bug
>  Components: odbc
>Reporter: Andrey Khitrin
>Assignee: Andrey Khitrin
>Priority: Major
>  Labels: ignite-3
>
> I tried to build AI3 from master (hash: 59107180b) on my MacBook and faced an 
> obstacle with compiling ODBC driver:
> {code}
> ./gradlew clean build -x check
> ...
> > Task :platforms:cmakeBuildOdbc FAILED
>   CMakePlugin.cmakeConfigure - ERRORS: 
> In file included from 
> /Users/zloddey/work/apache/ignite-3/modules/platforms/cpp/ignite/odbc/app/application_data_buffer.cpp:18:
> In file included from 
> /Users/zloddey/work/apache/ignite-3/modules/platforms/cpp/ignite/odbc/app/application_data_buffer.h:20:
> In file included from 
> /Users/zloddey/work/apache/ignite-3/modules/platforms/cpp/ignite/odbc/common_types.h:20:
> /Users/zloddey/work/apache/ignite-3/modules/platforms/cpp/ignite/odbc/system/odbc_constants.h:29:10:
>  fatal error: 'odbcinst.h' file not found
> #include 
>  ^~~~
> 1 error generated.
> make[2]: *** 
> [ignite/odbc/CMakeFiles/ignite3-odbc-obj.dir/app/application_data_buffer.cpp.o]
>  Error 1
> make[1]: *** [ignite/odbc/CMakeFiles/ignite3-odbc-obj.dir/all] Error 2
> make: *** [all] Error 2
> {code}
> I have an unixODBC package installed in my system, and odbcinst.h located in 
> /opt/local/include. My problem here is that this header is not found by build 
> scripts.



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

[jira] [Created] (IGNITE-20329) Cannot build ODBC modules on MacOS

2023-09-01 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-20329:
---

 Summary: Cannot build ODBC modules on MacOS
 Key: IGNITE-20329
 URL: https://issues.apache.org/jira/browse/IGNITE-20329
 Project: Ignite
  Issue Type: Bug
  Components: odbc
Reporter: Andrey Khitrin


I tried to build AI3 from master (hash: 59107180b) on my MacBook and faced an 
obstacle with compiling ODBC driver:

{code}
./gradlew clean build -x check
...
> Task :platforms:cmakeBuildOdbc FAILED
  CMakePlugin.cmakeConfigure - ERRORS: 
In file included from 
/Users/zloddey/work/apache/ignite-3/modules/platforms/cpp/ignite/odbc/app/application_data_buffer.cpp:18:
In file included from 
/Users/zloddey/work/apache/ignite-3/modules/platforms/cpp/ignite/odbc/app/application_data_buffer.h:20:
In file included from 
/Users/zloddey/work/apache/ignite-3/modules/platforms/cpp/ignite/odbc/common_types.h:20:
/Users/zloddey/work/apache/ignite-3/modules/platforms/cpp/ignite/odbc/system/odbc_constants.h:29:10:
 fatal error: 'odbcinst.h' file not found
#include 
 ^~~~
1 error generated.
make[2]: *** 
[ignite/odbc/CMakeFiles/ignite3-odbc-obj.dir/app/application_data_buffer.cpp.o] 
Error 1
make[1]: *** [ignite/odbc/CMakeFiles/ignite3-odbc-obj.dir/all] Error 2
make: *** [all] Error 2
{code}

I have an unixODBC package installed in my system, and odbcinst.h located in 
/opt/local/include. My problem here is that this header is not found by build 
scripts.



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

[jira] [Created] (IGNITE-20198) .NET Frequent failures in Plaform .NET (Core Linux) TC Project

2023-08-11 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-20198:
---

 Summary: .NET Frequent failures in Plaform .NET (Core Linux) TC 
Project
 Key: IGNITE-20198
 URL: https://issues.apache.org/jira/browse/IGNITE-20198
 Project: Ignite
  Issue Type: Bug
  Components: .NET
Affects Versions: 2.15
Reporter: Andrey Khitrin


* Out of memory: Java heap space 
* Execution timeout
* Flaky tests



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

[jira] [Created] (IGNITE-19976) Sql: ClassCastException when trying to select from indexed smallint column

2023-07-13 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-19976:
---

 Summary: Sql: ClassCastException when trying to select from 
indexed smallint column
 Key: IGNITE-19976
 URL: https://issues.apache.org/jira/browse/IGNITE-19976
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Andrey Khitrin


Steps to reproduce:

{code:sql}
sql-cli> create table tt(id INTEGER not null, field_1 TINYINT, field_2 
SMALLINT, primary key (id));
Updated 0 rows.
sql-cli> SELECT * FROM tt WHERE field_2 = 50;
╔╤═╤═╗
║ ID │ FIELD_1 │ FIELD_2 ║
╠╧═╧═╣
║ (empty)║
╚╝

-- select over field_2 works fine until we create an index on it!

sql-cli> CREATE INDEX tt_idx ON tt (field_2);
Updated 0 rows.
sql-cli> SELECT * FROM tt WHERE field_2 = 50;
SQL query execution error
Exception while executing query [query=SELECT * FROM tt WHERE field_2 = 50;]. 
Error message:Query remote fragment execution failed: nodeName=defaultNode, 
queryId=15a68600-41bc-46c5-b20d-7a96aad15477, fragmentId=4, 
originalMessage=class java.lang.Integer cannot be cast to class java.lang.Short 
(java.lang.Integer and java.lang.Short are in module java.base of loader 
'bootstrap')
{code}

This doesn't look good. A created index must not cause casting exception.

Reproduced on commit `fef7a24c2a029cac720d2fea3815c2a70a86b72f` (2023-07-12)



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

[jira] [Updated] (IGNITE-19419) Internal queue overload under intensive SQL load

2023-06-19 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin updated IGNITE-19419:

Summary: Internal queue overload under intensive SQL load  (was: Corrupted 
LogStorage under intensive SQL load)

> Internal queue overload under intensive SQL load
> 
>
> Key: IGNITE-19419
> URL: https://issues.apache.org/jira/browse/IGNITE-19419
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
>  Labels: ignite-3, storage-engine
> Attachments: ai3.jstack, logs.zip
>
>
> I tried to run a SQL benchmark (slightly modified [Benchbase TPC-C 
> scenario|https://github.com/cmu-db/benchbase/wiki/TPC-C]) against Ignite3 
> (commit hash b48ddcba7cd2bd3b9a053ae131c25b44a0400e27).
> Ignite3 was running in a single-node mode with -Xmx8G -Xms8G memory limit 
> (increased memory size comparing to IGNITE-19412). After some time it has 
> become unavailable to the client. Log is filled with error messages like the 
> following:
>  
> {code:java}
> 2023-05-03 17:51:57:705 +0300 
> [WARNING][%node0%JRaft-FSMCaller-Disruptor-_stripe_10-0][NodeImpl] Node 
>  got error: Error 
> [type=ERROR_TYPE_LOG, status=Status[EBUSY<1009>: LogManager is busy, disk 
> queue overload.]].
> 2023-05-03 17:51:57:705 +0300 
> [WARNING][CompletableFutureDelayScheduler][RaftGroupServiceImpl] Recoverable 
> error during the request type=ActionRequestImpl occurred (will be retried on 
> the randomly selected node): 
> java.util.concurrent.CompletionException: 
> java.util.concurrent.TimeoutException
>   at 
> java.base/java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:367)
>   at 
> java.base/java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:376)
>   at 
> java.base/java.util.concurrent.CompletableFuture$UniRelay.tryFire(CompletableFuture.java:1019)
>   at 
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
>   at 
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
>   at 
> java.base/java.util.concurrent.CompletableFuture$Timeout.run(CompletableFuture.java:2792)
>   at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
>   at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>   at 
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>   at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.util.concurrent.TimeoutException
>   ... 7 more
> 2023-05-03 17:51:57:705 +0300 
> [ERROR][%node0%JRaft-LogManager-Disruptor-_stripe_10-0][NodeImpl] Node 
>  append [2268, 2268] 
> failed, status=Status[EIO<1014>: Corrupted LogStorage].
> 2023-05-03 17:51:57:705 +0300 
> [WARNING][%node0%JRaft-FSMCaller-Disruptor-_stripe_10-0][FSMCallerImpl] 
> FSMCaller already in error status, ignore new error
> Error [type=ERROR_TYPE_LOG, status=Status[EBUSY<1009>: LogManager is busy, 
> disk queue overload.]]
>   at 
> org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.reportError(LogManagerImpl.java:587)
>   at 
> org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.appendEntries(LogManagerImpl.java:337)
>   at 
> org.apache.ignite.raft.jraft.core.NodeImpl.executeApplyingTasks(NodeImpl.java:1621)
>   at 
> org.apache.ignite.raft.jraft.core.NodeImpl$LogEntryAndClosureHandler.onEvent(NodeImpl.java:305)
>   at 
> org.apache.ignite.raft.jraft.core.NodeImpl$LogEntryAndClosureHandler.onEvent(NodeImpl.java:288)
>   at 
> org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:217)
>   at 
> org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:181)
>   at 
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:137)
>   at java.base/java.lang.Thread.run(Thread.java:829)
> 2023-05-03 17:51:57:706 +0300 
> [INFO][%node0%JRaft-FSMCaller-Disruptor-_stripe_10-0][ReplicatorGroupImpl] 
> Fail to find the next candidate.
> 2023-05-03 17:51:57:706 +0300 
> [ERROR][%node0%JRaft-LogManager-Disruptor-_stripe_10-0][NodeImpl] Node 
>  append [2271, 2271] 
> failed, status=Status[EIO<1014>: Corrupted LogStorage].
> 2023-05-03 17:51:57:706 +0300 
> [INFO][%node0%JRaft-FSMCaller-Disruptor-_stripe_10-0][StateMachineAdapter] 
> onLeaderStop: status=Status[EBADNODE<10009>: Raft

[jira] [Created] (IGNITE-19608) Startup errors are ignored in ignite3db script

2023-05-31 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-19608:
---

 Summary: Startup errors are ignored in ignite3db script
 Key: IGNITE-19608
 URL: https://issues.apache.org/jira/browse/IGNITE-19608
 Project: Ignite
  Issue Type: Bug
Affects Versions: 3.0.0-beta1
Reporter: Andrey Khitrin


Ignite3 node is started by `bin/ignite3db` shell script. Unfortunately, this 
script follows some shell scripting bad practices that makes troubleshooting 
harder when something goes wrong.

Particullary, there are following issues:
1. No guarding bash options (like `nounset`, `errexit`, or `pipefile`) is set.
2. When starting Java application, its stderr and stdout are redirected into 
`/dev/null`.

{code:bash}
  CMD="${JAVA_CMD_WITH_ARGS} ${APPLICATION_ARGS}"
  $CMD >>/dev/null 2>&1 ${IGNITE_HOME}/pid
{code}

Just for comparison: [control.sh in 
AI2|https://github.com/apache/ignite/blob/master/bin/control.sh] do not suffer 
from such behavior. This should be fixed in AI3 too.



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

[jira] [Updated] (IGNITE-19419) Corrupted LogStorage under intensive SQL load

2023-05-04 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin updated IGNITE-19419:

Attachment: ai3.jstack

> Corrupted LogStorage under intensive SQL load
> -
>
> Key: IGNITE-19419
> URL: https://issues.apache.org/jira/browse/IGNITE-19419
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
>  Labels: ignite-3, storage-engine
> Attachments: ai3.jstack, logs.zip
>
>
> I tried to run a SQL benchmark (slightly modified [Benchbase TPC-C 
> scenario|https://github.com/cmu-db/benchbase/wiki/TPC-C]) against Ignite3 
> (commit hash b48ddcba7cd2bd3b9a053ae131c25b44a0400e27).
> Ignite3 was running in a single-node mode with -Xmx8G -Xms8G memory limit 
> (increased memory size comparing to IGNITE-19412). After some time it has 
> become unavailable to the client. Log is filled with error messages like the 
> following:
>  {code:java}
> 2023-05-03 17:51:57:705 +0300 
> [WARNING][%node0%JRaft-FSMCaller-Disruptor-_stripe_10-0][NodeImpl] Node 
>  got error: Error 
> [type=ERROR_TYPE_LOG, status=Status[EBUSY<1009>: LogManager is busy, disk 
> queue overload.]].
> 2023-05-03 17:51:57:705 +0300 
> [WARNING][CompletableFutureDelayScheduler][RaftGroupServiceImpl] Recoverable 
> error during the request type=ActionRequestImpl occurred (will be retried on 
> the randomly selected node): 
> java.util.concurrent.CompletionException: 
> java.util.concurrent.TimeoutException
>   at 
> java.base/java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:367)
>   at 
> java.base/java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:376)
>   at 
> java.base/java.util.concurrent.CompletableFuture$UniRelay.tryFire(CompletableFuture.java:1019)
>   at 
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
>   at 
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
>   at 
> java.base/java.util.concurrent.CompletableFuture$Timeout.run(CompletableFuture.java:2792)
>   at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
>   at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>   at 
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>   at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.util.concurrent.TimeoutException
>   ... 7 more
> 2023-05-03 17:51:57:705 +0300 
> [ERROR][%node0%JRaft-LogManager-Disruptor-_stripe_10-0][NodeImpl] Node 
>  append [2268, 2268] 
> failed, status=Status[EIO<1014>: Corrupted LogStorage].
> 2023-05-03 17:51:57:705 +0300 
> [WARNING][%node0%JRaft-FSMCaller-Disruptor-_stripe_10-0][FSMCallerImpl] 
> FSMCaller already in error status, ignore new error
> Error [type=ERROR_TYPE_LOG, status=Status[EBUSY<1009>: LogManager is busy, 
> disk queue overload.]]
>   at 
> org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.reportError(LogManagerImpl.java:587)
>   at 
> org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.appendEntries(LogManagerImpl.java:337)
>   at 
> org.apache.ignite.raft.jraft.core.NodeImpl.executeApplyingTasks(NodeImpl.java:1621)
>   at 
> org.apache.ignite.raft.jraft.core.NodeImpl$LogEntryAndClosureHandler.onEvent(NodeImpl.java:305)
>   at 
> org.apache.ignite.raft.jraft.core.NodeImpl$LogEntryAndClosureHandler.onEvent(NodeImpl.java:288)
>   at 
> org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:217)
>   at 
> org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:181)
>   at 
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:137)
>   at java.base/java.lang.Thread.run(Thread.java:829)
> 2023-05-03 17:51:57:706 +0300 
> [INFO][%node0%JRaft-FSMCaller-Disruptor-_stripe_10-0][ReplicatorGroupImpl] 
> Fail to find the next candidate.
> 2023-05-03 17:51:57:706 +0300 
> [ERROR][%node0%JRaft-LogManager-Disruptor-_stripe_10-0][NodeImpl] Node 
>  append [2271, 2271] 
> failed, status=Status[EIO<1014>: Corrupted LogStorage].
> 2023-05-03 17:51:57:706 +0300 
> [INFO][%node0%JRaft-FSMCaller-Disruptor-_stripe_10-0][StateMachineAdapter] 
> onLeaderStop: status=Status[EBADNODE<10009>: Raft node(leader or candidate) 
> is in error.].
> 2023-05-03 17:51:57:706 +0300 
>

[jira] [Updated] (IGNITE-19419) Corrupted LogStorage under intensive SQL load

2023-05-04 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin updated IGNITE-19419:

Attachment: logs.zip

> Corrupted LogStorage under intensive SQL load
> -
>
> Key: IGNITE-19419
> URL: https://issues.apache.org/jira/browse/IGNITE-19419
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
>  Labels: ignite-3, storage-engine
> Attachments: ai3.jstack, logs.zip
>
>
> I tried to run a SQL benchmark (slightly modified [Benchbase TPC-C 
> scenario|https://github.com/cmu-db/benchbase/wiki/TPC-C]) against Ignite3 
> (commit hash b48ddcba7cd2bd3b9a053ae131c25b44a0400e27).
> Ignite3 was running in a single-node mode with -Xmx8G -Xms8G memory limit 
> (increased memory size comparing to IGNITE-19412). After some time it has 
> become unavailable to the client. Log is filled with error messages like the 
> following:
>  {code:java}
> 2023-05-03 17:51:57:705 +0300 
> [WARNING][%node0%JRaft-FSMCaller-Disruptor-_stripe_10-0][NodeImpl] Node 
>  got error: Error 
> [type=ERROR_TYPE_LOG, status=Status[EBUSY<1009>: LogManager is busy, disk 
> queue overload.]].
> 2023-05-03 17:51:57:705 +0300 
> [WARNING][CompletableFutureDelayScheduler][RaftGroupServiceImpl] Recoverable 
> error during the request type=ActionRequestImpl occurred (will be retried on 
> the randomly selected node): 
> java.util.concurrent.CompletionException: 
> java.util.concurrent.TimeoutException
>   at 
> java.base/java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:367)
>   at 
> java.base/java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:376)
>   at 
> java.base/java.util.concurrent.CompletableFuture$UniRelay.tryFire(CompletableFuture.java:1019)
>   at 
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
>   at 
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
>   at 
> java.base/java.util.concurrent.CompletableFuture$Timeout.run(CompletableFuture.java:2792)
>   at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
>   at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>   at 
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>   at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.util.concurrent.TimeoutException
>   ... 7 more
> 2023-05-03 17:51:57:705 +0300 
> [ERROR][%node0%JRaft-LogManager-Disruptor-_stripe_10-0][NodeImpl] Node 
>  append [2268, 2268] 
> failed, status=Status[EIO<1014>: Corrupted LogStorage].
> 2023-05-03 17:51:57:705 +0300 
> [WARNING][%node0%JRaft-FSMCaller-Disruptor-_stripe_10-0][FSMCallerImpl] 
> FSMCaller already in error status, ignore new error
> Error [type=ERROR_TYPE_LOG, status=Status[EBUSY<1009>: LogManager is busy, 
> disk queue overload.]]
>   at 
> org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.reportError(LogManagerImpl.java:587)
>   at 
> org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.appendEntries(LogManagerImpl.java:337)
>   at 
> org.apache.ignite.raft.jraft.core.NodeImpl.executeApplyingTasks(NodeImpl.java:1621)
>   at 
> org.apache.ignite.raft.jraft.core.NodeImpl$LogEntryAndClosureHandler.onEvent(NodeImpl.java:305)
>   at 
> org.apache.ignite.raft.jraft.core.NodeImpl$LogEntryAndClosureHandler.onEvent(NodeImpl.java:288)
>   at 
> org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:217)
>   at 
> org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:181)
>   at 
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:137)
>   at java.base/java.lang.Thread.run(Thread.java:829)
> 2023-05-03 17:51:57:706 +0300 
> [INFO][%node0%JRaft-FSMCaller-Disruptor-_stripe_10-0][ReplicatorGroupImpl] 
> Fail to find the next candidate.
> 2023-05-03 17:51:57:706 +0300 
> [ERROR][%node0%JRaft-LogManager-Disruptor-_stripe_10-0][NodeImpl] Node 
>  append [2271, 2271] 
> failed, status=Status[EIO<1014>: Corrupted LogStorage].
> 2023-05-03 17:51:57:706 +0300 
> [INFO][%node0%JRaft-FSMCaller-Disruptor-_stripe_10-0][StateMachineAdapter] 
> onLeaderStop: status=Status[EBADNODE<10009>: Raft node(leader or candidate) 
> is in error.].
> 2023-05-03 17:51:57:706 +0300 
>

[jira] [Updated] (IGNITE-19419) Corrupted LogStorage under intensive SQL load

2023-05-04 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin updated IGNITE-19419:

Description: 
I tried to run a SQL benchmark (slightly modified [Benchbase TPC-C 
scenario|https://github.com/cmu-db/benchbase/wiki/TPC-C]) against Ignite3 
(commit hash b48ddcba7cd2bd3b9a053ae131c25b44a0400e27).

Ignite3 was running in a single-node mode with -Xmx8G -Xms8G memory limit 
(increased memory size comparing to IGNITE-19412). After some time it has 
become unavailable to the client. Log is filled with error messages like the 
following:

 {code:java}
2023-05-03 17:51:57:705 +0300 
[WARNING][%node0%JRaft-FSMCaller-Disruptor-_stripe_10-0][NodeImpl] Node 
 got error: Error 
[type=ERROR_TYPE_LOG, status=Status[EBUSY<1009>: LogManager is busy, disk queue 
overload.]].
2023-05-03 17:51:57:705 +0300 
[WARNING][CompletableFutureDelayScheduler][RaftGroupServiceImpl] Recoverable 
error during the request type=ActionRequestImpl occurred (will be retried on 
the randomly selected node): 
java.util.concurrent.CompletionException: java.util.concurrent.TimeoutException
at 
java.base/java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:367)
at 
java.base/java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:376)
at 
java.base/java.util.concurrent.CompletableFuture$UniRelay.tryFire(CompletableFuture.java:1019)
at 
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
at 
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
at 
java.base/java.util.concurrent.CompletableFuture$Timeout.run(CompletableFuture.java:2792)
at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at 
java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.util.concurrent.TimeoutException
... 7 more
2023-05-03 17:51:57:705 +0300 
[ERROR][%node0%JRaft-LogManager-Disruptor-_stripe_10-0][NodeImpl] Node 
 append [2268, 2268] failed, 
status=Status[EIO<1014>: Corrupted LogStorage].
2023-05-03 17:51:57:705 +0300 
[WARNING][%node0%JRaft-FSMCaller-Disruptor-_stripe_10-0][FSMCallerImpl] 
FSMCaller already in error status, ignore new error
Error [type=ERROR_TYPE_LOG, status=Status[EBUSY<1009>: LogManager is busy, disk 
queue overload.]]
at 
org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.reportError(LogManagerImpl.java:587)
at 
org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.appendEntries(LogManagerImpl.java:337)
at 
org.apache.ignite.raft.jraft.core.NodeImpl.executeApplyingTasks(NodeImpl.java:1621)
at 
org.apache.ignite.raft.jraft.core.NodeImpl$LogEntryAndClosureHandler.onEvent(NodeImpl.java:305)
at 
org.apache.ignite.raft.jraft.core.NodeImpl$LogEntryAndClosureHandler.onEvent(NodeImpl.java:288)
at 
org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:217)
at 
org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:181)
at 
com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:137)
at java.base/java.lang.Thread.run(Thread.java:829)
2023-05-03 17:51:57:706 +0300 
[INFO][%node0%JRaft-FSMCaller-Disruptor-_stripe_10-0][ReplicatorGroupImpl] Fail 
to find the next candidate.
2023-05-03 17:51:57:706 +0300 
[ERROR][%node0%JRaft-LogManager-Disruptor-_stripe_10-0][NodeImpl] Node 
 append [2271, 2271] 
failed, status=Status[EIO<1014>: Corrupted LogStorage].
2023-05-03 17:51:57:706 +0300 
[INFO][%node0%JRaft-FSMCaller-Disruptor-_stripe_10-0][StateMachineAdapter] 
onLeaderStop: status=Status[EBADNODE<10009>: Raft node(leader or candidate) is 
in error.].
2023-05-03 17:51:57:706 +0300 
[ERROR][%node0%JRaft-LogManager-Disruptor-_stripe_10-0][NodeImpl] Node 
<30181391-2f04-40c0-8c35-a77592b0731f_part_5/node0> append [2285, 2285] failed, 
status=Status[EIO<1014>: Corrupted LogStorage].
{code}

More errors could be observed in the attached log archive.

  was:
I tried to run a SQL benchmark (slightly modified [Benchbase TPC-C 
scenario|https://github.com/cmu-db/benchbase/wiki/TPC-C]) against Ignite3 
(commit hash b48ddcba7cd2bd3b9a053ae131c25b44a0400e27).

Ignite3 was running with -Xmx6G -Xms6G memory limit. After some time it has 
reached memory limits and failed due to OutOfMemoryError. A heap dump was 
generated on

[jira] [Updated] (IGNITE-19419) Corrupted LogStorage under intensive SQL load

2023-05-04 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin updated IGNITE-19419:

Labels: ignite-3 storage-engine  (was: ignite-3 sql)

> Corrupted LogStorage under intensive SQL load
> -
>
> Key: IGNITE-19419
> URL: https://issues.apache.org/jira/browse/IGNITE-19419
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
>  Labels: ignite-3, storage-engine
> Attachments: ai3.jstack, logs.zip
>
>
> I tried to run a SQL benchmark (slightly modified [Benchbase TPC-C 
> scenario|https://github.com/cmu-db/benchbase/wiki/TPC-C]) against Ignite3 
> (commit hash b48ddcba7cd2bd3b9a053ae131c25b44a0400e27).
> Ignite3 was running in a single-node mode with -Xmx8G -Xms8G memory limit 
> (increased memory size comparing to IGNITE-19412). After some time it has 
> become unavailable to the client. Log is filled with error messages like the 
> following:
>  {code:java}
> 2023-05-03 17:51:57:705 +0300 
> [WARNING][%node0%JRaft-FSMCaller-Disruptor-_stripe_10-0][NodeImpl] Node 
>  got error: Error 
> [type=ERROR_TYPE_LOG, status=Status[EBUSY<1009>: LogManager is busy, disk 
> queue overload.]].
> 2023-05-03 17:51:57:705 +0300 
> [WARNING][CompletableFutureDelayScheduler][RaftGroupServiceImpl] Recoverable 
> error during the request type=ActionRequestImpl occurred (will be retried on 
> the randomly selected node): 
> java.util.concurrent.CompletionException: 
> java.util.concurrent.TimeoutException
>   at 
> java.base/java.util.concurrent.CompletableFuture.encodeRelay(CompletableFuture.java:367)
>   at 
> java.base/java.util.concurrent.CompletableFuture.completeRelay(CompletableFuture.java:376)
>   at 
> java.base/java.util.concurrent.CompletableFuture$UniRelay.tryFire(CompletableFuture.java:1019)
>   at 
> java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
>   at 
> java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
>   at 
> java.base/java.util.concurrent.CompletableFuture$Timeout.run(CompletableFuture.java:2792)
>   at 
> java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
>   at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>   at 
> java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:304)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
>   at 
> java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
>   at java.base/java.lang.Thread.run(Thread.java:829)
> Caused by: java.util.concurrent.TimeoutException
>   ... 7 more
> 2023-05-03 17:51:57:705 +0300 
> [ERROR][%node0%JRaft-LogManager-Disruptor-_stripe_10-0][NodeImpl] Node 
>  append [2268, 2268] 
> failed, status=Status[EIO<1014>: Corrupted LogStorage].
> 2023-05-03 17:51:57:705 +0300 
> [WARNING][%node0%JRaft-FSMCaller-Disruptor-_stripe_10-0][FSMCallerImpl] 
> FSMCaller already in error status, ignore new error
> Error [type=ERROR_TYPE_LOG, status=Status[EBUSY<1009>: LogManager is busy, 
> disk queue overload.]]
>   at 
> org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.reportError(LogManagerImpl.java:587)
>   at 
> org.apache.ignite.raft.jraft.storage.impl.LogManagerImpl.appendEntries(LogManagerImpl.java:337)
>   at 
> org.apache.ignite.raft.jraft.core.NodeImpl.executeApplyingTasks(NodeImpl.java:1621)
>   at 
> org.apache.ignite.raft.jraft.core.NodeImpl$LogEntryAndClosureHandler.onEvent(NodeImpl.java:305)
>   at 
> org.apache.ignite.raft.jraft.core.NodeImpl$LogEntryAndClosureHandler.onEvent(NodeImpl.java:288)
>   at 
> org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:217)
>   at 
> org.apache.ignite.raft.jraft.disruptor.StripedDisruptor$StripeEntryHandler.onEvent(StripedDisruptor.java:181)
>   at 
> com.lmax.disruptor.BatchEventProcessor.run(BatchEventProcessor.java:137)
>   at java.base/java.lang.Thread.run(Thread.java:829)
> 2023-05-03 17:51:57:706 +0300 
> [INFO][%node0%JRaft-FSMCaller-Disruptor-_stripe_10-0][ReplicatorGroupImpl] 
> Fail to find the next candidate.
> 2023-05-03 17:51:57:706 +0300 
> [ERROR][%node0%JRaft-LogManager-Disruptor-_stripe_10-0][NodeImpl] Node 
>  append [2271, 2271] 
> failed, status=Status[EIO<1014>: Corrupted LogStorage].
> 2023-05-03 17:51:57:706 +0300 
> [INFO][%node0%JRaft-FSMCaller-Disruptor-_stripe_10-0][StateMachineAdapter] 
> onLeaderStop: status=Status[EBADNODE<10009>: Raft node(leader or candidate) 
> is in error.].
> 2023-05-03 17:51:57:706

[jira] [Created] (IGNITE-19419) Corrupted LogStorage under intensive SQL load

2023-05-04 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-19419:
---

 Summary: Corrupted LogStorage under intensive SQL load
 Key: IGNITE-19419
 URL: https://issues.apache.org/jira/browse/IGNITE-19419
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Andrey Khitrin


I tried to run a SQL benchmark (slightly modified [Benchbase TPC-C 
scenario|https://github.com/cmu-db/benchbase/wiki/TPC-C]) against Ignite3 
(commit hash b48ddcba7cd2bd3b9a053ae131c25b44a0400e27).

Ignite3 was running with -Xmx6G -Xms6G memory limit. After some time it has 
reached memory limits and failed due to OutOfMemoryError. A heap dump was 
generated on failure. I can't attach this dump due to its size, but I've opened 
it in MAT and created a report (see zip file attached).

The report says that most of the retained heap (almost 5G) is occupied by a 
single instance of o.a.i.internal.sql.engine.exec.MailboxRegistryImpl class 
(see image attached).

{*}Hypothesis{*}: on an intense load, MailboxRegistryImpl creates a lot of 
lambda expressions. This happens faster than they're being utilized. With 
limited memory size, it could lead to OOM at some moment.

Benchmark is quite trivial by mechanics:

1. Create a table structure (see DDL file attached)
2. Fill tables with randomized data (several tens of thousands rows is enough)
3. Run select queries in a loop (actually, it wouldn't happen; OOM was raised 
on data insertion).



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

[jira] [Created] (IGNITE-19412) Potential memory leak in MailboxRegistryImpl under intensive SQL load

2023-05-03 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-19412:
---

 Summary: Potential memory leak in MailboxRegistryImpl under 
intensive SQL load
 Key: IGNITE-19412
 URL: https://issues.apache.org/jira/browse/IGNITE-19412
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Andrey Khitrin
 Attachments: Screenshot_20230503_172458.png, ddl-ignite3.sql, 
java_pid4802_Leak_Suspects.zip

I tried to run a SQL benchmark (slightly modified [Benchbase TPC-C 
scenario|https://github.com/cmu-db/benchbase/wiki/TPC-C]) against Ignite3 
(commit hash b48ddcba7cd2bd3b9a053ae131c25b44a0400e27).

Ignite3 was running with -Xmx6G -Xms6G memory limit. After some time it has 
reached memory limits and failed due to OutOfMemoryError. A heap dump was 
generated on failure. I can't attach this dump due to its size, but I've opened 
it in MAT and created a report (see zip file attached).

The report says that most of the retained heap (almost 5G) is occupied by a 
single instance of o.a.i.internal.sql.engine.exec.MailboxRegistryImpl class 
(see image attached).

{*}Hypothesis{*}: on an intense load, MailboxRegistryImpl creates a lot of 
lambda expressions. This happens faster than they're being utilized. With 
limited memory size, it could lead to OOM at some moment.

Benchmark is quite trivial by mechanics:

1. Create a table structure (see DDL file attached)
2. Fill tables with randomized data (several tens of thousands rows is enough)
3. Run select queries in a loop (actually, it wouldn't happen; OOM was raised 
on data insertion).



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

[jira] [Updated] (IGNITE-19352) Create table from query result

2023-04-24 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin updated IGNITE-19352:

Affects Version/s: 3.0.0-beta1

> Create table from query result
> --
>
> Key: IGNITE-19352
> URL: https://issues.apache.org/jira/browse/IGNITE-19352
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
>  Labels: ignite-3, sql
>
> Like in IGNITE-14555 for AI2, it would be useful to create tables from the 
> result of the query:
>  {code:sql}
> CREATE TABLE  AS 
> {code}
> In the AI3 beta1 and current `main` it's not possible:
> {code:sql}
> sql-cli> create table xx (key_field INT PRIMARY KEY, field1 INT);
> Updated 0 rows.
> sql-cli> insert into xx values (1, 1);
> Updated 1 rows.
> sql-cli> insert into xx values (2, 10);
> Updated 1 rows.
> sql-cli> create table xy as select key_field, field1 from xx where field1 < 5;
> SQL query execution error
> Exception while executing query [query=create table xy as select key_field, 
> field1 from xx where field1 < 5;]. Error message:IGN-SQL-3 
> TraceId:ff6bc711-14e5-42ab-b80c-5515a8b77c7c Failed to parse query: 
> Encountered " "AS" "as "" at line 1, column 17.
> Was expecting:
> "(" ...
> {code}



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

[jira] [Created] (IGNITE-19352) Create table from query result

2023-04-24 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-19352:
---

 Summary: Create table from query result
 Key: IGNITE-19352
 URL: https://issues.apache.org/jira/browse/IGNITE-19352
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Reporter: Andrey Khitrin


Like in IGNITE-14555 for AI2, it would be useful to create tables from the 
result of the query:
 {code:sql}
CREATE TABLE  AS 
{code}

In the AI3 beta1 and current `main` it's not possible:
{code:sql}
sql-cli> create table xx (key_field INT PRIMARY KEY, field1 INT);
Updated 0 rows.
sql-cli> insert into xx values (1, 1);
Updated 1 rows.
sql-cli> insert into xx values (2, 10);
Updated 1 rows.
sql-cli> create table xy as select key_field, field1 from xx where field1 < 5;
SQL query execution error
Exception while executing query [query=create table xy as select key_field, 
field1 from xx where field1 < 5;]. Error message:IGN-SQL-3 
TraceId:ff6bc711-14e5-42ab-b80c-5515a8b77c7c Failed to parse query: Encountered 
" "AS" "as "" at line 1, column 17.
Was expecting:
"(" ...
{code}



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

[jira] [Created] (IGNITE-19345) SQL: incorrect NULLIF behavior in some cases

2023-04-21 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-19345:
---

 Summary: SQL: incorrect NULLIF behavior in some cases
 Key: IGNITE-19345
 URL: https://issues.apache.org/jira/browse/IGNITE-19345
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Andrey Khitrin


During the validation of IGNITE-18167, the following error was found:
{code:sql}
sql-cli> SELECT NULLIF(1, 1) IS NULL;
SQL query execution error
Exception while executing query [query=SELECT NULLIF(1, 1) IS NULL;]. Error 
message:From line 1, column 8 to line 1, column 19: Illegal mixing of types in 
CASE or COALESCE statement
{code}

For chars, it works correctly:
{code:sql}
sql-cli> SELECT NULLIF('1', '1') IS NULL;
╔═╗
║ EXPR$0  ║
╠═╣
║ true║
╚═╝
{code}

For slightly more complex numeric query, it also works correctly:
{code:sql}
sql-cli> SELECT x IS NULL FROM (SELECT NULLIF(1, 1) AS x);
╔═╗
║ EXPR$0  ║
╠═╣
║ true║
╚═╝
{code}



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

[jira] [Commented] (IGNITE-18488) SQL: SUBSTRING function does not support NULL values

2023-04-21 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin commented on IGNITE-18488:
-

I've made a clone of this issue with updated description (IGNITE-19341). Hope 
it helps.

> SQL: SUBSTRING function does not support NULL values
> 
>
> Key: IGNITE-18488
> URL: https://issues.apache.org/jira/browse/IGNITE-18488
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Assignee: Andrey Mashenkov
>Priority: Major
>  Labels: ignite-3, sql
> Fix For: 3.0.0-beta2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> ANSI99 SQL specification ("6.18 ") says the following:
> {code:java}
> 3) If  is specified, then:
>   a) Let C be the value of the , ..., and let S 
> be the value of the .
>   b) If  is specified, then let L be the value of  length> ...
>   c) If either C, S, or L is the null value, then the result of the 
>  is the null value.
> {code}
> So, we should expect the following behavior:
> {code:sql}
> SUBSTRING('text' FROM 1 FOR NULL) -> NULL
> SUBSTRING('text' FROM NULL FOR 2) -> NULL
> SUBSTRING(NULL FROM 1 FOR 2) -> NULL
> {code}
> Instead, we got errors for these queries:
> {code:sql}
> sql-cli> SELECT SUBSTRING('text' FROM 1 FOR NULL);
> SQL query execution error
> Exception while executing query [query=SELECT SUBSTRING('text' FROM 1 FOR 
> NULL);]. Error message:From line 1, column 8 to line 1, column 40: Cannot 
> apply 'SUBSTRING' to arguments of type 'SUBSTRING( FROM  
> FOR )'. Supported form(s): 'SUBSTRING( FROM )'
> 'SUBSTRING( FROM  FOR )'
> 'SUBSTRING( FROM )'
> 'SUBSTRING( FROM  FOR )'
> 'SUBSTRING( FROM )'
> 'SUBSTRING( FROM  FOR )'
> 'SUBSTRING( FROM )'
> 'SUBSTRING( FROM  FOR )'
> sql-cli> SELECT SUBSTRING('text' FROM NULL FOR 2);
> SQL query execution error
> Exception while executing query [query=SELECT SUBSTRING('text' FROM NULL FOR 
> 2);]. Error message:From line 1, column 8 to line 1, column 40: Cannot apply 
> 'SUBSTRING' to arguments of type 'SUBSTRING( FROM  FOR 
> )'. Supported form(s): 'SUBSTRING( FROM )'
> 'SUBSTRING( FROM  FOR )'
> 'SUBSTRING( FROM )'
> 'SUBSTRING( FROM  FOR )'
> 'SUBSTRING( FROM )'
> 'SUBSTRING( FROM  FOR )'
> 'SUBSTRING( FROM )'
> 'SUBSTRING( FROM  FOR )'
> sql-cli> SELECT SUBSTRING(NULL FROM 1 FOR 2);
>   (client freezes, no answer at all)
> {code}
> *Important*: the last query causes {{NullPointerException}} within DB:
> {code:java}
> 2022-12-30 07:32:46:210 + 
> [WARNING][node1-srv-worker-1][ClientInboundMessageHandler] Error processing 
> client request
> java.lang.NullPointerException
> at 
> org.apache.ignite.internal.sql.SqlColumnTypeConverter.columnTypeToClass(SqlColumnTypeConverter.java:42)
> at 
> org.apache.ignite.client.handler.JdbcQueryCursorHandlerImpl.createColumnMetadata(JdbcQueryCursorHandlerImpl.java:162)
> at 
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at 
> java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
> 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.client.handler.JdbcQueryCursorHandlerImpl.queryMetadataAsync(JdbcQueryCursorHandlerImpl.java:133)
> at 
> org.apache.ignite.client.handler.requests.jdbc.ClientJdbcQueryMetadataRequest.process(ClientJdbcQueryMetadataRequest.java:47)
> at 
> org.apache.ignite.client.handler.ClientInboundMessageHandler.processOperation(ClientInboundMessageHandler.java:454)
> at 
> org.apache.ignite.client.handler.ClientInboundMessageHandler.processOperation(ClientInboundMessageHandler.java:336)
> at 
> org.apache.ignite.client.handler.ClientInboundMessageHandler.channelRead(ClientInboundMessageHandler.java:187)
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
> at 
> io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
> at 
> io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
> at 
> io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:327)
> at 
>

[jira] [Updated] (IGNITE-19341) SQL: SUBSTRING function does not support NULL values (try 2)

2023-04-21 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin updated IGNITE-19341:

Fix Version/s: (was: 3.0.0-beta2)

> SQL: SUBSTRING function does not support NULL values (try 2)
> 
>
> Key: IGNITE-19341
> URL: https://issues.apache.org/jira/browse/IGNITE-19341
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Assignee: Andrey Mashenkov
>Priority: Major
>  Labels: ignite-3, sql
>
> ANSI99 SQL specification ("6.18 ") says the following:
> {code:java}
> 3) If  is specified, then:
>   a) Let C be the value of the , ..., and let S 
> be the value of the .
>   b) If  is specified, then let L be the value of  length> ...
>   c) If either C, S, or L is the null value, then the result of the 
>  is the null value.
> {code}
> So, we should expect the following behavior:
> {code:sql}
> SUBSTRING('text' FROM 1 FOR NULL) -> NULL
> SUBSTRING('text' FROM NULL FOR 2) -> NULL
> SUBSTRING(NULL FROM 1 FOR 2) -> NULL
> {code}
> Instead, we got errors for these queries:
> {code:sql}
> sql-cli> SELECT SUBSTRING('text' FROM 1 FOR NULL);
> SQL query execution error
> Exception while executing query [query=SELECT SUBSTRING('text' FROM 1 FOR 
> NULL);]. Error message:From line 1, column 8
> to line 1, column 40: Cannot apply 'SUBSTRING' to arguments of type 
> 'SUBSTRING( FROM  FOR )'. Supported form(s): 
> 'SUBSTRING( FROM )'
> 'SUBSTRING( FROM  FOR )'
> 'SUBSTRING( FROM )'
> 'SUBSTRING( FROM  FOR )'
> 'SUBSTRING( FROM )'
> 'SUBSTRING( FROM  FOR )'
> 'SUBSTRING( FROM )'
> 'SUBSTRING( FROM  FOR )'
> sql-cli> SELECT SUBSTRING('text' FROM NULL FOR 2);
> SQL query execution error
> Exception while executing query [query=SELECT SUBSTRING('text' FROM NULL FOR 
> 2);]. Error message:From line 1, column 8
> to line 1, column 40: Cannot apply 'SUBSTRING' to arguments of type 
> 'SUBSTRING( FROM  FOR )'. Supported form(s): 
> 'SUBSTRING( FROM )'
> 'SUBSTRING( FROM  FOR )'
> 'SUBSTRING( FROM )'
> 'SUBSTRING( FROM  FOR )'
> 'SUBSTRING( FROM )'
> 'SUBSTRING( FROM  FOR )'
> 'SUBSTRING( FROM )'
> 'SUBSTRING( FROM  FOR )'
> {code}
> Only such request works fine:
> {code:sql}
> sql-cli> SELECT SUBSTRING(NULL FROM 1 FOR 2);
> ╔═╗
> ║ EXPR$0  ║
> ╠═╣
> ║ null║
> ╚═╝
> {code}



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

[jira] [Updated] (IGNITE-19341) SQL: SUBSTRING function does not support NULL values (try 2)

2023-04-21 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin updated IGNITE-19341:

Description: 
ANSI99 SQL specification ("6.18 ") says the following:
{code:java}
3) If  is specified, then:
  a) Let C be the value of the , ..., and let S be 
the value of the .
  b) If  is specified, then let L be the value of  ...
  c) If either C, S, or L is the null value, then the result of the  is the null value.
{code}
So, we should expect the following behavior:
{code:sql}
SUBSTRING('text' FROM 1 FOR NULL) -> NULL
SUBSTRING('text' FROM NULL FOR 2) -> NULL
SUBSTRING(NULL FROM 1 FOR 2) -> NULL
{code}

Instead, we got errors for these queries:
{code:sql}
sql-cli> SELECT SUBSTRING('text' FROM 1 FOR NULL);
SQL query execution error
Exception while executing query [query=SELECT SUBSTRING('text' FROM 1 FOR 
NULL);]. Error message:From line 1, column 8
to line 1, column 40: Cannot apply 'SUBSTRING' to arguments of type 
'SUBSTRING( FROM  FOR )'. Supported form(s): 
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'

sql-cli> SELECT SUBSTRING('text' FROM NULL FOR 2);
SQL query execution error
Exception while executing query [query=SELECT SUBSTRING('text' FROM NULL FOR 
2);]. Error message:From line 1, column 8
to line 1, column 40: Cannot apply 'SUBSTRING' to arguments of type 
'SUBSTRING( FROM  FOR )'. Supported form(s): 
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
{code}

Only such request works fine:
{code:sql}
sql-cli> SELECT SUBSTRING(NULL FROM 1 FOR 2);
╔═╗
║ EXPR$0  ║
╠═╣
║ null║
╚═╝
{code}

  was:
ANSI99 SQL specification ("6.18 ") says the following:
{code:java}
3) If  is specified, then:
  a) Let C be the value of the , ..., and let S be 
the value of the .
  b) If  is specified, then let L be the value of  ...
  c) If either C, S, or L is the null value, then the result of the  is the null value.
{code}
So, we should expect the following behavior:
{code:sql}
SUBSTRING('text' FROM 1 FOR NULL) -> NULL
SUBSTRING('text' FROM NULL FOR 2) -> NULL
SUBSTRING(NULL FROM 1 FOR 2) -> NULL
{code}
Instead, we got errors for these queries:
{code:sql}
sql-cli> SELECT SUBSTRING('text' FROM 1 FOR NULL);
SQL query execution error
Exception while executing query [query=SELECT SUBSTRING('text' FROM 1 FOR 
NULL);]. Error message:From line 1, column 8 to line 1, column 40: Cannot apply 
'SUBSTRING' to arguments of type 'SUBSTRING( FROM  FOR 
)'. Supported form(s): 'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'

sql-cli> SELECT SUBSTRING('text' FROM NULL FOR 2);
SQL query execution error
Exception while executing query [query=SELECT SUBSTRING('text' FROM NULL FOR 
2);]. Error message:From line 1, column 8 to line 1, column 40: Cannot apply 
'SUBSTRING' to arguments of type 'SUBSTRING( FROM  FOR 
)'. Supported form(s): 'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'

sql-cli> SELECT SUBSTRING(NULL FROM 1 FOR 2);
  (client freezes, no answer at all)
{code}

*Important*: the last query causes {{NullPointerException}} within DB:
{code:java}
2022-12-30 07:32:46:210 + 
[WARNING][node1-srv-worker-1][ClientInboundMessageHandler] Error processing 
client request
java.lang.NullPointerException
at 
org.apache.ignite.internal.sql.SqlColumnTypeConverter.columnTypeToClass(SqlColumnTypeConverter.java:42)
at 
org.apache.ignite.client.handler.JdbcQueryCursorHandlerImpl.createColumnMetadata(JdbcQueryCursorHandlerImpl.java:162)
at 
java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
at 
java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
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.client.handler.JdbcQueryCursorHandlerImpl.queryMetadataAsync(JdbcQueryCursorHandlerImpl.java:133)
at 
org.apache.ignite.client.handler.requests.jdbc.ClientJdbcQueryMetadataRequest.process(ClientJdbcQueryMetadataRequest.java:47)
at

[jira] [Created] (IGNITE-19341) SQL: SUBSTRING function does not support NULL values (try 2)

2023-04-21 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-19341:
---

 Summary: SQL: SUBSTRING function does not support NULL values (try 
2)
 Key: IGNITE-19341
 URL: https://issues.apache.org/jira/browse/IGNITE-19341
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Andrey Khitrin
Assignee: Andrey Mashenkov
 Fix For: 3.0.0-beta2


ANSI99 SQL specification ("6.18 ") says the following:
{code:java}
3) If  is specified, then:
  a) Let C be the value of the , ..., and let S be 
the value of the .
  b) If  is specified, then let L be the value of  ...
  c) If either C, S, or L is the null value, then the result of the  is the null value.
{code}
So, we should expect the following behavior:
{code:sql}
SUBSTRING('text' FROM 1 FOR NULL) -> NULL
SUBSTRING('text' FROM NULL FOR 2) -> NULL
SUBSTRING(NULL FROM 1 FOR 2) -> NULL
{code}
Instead, we got errors for these queries:
{code:sql}
sql-cli> SELECT SUBSTRING('text' FROM 1 FOR NULL);
SQL query execution error
Exception while executing query [query=SELECT SUBSTRING('text' FROM 1 FOR 
NULL);]. Error message:From line 1, column 8 to line 1, column 40: Cannot apply 
'SUBSTRING' to arguments of type 'SUBSTRING( FROM  FOR 
)'. Supported form(s): 'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'

sql-cli> SELECT SUBSTRING('text' FROM NULL FOR 2);
SQL query execution error
Exception while executing query [query=SELECT SUBSTRING('text' FROM NULL FOR 
2);]. Error message:From line 1, column 8 to line 1, column 40: Cannot apply 
'SUBSTRING' to arguments of type 'SUBSTRING( FROM  FOR 
)'. Supported form(s): 'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'

sql-cli> SELECT SUBSTRING(NULL FROM 1 FOR 2);
  (client freezes, no answer at all)
{code}

*Important*: the last query causes {{NullPointerException}} within DB:
{code:java}
2022-12-30 07:32:46:210 + 
[WARNING][node1-srv-worker-1][ClientInboundMessageHandler] Error processing 
client request
java.lang.NullPointerException
at 
org.apache.ignite.internal.sql.SqlColumnTypeConverter.columnTypeToClass(SqlColumnTypeConverter.java:42)
at 
org.apache.ignite.client.handler.JdbcQueryCursorHandlerImpl.createColumnMetadata(JdbcQueryCursorHandlerImpl.java:162)
at 
java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
at 
java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
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.client.handler.JdbcQueryCursorHandlerImpl.queryMetadataAsync(JdbcQueryCursorHandlerImpl.java:133)
at 
org.apache.ignite.client.handler.requests.jdbc.ClientJdbcQueryMetadataRequest.process(ClientJdbcQueryMetadataRequest.java:47)
at 
org.apache.ignite.client.handler.ClientInboundMessageHandler.processOperation(ClientInboundMessageHandler.java:454)
at 
org.apache.ignite.client.handler.ClientInboundMessageHandler.processOperation(ClientInboundMessageHandler.java:336)
at 
org.apache.ignite.client.handler.ClientInboundMessageHandler.channelRead(ClientInboundMessageHandler.java:187)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at 
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:327)
at 
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:299)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at 
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
at

[jira] [Commented] (IGNITE-18488) SQL: SUBSTRING function does not support NULL values

2023-04-19 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin commented on IGNITE-18488:
-

[~amashenkov] [~korlov]
Guys, do I understand correctly that the only 1 case of 3 was fixed here?
{code:sql}
sql-cli> SELECT SUBSTRING(NULL FROM 1 FOR 2);
╔═╗
║ EXPR$0  ║
╠═╣
║ null║
╚═╝
{code}
I still got an error on the fresh AI3 for this query:
{code:sql}
sql-cli> SELECT SUBSTRING('text' FROM 1 FOR NULL);
SQL query execution error
Exception while executing query [query=SELECT SUBSTRING('text' FROM 1 FOR 
NULL);]. Error message:From line 1, column 8
to line 1, column 40: Cannot apply 'SUBSTRING' to arguments of type 
'SUBSTRING( FROM  FOR )'. Supported form(s): 
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
{code}
And for this one:
{code:sql}
sql-cli> SELECT SUBSTRING('text' FROM NULL FOR 2);
SQL query execution error
Exception while executing query [query=SELECT SUBSTRING('text' FROM NULL FOR 
2);]. Error message:From line 1, column 8
to line 1, column 40: Cannot apply 'SUBSTRING' to arguments of type 
'SUBSTRING( FROM  FOR )'. Supported form(s): 
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
{code}
Please correct me if I'm wrong. What should we do with remaining two cases? 
They're also a part of the ANSI99 SQL spec.

> SQL: SUBSTRING function does not support NULL values
> 
>
> Key: IGNITE-18488
> URL: https://issues.apache.org/jira/browse/IGNITE-18488
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Assignee: Andrey Mashenkov
>Priority: Major
>  Labels: ignite-3, sql
> Fix For: 3.0.0-beta2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> ANSI99 SQL specification ("6.18 ") says the following:
> {code:java}
> 3) If  is specified, then:
>   a) Let C be the value of the , ..., and let S 
> be the value of the .
>   b) If  is specified, then let L be the value of  length> ...
>   c) If either C, S, or L is the null value, then the result of the 
>  is the null value.
> {code}
> So, we should expect the following behavior:
> {code:sql}
> SUBSTRING('text' FROM 1 FOR NULL) -> NULL
> SUBSTRING('text' FROM NULL FOR 2) -> NULL
> SUBSTRING(NULL FROM 1 FOR 2) -> NULL
> {code}
> Instead, we got errors for these queries:
> {code:sql}
> sql-cli> SELECT SUBSTRING('text' FROM 1 FOR NULL);
> SQL query execution error
> Exception while executing query [query=SELECT SUBSTRING('text' FROM 1 FOR 
> NULL);]. Error message:From line 1, column 8 to line 1, column 40: Cannot 
> apply 'SUBSTRING' to arguments of type 'SUBSTRING( FROM  
> FOR )'. Supported form(s): 'SUBSTRING( FROM )'
> 'SUBSTRING( FROM  FOR )'
> 'SUBSTRING( FROM )'
> 'SUBSTRING( FROM  FOR )'
> 'SUBSTRING( FROM )'
> 'SUBSTRING( FROM  FOR )'
> 'SUBSTRING( FROM )'
> 'SUBSTRING( FROM  FOR )'
> sql-cli> SELECT SUBSTRING('text' FROM NULL FOR 2);
> SQL query execution error
> Exception while executing query [query=SELECT SUBSTRING('text' FROM NULL FOR 
> 2);]. Error message:From line 1, column 8 to line 1, column 40: Cannot apply 
> 'SUBSTRING' to arguments of type 'SUBSTRING( FROM  FOR 
> )'. Supported form(s): 'SUBSTRING( FROM )'
> 'SUBSTRING( FROM  FOR )'
> 'SUBSTRING( FROM )'
> 'SUBSTRING( FROM  FOR )'
> 'SUBSTRING( FROM )'
> 'SUBSTRING( FROM  FOR )'
> 'SUBSTRING( FROM )'
> 'SUBSTRING( FROM  FOR )'
> sql-cli> SELECT SUBSTRING(NULL FROM 1 FOR 2);
>   (client freezes, no answer at all)
> {code}
> *Important*: the last query causes {{NullPointerException}} within DB:
> {code:java}
> 2022-12-30 07:32:46:210 + 
> [WARNING][node1-srv-worker-1][ClientInboundMessageHandler] Error processing 
> client request
> java.lang.NullPointerException
> at 
> org.apache.ignite.internal.sql.SqlColumnTypeConverter.columnTypeToClass(SqlColumnTypeConverter.java:42)
> at 
> org.apache.ignite.client.handler.JdbcQueryCursorHandlerImpl.createColumnMetadata(JdbcQueryCursorHandlerImpl.java:162)
> at 
> java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
> at 
> java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
> 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)
>

[jira] [Created] (IGNITE-18492) SQL: Inconsistent behavior of LENGTH limit for CHAR data type

2022-12-30 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-18492:
---

 Summary: SQL: Inconsistent behavior of LENGTH limit for CHAR data 
type
 Key: IGNITE-18492
 URL: https://issues.apache.org/jira/browse/IGNITE-18492
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Andrey Khitrin


When I create a table with {{CHAR(length)}} column, it's still possible to 
insert character values with length greater than given limit.
{code:sql}
sql-cli> create table xx (pk int primary key, f1 char(5));
Updated 0 rows.
sql-cli> insert into xx values (1, 'abcdefgh');
Updated 1 rows.
sql-cli> select * from xx;
╔╤══╗
║ PK │ F1   ║
╠╪══╣
║ 1  │ abcdefgh ║
╚╧══╝
{code}
In other hand, length limit is applied when I insert non-char value that's 
casted into {{CHAR}} implicitly. With the same table as above:
{code:sql}
sql-cli> insert into xx values (2, 1234567);
Updated 1 rows.
sql-cli> select * from xx;
╔╤══╗
║ PK │ F1   ║
╠╪══╣
║ 2  │ 12345║
╟┼──╢
║ 1  │ abcdefgh ║
╚╧══╝
{code}
Behavior should be consistent: ether strip both values down to the given length 
limit, or deny to insert too long values in both cases (like it's done in other 
DBs, like postgresql).



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

[jira] [Created] (IGNITE-18488) SQL: SUBSTRING function does not support NULL values

2022-12-29 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-18488:
---

 Summary: SQL: SUBSTRING function does not support NULL values
 Key: IGNITE-18488
 URL: https://issues.apache.org/jira/browse/IGNITE-18488
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Andrey Khitrin


ANSI99 SQL specification ("6.18 ") says the following:
{code:java}
3) If  is specified, then:
  a) Let C be the value of the , ..., and let S be 
the value of the .
  b) If  is specified, then let L be the value of  ...
  c) If either C, S, or L is the null value, then the result of the  is the null value.
{code}
So, we should expect the following behavior:
{code:sql}
SUBSTRING('text' FROM 1 FOR NULL) -> NULL
SUBSTRING('text' FROM NULL FOR 2) -> NULL
SUBSTRING(NULL FROM 1 FOR 2) -> NULL
{code}
Instead, we got errors for these queries:
{code:sql}
sql-cli> SELECT SUBSTRING('text' FROM 1 FOR NULL);
SQL query execution error
Exception while executing query [query=SELECT SUBSTRING('text' FROM 1 FOR 
NULL);]. Error message:From line 1, column 8 to line 1, column 40: Cannot apply 
'SUBSTRING' to arguments of type 'SUBSTRING( FROM  FOR 
)'. Supported form(s): 'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'

sql-cli> SELECT SUBSTRING('text' FROM NULL FOR 2);
SQL query execution error
Exception while executing query [query=SELECT SUBSTRING('text' FROM NULL FOR 
2);]. Error message:From line 1, column 8 to line 1, column 40: Cannot apply 
'SUBSTRING' to arguments of type 'SUBSTRING( FROM  FOR 
)'. Supported form(s): 'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'
'SUBSTRING( FROM )'
'SUBSTRING( FROM  FOR )'

sql-cli> SELECT SUBSTRING(NULL FROM 1 FOR 2);
  (client freezes, no answer at all)
{code}

*Important*: the last query causes {{NullPointerException}} within DB:
{code:java}
2022-12-30 07:32:46:210 + 
[WARNING][node1-srv-worker-1][ClientInboundMessageHandler] Error processing 
client request
java.lang.NullPointerException
at 
org.apache.ignite.internal.sql.SqlColumnTypeConverter.columnTypeToClass(SqlColumnTypeConverter.java:42)
at 
org.apache.ignite.client.handler.JdbcQueryCursorHandlerImpl.createColumnMetadata(JdbcQueryCursorHandlerImpl.java:162)
at 
java.base/java.util.stream.ReferencePipeline$3$1.accept(ReferencePipeline.java:195)
at 
java.base/java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1655)
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.client.handler.JdbcQueryCursorHandlerImpl.queryMetadataAsync(JdbcQueryCursorHandlerImpl.java:133)
at 
org.apache.ignite.client.handler.requests.jdbc.ClientJdbcQueryMetadataRequest.process(ClientJdbcQueryMetadataRequest.java:47)
at 
org.apache.ignite.client.handler.ClientInboundMessageHandler.processOperation(ClientInboundMessageHandler.java:454)
at 
org.apache.ignite.client.handler.ClientInboundMessageHandler.processOperation(ClientInboundMessageHandler.java:336)
at 
org.apache.ignite.client.handler.ClientInboundMessageHandler.channelRead(ClientInboundMessageHandler.java:187)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at 
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:327)
at 
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:299)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at 
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at

[jira] [Commented] (IGNITE-18300) Node cannot properly start after failure in index creation

2022-11-30 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin commented on IGNITE-18300:
-

Succesfully reproduced.
 # On a fresh DB, create a table and two indices, put some data:

{code:sql}
sql-cli> CREATE TABLE test_indices (field1 INTEGER PRIMARY KEY, field2 INTEGER, 
field3 INTEGER);
Updated 0 rows.
sql-cli> CREATE INDEX ti1 ON test_indices (field2);
Updated 0 rows.
sql-cli> INSERT INTO test_indices VALUES(1, 1, 1);
Updated 1 rows.
sql-cli> CREATE INDEX ti2 ON test_indices (field3, field1);
Updated 0 rows.
sql-cli> INSERT INTO test_indices VALUES(2, 1, 0);
Updated 1 rows.
sql-cli> SELECT * FROM test_indices;
╔╤╤╗
║ FIELD1 │ FIELD2 │ FIELD3 ║
╠╪╪╣
║ 2      │ 1      │ 0      ║
╟┼┼╢
║ 1      │ 1      │ 1      ║
╚╧╧╝ {code}
2. Exit from SQL console and restart DB (e.g., via `systemctl restart 
ignite3db.service`).

3. After restart, we got a block

 

> Node cannot properly start after failure in index creation
> --
>
> Key: IGNITE-18300
> URL: https://issues.apache.org/jira/browse/IGNITE-18300
> Project: Ignite
>  Issue Type: Bug
>  Components: ignite-3
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
>  Labels: sql
> Attachments: ignite3-cli.dump, ignite3-db.dump, logs.tgz
>
>
> I play with AI3 beta on a virtual machine (a single node). I tried to create 
> a SQL index on a table (unsuccessfully), and now I couldn't even work with a 
> node.
> Symptoms:
>  # ignite3 CLI connects to DB node but cannot execute any command properly. 
> Because of auto completion, it asks DB for a list of existing tables and 
> waits for it forever. For end user, it looks like CLI freezes. Probably, 
> that's a separate issue.
>  # Ignite3 DB cannot respond to CLI because it's struck in endless waiting.
> I don't remember well what caused this issue. Most probably, it happened 
> because of different `CREATE INDEX` commands I played with before. I've made 
> thread dumps both for CLI and DB processes, and also attached all exisitng DB 
> logs (within .tgz file). Hope this helps.



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

[jira] [Updated] (IGNITE-18300) Node cannot properly start after failure in index creation

2022-11-30 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin updated IGNITE-18300:

Summary: Node cannot properly start after failure in index creation  (was: 
Node cannot properly start node after failure in index creation)

> Node cannot properly start after failure in index creation
> --
>
> Key: IGNITE-18300
> URL: https://issues.apache.org/jira/browse/IGNITE-18300
> Project: Ignite
>  Issue Type: Bug
>  Components: ignite-3
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
>  Labels: sql
> Attachments: ignite3-cli.dump, ignite3-db.dump, logs.tgz
>
>
> I play with AI3 beta on a virtual machine (a single node). I tried to create 
> a SQL index on a table (unsuccessfully), and now I couldn't even work with a 
> node.
> Symptoms:
>  # ignite3 CLI connects to DB node but cannot execute any command properly. 
> Because of auto completion, it asks DB for a list of existing tables and 
> waits for it forever. For end user, it looks like CLI freezes. Probably, 
> that's a separate issue.
>  # Ignite3 DB cannot respond to CLI because it's struck in endless waiting.
> I don't remember well what caused this issue. Most probably, it happened 
> because of different `CREATE INDEX` commands I played with before. I've made 
> thread dumps both for CLI and DB processes, and also attached all exisitng DB 
> logs (within .tgz file). Hope this helps.



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

[jira] [Created] (IGNITE-18300) Node cannot properly start node after failure in index creation

2022-11-30 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-18300:
---

 Summary: Node cannot properly start node after failure in index 
creation
 Key: IGNITE-18300
 URL: https://issues.apache.org/jira/browse/IGNITE-18300
 Project: Ignite
  Issue Type: Bug
  Components: ignite-3
Affects Versions: 3.0.0-beta1
Reporter: Andrey Khitrin
 Attachments: ignite3-cli.dump, ignite3-db.dump, logs.tgz

I play with AI3 beta on a virtual machine (a single node). I tried to create a 
SQL index on a table (unsuccessfully), and now I couldn't even work with a node.

Symptoms:
 # ignite3 CLI connects to DB node but cannot execute any command properly. 
Because of auto completion, it asks DB for a list of existing tables and waits 
for it forever. For end user, it looks like CLI freezes. Probably, that's a 
separate issue.
 # Ignite3 DB cannot respond to CLI because it's struck in endless waiting.

I don't remember well what caused this issue. Most probably, it happened 
because of different `CREATE INDEX` commands I played with before. I've made 
thread dumps both for CLI and DB processes, and also attached all exisitng DB 
logs (within .tgz file). Hope this helps.



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

[jira] [Updated] (IGNITE-18218) Cluster initialization should be covered in docs better

2022-11-21 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin updated IGNITE-18218:

Description: 
While playing with AI3 beta1 deb package, I've noticed that 'ignite3db' service 
doesn't join any cluster after being installed and started. That may be fine 
from the DB's point of view, but this behavior may not obvious for a mere user. 
In order to make AI3 ready to work, user needs to run 'ignite3 cluster init 
...' first. Unfortunately, this point is not currently covered properly neither 
in [DEVNOTES.md|https://github.com/apache/ignite-3/blob/main/DEVNOTES.md] nor 
in [existing 
docs|https://ignite.apache.org/docs/3.0.0-beta/quick-start/getting-started-guide].
 Command 'systemctl status ignite3db.service' says "active (running)", command 
'ignite3 node status' shows "state: starting", DB log says "Components started, 
joining the cluster". Everything seem to work fine, but the next user's step is 
not obvious here. User may try to open SQL console but it will not work until 
cluster is initialized.


I'm afraid a significant part of newcomers may be discouraged by this behavior. 
They could be a step close to the final line, but think "it doesn't work with 
no reason", and refuse to try AI3 anymore. To avoid this, some words about 
"cluster init" should be added to "Getting started guide" and, probably, to 
DEVNOTES.

  was:
While playing with AI3 beta1 deb package, I've noticed that 'ignite3db' service 
doesn't join any cluster after being installed and started. That may be fine 
from the DB's point of view, but this behavior may not obvious for a mere user. 
In order to make AI3 ready to work, user needs to run 'ignite3 cluster init 
...' first. Unfortunately, this point is not currently covered properly neither 
in [DEVNOTES.md|https://github.com/apache/ignite-3/blob/main/DEVNOTES.md] nor 
in [existing 
docs|https://ignite.apache.org/docs/3.0.0-beta/quick-start/getting-started-guide].
 Command 'systemctl status ignite3db.service' says "active (running)", command 
'ignite3 node status' shows "state: starting", DB log says "Components started, 
joining the cluster".  Everything seem to work fine, but the next user's step 
is not obvious here. User may try to open SQL console but it will not work 
until cluster is initialized.
I'm afraid a significant part of newcomers may be discouraged by this behavior. 
They could be a step close to the final line, but think "it doesn't work with 
no reason", and refuse to try AI3 anymore. To avoid this, some words about 
"cluster init" should be added to "Getting started guide" and, probably, to 
DEVNOTES.


> Cluster initialization should be covered in docs better
> ---
>
> Key: IGNITE-18218
> URL: https://issues.apache.org/jira/browse/IGNITE-18218
> Project: Ignite
>  Issue Type: Improvement
>  Components: documentation
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
>  Labels: ignite-3
>
> While playing with AI3 beta1 deb package, I've noticed that 'ignite3db' 
> service doesn't join any cluster after being installed and started. That may 
> be fine from the DB's point of view, but this behavior may not obvious for a 
> mere user. In order to make AI3 ready to work, user needs to run 'ignite3 
> cluster init ...' first. Unfortunately, this point is not currently covered 
> properly neither in 
> [DEVNOTES.md|https://github.com/apache/ignite-3/blob/main/DEVNOTES.md] nor in 
> [existing 
> docs|https://ignite.apache.org/docs/3.0.0-beta/quick-start/getting-started-guide].
>  Command 'systemctl status ignite3db.service' says "active (running)", 
> command 'ignite3 node status' shows "state: starting", DB log says 
> "Components started, joining the cluster". Everything seem to work fine, but 
> the next user's step is not obvious here. User may try to open SQL console 
> but it will not work until cluster is initialized.
> I'm afraid a significant part of newcomers may be discouraged by this 
> behavior. They could be a step close to the final line, but think "it doesn't 
> work with no reason", and refuse to try AI3 anymore. To avoid this, some 
> words about "cluster init" should be added to "Getting started guide" and, 
> probably, to DEVNOTES.



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

[jira] [Created] (IGNITE-18218) Cluster initialization should be covered in docs better

2022-11-21 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-18218:
---

 Summary: Cluster initialization should be covered in docs better
 Key: IGNITE-18218
 URL: https://issues.apache.org/jira/browse/IGNITE-18218
 Project: Ignite
  Issue Type: Improvement
  Components: documentation
Affects Versions: 3.0.0-beta1
Reporter: Andrey Khitrin


While playing with AI3 beta1 deb package, I've noticed that 'ignite3db' service 
doesn't join any cluster after being installed and started. That may be fine 
from the DB's point of view, but this behavior may not obvious for a mere user. 
In order to make AI3 ready to work, user needs to run 'ignite3 cluster init 
...' first. Unfortunately, this point is not currently covered properly neither 
in [DEVNOTES.md|https://github.com/apache/ignite-3/blob/main/DEVNOTES.md] nor 
in [existing 
docs|https://ignite.apache.org/docs/3.0.0-beta/quick-start/getting-started-guide].
 Command 'systemctl status ignite3db.service' says "active (running)", command 
'ignite3 node status' shows "state: starting", DB log says "Components started, 
joining the cluster".  Everything seem to work fine, but the next user's step 
is not obvious here. User may try to open SQL console but it will not work 
until cluster is initialized.
I'm afraid a significant part of newcomers may be discouraged by this behavior. 
They could be a step close to the final line, but think "it doesn't work with 
no reason", and refuse to try AI3 anymore. To avoid this, some words about 
"cluster init" should be added to "Getting started guide" and, probably, to 
DEVNOTES.



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

[jira] [Created] (IGNITE-18191) Add specific Java launch arguments for Java 15+ for .NET platform

2022-11-18 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-18191:
---

 Summary: Add specific Java launch arguments for Java 15+ for .NET 
platform
 Key: IGNITE-18191
 URL: https://issues.apache.org/jira/browse/IGNITE-18191
 Project: Ignite
  Issue Type: Improvement
  Components: platforms
Reporter: Andrey Khitrin


Looks like .Net platform and examples do not support recent versions of Java. 
It requires a special set of JVM arguments to run AI on Java 15+ (see 
[jvmdefaults.sh|https://github.com/apache/ignite/blob/master/bin/include/jvmdefaults.sh]),
 but .Net runner only contains checks and arguments for Java 9+ (see 
[Jmv.cs|https://github.com/apache/ignite/blob/master/modules/platforms/dotnet/Apache.Ignite.Core/Impl/Unmanaged/Jni/Jvm.cs]).
 Looks like new arguments should be added here.



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

[jira] [Created] (IGNITE-18175) SQL: value out of type bounds is converted into 0 during implicit casting

2022-11-16 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-18175:
---

 Summary: SQL: value out of type bounds is converted into 0 during 
implicit casting
 Key: IGNITE-18175
 URL: https://issues.apache.org/jira/browse/IGNITE-18175
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Andrey Khitrin


A simple scenario:
{code:sql}
create table test_e011_INTEGER_from (key_field INT PRIMARY KEY, field1 INTEGER);
insert into test_e011_INTEGER_from (key_field, field1) values (1, -2147483648);

create table test_e011_SMALLINT (key_field INT PRIMARY KEY, field1_SMALLINT 
SMALLINT);
insert into test_e011_SMALLINT (key_field, field1_SMALLINT) values (1, (select 
field1 from test_e011_INTEGER_from where key_field=1));

select * from test_e011_SMALLINT;
{code}
I expect it either  to return '1, null' (like in postrgres or sqlite3) or to 
raise an error on insert (like in GG8) as value of -2147483648 is out of bounds 
for SMALLINT data type.
Instead, '1, 0' is stored within test_e011_SMALLINT table and returned from 
select. In other words, -2147483648 was converted into 0. Such behavior seems 
as incorrect.



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

[jira] [Created] (IGNITE-18174) SQL: implement expanded NULL predicate

2022-11-16 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-18174:
---

 Summary: SQL: implement expanded NULL predicate
 Key: IGNITE-18174
 URL: https://issues.apache.org/jira/browse/IGNITE-18174
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Reporter: Andrey Khitrin


"Expanded NULL predicate" is referenced in SQL standard as F481 feature. It 
allows to use something other than a column reference as row value expression.

The following query works in AI2:
{code:sql}
create table tmp_simple_table (key_field INT PRIMARY KEY,x INT,y INT,z INT);
insert into tmp_simple_table (key_field,x,y,z) values (1, 1,1,1);
insert into tmp_simple_table (key_field,x,y,z) values (2, 2,2,2);
insert into tmp_simple_table (key_field,x,y,z) values (3, null,3,null);
insert into tmp_simple_table (key_field,x,y,z) values (4, 4,null,null);
insert into tmp_simple_table (key_field,x,y,z) values (5, null,null,null);
select x, y, z from tmp_simple_table t 
  where (select x, z from tmp_simple_table where x=t.x and y=t.y and z=t.z) is 
not NULL;  -- expanded NULL predicate
{code}
But in AI3 beta1 it's not implemented yet.



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

[jira] [Created] (IGNITE-18173) SQL: implement EVERY and SOME aggregate functions

2022-11-16 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-18173:
---

 Summary: SQL: implement EVERY and SOME aggregate functions
 Key: IGNITE-18173
 URL: https://issues.apache.org/jira/browse/IGNITE-18173
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Reporter: Andrey Khitrin


Aggregate functions EVERY and SOME are part of SQL standard. Unfortunately, 
they're not implemented in AI3 beta1 yet. Could you please implement them?

In AI2, they work in the following manner:
{code:sql}
create table tmp_table_age_name_wage (key_field INT PRIMARY KEY,AGE INT,field1 
VARCHAR,field2 INT);
insert into tmp_table_age_name_wage (key_field,AGE,field1,field2) values (1, 
42,'John',10);
insert into tmp_table_age_name_wage (key_field,AGE,field1,field2) values (2, 
43,'Jack',5);
insert into tmp_table_age_name_wage (key_field,AGE,field1,field2) values (3, 
42,'Jen',3);
insert into tmp_table_age_name_wage (key_field,AGE,field1,field2) values (4, 
42,'Jim',7);
insert into tmp_table_age_name_wage (key_field,AGE,field1,field2) values (5, 
41,'Jess',3);
insert into tmp_table_age_name_wage (key_field,AGE,field1,field2) values (6, 
50,'Joe',4);
insert into tmp_table_age_name_wage (key_field,AGE,field1,field2) values (7, 
43,'Jeff',2);
insert into tmp_table_age_name_wage (key_field,AGE,field1,field2) values (8, 
32,'Joel',8);
insert into tmp_table_age_name_wage (key_field,AGE,field1,field2) values (9, 
33,'Joe',3);
insert into tmp_table_age_name_wage (key_field,AGE,field1,field2) values (10, 
41,'Jill',9);
SELECT EVERY(AGE > 20) FROM tmp_table_age_name_wage;--> true
SELECT EVERY(AGE > 40) FROM tmp_table_age_name_wage;--> false
SELECT SOME(field2 = 9) FROM tmp_table_age_name_wage;   --> true
SELECT SOME(field2 <> 9) FROM tmp_table_age_name_wage;  --> true
{code}




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

[jira] [Created] (IGNITE-18168) SQL: incorrect sum of several FLOAT values

2022-11-15 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-18168:
---

 Summary: SQL: incorrect sum of several FLOAT values
 Key: IGNITE-18168
 URL: https://issues.apache.org/jira/browse/IGNITE-18168
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Andrey Khitrin


This behavior seems incorrect:
{code:sql}
create table xx (key_field INT PRIMARY KEY,field2 FLOAT);
insert into xx (key_field,field2) values (1, 10);
insert into xx (key_field,field2) values (2, 5);
insert into xx (key_field,field2) values (3, 3);
insert into xx (key_field,field2) values (4, 5.1);
insert into xx (key_field,field2) values (5, 3);
insert into xx (key_field,field2) values (6, 4);
insert into xx (key_field,field2) values (7, 2);
insert into xx (key_field,field2) values (8, 8);
insert into xx (key_field,field2) values (9, 3);
insert into xx (key_field,field2) values (10,9);
insert into xx (key_field,field2) values (11,9);
SELECT SUM(field2) FROM xx;
--> returns 61.1015625, expected 61.1
{code}
 



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

[jira] [Created] (IGNITE-18167) SQL: incorrect NULLIF behavior

2022-11-15 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-18167:
---

 Summary: SQL: incorrect NULLIF behavior
 Key: IGNITE-18167
 URL: https://issues.apache.org/jira/browse/IGNITE-18167
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Andrey Khitrin


A SQL spec says the following:

??NULLIF (V1 , V2) is equivalent to the following : CASE 
WHEN V1 = V2 THEN NULL ELSE V1 END??

When I try to run it, the rule above is true only for the simplest cases.

{code:sql}
select NULLIF(25, 25);  --> null(OK)
select NULLIF(24, 25);  --> 24  (OK)
select NULLIF('test', 'abc');   --> 'test'  (OK)
select NULLIF('test', 'test');  --> ''  (should be null!)
select NULLIF(24 + 1, 26 - 1);  --> error IGN-SQL-27(should be null!)
{code}

Probably, there are two defects: one is for wrong return value in case of 
textual data, and another one is for error when expression within NULLIF is 
used.



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

[jira] [Created] (IGNITE-18166) SQL: LIKE predicate is not supported for BINARY data

2022-11-15 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-18166:
---

 Summary: SQL: LIKE predicate is not supported for BINARY data
 Key: IGNITE-18166
 URL: https://issues.apache.org/jira/browse/IGNITE-18166
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 3.0.0-beta1
Reporter: Andrey Khitrin


A 'T022' feature in SQL standard allows to use LIKE predicate for BINARY data. 
Unfortunately, it is not supported in AI3 beta1:
{code:sql}
create table tmp_table_binary (key_field INT PRIMARY KEY,field1 BINARY);
INSERT INTO tmp_table_binary (key_field, field1) values(1, '00ffaa');
INSERT INTO tmp_table_binary (key_field, field1) values(2, 'ffcc');
select * from tmp_table_binary where field1 like '%ff%'; -- 
expected to return both rows
select * from tmp_table_binary where field1 like '_f%';  -- 
expected to return 'ffcc'
select * from tmp_table_binary where field1 like '_fc_'; -- 
expected to return 'ffcc'
{code}
Instead of returning data, all queries show the following error:
{code:java}
Error: Exception while executing query [query=select * from tmp_table_binary 
where field1 like '%ff%']. Error message:From line 1, column 38 to line 1, 
column 55: Cannot apply 'LIKE' to arguments of type 'LIKE(, 
)'. Supported form(s): 'LIKE(, , )' 
(state=5,code=0)
java.sql.SQLException: Exception while executing query [query=select * from 
tmp_table_binary where field1 like '%ff%']. Error message:From line 1, column 
38 to line 1, column 55: Cannot apply 'LIKE' to arguments of type 
'LIKE(, )'. Supported form(s): 'LIKE(, , 
)'
at 
org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
at 
org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:148)
at 
org.apache.ignite.internal.jdbc.JdbcStatement.execute(JdbcStatement.java:341)
...
{code}



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

[jira] [Commented] (IGNITE-17997) Whitespaces at the end are ignored during string comparison

2022-10-28 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin commented on IGNITE-17997:
-

Thank you, I see expected behavior with `VARCHAR`:

{code:sql}
sql-cli> select cast('a' AS VARCHAR) = cast('a' AS VARCHAR) as test;
╔═╗
║ TEST║
╠═╣
║ true║
╚═╝

sql-cli> select cast('a' AS VARCHAR) = cast('a ' AS VARCHAR) as test;
╔═╗
║ TEST║
╠═╣
║ false   ║
╚═╝
{code}

> Whitespaces at the end are ignored during string comparison
> ---
>
> Key: IGNITE-17997
> URL: https://issues.apache.org/jira/browse/IGNITE-17997
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
>
> In 3.0.0-Beta-1:
> {code:java}
> sql-cli> select 'a' = 'a' as t1, 'a' = 'b' as t2, 'a' = 'a   ' as t3, 'a' = ' 
>   a' as t4;
> ╔══╤═══╤══╤═══╗
> ║ T1   │ T2    │ T3   │ T4    ║
> ╠══╪═══╪══╪═══╣
> ║ true │ false │ true │ false ║
> ╚══╧═══╧══╧═══╝
> {code}
> Tests T1, T2, and T4 show correct behavior. But in test T2 we see that string 
> 'a' is considered being equal to string 'a   '  (same string but with 
> arbitrary amount of whitespaces at the end). This is incorrect behavior.
> This issue may have the same nature as IGNITE-17996, but it's just a 
> hypothesis.



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

[jira] [Created] (IGNITE-18001) Ignite node may become unavailable after some play with SQL

2022-10-27 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-18001:
---

 Summary: Ignite node may become unavailable after some play with 
SQL
 Key: IGNITE-18001
 URL: https://issues.apache.org/jira/browse/IGNITE-18001
 Project: Ignite
  Issue Type: Bug
Affects Versions: 3.0.0-beta1
Reporter: Andrey Khitrin
 Attachments: ignite3db-0.log, ignite3db-1.log

Steps to reproduce:
 # Start AI3 node, init cluster
 # Connect to node via Ignite3 CLI
 # Open SQL console in Ignite3 CLI
 # Play with SQL queries: create tables, invoke select queries, drop tables, so 
on. Probably, this step is not needed. Probably, it may be important to perform 
some queries with errors.
 # Wait for some time (30-60 mins) having SQL console open.
 # Try to execute new query after the pause. It {*}hangs{*}.

In DB log, a lot of the following errors occur (some of them could occur even 
before step 6 above):
{code}
2022-10-27 18:15:57:391 +0400 
[WARNING][%defaultNode%Raft-Group-Client-11][RaftGroupServiceImpl] Recoverable 
error duri
ng the request type=ActionRequestImpl occurred (will be retried on the randomly 
selected node):
java.util.concurrent.TimeoutException
at 
java.base/java.util.concurrent.CompletableFuture$Timeout.run(CompletableFuture.java:2792)
at 
java.base/java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:515)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at 
java.base/java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecut
or.java:304)
at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
2022-10-27 18:17:21:376 +0400 
[INFO][%defaultNode%checkpoint-thread-1][Checkpoint] Skipping checkpoint (no 
pages were m
odified) [checkpointBeforeWriteLockTime=0ms, checkpointWriteLockWait=0ms, 
checkpointListenersExecuteTime=0ms, checkpoin
tWriteLockHoldTime=0ms, reason='timeout']
{code}

After attempt to restart node (`./bin/ignite3db.sh stop && ./bin/ignite3db.sh 
start`) another stacktrace occurs in log:
{code}2022-10-27 18:24:06:489 +0400 
[INFO][ForkJoinPool.commonPool-worker-9][ClientHandlerModule] Thin client 
protocol started successfully[port=10800]
2022-10-27 18:24:06:490 +0400 
[INFO][ForkJoinPool.commonPool-worker-9][IgniteImpl] Components started, 
performing recovery
2022-10-27 18:24:06:868 +0400 
[INFO][ForkJoinPool.commonPool-worker-9][ConfigurationRegistry] Failed to 
notify configuration listener
java.util.NoSuchElementException: 
table.tables.ee9c42e0-9b96-4164-b13b-8bec99d3171a.assignments
at 
org.apache.ignite.internal.configuration.util.ConfigurationUtil.findEx(ConfigurationUtil.java:852)
at 
org.apache.ignite.internal.configuration.ConfigurationChanger.getLatest(ConfigurationChanger.java:439)
at 
org.apache.ignite.internal.configuration.direct.DirectPropertyProxy.value(DirectPropertyProxy.java:65)
at 
org.apache.ignite.internal.table.distributed.TableManager.updateAssignmentInternal(TableManager.java:652)
at 
org.apache.ignite.internal.table.distributed.TableManager.onUpdateAssignments(TableManager.java:616)
at 
org.apache.ignite.internal.configuration.notifications.ConfigurationNotifier.notifyPublicListeners(ConfigurationNotifier.java:492)
at 
org.apache.ignite.internal.configuration.notifications.ConfigurationNotifier$2.visitLeafNode(ConfigurationNotifier.java:374)
at 
org.apache.ignite.internal.configuration.notifications.ConfigurationNotifier$2.visitLeafNode(ConfigurationNotifier.java:370)
at 
org.apache.ignite.internal.schema.configuration.TableNode.traverseChildren(Unknown
 Source)
at 
org.apache.ignite.internal.configuration.notifications.ConfigurationNotifier.notifyListeners(ConfigurationNotifier.java:370)
at 
org.apache.ignite.internal.configuration.notifications.ConfigurationNotifier$2.visitNamedListNode(ConfigurationNotifier.java:460)
at 
org.apache.ignite.internal.configuration.notifications.ConfigurationNotifier$2.visitNamedListNode(ConfigurationNotifier.java:370)
at 
org.apache.ignite.internal.schema.configuration.TablesNode.traverseChildren(Unknown
 Source)
at 
org.apache.ignite.internal.configuration.notifications.ConfigurationNotifier.notifyListeners(ConfigurationNotifier.java:370)
at 
org.apache.ignite.internal.configuration.notifications.ConfigurationNotifier.notifyListeners(ConfigurationNotifier.java:88)
at 
org.apache.ignite.internal.configuration.ConfigurationRegistry$2.visitInnerNode(ConfigurationRegistry.java:310)
at 
org.apache.ignite.internal.configuration.ConfigurationRegistry$2.visitInnerNode(ConfigurationRegistry.java:292)
at

[jira] [Commented] (IGNITE-17997) Whitespaces at the end are ignored during string comparison

2022-10-27 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin commented on IGNITE-17997:
-

Thank you. I've forgot about collations. As I can see, the same behavior could 
be achieved in other database engines, depending on data type and/or query 
options. E.g., in [sqlite3|https://www.sqlite.org/datatype3.html#collation]:
{code:sql}
sqlite> SELECT 'a' = 'a ';
0-- false
sqlite> SELECT 'a' = 'a ' COLLATE RTRIM;
1-- true
{code}
In that case, I hardly can treat this behavior as a bug. At most, it's a 
different default, not obvious though.

[~korlov] what would you say about IGNITE-17996? Does this behavior obey the 
same rules?

Also, are there plans to support different collation schemes in the future?

> Whitespaces at the end are ignored during string comparison
> ---
>
> Key: IGNITE-17997
> URL: https://issues.apache.org/jira/browse/IGNITE-17997
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Affects Versions: 3.0.0-beta1
>Reporter: Andrey Khitrin
>Priority: Major
>
> In 3.0.0-Beta-1:
> {code:java}
> sql-cli> select 'a' = 'a' as t1, 'a' = 'b' as t2, 'a' = 'a   ' as t3, 'a' = ' 
>   a' as t4;
> ╔══╤═══╤══╤═══╗
> ║ T1   │ T2    │ T3   │ T4    ║
> ╠══╪═══╪══╪═══╣
> ║ true │ false │ true │ false ║
> ╚══╧═══╧══╧═══╝
> {code}
> Tests T1, T2, and T4 show correct behavior. But in test T2 we see that string 
> 'a' is considered being equal to string 'a   '  (same string but with 
> arbitrary amount of whitespaces at the end). This is incorrect behavior.
> This issue may have the same nature as IGNITE-17996, but it's just a 
> hypothesis.



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

[jira] [Created] (IGNITE-17997) Whitespaces at the end are ignored during string comparison

2022-10-27 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-17997:
---

 Summary: Whitespaces at the end are ignored during string 
comparison
 Key: IGNITE-17997
 URL: https://issues.apache.org/jira/browse/IGNITE-17997
 Project: Ignite
  Issue Type: Bug
Affects Versions: 3.0.0-beta1
Reporter: Andrey Khitrin


In 3.0.0-Beta-1:
{code:java}
sql-cli> select 'a' = 'a' as t1, 'a' = 'b' as t2, 'a' = 'a   ' as t3, 'a' = '   
a' as t4;
╔══╤═══╤══╤═══╗
║ T1   │ T2    │ T3   │ T4    ║
╠══╪═══╪══╪═══╣
║ true │ false │ true │ false ║
╚══╧═══╧══╧═══╝
{code}
Tests T1, T2, and T4 show correct behavior. But in test T2 we see that string 
'a' is considered being equal to string 'a   '  (same string but with arbitrary 
amount of whitespaces at the end). This is incorrect behavior.

This issue may have the same nature as IGNITE-17996, but it's just a hypothesis.



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

[jira] [Created] (IGNITE-17996) Strange behavior of SQL CASE expression

2022-10-27 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-17996:
---

 Summary: Strange behavior of SQL CASE expression
 Key: IGNITE-17996
 URL: https://issues.apache.org/jira/browse/IGNITE-17996
 Project: Ignite
  Issue Type: Bug
Affects Versions: 3.0.0-beta1
Reporter: Andrey Khitrin


I observe strange behavior in the next scenario:

 
{code:java}
sql-cli> create table xx (f1 int primary key);
Updated 0 rows.
sql-cli> insert into xx values (1);
Updated 1 rows.
sql-cli> insert into xx values (2);
Updated 1 rows.
sql-cli> select f1, case when f1 < 2 then 'foo' else 'barbar' end as s, 
length(case when f1 < 2 then 'foo' else 'barbar' end) as ls from xx;
╔╤╤╗
║ F1 │ S      │ LS ║
╠╪╪╣
║ 2  │ barbar │ 6  ║
╟┼┼╢
║ 1  │ foo    │ 6  ║
╚╧╧╝
 {code}
I expect `CASE` to return 'foo' value, but de-facto it returns 'foo   ' ('foo' 
with 3 whitespaces at the end).  Seems like this should be fixed.

 



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

[jira] [Created] (IGNITE-17953) NPE and closed connection on some malformed SQL requests using third-party SQL clients

2022-10-21 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-17953:
---

 Summary: NPE and closed connection on some malformed SQL requests 
using third-party SQL clients
 Key: IGNITE-17953
 URL: https://issues.apache.org/jira/browse/IGNITE-17953
 Project: Ignite
  Issue Type: Bug
  Components: sql
Reporter: Andrey Khitrin
 Fix For: 3.0.0-beta1


I try to run different SQL queries in AI3 using 
[SqlLine|https://github.com/julianhyde/sqlline] tool and fresh ignite-client 
JAR downloaded from CI. I tried both correct and some incorrect SQL queries. 
And it looks like some incorrect SQL queries lead to irrecoverable error on the 
client side. The stack trace is the following:
{code:java}
Oct 21, 2022 4:57:02 PM io.netty.channel.DefaultChannelPipeline 
onUnhandledInboundException
WARNING: An exceptionCaught() event was fired, and it reached at the tail of 
the pipeline. It usually means the last handler in the pipeline did not handle 
the exception.
java.lang.NullPointerException
at org.apache.ignite.lang.ErrorGroup.errorMessage(ErrorGroup.java:193)
at 
org.apache.ignite.lang.IgniteException.(IgniteException.java:190)
at 
org.apache.ignite.internal.client.TcpClientChannel.readError(TcpClientChannel.java:336)
at 
org.apache.ignite.internal.client.TcpClientChannel.processNextMessage(TcpClientChannel.java:301)
at 
org.apache.ignite.internal.client.TcpClientChannel.onMessage(TcpClientChannel.java:160)
at 
org.apache.ignite.internal.client.io.netty.NettyClientConnection.onMessage(NettyClientConnection.java:94)
at 
org.apache.ignite.internal.client.io.netty.NettyClientMessageHandler.channelRead(NettyClientMessageHandler.java:34)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at 
io.netty.handler.codec.ByteToMessageDecoder.fireChannelRead(ByteToMessageDecoder.java:327)
at 
io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:299)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at 
io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:357)
at 
io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1410)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:379)
at 
io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:365)
at 
io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:919)
at 
io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:166)
at 
io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:722)
at 
io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:658)
at 
io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:584)
at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:496)
at 
io.netty.util.concurrent.SingleThreadEventExecutor$4.run(SingleThreadEventExecutor.java:995)
at 
io.netty.util.internal.ThreadExecutorMap$2.run(ThreadExecutorMap.java:74)
at 
io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
at java.base/java.lang.Thread.run(Thread.java:829)

Oct 21, 2022 4:58:07 PM io.netty.channel.DefaultChannelPipeline 
onUnhandledInboundException
WARNING: An exceptionCaught() event was fired, and it reached at the tail of 
the pipeline. It usually means the last handler in the pipeline did not handle 
the exception.
java.io.IOException: Connection reset by peer
at java.base/sun.nio.ch.FileDispatcherImpl.read0(Native Method)
at java.base/sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39)
at java.base/sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:276)
at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:233)
at java.base/sun.nio.ch.IOUtil.read(IOUtil.java:223)
at 
java.base/sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:356)
at io.netty.buffer.PooledByteBuf.setBytes(PooledByteBuf.java:258)
at io.netty.buffer.AbstractByteBuf.writeBytes(AbstractByteBuf.java:1132)
at 
io.netty.channel.socket.nio.NioSocketChannel.doReadBytes(NioSocketChannel.java:357)
at

[jira] [Created] (IGNITE-17174) Incomplete documentation in examples module

2022-06-15 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-17174:
---

 Summary: Incomplete documentation in examples module
 Key: IGNITE-17174
 URL: https://issues.apache.org/jira/browse/IGNITE-17174
 Project: Ignite
  Issue Type: Bug
  Components: examples
Affects Versions: 3.0.0-alpha5
Reporter: Andrey Khitrin


In AI3 Alpha 5, there are few documentation issues related to examples:
 # Some examples do not have description in `README.md`: 
KeyValueViewPojoExample, RecordViewPojoExample, TransactionsExample.
 # One example doesn't contain run instruction in Javadoc: SqlApiExample
 # Class StorageEngineExample has misleading name. It's not a runnable example 
(with main() method) but it's named like other examples.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Created] (IGNITE-17173) Examples module cannot be built due to SNAPSHOT maven dependencies

2022-06-15 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-17173:
---

 Summary: Examples module cannot be built due to SNAPSHOT maven 
dependencies
 Key: IGNITE-17173
 URL: https://issues.apache.org/jira/browse/IGNITE-17173
 Project: Ignite
  Issue Type: Bug
  Components: examples
Affects Versions: 3.0.0-alpha5
Reporter: Andrey Khitrin


Currently, `examples` module (in git tree) depends on `-SNAPSHOT` versions of 
Apache Ignite. This easily causes inability to run them in a way described in 
README.

A mere user may want to run examples in the following way:
 # Clone source code from Github.
 # Open examples module in IDE
 # Try to run examples using instructions provided

Unfortunately, this will not work because of `-SNAPSHOT` versioning of examples 
module. Snapshot builds of AI3 modules that examples module depends on are not 
published on any publicly accessible repository. Hence, instead of working 
example, user could only get a distracting compilation error.

In theory, there could be 2 ways to deal with it:
 # Only use examples from distribution ZIP file. This version doesn't have 
`-SNAPSHOT` dependencies, so it could be built easily. Alas, this way is not 
quite obvious for one who get used to work with OSS via GitHub primarily. In 
addition, this way is not available for pre-release testing.
 # Build all dependencies (e.g., a whole AI3) from the source locally. Again, 
it's not documented, and it could really take significant time. And it's still 
far from the "{_}Import the examples project into your IDE{_}" claim.

Something should be done with it. Possibly, examples module should have its own 
life cycle (maybe even in a separate repository). Possibly, few additional 
instructions should be written for solving typical user problems described 
above.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Updated] (IGNITE-17129) cli tool dosn’t expand tilde in a config path

2022-06-07 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin updated IGNITE-17129:

Labels: ignite-3  (was: )

> cli tool dosn’t expand tilde in a config path 
> --
>
> Key: IGNITE-17129
> URL: https://issues.apache.org/jira/browse/IGNITE-17129
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 3.0.0-alpha5
>Reporter: Andrey Khitrin
>Priority: Major
>  Labels: ignite-3
>
> Many Linux users use tilde ({{{}~{}}}) as a shortcut for a user's home 
> directory. CLI tool could expand environment variables (like {{{}$HOME{}}}) 
> in config path, but fails to expand tilde.
> An example:
> {code:java}
> $ ./ignite node start 
> --config=~/work/apache/ignite-3/examples/config/ignite-config.json 
> my-first-node
> Starting a new Ignite node...
> Can't start the node. Read logs for details: 
> /home/zloddey/opt/ai3/ignite-log/my-first-node.log
> $ cat /home/zloddey/opt/ai3/ignite-log/my-first-node.log
> Exception in thread "main" class org.apache.ignite.lang.IgniteException: 
> Unable to read user specific configuration.
> at 
> org.apache.ignite.internal.app.IgnitionImpl.start(IgnitionImpl.java:97)
> at org.apache.ignite.IgnitionManager.start(IgnitionManager.java:105)
> at 
> org.apache.ignite.app.IgniteCliRunner.start(IgniteCliRunner.java:109)
> at org.apache.ignite.app.IgniteCliRunner.main(IgniteCliRunner.java:44)
> Caused by: java.nio.file.NoSuchFileException: 
> /home/zloddey/opt/ai3/~/work/apache/ignite-3/examples/config/ignite-config.json
> at 
> java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
> at 
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
> at 
> java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
> at 
> java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:219)
> at java.base/java.nio.file.Files.newByteChannel(Files.java:371)
> at java.base/java.nio.file.Files.newByteChannel(Files.java:422)
> at java.base/java.nio.file.Files.readAllBytes(Files.java:3206)
> at java.base/java.nio.file.Files.readString(Files.java:3284)
> at java.base/java.nio.file.Files.readString(Files.java:3243)
> at 
> org.apache.ignite.internal.app.IgnitionImpl.start(IgnitionImpl.java:92)
> ... 3 more
>  {code}
> When I use {{/home/zloddey}} or {{$HOME}} instead of tilde, it works fine.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Created] (IGNITE-17129) cli tool dosn’t expand tilde in a config path

2022-06-07 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-17129:
---

 Summary: cli tool dosn’t expand tilde in a config path 
 Key: IGNITE-17129
 URL: https://issues.apache.org/jira/browse/IGNITE-17129
 Project: Ignite
  Issue Type: Bug
Affects Versions: 3.0.0-alpha5
Reporter: Andrey Khitrin


Many Linux users use tilde ({{{}~{}}}) as a shortcut for a user's home 
directory. CLI tool could expand environment variables (like {{{}$HOME{}}}) in 
config path, but fails to expand tilde.

An example:
{code:java}
$ ./ignite node start 
--config=~/work/apache/ignite-3/examples/config/ignite-config.json my-first-node
Starting a new Ignite node...
Can't start the node. Read logs for details: 
/home/zloddey/opt/ai3/ignite-log/my-first-node.log

$ cat /home/zloddey/opt/ai3/ignite-log/my-first-node.log
Exception in thread "main" class org.apache.ignite.lang.IgniteException: Unable 
to read user specific configuration.
at 
org.apache.ignite.internal.app.IgnitionImpl.start(IgnitionImpl.java:97)
at org.apache.ignite.IgnitionManager.start(IgnitionManager.java:105)
at org.apache.ignite.app.IgniteCliRunner.start(IgniteCliRunner.java:109)
at org.apache.ignite.app.IgniteCliRunner.main(IgniteCliRunner.java:44)
Caused by: java.nio.file.NoSuchFileException: 
/home/zloddey/opt/ai3/~/work/apache/ignite-3/examples/config/ignite-config.json
at 
java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:92)
at 
java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:111)
at 
java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:116)
at 
java.base/sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:219)
at java.base/java.nio.file.Files.newByteChannel(Files.java:371)
at java.base/java.nio.file.Files.newByteChannel(Files.java:422)
at java.base/java.nio.file.Files.readAllBytes(Files.java:3206)
at java.base/java.nio.file.Files.readString(Files.java:3284)
at java.base/java.nio.file.Files.readString(Files.java:3243)
at 
org.apache.ignite.internal.app.IgnitionImpl.start(IgnitionImpl.java:92)
... 3 more
 {code}
When I use {{/home/zloddey}} or {{$HOME}} instead of tilde, it works fine.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Commented] (IGNITE-17088) SQL API: Add examples.

2022-06-07 Thread Andrey Khitrin (Jira)



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

Andrey Khitrin commented on IGNITE-17088:
-

Hi! I've tried to run this example and found it failing with 
{{UnsupportedOperationException}} (due to IGNITE-17057 probably). Is it OK to 
have a failing example in Alpha release?

> SQL API: Add examples.
> --
>
> Key: IGNITE-17088
> URL: https://issues.apache.org/jira/browse/IGNITE-17088
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-alpha5
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Add examples of using SQL API.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

[jira] [Created] (IGNITE-17128) PersistentPageMemoryStorageExample cannot be run twice

2022-06-07 Thread Andrey Khitrin (Jira)

Andrey Khitrin created IGNITE-17128:
---

 Summary: PersistentPageMemoryStorageExample cannot be run twice
 Key: IGNITE-17128
 URL: https://issues.apache.org/jira/browse/IGNITE-17128
 Project: Ignite
  Issue Type: Bug
  Components: examples
Affects Versions: 3.0.0-alpha5
Reporter: Andrey Khitrin


{*}Issue{*}: example PersistentPageMemoryStorageExample cannot be run twice. At 
the first attempt it runs fine. But at the second attempt, it fails with the 
following exception:
{code:java}
Exception in thread "main" java.sql.SQLException: Exception while executing 
query INSERT INTO ACCOUNTS (ACCOUNT_ID, FIRST_NAME, LAST_NAME, BALANCE) values 
(?, ?, ?, ?). Error message: java.util.concurrent.CompletionException: class 
org.apache.ignite.lang.IgniteException: Failed to INSERT some keys because they 
are already in cache. [rows=[Row[1, John, Doe, 1000.0]]]
    at 
java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:314)
    at 
java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:319)
    at 
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:932)
    at 
java.base/java.util.concurrent.CompletableFuture$UniHandle.tryFire(CompletableFuture.java:907)
    at 
java.base/java.util.concurrent.CompletableFuture.postComplete(CompletableFuture.java:506)
    at 
java.base/java.util.concurrent.CompletableFuture.completeExceptionally(CompletableFuture.java:2088)
    at 
org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.lambda$closeAsync$0(AsyncRootNode.java:194)
    at 
java.base/java.util.concurrent.LinkedBlockingQueue.forEachFrom(LinkedBlockingQueue.java:1010)
    at 
java.base/java.util.concurrent.LinkedBlockingQueue.forEach(LinkedBlockingQueue.java:979)
    at 
org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.closeAsync(AsyncRootNode.java:194)
    at 
org.apache.ignite.internal.sql.engine.exec.rel.AsyncRootNode.onError(AsyncRootNode.java:149)
    at 
org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:157)
    at 
org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:157)
    at 
org.apache.ignite.internal.sql.engine.exec.rel.AbstractNode.onError(AbstractNode.java:157)
    at 
org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:298)
    at 
org.apache.ignite.internal.sql.engine.exec.QueryTaskExecutorImpl.lambda$execute$0(QueryTaskExecutorImpl.java:78)
    at 
java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
    at 
java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
    at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: class org.apache.ignite.lang.IgniteException: Failed to INSERT some 
keys because they are already in cache. [rows=[Row[1, John, Doe, 1000.0]]]
    at 
org.apache.ignite.internal.sql.engine.AsyncSqlCursorImpl.lambda$requestNextAsync$0(AsyncSqlCursorImpl.java:74)
    at 
java.base/java.util.concurrent.CompletableFuture.uniHandle(CompletableFuture.java:930)
    ... 16 more
Caused by: class org.apache.ignite.lang.IgniteInternalException: Failed to 
INSERT some keys because they are already in cache. [rows=[Row[1, John, Doe, 
1000.0]]]
    at 
org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.conflictKeysException(ModifyNode.java:256)
    at 
org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.flushTuples(ModifyNode.java:233)
    at 
org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.tryEnd(ModifyNode.java:175)
    at 
org.apache.ignite.internal.sql.engine.exec.rel.ModifyNode.end(ModifyNode.java:148)
    at 
org.apache.ignite.internal.sql.engine.exec.rel.ProjectNode.end(ProjectNode.java:81)
    at 
org.apache.ignite.internal.sql.engine.exec.rel.ScanNode.push(ScanNode.java:132)
    at 
org.apache.ignite.internal.sql.engine.exec.ExecutionContext.lambda$execute$0(ExecutionContext.java:295)
    ... 4 more    at 
org.apache.ignite.internal.jdbc.proto.IgniteQueryErrorCode.createJdbcSqlException(IgniteQueryErrorCode.java:57)
    at 
org.apache.ignite.internal.jdbc.JdbcStatement.execute0(JdbcStatement.java:147)
    at 
org.apache.ignite.internal.jdbc.JdbcPreparedStatement.executeWithArguments(JdbcPreparedStatement.java:657)
    at 
org.apache.ignite.internal.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:136)
    at 
org.apache.ignite.example.storage.PersistentPageMemoryStorageExample.main(PersistentPageMemoryStorageExample.java:105)Process
 finished with exit code 1
 {code}
This could be mitigated by re-creation of ignite working environment, but I'm 
not sure whether this behavior is desired.



--
This message was sent by Atlassian Jira
(v8.20.7#820007)

89 matches

Mail list logo