date:20221017



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

Pavel Tupitsyn commented on IGNITE-17910:
-

Merged to main: d99593434f8273a82d0fbc0253b9dea9626fa4cc

> .NET: Thin 3.0: Add KeyValueView
> 
>
> Key: IGNITE-17910
> URL: https://issues.apache.org/jira/browse/IGNITE-17910
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Following tuple-based KeyvalueBinaryView in IGNITE-16226, add KeyValueView 
> with object mapping.



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

[jira] [Comment Edited] (IGNITE-11368) use the same information about indexes for JDBC drivers as for system view INDEXES

2022-10-17 Thread Ilya Shishkov (Jira)



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

Ilya Shishkov edited comment on IGNITE-11368 at 10/17/22 5:41 PM:
--

[~timonin.maksim], [~jooger], can you take a look, please: 
https://github.com/apache/ignite/pull/10316 ?

Above failure are unrelated to the fix.


was (Author: shishkovilja):
[~timonin.maksim], [~jooger], can you take a look, please?

Above failure are unrelated to the fix.

> use the same information about indexes for JDBC drivers as for system view 
> INDEXES
> --
>
> Key: IGNITE-11368
> URL: https://issues.apache.org/jira/browse/IGNITE-11368
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, odbc, sql
>Reporter: Yury Gerzhedovich
>Assignee: Ilya Shishkov
>Priority: Major
>  Labels: ise, newbie
> Attachments: indexes_sqlline.txt
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> As of now indexes information for JDBC drivers get by another way then system 
> SQL view INDEXES. Need to use single source of the information to have 
> consistent picture.
> So, JDBC drivers should use the same source as SQL view INDEXES 
> (org.apache.ignite.internal.processors.query.h2.sys.view.SqlSystemViewIndexes)
> Start point for JDBC index metadata is 
> org.apache.ignite.internal.jdbc2.JdbcDatabaseMetadata#getIndexInfo
> Also order of result should be correspond Javadoc ('ordered by NON_UNIQUE, 
> TYPE, INDEX_NAME, and ORDINAL_POSITION') - at present it is not so.



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

[jira] [Updated] (IGNITE-17738) Cluster must be able to fix the inconsistency on restart/node_join by itself



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

Anton Vinogradov updated IGNITE-17738:
--
Summary: Cluster must be able to fix the inconsistency on restart/node_join 
by itself  (was: Cluster must be able to fix the inconsistency on restart by 
itself)

> Cluster must be able to fix the inconsistency on restart/node_join by itself
> 
>
> Key: IGNITE-17738
> URL: https://issues.apache.org/jira/browse/IGNITE-17738
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Priority: Major
>  Labels: iep-31, ise
> Attachments: PartialHistoricalRebalanceTest.java, 
> SkippedRebalanceBecauseOfTheSameLwmTest.java
>
>
> On cluster restart (because of power-off, OOM or some other problem) it's 
> possible to have PDS inconsistent (primary partitions may contain operations 
> missed on backups as well as counters may contain gaps even on primary).
> 1) Currently, "historical rebalance" is able to sync the data to the highest 
> LWM for every partition. 
> Most likely, a primary will be chosen as a rebalance source, but the data 
> after the LWM will not be rebalanced. So, all updates between LWM and HWM 
> will not be synchronized.
> See  [^PartialHistoricalRebalanceTest.java] 
> Such partition may be rebalanced correctly "later" in case of full rebalance 
> will be triggered sometime.
> 2) In case LWM is the same on primary and backup, rebalance will be skipped 
> for such partition.
> See  [^SkippedRebalanceBecauseOfTheSameLwmTest.java] 
> Proposals:
> 1) Cheap fix
> A possible solution for the case when the cluster failed and restarted (same 
> baseline) is to fix the counters automatically (when cluster composition is 
> equal to the baseline specified before the crash).
> Counters should be set as
>  - HWM at primary and as LWM at backups for caches with 2+ backups,
>  - LWM at primary and as HWM at backups for caches with a single backup.
> 2) Correct fix
> Rebalance must honor whole counter state (LWM, HWM, gaps).
> 2.1) In case when WAL is available all entries between LWM and HWM 
> (including) must be rebalanced to other nodes where they are required.
> Even from backups to the primary.
> 2.2) Full rebalance must be restricted when it causes any updates loss.
> For example, it's 
> - ok to replace B with A when 
> A[lwm=100, gaps=[142], hwm=200] and B[lwm=50, gaps=[76,99,111], hwm=120],
> because A contains whole B.
> - NOT ok to replace B with A when 
> A[lwm=100, gaps=[142], hwm=200] and B[lwm=50, gaps=[76,99,111], hwm=*148*], 
> when update *142* will be lost.



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

[jira] [Commented] (IGNITE-11611) If partition consistency cannot be restored during rebalance using counters the most recent partition data should be used.



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

Anton Vinogradov commented on IGNITE-11611:
---

[~ascherbakov] , such approach may/will cause data loss.

Partition copies with not a "most recent" data may contain a data missed at 
"most recent" data owner.

Correct fix is to rebalance entries between LWM and HWM using the historical 
rebalance as well when possible (see. IGNITE-17738 for details)

When historihal rebalance is not possible we must fix the data using the 
recovery tool (see. IGNITE-15167 for details)

> If partition consistency cannot be restored during rebalance using counters 
> the most recent partition data should be used.
> --
>
> Key: IGNITE-11611
> URL: https://issues.apache.org/jira/browse/IGNITE-11611
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Scherbakov
>Priority: Major
>
> This is possible if all owners are left, then returned and counters are 
> inconsistent (no dedicated max counter node)
> In such a case the "most recent" partition can be used for supplying purposes.
> We should track topology history to find the node with "most recent" updates.



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

[jira] [Updated] (IGNITE-17738) Cluster must be able to fix the inconsistency on restart by itself



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

Anton Vinogradov updated IGNITE-17738:
--
Description: 
On cluster restart (because of power-off, OOM or some other problem) it's 
possible to have PDS inconsistent (primary partitions may contain operations 
missed on backups as well as counters may contain gaps even on primary).

1) Currently, "historical rebalance" is able to sync the data to the highest 
LWM for every partition. 
Most likely, a primary will be chosen as a rebalance source, but the data after 
the LWM will not be rebalanced. So, all updates between LWM and HWM will not be 
synchronized.
See  [^PartialHistoricalRebalanceTest.java] 

Such partition may be rebalanced correctly "later" in case of full rebalance 
will be triggered sometime.

2) In case LWM is the same on primary and backup, rebalance will be skipped for 
such partition.
See  [^SkippedRebalanceBecauseOfTheSameLwmTest.java] 

Proposals:

1) Cheap fix
A possible solution for the case when the cluster failed and restarted (same 
baseline) is to fix the counters automatically (when cluster composition is 
equal to the baseline specified before the crash).

Counters should be set as
 - HWM at primary and as LWM at backups for caches with 2+ backups,
 - LWM at primary and as HWM at backups for caches with a single backup.

2) Correct fix
Rebalance must honor whole counter state (LWM, HWM, gaps).
2.1) In case when WAL is available all entries between LWM and HWM (including) 
must be rebalanced to other nodes where they are required.
Even from backups to the primary.
2.2) Full rebalance must be restricted when it causes any updates loss.
For example, it's 
- ok to replace B with A when 
A[lwm=100, gaps=[142], hwm=200] and B[lwm=50, gaps=[76,99,111], hwm=120],
because A contains whole B.
- NOT ok to replace B with A when 
A[lwm=100, gaps=[142], hwm=200] and B[lwm=50, gaps=[76,99,111], hwm=*148*], 
when update *142* will be lost.

  was:
On cluster restart (because of power-off, OOM or some other problem) it's 
possible to have PDS inconsistent (primary partitions may contain operations 
missed on backups as well as counters may contain gaps even on primary).

1) Currently, "historical rebalance" is able to sync the data to the highest 
LWM for every partition. 
Most likely, a primary will be chosen as a rebalance source, but the data after 
the LWM will not be rebalanced. So, all updates between LWM and HWM will not be 
synchronized.
See  [^PartialHistoricalRebalanceTest.java] 

Such partition may be rebalanced correctly "later" in case of full rebalance 
will be triggered sometime.

2) In case LWM is the same on primary and backup, rebalance will be skipped for 
such partition.
See  [^SkippedRebalanceBecauseOfTheSameLwmTest.java] 

Proposals:

1) Cheap fix
A possible solution for the case when the cluster failed and restarted (same 
baseline) is to fix the counters automatically (when cluster composition is 
equal to the baseline specified before the crash).

Counters should be set as
 - HWM at primary and as LWM at backups for caches with 2+ backups,
 - LWM at primary and as HWM at backups for caches with a single backup.

2) Correct fix
Rebalance must honor whole counter state (LWM, HWM, gaps).
2.1) In case when WAL is available all entries between LWM and HWM (including) 
must be rebalanced to other nodes where they are required.
Even from backups to the primary.
2.2) Full rebalance must be restricted when it causes any updates loss.
For example, it's 
- ok to replace B with A when 
A[lwm=100, gaps=[142], hwm=200] and B[lwm=50, gaps=[76,99,111], hwm=120]
- NOT ok to replace B with A when 
A[lwm=100, gaps=[142], hwm=200] and B[lwm=50, gaps=[76,99,111], hwm=*148*], 
when update *142* will be lost.


> Cluster must be able to fix the inconsistency on restart by itself
> --
>
> Key: IGNITE-17738
> URL: https://issues.apache.org/jira/browse/IGNITE-17738
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Priority: Major
>  Labels: iep-31, ise
> Attachments: PartialHistoricalRebalanceTest.java, 
> SkippedRebalanceBecauseOfTheSameLwmTest.java
>
>
> On cluster restart (because of power-off, OOM or some other problem) it's 
> possible to have PDS inconsistent (primary partitions may contain operations 
> missed on backups as well as counters may contain gaps even on primary).
> 1) Currently, "historical rebalance" is able to sync the data to the highest 
> LWM for every partition. 
> Most likely, a primary will be chosen as a rebalance source, but the data 
> after the LWM will not be rebalanced. So, all updates between LWM and HWM 
> will not be synchronized.
> See  [^PartialHistoricalRebalanceTest.java] 
> Such partition may be rebalanced

[jira] [Updated] (IGNITE-17738) Cluster must be able to fix the inconsistency on restart by itself



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

Anton Vinogradov updated IGNITE-17738:
--
Description: 
On cluster restart (because of power-off, OOM or some other problem) it's 
possible to have PDS inconsistent (primary partitions may contain operations 
missed on backups as well as counters may contain gaps even on primary).

1) Currently, "historical rebalance" is able to sync the data to the highest 
LWM for every partition. 
Most likely, a primary will be chosen as a rebalance source, but the data after 
the LWM will not be rebalanced. So, all updates between LWM and HWM will not be 
synchronized.
See  [^PartialHistoricalRebalanceTest.java] 

Such partition may be rebalanced correctly "later" in case of full rebalance 
will be triggered sometime.

2) In case LWM is the same on primary and backup, rebalance will be skipped for 
such partition.
See  [^SkippedRebalanceBecauseOfTheSameLwmTest.java] 

Proposals:

1) Cheap fix
A possible solution for the case when the cluster failed and restarted (same 
baseline) is to fix the counters automatically (when cluster composition is 
equal to the baseline specified before the crash).

Counters should be set as
 - HWM at primary and as LWM at backups for caches with 2+ backups,
 - LWM at primary and as HWM at backups for caches with a single backup.

2) Correct fix
Rebalance must honor whole counter state (LWM, HWM, gaps).
2.1) In case when WAL is available all entries between LWM and HWM (including) 
must be rebalanced to other nodes where they are required.
Even from backups to the primary.
2.2) Full rebalance must be restricted when it causes any updates loss.
For example, it's 
- ok to replace B with A when 
A[lwm=100, gaps=[142], hwm=200] and B[lwm=50, gaps=[76,99,111], hwm=120]
- NOT ok to replace B with A when 
A[lwm=100, gaps=[142], hwm=200] and B[lwm=50, gaps=[76,99,111], hwm=*148*], 
when update *142* will be lost.

  was:
On cluster restart (because of power-off, OOM or some other problem) it's 
possible to have PDS inconsistent (primary partitions may contain operations 
missed on backups as well as counters may contain gaps even on primary).

1) Currently, "historical rebalance" is able to sync the data to the highest 
LWM for every partition. 
Most likely, a primary will be chosen as a rebalance source, but the data after 
the LWM will not be rebalanced. So, all updates between LWM and HWM will not be 
synchronized.
See  [^PartialHistoricalRebalanceTest.java] 

Such partition may be rebalanced correctly "later" in case of full rebalance 
will be triggered sometime.

2) In case LWM is the same on primary and backup, rebalance will be skipped for 
such partition.
See  [^SkippedRebalanceBecauseOfTheSameLwmTest.java] 

Proposals:

1) Cheap fix
A possible solution for the case when the cluster failed and restarted (same 
baseline) is to fix the counters automatically (when cluster composition is 
equal to the baseline specified before the crash).

Counters should be set as
 - HWM at primary and as LWM at backups for caches with 2+ backups,
 - LWM at primary and as HWM at backups for caches with a single backup.

2) Correct fix
Rebalance must honor whole counter state (LWM, HWM, gaps).
2.1) In case when WAL is available all entries between LWM and HWM (including) 
must be rebalanced to other nodes where they required.
Even from backups to the primary.
2.2) Full rebalance must be restricted when it causes any updates loss.
For example, it's 
- ok to replace B with A when 
A[lwm=100, gaps=[142], hwm=200] and B[lwm=50, gaps=[76,99,111], hwm=120]
- NOT ok to replace B with A when 
A[lwm=100, gaps=[142], hwm=200] and B[lwm=50, gaps=[76,99,111], hwm=*148*], 
when update *142* will be lost.


> Cluster must be able to fix the inconsistency on restart by itself
> --
>
> Key: IGNITE-17738
> URL: https://issues.apache.org/jira/browse/IGNITE-17738
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Priority: Major
>  Labels: iep-31, ise
> Attachments: PartialHistoricalRebalanceTest.java, 
> SkippedRebalanceBecauseOfTheSameLwmTest.java
>
>
> On cluster restart (because of power-off, OOM or some other problem) it's 
> possible to have PDS inconsistent (primary partitions may contain operations 
> missed on backups as well as counters may contain gaps even on primary).
> 1) Currently, "historical rebalance" is able to sync the data to the highest 
> LWM for every partition. 
> Most likely, a primary will be chosen as a rebalance source, but the data 
> after the LWM will not be rebalanced. So, all updates between LWM and HWM 
> will not be synchronized.
> See  [^PartialHistoricalRebalanceTest.java] 
> Such partition may be rebalanced correctly "later" in case of full

[jira] [Updated] (IGNITE-17738) Cluster must be able to fix the inconsistency on restart by itself



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

Anton Vinogradov updated IGNITE-17738:
--
Description: 
On cluster restart (because of power-off, OOM or some other problem) it's 
possible to have PDS inconsistent (primary partitions may contain operations 
missed on backups as well as counters may contain gaps even on primary).

1) Currently, "historical rebalance" is able to sync the data to the highest 
LWM for every partition. 
Most likely, a primary will be chosen as a rebalance source, but the data after 
the LWM will not be rebalanced. So, all updates between LWM and HWM will not be 
synchronized.
See  [^PartialHistoricalRebalanceTest.java] 

Such partition may be rebalanced correctly "later" in case of full rebalance 
will be triggered sometime.

2) In case LWM is the same on primary and backup, rebalance will be skipped for 
such partition.
See  [^SkippedRebalanceBecauseOfTheSameLwmTest.java] 

Proposals:

1) Cheap fix
A possible solution for the case when the cluster failed and restarted (same 
baseline) is to fix the counters automatically (when cluster composition is 
equal to the baseline specified before the crash).

Counters should be set as
 - HWM at primary and as LWM at backups for caches with 2+ backups,
 - LWM at primary and as HWM at backups for caches with a single backup.

2) Correct fix
Rebalance must honor whole counter state (LWM, HWM, gaps).
2.1) In case when WAL is available all entries between LWM and HWM (including) 
must be rebalanced to other nodes where they required.
Even from backups to the primary.
2.2) Full rebalance must be restricted when it causes any updates loss.
For example, it's 
- ok to replace B with A when 
A[lwm=100, gaps=[142], hwm=200] and B[lwm=50, gaps=[76,99,111], hwm=120]
- NOT ok to replace B with A when 
A[lwm=100, gaps=[142], hwm=200] and B[lwm=50, gaps=[76,99,111], hwm=*148*], 
when update *142* will be lost.

  was:
On cluster restart (because of power-off, OOM or some other problem) it's 
possible to have PDS inconsistent (primary partitions may contain operations 
missed on backups as well as counters may contain gaps even on primary).

1) Currently, "historical rebalance" is able to sync the data to the highest 
LWM for every partition. 
Most likely, a primary will be chosen as a rebalance source, but the data after 
the LWM will not be rebalanced. So, all updates between LWM and HWM will not be 
synchronized.
See  [^PartialHistoricalRebalanceTest.java] 

Such partition may be rebalanced correctly "later" in case of full rebalance 
will be triggered sometime.

2) In case LWM is the same on primary and backup, rebalance will be skipped for 
such partition.
See  [^SkippedRebalanceBecauseOfTheSameLwmTest.java] 

Proposals:

1) Cheap fix
A possible solution for the case when the cluster failed and restarted (same 
baseline) is to fix the counters automatically (when cluster composition is 
equal to the baseline specified before the crash).

Counters should be set as
 - HWM at primary and as LWM at backups for caches with 2+ backups,
 - LWM at primary and as HWM at backups for caches with a single backup.

2) Correct fix
Rebalance must honor whole counter state (LWM, HWM, gaps).
2.1) In case when WAL is available all entries between LWM and HWM (including) 
must be rebalanced to other nodes where they required.
2.2) Full rebalance must be restricted when it causes any updates loss.
For example, it's 
- ok to replace B with A when 
A[lwm=100, gaps=[142], hwm=200] and B[lwm=50, gaps=[76,99,111], hwm=120]
- NOT ok to replace B with A when 
A[lwm=100, gaps=[142], hwm=200] and B[lwm=50, gaps=[76,99,111], hwm=*148*], 
when update *142* will be lost.


> Cluster must be able to fix the inconsistency on restart by itself
> --
>
> Key: IGNITE-17738
> URL: https://issues.apache.org/jira/browse/IGNITE-17738
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Priority: Major
>  Labels: iep-31, ise
> Attachments: PartialHistoricalRebalanceTest.java, 
> SkippedRebalanceBecauseOfTheSameLwmTest.java
>
>
> On cluster restart (because of power-off, OOM or some other problem) it's 
> possible to have PDS inconsistent (primary partitions may contain operations 
> missed on backups as well as counters may contain gaps even on primary).
> 1) Currently, "historical rebalance" is able to sync the data to the highest 
> LWM for every partition. 
> Most likely, a primary will be chosen as a rebalance source, but the data 
> after the LWM will not be rebalanced. So, all updates between LWM and HWM 
> will not be synchronized.
> See  [^PartialHistoricalRebalanceTest.java] 
> Such partition may be rebalanced correctly "later" in case of full rebalance 
> will be triggered sometime.

[jira] [Updated] (IGNITE-17738) Cluster must be able to fix the inconsistency on restart by itself



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

Anton Vinogradov updated IGNITE-17738:
--
Description: 
On cluster restart (because of power-off, OOM or some other problem) it's 
possible to have PDS inconsistent (primary partitions may contain operations 
missed on backups as well as counters may contain gaps even on primary).

1) Currently, "historical rebalance" is able to sync the data to the highest 
LWM for every partition. 
Most likely, a primary will be chosen as a rebalance source, but the data after 
the LWM will not be rebalanced. So, all updates between LWM and HWM will not be 
synchronized.
See  [^PartialHistoricalRebalanceTest.java] 

Such partition may be rebalanced correctly "later" in case of full rebalance 
will be triggered sometime.

2) In case LWM is the same on primary and backup, rebalance will be skipped for 
such partition.
See  [^SkippedRebalanceBecauseOfTheSameLwmTest.java] 

Proposals:

1) Cheap fix
A possible solution for the case when the cluster failed and restarted (same 
baseline) is to fix the counters automatically (when cluster composition is 
equal to the baseline specified before the crash).

Counters should be set as
 - HWM at primary and as LWM at backups for caches with 2+ backups,
 - LWM at primary and as HWM at backups for caches with a single backup.

2) Correct fix
Rebalance must honor whole counter state (LWM, HWM, gaps).
2.1) In case when WAL is available all entries between LWM and HWM (including) 
must be rebalanced to other nodes where they required.
2.2) Full rebalance must be restricted when it causes any updates loss.
For example, it's 
- ok to replace B with A when 
A[lwm=100, gaps=[142], hwm=200] and B[lwm=50, gaps=[76,99,111], hwm=120]
- NOT ok to replace B with A when 
A[lwm=100, gaps=[142], hwm=200] and B[lwm=50, gaps=[76,99,111], hwm=*148*], 
when update *142* will be lost.

  was:
On cluster restart (because of power-off, OOM or some other problem) it's 
possible to have PDS inconsistent (primary partitions may contain operations 
missed on backups as well as counters may contain gaps even on primary).

1) Currently, "historical rebalance" is able to sync the data to the highest 
LWM for every partition. 
Most likely, a primary will be chosen as a rebalance source, but the data after 
the LWM will not be rebalanced. So, all updates between LWM and HWM will not be 
synchronized.
See  [^PartialHistoricalRebalanceTest.java] 

Such partition may be rebalanced correctly "later" in case of full rebalance 
will be triggered sometime.

2) In case LWM is the same on primary and backup, rebalance will be skipped for 
such partition.
See  [^SkippedRebalanceBecauseOfTheSameLwmTest.java] 

A possible solution for the case when the cluster failed and restarted (same 
baseline) is to fix the counters automatically (when cluster composition is 
equal to the baseline specified before the crash).

Counters should be set as
 - HWM at primary and as LWM at backups for caches with 2+ backups,
 - LWM at primary and as HWM at backups for caches with a single backup.


> Cluster must be able to fix the inconsistency on restart by itself
> --
>
> Key: IGNITE-17738
> URL: https://issues.apache.org/jira/browse/IGNITE-17738
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Priority: Major
>  Labels: iep-31, ise
> Attachments: PartialHistoricalRebalanceTest.java, 
> SkippedRebalanceBecauseOfTheSameLwmTest.java
>
>
> On cluster restart (because of power-off, OOM or some other problem) it's 
> possible to have PDS inconsistent (primary partitions may contain operations 
> missed on backups as well as counters may contain gaps even on primary).
> 1) Currently, "historical rebalance" is able to sync the data to the highest 
> LWM for every partition. 
> Most likely, a primary will be chosen as a rebalance source, but the data 
> after the LWM will not be rebalanced. So, all updates between LWM and HWM 
> will not be synchronized.
> See  [^PartialHistoricalRebalanceTest.java] 
> Such partition may be rebalanced correctly "later" in case of full rebalance 
> will be triggered sometime.
> 2) In case LWM is the same on primary and backup, rebalance will be skipped 
> for such partition.
> See  [^SkippedRebalanceBecauseOfTheSameLwmTest.java] 
> Proposals:
> 1) Cheap fix
> A possible solution for the case when the cluster failed and restarted (same 
> baseline) is to fix the counters automatically (when cluster composition is 
> equal to the baseline specified before the crash).
> Counters should be set as
>  - HWM at primary and as LWM at backups for caches with 2+ backups,
>  - LWM at primary and as HWM at backups for caches with a single backup.
> 2) Correct fix
> Rebalance must

[jira] [Commented] (IGNITE-17910) .NET: Thin 3.0: Add KeyValueView

2022-10-17 Thread Igor Sapego (Jira)



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

Igor Sapego commented on IGNITE-17910:
--

[~ptupitsyn] looks good to me

> .NET: Thin 3.0: Add KeyValueView
> 
>
> Key: IGNITE-17910
> URL: https://issues.apache.org/jira/browse/IGNITE-17910
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Following tuple-based KeyvalueBinaryView in IGNITE-16226, add KeyValueView 
> with object mapping.



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

[jira] [Updated] (IGNITE-17116) Add architecture documentation for CLI module.



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

Vyacheslav Koptilin updated IGNITE-17116:
-
Fix Version/s: 3.0.0-beta2

> Add architecture documentation for CLI module.
> --
>
> Key: IGNITE-17116
> URL: https://issues.apache.org/jira/browse/IGNITE-17116
> Project: Ignite
>  Issue Type: Task
>Reporter: Aleksandr
>Assignee: Aleksandr
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> A developer should read the documentation and:
> * how to create an executable command
> * how to test an executable command (unit and integration)
> * how to create an interactive command
> * how to test an interactive command
> Also, the ExecutionPepiline concept and the extention mechanismshould be 
> described.



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

[jira] [Updated] (IGNITE-17913) Ignite node start is broken



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

Vyacheslav Koptilin updated IGNITE-17913:
-
Ignite Flags:   (was: Docs Required,Release Notes Required)

> Ignite node start is broken
> ---
>
> Key: IGNITE-17913
> URL: https://issues.apache.org/jira/browse/IGNITE-17913
> Project: Ignite
>  Issue Type: Bug
>  Components: cli
>Reporter: Aleksandr
>Assignee: Vadim Pakhnushev
>Priority: Critical
>  Labels: ignite-3, ignite-3-cli-tool
> Fix For: 3.0.0-beta1
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> It seems like several recent AI3 CLI builds (including ignite-3.0.0-beta-1 
> branch) are broken. It's impossible to start a single node. 
> Steps to reproduce:
> 1) Download build artifacts from TeamCity
> 2) Install distribution using ignite bootstrap --repo=
> 3) Try to start node:
> $ ./ignite node start --config=examples/config/ignite-config.conf 
> standalone-sql-node
> Starting a new Ignite node...
> Can't start the node. Read logs for details: 
> /home/zloddey/opt/ai3/ignite-log/standalone-sql-node.log
> In log file, there is the following error:
> Missing required option: '--node-name='
> Usage: runner --node-name= --work-dir= 
> [--join=[,
>   ...]]... [--config-path= |
>   --config-string=]
>   --config-path=
>  Path to node configuration file in HOCON format.
>   --config-string=
>  Node configuration in HOCON format.
>   --join=[,...]
>  Seed nodes.
>   --node-name= Node name.
>   --work-dir=   Path to node working directory.



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

[jira] [Updated] (IGNITE-17883) Remove the invoke method from KeyValurView and RecordView interfaces



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

Vyacheslav Koptilin updated IGNITE-17883:
-
Fix Version/s: 3.0.0-beta2
   (was: 3.0.0-beta1)

> Remove the invoke method from KeyValurView and RecordView interfaces
> 
>
> Key: IGNITE-17883
> URL: https://issues.apache.org/jira/browse/IGNITE-17883
> Project: Ignite
>  Issue Type: Bug
>Affects Versions: 3.0.0-beta1
>Reporter: Vyacheslav Koptilin
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> _KeyValueView_ and _RecordView_ provide the following methods:
> {code:java}
> /**
>  * Executes invoke processor code against the value associated with the 
> provided key.
>  *
>  * @param tx The transaction or {@code null} to auto commit.
>  * @param key A key associated with the value that invoke processor will be 
> applied to. The key cannot be {@code null}.
>  * @param proc An invocation processor.
>  * @param args Optional invoke processor arguments.
>  * @param  Invoke processor result type.
>  * @return Result of the processing.
>  * @see InvokeProcessor
>  */
>  R invoke(@Nullable Transaction tx, @NotNull K key, 
> InvokeProcessor proc, Serializable... args);
> /**
>  * Asynchronously executes invoke processor code against the value associated 
> with the provided key.
>  *
>  * @param tx The transaction or {@code null} to auto commit.
>  * @param key A key associated with the value that invoke processor will be 
> applied to. The key cannot be {@code null}.
>  * @param proc An invocation processor.
>  * @param args Optional invoke processor arguments.
>  * @param  Invoke processor result type.
>  * @return Future representing pending completion of the operation.
>  * @see InvokeProcessor
>  */
> @NotNull  CompletableFuture invokeAsync(
> @Nullable Transaction tx,
> @NotNull K key,
> InvokeProcessor proc,
> Serializable... args);
> /**
>  * Executes invoke processor code against values associated with the provided 
> keys.
>  *
>  * @param tx The transaction or {@code null} to auto commit.
>  * @param  Invoke processor result type.
>  * @param keys Ordered collection of keys which values associated with should 
> be processed. The keys cannot be {@code null}.
>  * @param proc An invocation processor.
>  * @param args Optional invoke processor arguments.
>  * @return Results of the processing.
>  * @see InvokeProcessor
>  */
>  Map invokeAll(
> @Nullable Transaction tx,
> @NotNull Collection keys,
> InvokeProcessor proc,
> Serializable... args);
> /**
>  * Asynchronously executes invoke processor code against values associated 
> with the provided keys.
>  *
>  * @param tx The transaction or {@code null} to auto commit.
>  * @param  Invoke processor result type.
>  * @param keys Ordered collection of keys which values associated with should 
> be processed. The keys cannot be {@code null}.
>  * @param proc An invocation processor.
>  * @param args Optional invoke processor arguments.
>  * @return Future representing pending completion of the operation.
>  * @see InvokeProcessor
>  */
> @NotNull  CompletableFuture> invokeAllAsync(
> @Nullable Transaction tx,
> @NotNull Collection keys,
> InvokeProcessor proc,
> Serializable... args);
>  {code}
> The main problem with these methods assume that the user defined closure - 
> _InvokeProcessor_ must be idempotent. This is a consequence of the 
> limitations of the replication protocol. However, the implementation does not 
> have the right way to check this requirement. For example, a simple closure 
> that increments a value for a key could lead to data inconsistency under some 
> circumstances.
> For now, _IgniteCompute.executeColocated_ can be used in order to handle 
> these needs.



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

[jira] [Updated] (IGNITE-16746) Error handling in Compute



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

Vyacheslav Koptilin updated IGNITE-16746:
-
Fix Version/s: 3.0.0-beta2
   (was: 3.0.0-beta1)

> Error handling in Compute
> -
>
> Key: IGNITE-16746
> URL: https://issues.apache.org/jira/browse/IGNITE-16746
> Project: Ignite
>  Issue Type: Improvement
>  Components: compute
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Compute should probably have its own set (hierarchy?) of exceptions.
> Also, internal exceptions like NodeStoppingException should not propagate to 
> user code.



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

[jira] [Updated] (IGNITE-16750) Improve separation between public and internal interfaces of Table



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

Vyacheslav Koptilin updated IGNITE-16750:
-
Fix Version/s: 3.0.0-beta2
   (was: 3.0.0-beta1)

> Improve separation between public and internal interfaces of Table
> --
>
> Key: IGNITE-16750
> URL: https://issues.apache.org/jira/browse/IGNITE-16750
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Roman Puchkovskiy
>Priority: Minor
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Currently, there is a public part including Table and IgniteTables that can 
> be used to get instances of Table; and a private part represented with 
> TableImpl and IgniteTablesInternal that can be used to get instances of 
> TableImpl.
> We probably need to decouple the internal and public interfaces so that they 
> form different layers.
> Maybe we should use InternalTable in the internal code instead of using 
> TableImpl?
> h4. Upd 1:
> Seems that we should use proxies/gateways (something similar to 
> GatewayProtectedCacheProxy) that will
>  * Separate public and internal public api.
>  * Add ability to check whether node is available or stopping.
>  * Ease resource cleanup on components/node stop.
>  * Permission checks, etc.



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

[jira] [Updated] (IGNITE-17916) Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property



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

Julia Bakulina updated IGNITE-17916:

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

> Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property
> ---
>
> Key: IGNITE-17916
> URL: https://issues.apache.org/jira/browse/IGNITE-17916
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Julia Bakulina
>Assignee: Julia Bakulina
>Priority: Minor
>  Labels: ise
>
> The ticket is a part of 
> [IGNITE-8801|https://issues.apache.org/jira/browse/IGNITE-8801?filter=-1].
> As decided during the discussion in Ignite Dev List, we need to break changes 
> of IGNITE-8801 into 2 steps:
> 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next 
> release - IGNITE-17916;
> 2) delete this property in the release after the next one - IGNITE-8801.



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

[jira] [Updated] (IGNITE-17916) Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property



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

Julia Bakulina updated IGNITE-17916:

Labels: ise  (was: )

> Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property
> ---
>
> Key: IGNITE-17916
> URL: https://issues.apache.org/jira/browse/IGNITE-17916
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Julia Bakulina
>Assignee: Julia Bakulina
>Priority: Minor
>  Labels: ise
>
> The ticket is a part of 
> [IGNITE-8801|https://issues.apache.org/jira/browse/IGNITE-8801?filter=-1].
> As decided during the discussion in Ignite Dev List, we need to break changes 
> of IGNITE-8801 into 2 steps:
> 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next 
> release - IGNITE-17916;
> 2) delete this property in the release after the next one - IGNITE-8801.



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

[jira] [Updated] (IGNITE-17884) Ignite interface should expose TopologyService



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

Vyacheslav Koptilin updated IGNITE-17884:
-
Fix Version/s: 3.0.0-beta2
   (was: 3.0.0-beta1)

> Ignite interface should expose TopologyService
> --
>
> Key: IGNITE-17884
> URL: https://issues.apache.org/jira/browse/IGNITE-17884
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vyacheslav Koptilin
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> There is no way to get an instanace of TopologyService via Ignite interface. 
> The following methods just duplicate a part of TopologyService and looks like 
> a temporary solution:
> {code:java}
> /**
>  * Gets the cluster nodes.
>  * NOTE: Temporary API to enable Compute until we have proper Cluster API.
>  *
>  * @return Collection of cluster nodes.
>  */
> Collection clusterNodes();
> /**
>  * Gets the cluster nodes.
>  * NOTE: Temporary API to enable Compute until we have proper Cluster API.
>  *
>  * @return Collection of cluster nodes.
>  */
> CompletableFuture> clusterNodesAsync();
>  {code}
> Need just to expose _TopologeService_ instead of these methods.



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

[jira] [Updated] (IGNITE-8801) Change default behaviour of atomic operations inside transactions



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

Julia Bakulina updated IGNITE-8801:
---
Description: 
Need to change default behaviour of atomic operations to fail inside 
transactions.

1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
2) Set default value to restrict atomic operations in 
\{{CacheOperationContext}} constructor without arguments and arguments for 
calls of another constructor.
3) Fix javadocs.

As decided during the discussion in Ignite Dev List, we need to break changes 
of IGNITE-8801 into 2 steps:
1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next 
release - IGNITE-17916;
2) delete this property in the release after the next one - IGNITE-8801.

  was:
Need to change default behaviour of atomic operations to fail inside 
transactions.

1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
2) Set default value to restrict atomic operations in 
\{{CacheOperationContext}} constructor without arguments and arguments for 
calls of another constructor.
3) Fix javadocs.


> Change default behaviour of atomic operations inside transactions
> -
>
> Key: IGNITE-8801
> URL: https://issues.apache.org/jira/browse/IGNITE-8801
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Ryabov Dmitrii
>Assignee: Julia Bakulina
>Priority: Minor
>  Labels: ise
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Need to change default behaviour of atomic operations to fail inside 
> transactions.
> 1) Remove IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.
> 2) Set default value to restrict atomic operations in 
> \{{CacheOperationContext}} constructor without arguments and arguments for 
> calls of another constructor.
> 3) Fix javadocs.
> As decided during the discussion in Ignite Dev List, we need to break changes 
> of IGNITE-8801 into 2 steps:
> 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next 
> release - IGNITE-17916;
> 2) delete this property in the release after the next one - IGNITE-8801.



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

[jira] [Updated] (IGNITE-17885) Convert ClusterNode class to interface



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

Vyacheslav Koptilin updated IGNITE-17885:
-
Fix Version/s: 3.0.0-beta2
   (was: 3.0.0-beta1)

> Convert ClusterNode class to interface
> --
>
> Key: IGNITE-17885
> URL: https://issues.apache.org/jira/browse/IGNITE-17885
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Vyacheslav Koptilin
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> It would bi nice convert the _ClusterNode_ class to java interface. It will 
> allow to introduce _DetachedNode_ concept that represents an offline node 
> (however, such a node can be a part of logical topology), and avoid using 
> internal utility classes/methods in the public API.



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

[jira] [Updated] (IGNITE-17916) Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property



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

Julia Bakulina updated IGNITE-17916:

Description: 
The ticket is a part of 
[IGNITE-8801|https://issues.apache.org/jira/browse/IGNITE-8801?filter=-1].
As decided during the discussion in Ignite Dev List, we need to break changes 
of IGNITE-8801 into 2 steps:
1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next 
release - IGNITE-17916;
2) delete this property in the release after the next one - IGNITE-8801.

  was:
The ticket is a part of 
[IGNITE-8801|https://issues.apache.org/jira/browse/IGNITE-8801?filter=-1].
As decided during the discussion in Ignite Dev List, we need to break changes 
of IGNITE-8801 into 2 steps:
1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next 
release - this ticket;
2) delete this property in the release after the next one - IGNITE-8801.


> Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property
> ---
>
> Key: IGNITE-17916
> URL: https://issues.apache.org/jira/browse/IGNITE-17916
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Julia Bakulina
>Assignee: Julia Bakulina
>Priority: Minor
>
> The ticket is a part of 
> [IGNITE-8801|https://issues.apache.org/jira/browse/IGNITE-8801?filter=-1].
> As decided during the discussion in Ignite Dev List, we need to break changes 
> of IGNITE-8801 into 2 steps:
> 1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next 
> release - IGNITE-17916;
> 2) delete this property in the release after the next one - IGNITE-8801.



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

[jira] [Created] (IGNITE-17916) Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property

Julia Bakulina created IGNITE-17916:
---

 Summary: Deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property
 Key: IGNITE-17916
 URL: https://issues.apache.org/jira/browse/IGNITE-17916
 Project: Ignite
  Issue Type: Improvement
Reporter: Julia Bakulina
Assignee: Julia Bakulina


The ticket is a part of 
[IGNITE-8801|https://issues.apache.org/jira/browse/IGNITE-8801?filter=-1].
As decided during the discussion in Ignite Dev List, we need to break changes 
of IGNITE-8801 into 2 steps:
1) deprecate IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property during the next 
release - this ticket;
2) delete this property in the release after the next one - IGNITE-8801.



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

[jira] [Commented] (IGNITE-17820) Ignite 3. SQL. Add native support for SEARCH/SARG operator



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

Yury Gerzhedovich commented on IGNITE-17820:


[~amashenkov] , LGTM

> Ignite 3. SQL. Add native support for SEARCH/SARG operator
> --
>
> Key: IGNITE-17820
> URL: https://issues.apache.org/jira/browse/IGNITE-17820
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
>  Labels: calcite, ignite-3
> Fix For: 3.0.0-beta1
>
>
> Currently, Calcite compose some field conditions to {{SEARCH/SARG}} operator 
> (for example: {{field IN (scalar)}}, {{field <> ...}}, {{field = value1 OR 
> field = value2}}, etc). This operator is not supported natively by Ignite 
> Calcite engine and converted back to original expression using 
> {{RexUtil.expandSearch}} method on the {{RexToLixTranslator}} phase. 
>  Such behavior forces Ignite to use full table scan instead of indexes in 
> some cases. For example, if {{field}} is indexed, with {{field IN (1, 2)}} 
> condition usually is much faster to scan index for 2 values, then full scan 
> table and filter out results. For {{OR}} operator {{OrToUnion}} rule can't be 
> applied and there will be full table scan again.
>  We should support index traversing using SEARCH/SARG operator.
>  Alternatively we can convert {{SEARCH/SARG}} to {{UNIONs}} (similarly to 
> {{OrToUnion}} rule), but this approach will extend plan search space a lot.



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

[jira] [Created] (IGNITE-17915) Generalize support for inversion of control mechanisms

2022-10-17 Thread Jira

Łukasz Dywicki created IGNITE-17915:
---

 Summary: Generalize support for inversion of control  mechanisms
 Key: IGNITE-17915
 URL: https://issues.apache.org/jira/browse/IGNITE-17915
 Project: Ignite
  Issue Type: Improvement
  Components: spring
Affects Versions: 2.14
Reporter: Łukasz Dywicki


Current inversion of control support for Ignite is bound to Spring framework 
and Spring ApplicationContext interface which is used to lookup beans by type 
or name.

Above lookup criteria are fairly generic and can be used to first - extract, 
second - generalize support for foreign injections within Ignite itself. With 
little work it is possible to open this for further extensions. This is known 
pattern used in other Apache projects, ie. 
[{{BeanRepository}}|https://github.com/apache/camel/blob/camel-3.19.0/core/camel-api/src/main/java/org/apache/camel/spi/BeanRepository.java]
 and 
[{{Registry}}|https://github.com/apache/camel/blob/camel-3.19.0/core/camel-api/src/main/java/org/apache/camel/spi/Registry.java].

Main motivation is Ignite running under OSGi which does not host Spring (Spring 
framework dropped support for OSGi a while ago), and has alternative ways to 
provide similar functionality. For OSGi there are mechanisms such as OSGi 
Blueprint and OSGi Service Registry itself.



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

[jira] [Commented] (IGNITE-17870) SQL. Do not yield separate query result for comments



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

Yury Gerzhedovich commented on IGNITE-17870:


[~amashenkov] , LGTM, thanks for the contribution!

> SQL. Do not yield separate query result for comments
> 
>
> Key: IGNITE-17870
> URL: https://issues.apache.org/jira/browse/IGNITE-17870
> Project: Ignite
>  Issue Type: Bug
>  Components: sql
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Motivation
> Currently, lines with commented out lines yield additional query result. For 
> the query below, three results will be returned (result for comment is 
> “updated rows: 0“). You can play with the comments position within the entire 
> query, the behavior with comments is not consistent and clear.
> -- asdf
> SELECT * FROM Test_Person limit 1;
> update Test_Person set name='sdfsdf' where id = ;
> -- come
> -- asdf
> What to do
> Do not yield a separate query result for commented out lines.



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

[jira] [Commented] (IGNITE-17864) Optimize scan(HybridTimestamp.MAX_VALUE) and read(HybridTimestamp.MAX_VALUE)



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

Roman Puchkovskiy commented on IGNITE-17864:


Thanks!

> Optimize scan(HybridTimestamp.MAX_VALUE) and read(HybridTimestamp.MAX_VALUE)
> 
>
> Key: IGNITE-17864
> URL: https://issues.apache.org/jira/browse/IGNITE-17864
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Please check https://issues.apache.org/jira/browse/IGNITE-17856 for more 
> details about scan(UUID txId) and read(RowId rowId, UUID txId) removal. 
> Within given ticket it's expected that timestamp based scans and reads will 
> be optimized in order to perform HybridTimestamp.MAX_VALUE bouned operations 
> in a most efficient way.



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

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



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

Aleksandr commented on IGNITE-17489:


created follow-up ticket https://issues.apache.org/jira/browse/IGNITE-17914

> Packaging: Brew package
> ---
>
> Key: IGNITE-17489
> URL: https://issues.apache.org/jira/browse/IGNITE-17489
> Project: Ignite
>  Issue Type: New Feature
>  Components: build
>Reporter: Mikhail Pochatkin
>Assignee: Aleksandr
>Priority: Major
>  Labels: ignite-3
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




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

[jira] [Updated] (IGNITE-17914) Create PR to homebrew-core



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

Aleksandr updated IGNITE-17914:
---
Description: In IGNITE-17489 two homebrew formulas were developed. They 
have to be merged to the homebrew-core module after beta1 is available with 
url.  (was: In IGNITE-17781 two homebrew formulas were developed. They have to 
be merged to the homebrew-core module after beta1 is available with url.)

> Create PR to homebrew-core
> --
>
> Key: IGNITE-17914
> URL: https://issues.apache.org/jira/browse/IGNITE-17914
> Project: Ignite
>  Issue Type: Task
>  Components: build, cli
>Reporter: Aleksandr
>Priority: Major
>  Labels: ignite-3
>
> In IGNITE-17489 two homebrew formulas were developed. They have to be merged 
> to the homebrew-core module after beta1 is available with url.



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

[jira] [Created] (IGNITE-17914) Create PR to homebrew-core

Aleksandr created IGNITE-17914:
--

 Summary: Create PR to homebrew-core
 Key: IGNITE-17914
 URL: https://issues.apache.org/jira/browse/IGNITE-17914
 Project: Ignite
  Issue Type: Task
  Components: build, cli
Reporter: Aleksandr


In IGNITE-17781 two homebrew formulas were developed. They have to be merged to 
the homebrew-core module after beta1 is available with url.



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

[jira] [Updated] (IGNITE-17816) Sort out and merge Calcite tickets to Ignite 3.0 (step 7)



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

Yury Gerzhedovich updated IGNITE-17816:
---
Fix Version/s: 3.0.0-beta2
   (was: 3.0.0-beta1)

>  Sort out and merge Calcite tickets to Ignite 3.0 (step 7)
> --
>
> Key: IGNITE-17816
> URL: https://issues.apache.org/jira/browse/IGNITE-17816
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
>  Labels: calcite, ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Let's merge the following tickets to ignite 3.0:
> https://issues.apache.org/jira/browse/IGNITE-16443
> https://issues.apache.org/jira/browse/IGNITE-16151
> https://issues.apache.org/jira/browse/IGNITE-16701
> https://issues.apache.org/jira/browse/IGNITE-16693
> https://issues.apache.org/jira/browse/IGNITE-16053
> After merge needs to remove the label {*}calcite3-required{*}.
> Tickets that could be simply merged - merge immediately. For hard cases let's 
> create separate tickets with estimation and link them to IGNITE-15658 or 
> links to blocker ticket.



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

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



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

Yury Gerzhedovich updated IGNITE-17702:
---
Fix Version/s: 3.0.0-beta1
   (was: 3.0.0-beta2)

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



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

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



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

Yury Gerzhedovich updated IGNITE-17702:
---
Fix Version/s: 3.0.0-beta2
   (was: 3.0.0-beta1)

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



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

[jira] [Updated] (IGNITE-17864) Optimize scan(HybridTimestamp.MAX_VALUE) and read(HybridTimestamp.MAX_VALUE)

2022-10-17 Thread Semyon Danilov (Jira)



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

Semyon Danilov updated IGNITE-17864:

Fix Version/s: 3.0.0-beta2

> Optimize scan(HybridTimestamp.MAX_VALUE) and read(HybridTimestamp.MAX_VALUE)
> 
>
> Key: IGNITE-17864
> URL: https://issues.apache.org/jira/browse/IGNITE-17864
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Please check https://issues.apache.org/jira/browse/IGNITE-17856 for more 
> details about scan(UUID txId) and read(RowId rowId, UUID txId) removal. 
> Within given ticket it's expected that timestamp based scans and reads will 
> be optimized in order to perform HybridTimestamp.MAX_VALUE bouned operations 
> in a most efficient way.



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

[jira] [Commented] (IGNITE-17816) Sort out and merge Calcite tickets to Ignite 3.0 (step 7)



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

Andrey Mashenkov commented on IGNITE-17816:
---

[~jooger], thanks for your contribution, merged to main.

>  Sort out and merge Calcite tickets to Ignite 3.0 (step 7)
> --
>
> Key: IGNITE-17816
> URL: https://issues.apache.org/jira/browse/IGNITE-17816
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
>  Labels: calcite, ignite-3
> Fix For: 3.0.0-beta1
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Let's merge the following tickets to ignite 3.0:
> https://issues.apache.org/jira/browse/IGNITE-16443
> https://issues.apache.org/jira/browse/IGNITE-16151
> https://issues.apache.org/jira/browse/IGNITE-16701
> https://issues.apache.org/jira/browse/IGNITE-16693
> https://issues.apache.org/jira/browse/IGNITE-16053
> After merge needs to remove the label {*}calcite3-required{*}.
> Tickets that could be simply merged - merge immediately. For hard cases let's 
> create separate tickets with estimation and link them to IGNITE-15658 or 
> links to blocker ticket.



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

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



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

Andrey Mashenkov updated IGNITE-16053:
--
Labels: calcite  (was: calcite calcite3-required)

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

[jira] [Updated] (IGNITE-16701) Calcite engine. Merge join incorrectly works when there are more then two matched rows on the right side



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

Andrey Mashenkov updated IGNITE-16701:
--
Labels: calcite  (was: calcite calcite3-required)

> Calcite engine. Merge join incorrectly works when there are more then two 
> matched rows on the right side
> 
>
> Key: IGNITE-16701
> URL: https://issues.apache.org/jira/browse/IGNITE-16701
> Project: Ignite
>  Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: calcite
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Reproducer:
> {code:java}
> executeSql("CREATE TABLE t1(i INT)");
> executeSql("CREATE INDEX t1_i ON t1(i)");
> executeSql("INSERT INTO t1 VALUES (0)");
> executeSql("CREATE TABLE t2(i INT)");
> executeSql("CREATE INDEX t2_i ON t2(i)");
> executeSql("INSERT INTO t2 VALUES (0), (0), (0)");
> assertQuery("SELECT /*+ DISABLE_RULE('CorrelatedNestedLoopJoin', 
> 'NestedLoopJoinConverter') */ t1.i FROM t1 LEFT JOIN t2 ON t1.i = 
> t2.i").returns(0).returns(0).returns(0).check();
> {code}
> Should return [0, 0, 0], but returns [0, 0].
>  
>  



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

[jira] [Updated] (IGNITE-16151) Introduce timeout for calcite planner



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

Andrey Mashenkov updated IGNITE-16151:
--
Labels: calcite  (was: calcite calcite3-required)

> Introduce timeout for calcite planner
> -
>
> Key: IGNITE-16151
> URL: https://issues.apache.org/jira/browse/IGNITE-16151
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
>  Labels: calcite
>  Time Spent: 3h 10m
>  Remaining Estimate: 0h
>
> Since it is quite common case that calcite planner can produce too many plans 
> and can planning infinitely, it is of crucial
> importance to be able to cancel this process on timeout.



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

[jira] [Updated] (IGNITE-16693) Calcite engine. Merge join incorrectly works with null values



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

Andrey Mashenkov updated IGNITE-16693:
--
Labels: calcite  (was: calcite calcite3-required)

> Calcite engine. Merge join incorrectly works with null values
> -
>
> Key: IGNITE-16693
> URL: https://issues.apache.org/jira/browse/IGNITE-16693
> Project: Ignite
>  Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: calcite
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Reproducer:
> {code:java}
> executeSql("CREATE TABLE t(i INT)");
> executeSql("CREATE INDEX t_i ON t(i)");
> executeSql("INSERT INTO t VALUES (0), (null)");
> assertQuery("SELECT t1.i FROM t t1 JOIN t t2 ON t1.i = 
> t2.i").returns(0).check();
> {code}



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

[jira] [Updated] (IGNITE-16443) Calcite engine. Incorrect nulls in search row processing by hash/sorted spools



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

Andrey Mashenkov updated IGNITE-16443:
--
Labels: calcite  (was: calcite3-required)

> Calcite engine. Incorrect nulls in search row processing by hash/sorted spools
> --
>
> Key: IGNITE-16443
> URL: https://issues.apache.org/jira/browse/IGNITE-16443
> Project: Ignite
>  Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: calcite
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Currently, the sorted spool comparator treats nulls in the search row as 
> regular values and applies nulls ordering to them, but these nulls have 
> another meaning: it means that any value matches the bound.
> For example, if we have the condition for spool {{a > 0}} it will be 
> transformed to bounds: {{lower [0]}}, {{upper [null]}}, after comparing rows 
> with lower bound we will get the correct result, but comparing with upper 
> bound always give us {{1}} (value > null) with {{nulls first}} collation and 
> no rows will be returned by index spool.
> For hash spool there is the reverse problem, we should not find rows if nulls 
> are present in the search row, since condition NULL=NULL should not satisfy 
> the filter in SQL.
> For index scan, there are no problems that lead to data inconsistency, but in 
> the case of nulls in the search row, any value matches the bound and index 
> scan becomes very ineffective. For example, if we have the index by field 
> {{a}} and filter {{a = $cor0.b}}, for {{$cor0.b = null}} there will be the 
> full index scan, all rows will be passed to the predicate and 0 rows will be 
> produced after the predicate. 
> Another problem with comparators: there is a dead code in 
> {{ExpressionFactoryImpl#comparator(RelFieldCollation)}} which compare object 
> by hash or bytes:
>  * This code never executes since we support now only comparable types by 
> Calcite-based SQL engine
>  * Depends on H2
>  * Serialize object by standard java serialization
>  * Works only for ASC ordering
>  * Works for sort/spool/sort aggregate nodes, but doesn't work for merge join
> I think we can get rid of this code at least until we don't support Object 
> types and revert corresponding changes to ignite-indexing to avoid merge 
> conflicts.



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

[jira] [Updated] (IGNITE-17816) Sort out and merge Calcite tickets to Ignite 3.0 (step 7)



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

Yury Gerzhedovich updated IGNITE-17816:
---
Fix Version/s: 3.0.0-beta1

>  Sort out and merge Calcite tickets to Ignite 3.0 (step 7)
> --
>
> Key: IGNITE-17816
> URL: https://issues.apache.org/jira/browse/IGNITE-17816
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
>  Labels: calcite, ignite-3
> Fix For: 3.0.0-beta1
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Let's merge the following tickets to ignite 3.0:
> https://issues.apache.org/jira/browse/IGNITE-16443
> https://issues.apache.org/jira/browse/IGNITE-16151
> https://issues.apache.org/jira/browse/IGNITE-16701
> https://issues.apache.org/jira/browse/IGNITE-16693
> https://issues.apache.org/jira/browse/IGNITE-16053
> After merge needs to remove the label {*}calcite3-required{*}.
> Tickets that could be simply merged - merge immediately. For hard cases let's 
> create separate tickets with estimation and link them to IGNITE-15658 or 
> links to blocker ticket.



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

[jira] [Updated] (IGNITE-17913) Ignite node start is broken



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

Vyacheslav Koptilin updated IGNITE-17913:
-
Fix Version/s: 3.0.0-beta1

> Ignite node start is broken
> ---
>
> Key: IGNITE-17913
> URL: https://issues.apache.org/jira/browse/IGNITE-17913
> Project: Ignite
>  Issue Type: Bug
>  Components: cli
>Reporter: Aleksandr
>Assignee: Vadim Pakhnushev
>Priority: Critical
>  Labels: ignite-3, ignite-3-cli-tool
> Fix For: 3.0.0-beta1
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> It seems like several recent AI3 CLI builds (including ignite-3.0.0-beta-1 
> branch) are broken. It's impossible to start a single node. 
> Steps to reproduce:
> 1) Download build artifacts from TeamCity
> 2) Install distribution using ignite bootstrap --repo=
> 3) Try to start node:
> $ ./ignite node start --config=examples/config/ignite-config.conf 
> standalone-sql-node
> Starting a new Ignite node...
> Can't start the node. Read logs for details: 
> /home/zloddey/opt/ai3/ignite-log/standalone-sql-node.log
> In log file, there is the following error:
> Missing required option: '--node-name='
> Usage: runner --node-name= --work-dir= 
> [--join=[,
>   ...]]... [--config-path= |
>   --config-string=]
>   --config-path=
>  Path to node configuration file in HOCON format.
>   --config-string=
>  Node configuration in HOCON format.
>   --join=[,...]
>  Seed nodes.
>   --node-name= Node name.
>   --work-dir=   Path to node working directory.



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

[jira] [Commented] (IGNITE-17321) Document which api can work with partition awareness

2022-10-17 Thread Luchnikov Alexander (Jira)



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

Luchnikov Alexander commented on IGNITE-17321:
--

[~timonin.maksim]
After I made a PR, I thought that it would be more correct to describe this 
information in:
# https://cwiki.apache.org/confluence/display/IGNITE/Thin+clients+features
# 
https://ignite.apache.org/docs/latest/thin-clients/java-thin-client#partition-awareness
 for all platform
# javadoc

Make a subtask for my PR?

> Document which api can work with partition awareness
> 
>
> Key: IGNITE-17321
> URL: https://issues.apache.org/jira/browse/IGNITE-17321
> Project: Ignite
>  Issue Type: Improvement
>  Components: thin client
>Reporter: Luchnikov Alexander
>Assignee: Luchnikov Alexander
>Priority: Minor
>  Labels: docuentation, ise
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In javadoc 
> org.apache.ignite.configuration.ClientConfiguration#partitionAwarenessEnabled 
> and in the description of functionality
> https://ignite.apache.org/docs/latest/thin-clients/java-thin-client#partition-awareness,
>  it is not described with which api this functionality will work and in what 
> cases. For example, will it work with getAll, in a transaction?
> Describe in the documentation and in the javadoc in which cases it works and 
> with which api.



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

[jira] [Commented] (IGNITE-17321) Document which api can work with partition awareness

2022-10-17 Thread Luchnikov Alexander (Jira)



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

Luchnikov Alexander commented on IGNITE-17321:
--

[~timonin.maksim] Could you please take a look?

> Document which api can work with partition awareness
> 
>
> Key: IGNITE-17321
> URL: https://issues.apache.org/jira/browse/IGNITE-17321
> Project: Ignite
>  Issue Type: Improvement
>  Components: thin client
>Reporter: Luchnikov Alexander
>Assignee: Luchnikov Alexander
>Priority: Minor
>  Labels: docuentation, ise
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In javadoc 
> org.apache.ignite.configuration.ClientConfiguration#partitionAwarenessEnabled 
> and in the description of functionality
> https://ignite.apache.org/docs/latest/thin-clients/java-thin-client#partition-awareness,
>  it is not described with which api this functionality will work and in what 
> cases. For example, will it work with getAll, in a transaction?
> Describe in the documentation and in the javadoc in which cases it works and 
> with which api.



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

[jira] [Assigned] (IGNITE-17321) Document which api can work with partition awareness

2022-10-17 Thread Luchnikov Alexander (Jira)



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

Luchnikov Alexander reassigned IGNITE-17321:


Assignee: Luchnikov Alexander

> Document which api can work with partition awareness
> 
>
> Key: IGNITE-17321
> URL: https://issues.apache.org/jira/browse/IGNITE-17321
> Project: Ignite
>  Issue Type: Improvement
>  Components: thin client
>Reporter: Luchnikov Alexander
>Assignee: Luchnikov Alexander
>Priority: Minor
>  Labels: docuentation, ise
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In javadoc 
> org.apache.ignite.configuration.ClientConfiguration#partitionAwarenessEnabled 
> and in the description of functionality
> https://ignite.apache.org/docs/latest/thin-clients/java-thin-client#partition-awareness,
>  it is not described with which api this functionality will work and in what 
> cases. For example, will it work with getAll, in a transaction?
> Describe in the documentation and in the javadoc in which cases it works and 
> with which api.



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

[jira] [Updated] (IGNITE-17325) Implement a comparator for inlined BinaryTuple in sorted index



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

Kirill Tkalenko updated IGNITE-17325:
-
Description: 
We need to implement an inlined *BinaryTuple* comparator in a sorted index for 
a B+tree.
You need to take into account the format of the *BinaryTuple* and the fact that 
it can be truncated.
As a basis, you can take 
*org.apache.ignite.internal.storage.index.BinaryTupleComparator*.

  was:We should be able to compare columns in IGNITE-17318 / IGNITE-17320 
without deserializing them. This includes String, BigInteger, BigDecimal, 
BitMap and maybe other types that I forgot about


> Implement a comparator for inlined BinaryTuple in sorted index
> --
>
> Key: IGNITE-17325
> URL: https://issues.apache.org/jira/browse/IGNITE-17325
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Bessonov
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> We need to implement an inlined *BinaryTuple* comparator in a sorted index 
> for a B+tree.
> You need to take into account the format of the *BinaryTuple* and the fact 
> that it can be truncated.
> As a basis, you can take 
> *org.apache.ignite.internal.storage.index.BinaryTupleComparator*.



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

[jira] [Updated] (IGNITE-17325) Implement a comparator for inlined BinaryTuple in sorted index



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

Kirill Tkalenko updated IGNITE-17325:
-
Summary: Implement a comparator for inlined BinaryTuple in sorted index  
(was: Implement a comparator for inlined BinaryTuple)

> Implement a comparator for inlined BinaryTuple in sorted index
> --
>
> Key: IGNITE-17325
> URL: https://issues.apache.org/jira/browse/IGNITE-17325
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Bessonov
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> We should be able to compare columns in IGNITE-17318 / IGNITE-17320 without 
> deserializing them. This includes String, BigInteger, BigDecimal, BitMap and 
> maybe other types that I forgot about



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

[jira] [Updated] (IGNITE-17325) Implement a comparator for inlined BinaryTuple



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

Kirill Tkalenko updated IGNITE-17325:
-
Summary: Implement a comparator for inlined BinaryTuple  (was: Consider 
in-place compare for BinaryTuple comparator)

> Implement a comparator for inlined BinaryTuple
> --
>
> Key: IGNITE-17325
> URL: https://issues.apache.org/jira/browse/IGNITE-17325
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Bessonov
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> We should be able to compare columns in IGNITE-17318 / IGNITE-17320 without 
> deserializing them. This includes String, BigInteger, BigDecimal, BitMap and 
> maybe other types that I forgot about



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

[jira] [Updated] (IGNITE-16226) .NET: Thin 3.0: Add KeyValueBinaryView



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

Vyacheslav Koptilin updated IGNITE-16226:
-
Affects Version/s: (was: 3.0.0-beta2)

> .NET: Thin 3.0: Add KeyValueBinaryView
> --
>
> Key: IGNITE-16226
> URL: https://issues.apache.org/jira/browse/IGNITE-16226
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Implement *IKeyValueView*.



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

[jira] [Updated] (IGNITE-16226) .NET: Thin 3.0: Add KeyValueBinaryView



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

Vyacheslav Koptilin updated IGNITE-16226:
-
Fix Version/s: 3.0.0-beta2
   (was: 3.0.0-beta1)

> .NET: Thin 3.0: Add KeyValueBinaryView
> --
>
> Key: IGNITE-16226
> URL: https://issues.apache.org/jira/browse/IGNITE-16226
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms, thin client
>Affects Versions: 3.0.0-beta2
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Implement *IKeyValueView*.



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

[jira] [Updated] (IGNITE-16226) .NET: Thin 3.0: Add KeyValueBinaryView



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

Pavel Tupitsyn updated IGNITE-16226:

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

> .NET: Thin 3.0: Add KeyValueBinaryView
> --
>
> Key: IGNITE-16226
> URL: https://issues.apache.org/jira/browse/IGNITE-16226
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms, thin client
>Affects Versions: 3.0.0-beta2
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, ignite-3
> Fix For: 3.0.0-beta1
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Implement *IKeyValueView*.



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

[jira] [Updated] (IGNITE-17325) Consider in-place compare for BinaryTuple comparator



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

Kirill Tkalenko updated IGNITE-17325:
-
Ignite Flags:   (was: Docs Required,Release Notes Required)

> Consider in-place compare for BinaryTuple comparator
> 
>
> Key: IGNITE-17325
> URL: https://issues.apache.org/jira/browse/IGNITE-17325
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Bessonov
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> We should be able to compare columns in IGNITE-17318 / IGNITE-17320 without 
> deserializing them. This includes String, BigInteger, BigDecimal, BitMap and 
> maybe other types that I forgot about



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

[jira] [Updated] (IGNITE-17325) Consider in-place compare for BinaryTuple comparator



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

Kirill Tkalenko updated IGNITE-17325:
-
Fix Version/s: 3.0.0-beta2

> Consider in-place compare for BinaryTuple comparator
> 
>
> Key: IGNITE-17325
> URL: https://issues.apache.org/jira/browse/IGNITE-17325
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Bessonov
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> We should be able to compare columns in IGNITE-17318 / IGNITE-17320 without 
> deserializing them. This includes String, BigInteger, BigDecimal, BitMap and 
> maybe other types that I forgot about



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

[jira] [Assigned] (IGNITE-17913) Ignite node start is broken

2022-10-17 Thread Vadim Pakhnushev (Jira)



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

Vadim Pakhnushev reassigned IGNITE-17913:
-

Assignee: Vadim Pakhnushev

> Ignite node start is broken
> ---
>
> Key: IGNITE-17913
> URL: https://issues.apache.org/jira/browse/IGNITE-17913
> Project: Ignite
>  Issue Type: Bug
>  Components: cli
>Reporter: Aleksandr
>Assignee: Vadim Pakhnushev
>Priority: Critical
>  Labels: ignite-3, ignite-3-cli-tool
>
> It seems like several recent AI3 CLI builds (including ignite-3.0.0-beta-1 
> branch) are broken. It's impossible to start a single node. 
> Steps to reproduce:
> 1) Download build artifacts from TeamCity
> 2) Install distribution using ignite bootstrap --repo=
> 3) Try to start node:
> $ ./ignite node start --config=examples/config/ignite-config.conf 
> standalone-sql-node
> Starting a new Ignite node...
> Can't start the node. Read logs for details: 
> /home/zloddey/opt/ai3/ignite-log/standalone-sql-node.log
> In log file, there is the following error:
> Missing required option: '--node-name='
> Usage: runner --node-name= --work-dir= 
> [--join=[,
>   ...]]... [--config-path= |
>   --config-string=]
>   --config-path=
>  Path to node configuration file in HOCON format.
>   --config-string=
>  Node configuration in HOCON format.
>   --join=[,...]
>  Seed nodes.
>   --node-name= Node name.
>   --work-dir=   Path to node working directory.



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

[jira] [Assigned] (IGNITE-17860) Wrong request example for the 'Compare-And-Swap' REST API command

2022-10-17 Thread Igor Gusev (Jira)



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

Igor Gusev reassigned IGNITE-17860:
---

Assignee: Igor Gusev

> Wrong request example for the 'Compare-And-Swap' REST API command
> -
>
> Key: IGNITE-17860
> URL: https://issues.apache.org/jira/browse/IGNITE-17860
> Project: Ignite
>  Issue Type: Task
>  Components: documentation
>Reporter: Igor Gusev
>Assignee: Igor Gusev
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> [https://ignite.apache.org/docs/2.13.0/restapi#compare-and-swap]
> The 'Compare-And-Swap' Ignite REST API request example mentions 
> authentificate command instead of 'Compare-And-Swap' command.
>  
>  



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

[jira] [Updated] (IGNITE-17872) Fetch commit index on non-primary replicas instead of waiting for safe time in case of RO tx on idle cluster

2022-10-17 Thread Denis Chudov (Jira)

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

Denis Chudov updated IGNITE-17872:
--
Description:
Safe time for non-primary replicas (see IGNITE-17263 ) was conceived as
optimization to avoid unnecessary network hops. Safe time is propagated from
primary replica via raft appendEntries messages. When there is constant load on
cluster that is caused by RW transactions, these messages are refreshing safe
time on replicas with decent frequency, but in case of idle cluster, or cluster
with read-only load, safe time is propagated periodically via heartbeats. This
means that, if a RO transaction with read timestamp in present or future, is
trying to read a value from non-primary replica, it will wait for safe time
first, which is bound to frequency of heartbeat messages, and hence, the
duration of the read operation may be close to the period of heartbeats. This
looks weird and will cause performance issues.

Example:
Heartbeat period is 500 ms.
Current safe time on replica is 1.
We are processing read-only request with timestamp=2.
There were no RW transactions for some time, and the next expected update of
safe time, according to the heartbeat period, is 1 + 500 = 501.
This means that we should wait for about 499 ms (assuming the clock skew and
ping in cluster is 0) to proceed with RO request processing.

So, even though safe time is an optimization, we shouldn't use it in cases when
there are no RW transactions affecting the given replica, and the timestamp of
current RO transaction is greater than safe time. Instead of waiting for the
safe time update, we should fallback to reading index from the leader to
minimize the time of processing the current RO request.

To do this, we should compare the read timestamp with safe time, and if read
timestamp is greater, and since the last RW transaction (affecting this
replica) some time passed that is greater than some timeout (i.e. we expect
that the safe time will be updated only via periodic updates) we shouldn't wait
for safe time and perform read index request to leader to get the latest
updates that may not have been replicated yet.

If readIndex shows that the current committed index on leader is the same that
is on replica (i.e. replica doesn't expect any updates that are being
replicated) it means that read-only request must wait for safe time update
without further attempts to repeat readIndex operation which highly likely will
be mostly useless.

We should also think about the measures to prevent extra load from replicas
spamming readIndex while receiving multiple read-only requests.

was:
Safe time for non-primary replicas (see IGNITE-17263 ) was conceived as
optimization to avoid unnecessary network hops. Safe time is propagated from
primary replica via raft appendEntries messages. When there is constant load on
cluster that is caused by RW transactions, these messages are refreshing safe
time on replicas with decent frequency, but in case of idle cluster, or cluster
with read-only load, safe time is propagated periodically via heartbeats. This
means that, if a RO transaction with read timestamp in present or future, is
trying to read a value from non-primary replica, it will wait for safe time
first, which is bound to frequency of heartbeat messages, and hence, the
duration of the read operation may be close to the period of heartbeats. This
looks weird and will cause performance issues.

[jira] [Updated] (IGNITE-17872) Fetch commit index on non-primary replicas instead of waiting for safe time in case of RO tx on idle cluster

2022-10-17 Thread Denis Chudov (Jira)

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

If readIndex shows that the current committed index on leader is the same that
is on replica (i.e. replica doesn't expect any updates that are being
replicated) it means that read-only request must wait for actual safe time
without further attempts to repeat readIndex operation which highly likely will
be mostly useless.

We should also think about the measures to prevent extra load from replicas
spamming readIndex while receiving multiple read-only requests.

> Fetch commit index on non-primary replicas instead of waiting for safe time
> in case of RO tx on idle cluster
>

[jira] [Updated] (IGNITE-17913) Ignite node start is broken



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

Aleksandr updated IGNITE-17913:
---
Component/s: cli

> Ignite node start is broken
> ---
>
> Key: IGNITE-17913
> URL: https://issues.apache.org/jira/browse/IGNITE-17913
> Project: Ignite
>  Issue Type: Bug
>  Components: cli
>Reporter: Aleksandr
>Priority: Critical
>  Labels: ignite-3, ignite-3-cli-tool
>
> It seems like several recent AI3 CLI builds (including ignite-3.0.0-beta-1 
> branch) are broken. It's impossible to start a single node. 
> Steps to reproduce:
> 1) Download build artifacts from TeamCity
> 2) Install distribution using ignite bootstrap --repo=
> 3) Try to start node:
> $ ./ignite node start --config=examples/config/ignite-config.conf 
> standalone-sql-node
> Starting a new Ignite node...
> Can't start the node. Read logs for details: 
> /home/zloddey/opt/ai3/ignite-log/standalone-sql-node.log
> In log file, there is the following error:
> Missing required option: '--node-name='
> Usage: runner --node-name= --work-dir= 
> [--join=[,
>   ...]]... [--config-path= |
>   --config-string=]
>   --config-path=
>  Path to node configuration file in HOCON format.
>   --config-string=
>  Node configuration in HOCON format.
>   --join=[,...]
>  Seed nodes.
>   --node-name= Node name.
>   --work-dir=   Path to node working directory.



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

[jira] [Commented] (IGNITE-17913) Ignite node start is broken



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

Aleksandr commented on IGNITE-17913:


Seems like the regression after 
https://issues.apache.org/jira/browse/IGNITE-17726

> Ignite node start is broken
> ---
>
> Key: IGNITE-17913
> URL: https://issues.apache.org/jira/browse/IGNITE-17913
> Project: Ignite
>  Issue Type: Bug
>Reporter: Aleksandr
>Priority: Critical
>  Labels: ignite-3, ignite-3-cli-tool
>
> It seems like several recent AI3 CLI builds (including ignite-3.0.0-beta-1 
> branch) are broken. It's impossible to start a single node. 
> Steps to reproduce:
> 1) Download build artifacts from TeamCity
> 2) Install distribution using ignite bootstrap --repo=
> 3) Try to start node:
> $ ./ignite node start --config=examples/config/ignite-config.conf 
> standalone-sql-node
> Starting a new Ignite node...
> Can't start the node. Read logs for details: 
> /home/zloddey/opt/ai3/ignite-log/standalone-sql-node.log
> In log file, there is the following error:
> Missing required option: '--node-name='
> Usage: runner --node-name= --work-dir= 
> [--join=[,
>   ...]]... [--config-path= |
>   --config-string=]
>   --config-path=
>  Path to node configuration file in HOCON format.
>   --config-string=
>  Node configuration in HOCON format.
>   --join=[,...]
>  Seed nodes.
>   --node-name= Node name.
>   --work-dir=   Path to node working directory.



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

[jira] [Created] (IGNITE-17913) Ignite node start is broken

Aleksandr created IGNITE-17913:
--

 Summary: Ignite node start is broken
 Key: IGNITE-17913
 URL: https://issues.apache.org/jira/browse/IGNITE-17913
 Project: Ignite
  Issue Type: Bug
Reporter: Aleksandr


It seems like several recent AI3 CLI builds (including ignite-3.0.0-beta-1 
branch) are broken. It's impossible to start a single node. 

Steps to reproduce:
1) Download build artifacts from TeamCity
2) Install distribution using ignite bootstrap --repo=
3) Try to start node:
$ ./ignite node start --config=examples/config/ignite-config.conf 
standalone-sql-node
Starting a new Ignite node...
Can't start the node. Read logs for details: 
/home/zloddey/opt/ai3/ignite-log/standalone-sql-node.log
In log file, there is the following error:
Missing required option: '--node-name='
Usage: runner --node-name= --work-dir= [--join=[,
  ...]]... [--config-path= |
  --config-string=]
  --config-path=
 Path to node configuration file in HOCON format.
  --config-string=
 Node configuration in HOCON format.
  --join=[,...]
 Seed nodes.
  --node-name= Node name.
  --work-dir=   Path to node working directory.





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

[jira] [Updated] (IGNITE-17912) Ducktape tests broken

2022-10-17 Thread Nikolay Izhikov (Jira)



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

Nikolay Izhikov updated IGNITE-17912:
-
Fix Version/s: 2.15

> Ducktape tests broken
> -
>
> Key: IGNITE-17912
> URL: https://issues.apache.org/jira/browse/IGNITE-17912
> Project: Ignite
>  Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
> Fix For: 2.15
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Several Ducktape tests broken after IGNITE-17736.
> {noformat}
> FAILED TESTS
> 1a94b6@‌‌ignitetest.tests.rebalance.in_memory_test.RebalanceInMemoryTest.test_node_join.backups=1.cache_count=1.entry_count=15000.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-2.13.0
> 1a94b6@‌‌ignitetest.tests.rebalance.in_memory_test.RebalanceInMemoryTest.test_node_left.backups=1.cache_count=1.entry_count=15000.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-2.13.0
> 1a94b6@‌‌ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.node_join_historical_test.backups=1.cache_count=1.entry_count=15000.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-2.13.0
> 1d1243@‌‌ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.test_node_left.backups=1.cache_count=1.entry_count=5.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-dev
> 9d1550@‌‌ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.test_node_join.backups=1.cache_count=1.entry_count=5000.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-2.13.0
> dc8511@‌‌ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.test_node_join.backups=1.cache_count=1.entry_count=5000.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-dev
> f75167@‌‌ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.test_node_left.backups=1.cache_count=1.entry_count=5.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-2.13.0
> fbd673@‌‌ignitetest.tests.rebalance.in_memory_test.RebalanceInMemoryTest.test_node_join.backups=1.cache_count=1.entry_count=15000.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-dev
> fbd673@‌‌ignitetest.tests.rebalance.in_memory_test.RebalanceInMemoryTest.test_node_left.backups=1.cache_count=1.entry_count=15000.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-dev
> fbd673@‌‌ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.node_join_historical_test.backups=1.cache_count=1.entry_count=15000.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-dev
> 43105a@‌‌ignitetest.tests.control_utility.consistency_test.ConsistencyTest.test_logging.ignite_version=ignite-dev
> {noformat}



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

[jira] [Updated] (IGNITE-17909) Extract Network configuration into corresponding modules

2022-10-17 Thread Aleksandr Polovtcev (Jira)



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

Aleksandr Polovtcev updated IGNITE-17909:
-
Fix Version/s: 3.0.0-beta2

> Extract Network configuration into corresponding modules
> 
>
> Key: IGNITE-17909
> URL: https://issues.apache.org/jira/browse/IGNITE-17909
> Project: Ignite
>  Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> This is part of the work related to removing configuration from the 
> ignite-api module. Network configuration schema should be moved to the 
> {{ignite-network}} module.



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

[jira] [Comment Edited] (IGNITE-17816) Sort out and merge Calcite tickets to Ignite 3.0 (step 7)



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

Andrey Mashenkov edited comment on IGNITE-17816 at 10/17/22 10:33 AM:
--

I see 5 tickets in description and 8 commits, all of them have same name.


was (Author: amashenkov):
I see 6 tickets in description and 8 commits, all of them have same name.

>  Sort out and merge Calcite tickets to Ignite 3.0 (step 7)
> --
>
> Key: IGNITE-17816
> URL: https://issues.apache.org/jira/browse/IGNITE-17816
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
>  Labels: calcite, ignite-3
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Let's merge the following tickets to ignite 3.0:
> https://issues.apache.org/jira/browse/IGNITE-16443
> https://issues.apache.org/jira/browse/IGNITE-16151
> https://issues.apache.org/jira/browse/IGNITE-16701
> https://issues.apache.org/jira/browse/IGNITE-16693
> https://issues.apache.org/jira/browse/IGNITE-16053
> After merge needs to remove the label {*}calcite3-required{*}.
> Tickets that could be simply merged - merge immediately. For hard cases let's 
> create separate tickets with estimation and link them to IGNITE-15658 or 
> links to blocker ticket.



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

[jira] [Commented] (IGNITE-17816) Sort out and merge Calcite tickets to Ignite 3.0 (step 7)



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

Andrey Mashenkov commented on IGNITE-17816:
---

I see 6 tickets in description and 8 commits, all of them have same name.

>  Sort out and merge Calcite tickets to Ignite 3.0 (step 7)
> --
>
> Key: IGNITE-17816
> URL: https://issues.apache.org/jira/browse/IGNITE-17816
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
>  Labels: calcite, ignite-3
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Let's merge the following tickets to ignite 3.0:
> https://issues.apache.org/jira/browse/IGNITE-16443
> https://issues.apache.org/jira/browse/IGNITE-16151
> https://issues.apache.org/jira/browse/IGNITE-16701
> https://issues.apache.org/jira/browse/IGNITE-16693
> https://issues.apache.org/jira/browse/IGNITE-16053
> After merge needs to remove the label {*}calcite3-required{*}.
> Tickets that could be simply merged - merge immediately. For hard cases let's 
> create separate tickets with estimation and link them to IGNITE-15658 or 
> links to blocker ticket.



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

[jira] [Commented] (IGNITE-17816) Sort out and merge Calcite tickets to Ignite 3.0 (step 7)



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

Yury Gerzhedovich commented on IGNITE-17816:


[~amashenkov] , yes, all of them are ported ( one has been removed from the 
scope). Each of them ported as a separate commit, except few additional commits 
related to fixing flaky reworked test and fixes related to code style.

>  Sort out and merge Calcite tickets to Ignite 3.0 (step 7)
> --
>
> Key: IGNITE-17816
> URL: https://issues.apache.org/jira/browse/IGNITE-17816
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
>  Labels: calcite, ignite-3
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Let's merge the following tickets to ignite 3.0:
> https://issues.apache.org/jira/browse/IGNITE-16443
> https://issues.apache.org/jira/browse/IGNITE-16151
> https://issues.apache.org/jira/browse/IGNITE-16701
> https://issues.apache.org/jira/browse/IGNITE-16693
> https://issues.apache.org/jira/browse/IGNITE-16053
> After merge needs to remove the label {*}calcite3-required{*}.
> Tickets that could be simply merged - merge immediately. For hard cases let's 
> create separate tickets with estimation and link them to IGNITE-15658 or 
> links to blocker ticket.



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

[jira] [Updated] (IGNITE-17816) Sort out and merge Calcite tickets to Ignite 3.0 (step 7)



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

Yury Gerzhedovich updated IGNITE-17816:
---
Description: 
Let's merge the following tickets to ignite 3.0:
https://issues.apache.org/jira/browse/IGNITE-16443
https://issues.apache.org/jira/browse/IGNITE-16151
https://issues.apache.org/jira/browse/IGNITE-16701
https://issues.apache.org/jira/browse/IGNITE-16693
https://issues.apache.org/jira/browse/IGNITE-16053

After merge needs to remove the label {*}calcite3-required{*}.

Tickets that could be simply merged - merge immediately. For hard cases let's 
create separate tickets with estimation and link them to IGNITE-15658 or links 
to blocker ticket.

  was:
Let's merge the following tickets to ignite 3.0:
https://issues.apache.org/jira/browse/IGNITE-16443
https://issues.apache.org/jira/browse/IGNITE-16151
https://issues.apache.org/jira/browse/IGNITE-16701
https://issues.apache.org/jira/browse/IGNITE-16693
https://issues.apache.org/jira/browse/IGNITE-15425
https://issues.apache.org/jira/browse/IGNITE-16053

After merge needs to remove the label *calcite3-required*.



Tickets that could be simply merged - merge immediately. For hard cases let's 
create separate tickets with estimation and link them to IGNITE-15658 or links 
to blocker ticket.


>  Sort out and merge Calcite tickets to Ignite 3.0 (step 7)
> --
>
> Key: IGNITE-17816
> URL: https://issues.apache.org/jira/browse/IGNITE-17816
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
>  Labels: calcite, ignite-3
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Let's merge the following tickets to ignite 3.0:
> https://issues.apache.org/jira/browse/IGNITE-16443
> https://issues.apache.org/jira/browse/IGNITE-16151
> https://issues.apache.org/jira/browse/IGNITE-16701
> https://issues.apache.org/jira/browse/IGNITE-16693
> https://issues.apache.org/jira/browse/IGNITE-16053
> After merge needs to remove the label {*}calcite3-required{*}.
> Tickets that could be simply merged - merge immediately. For hard cases let's 
> create separate tickets with estimation and link them to IGNITE-15658 or 
> links to blocker ticket.



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

[jira] [Commented] (IGNITE-17816) Sort out and merge Calcite tickets to Ignite 3.0 (step 7)



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

Andrey Mashenkov commented on IGNITE-17816:
---

There are 6 tickets in description to port to ignite-3.
It is almost impossible to figure out quickly what changes in 40+ files relates 
to what tickets.

>  Sort out and merge Calcite tickets to Ignite 3.0 (step 7)
> --
>
> Key: IGNITE-17816
> URL: https://issues.apache.org/jira/browse/IGNITE-17816
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
>  Labels: calcite, ignite-3
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Let's merge the following tickets to ignite 3.0:
> https://issues.apache.org/jira/browse/IGNITE-16443
> https://issues.apache.org/jira/browse/IGNITE-16151
> https://issues.apache.org/jira/browse/IGNITE-16701
> https://issues.apache.org/jira/browse/IGNITE-16693
> https://issues.apache.org/jira/browse/IGNITE-15425
> https://issues.apache.org/jira/browse/IGNITE-16053
> After merge needs to remove the label *calcite3-required*.
> Tickets that could be simply merged - merge immediately. For hard cases let's 
> create separate tickets with estimation and link them to IGNITE-15658 or 
> links to blocker ticket.



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

[jira] [Comment Edited] (IGNITE-17816) Sort out and merge Calcite tickets to Ignite 3.0 (step 7)



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

Andrey Mashenkov edited comment on IGNITE-17816 at 10/17/22 10:05 AM:
--

There are 6 tickets in description to port to ignite-3.
It is almost impossible to figure out quickly what changes in 40+ files relates 
to what tickets.

Did all of them were ported? How to check this? 


was (Author: amashenkov):
There are 6 tickets in description to port to ignite-3.
It is almost impossible to figure out quickly what changes in 40+ files relates 
to what tickets.

>  Sort out and merge Calcite tickets to Ignite 3.0 (step 7)
> --
>
> Key: IGNITE-17816
> URL: https://issues.apache.org/jira/browse/IGNITE-17816
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
>  Labels: calcite, ignite-3
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Let's merge the following tickets to ignite 3.0:
> https://issues.apache.org/jira/browse/IGNITE-16443
> https://issues.apache.org/jira/browse/IGNITE-16151
> https://issues.apache.org/jira/browse/IGNITE-16701
> https://issues.apache.org/jira/browse/IGNITE-16693
> https://issues.apache.org/jira/browse/IGNITE-15425
> https://issues.apache.org/jira/browse/IGNITE-16053
> After merge needs to remove the label *calcite3-required*.
> Tickets that could be simply merged - merge immediately. For hard cases let's 
> create separate tickets with estimation and link them to IGNITE-15658 or 
> links to blocker ticket.



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

[jira] [Commented] (IGNITE-17909) Extract Network configuration into corresponding modules



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

Roman Puchkovskiy commented on IGNITE-17909:


The patch looks good to me

> Extract Network configuration into corresponding modules
> 
>
> Key: IGNITE-17909
> URL: https://issues.apache.org/jira/browse/IGNITE-17909
> Project: Ignite
>  Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
>  Labels: ignite-3
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This is part of the work related to removing configuration from the 
> ignite-api module. Network configuration schema should be moved to the 
> {{ignite-network}} module.



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

[jira] [Updated] (IGNITE-17909) Extract Network configuration into corresponding modules



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

Roman Puchkovskiy updated IGNITE-17909:
---
Reviewer: Roman Puchkovskiy

> Extract Network configuration into corresponding modules
> 
>
> Key: IGNITE-17909
> URL: https://issues.apache.org/jira/browse/IGNITE-17909
> Project: Ignite
>  Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
>  Labels: ignite-3
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This is part of the work related to removing configuration from the 
> ignite-api module. Network configuration schema should be moved to the 
> {{ignite-network}} module.



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

[jira] [Updated] (IGNITE-17912) Ducktape tests broken

2022-10-17 Thread Nikolay Izhikov (Jira)



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

Nikolay Izhikov updated IGNITE-17912:
-
Description: 
Several Ducktape tests broken after IGNITE-17736.

{noformat}
FAILED TESTS
1a94b6@‌‌ignitetest.tests.rebalance.in_memory_test.RebalanceInMemoryTest.test_node_join.backups=1.cache_count=1.entry_count=15000.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-2.13.0
1a94b6@‌‌ignitetest.tests.rebalance.in_memory_test.RebalanceInMemoryTest.test_node_left.backups=1.cache_count=1.entry_count=15000.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-2.13.0
1a94b6@‌‌ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.node_join_historical_test.backups=1.cache_count=1.entry_count=15000.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-2.13.0
1d1243@‌‌ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.test_node_left.backups=1.cache_count=1.entry_count=5.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-dev
9d1550@‌‌ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.test_node_join.backups=1.cache_count=1.entry_count=5000.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-2.13.0
dc8511@‌‌ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.test_node_join.backups=1.cache_count=1.entry_count=5000.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-dev
f75167@‌‌ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.test_node_left.backups=1.cache_count=1.entry_count=5.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-2.13.0
fbd673@‌‌ignitetest.tests.rebalance.in_memory_test.RebalanceInMemoryTest.test_node_join.backups=1.cache_count=1.entry_count=15000.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-dev
fbd673@‌‌ignitetest.tests.rebalance.in_memory_test.RebalanceInMemoryTest.test_node_left.backups=1.cache_count=1.entry_count=15000.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-dev
fbd673@‌‌ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.node_join_historical_test.backups=1.cache_count=1.entry_count=15000.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-dev
43105a@‌‌ignitetest.tests.control_utility.consistency_test.ConsistencyTest.test_logging.ignite_version=ignite-dev
{noformat}

  was:
Several Ducktape tests broken after IGNITE-17736.



> Ducktape tests broken
> -
>
> Key: IGNITE-17912
> URL: https://issues.apache.org/jira/browse/IGNITE-17912
> Project: Ignite
>  Issue Type: Bug
>Reporter: Nikolay Izhikov
>Assignee: Nikolay Izhikov
>Priority: Major
>
> Several Ducktape tests broken after IGNITE-17736.
> {noformat}
> FAILED TESTS
> 1a94b6@‌‌ignitetest.tests.rebalance.in_memory_test.RebalanceInMemoryTest.test_node_join.backups=1.cache_count=1.entry_count=15000.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-2.13.0
> 1a94b6@‌‌ignitetest.tests.rebalance.in_memory_test.RebalanceInMemoryTest.test_node_left.backups=1.cache_count=1.entry_count=15000.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-2.13.0
> 1a94b6@‌‌ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.node_join_historical_test.backups=1.cache_count=1.entry_count=15000.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-2.13.0
> 1d1243@‌‌ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.test_node_left.backups=1.cache_count=1.entry_count=5.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-dev
> 9d1550@‌‌ignitetest.tests.rebalance.persistent_test.RebalancePersistentTest.test_node_join.backups=1.cache_count=1.entry_count=5000.entry_size=5.preloaders=1.thread_pool_size=None.batch_size=None.batches_prefetch_count=None.throttle=None.ignite_version=ignite-2.13.0
>

[jira] [Created] (IGNITE-17912) Ducktape tests broken

2022-10-17 Thread Nikolay Izhikov (Jira)

Nikolay Izhikov created IGNITE-17912:


 Summary: Ducktape tests broken
 Key: IGNITE-17912
 URL: https://issues.apache.org/jira/browse/IGNITE-17912
 Project: Ignite
  Issue Type: Bug
Reporter: Nikolay Izhikov
Assignee: Nikolay Izhikov


Several Ducktape tests broken after IGNITE-17736.




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

[jira] [Commented] (IGNITE-11368) use the same information about indexes for JDBC drivers as for system view INDEXES

2022-10-17 Thread Ilya Shishkov (Jira)



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

Ilya Shishkov commented on IGNITE-11368:


[~timonin.maksim], [~jooger], can you take a look, please?

Above failure are unrelated to the fix.

> use the same information about indexes for JDBC drivers as for system view 
> INDEXES
> --
>
> Key: IGNITE-11368
> URL: https://issues.apache.org/jira/browse/IGNITE-11368
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, odbc, sql
>Reporter: Yury Gerzhedovich
>Assignee: Ilya Shishkov
>Priority: Major
>  Labels: ise, newbie
> Attachments: indexes_sqlline.txt
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> As of now indexes information for JDBC drivers get by another way then system 
> SQL view INDEXES. Need to use single source of the information to have 
> consistent picture.
> So, JDBC drivers should use the same source as SQL view INDEXES 
> (org.apache.ignite.internal.processors.query.h2.sys.view.SqlSystemViewIndexes)
> Start point for JDBC index metadata is 
> org.apache.ignite.internal.jdbc2.JdbcDatabaseMetadata#getIndexInfo
> Also order of result should be correspond Javadoc ('ordered by NON_UNIQUE, 
> TYPE, INDEX_NAME, and ORDINAL_POSITION') - at present it is not so.



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

[jira] [Commented] (IGNITE-11368) use the same information about indexes for JDBC drivers as for system view INDEXES

2022-10-17 Thread Ignite TC Bot (Jira)



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

Ignite TC Bot commented on IGNITE-11368:


{panel:title=Branch: [pull/10316/head] Base: [master] : Possible Blockers 
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 2{color} [[tests 1 TIMEOUT , Out Of Memory Error 
|https://ci.ignite.apache.org/viewLog.html?buildId=6837422]]
* IgniteCacheTestSuite2: 
IgniteCacheClientNodeChangingTopologyTest.testPessimisticTx - Test has low fail 
rate in base branch 0,0% and is not flaky

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

> use the same information about indexes for JDBC drivers as for system view 
> INDEXES
> --
>
> Key: IGNITE-11368
> URL: https://issues.apache.org/jira/browse/IGNITE-11368
> Project: Ignite
>  Issue Type: Task
>  Components: jdbc, odbc, sql
>Reporter: Yury Gerzhedovich
>Assignee: Ilya Shishkov
>Priority: Major
>  Labels: ise, newbie
> Attachments: indexes_sqlline.txt
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> As of now indexes information for JDBC drivers get by another way then system 
> SQL view INDEXES. Need to use single source of the information to have 
> consistent picture.
> So, JDBC drivers should use the same source as SQL view INDEXES 
> (org.apache.ignite.internal.processors.query.h2.sys.view.SqlSystemViewIndexes)
> Start point for JDBC index metadata is 
> org.apache.ignite.internal.jdbc2.JdbcDatabaseMetadata#getIndexInfo
> Also order of result should be correspond Javadoc ('ordered by NON_UNIQUE, 
> TYPE, INDEX_NAME, and ORDINAL_POSITION') - at present it is not so.



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

[jira] [Assigned] (IGNITE-9205) Add ability to change WAL mode for cachegroup through public API and SQL



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

Ivan Daschinsky reassigned IGNITE-9205:
---

Assignee: (was: Ivan Daschinsky)

> Add ability to change WAL mode for cachegroup through public API and SQL
> 
>
> Key: IGNITE-9205
> URL: https://issues.apache.org/jira/browse/IGNITE-9205
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Ivan Daschinsky
>Priority: Minor
>
> Sometimes it's desirable to disable WAL for cachegroup, but currently it's 
> impossible either through public API or SQL.
> 1. ALTER CACHEGROUP should be added to DDL
> 2. API to at least ClusterEx.



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

[jira] [Updated] (IGNITE-17260) Enrich IgniteTransactions and Transaction interfaces with RO related methods

2022-10-17 Thread Alexander Lapin (Jira)



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

Alexander Lapin updated IGNITE-17260:
-
Description: 
It's required to explicitly register an intent of starting readOnly 
transaction, so following decorator producer is expected in IgniteTransactions
{code:java}
/**
 * Decorated {@code IgniteTransactions} instance that will start read-only 
transactions.
 *
 * @return Decorated {@code IgniteTransactions} instance that will start 
read-only transactions.
 */
IgniteTransactions readOnly(); {code}
Besides that Transaction interface should be extended with
{code:java}
boolean isReadOnly();{code}
and
{code:java}
HybridTimestamp timestamp();{code}
methods.

And finally three more overloaded methods will be added to the InternalTable
{code:java}
    CompletableFuture get(
            BinaryRowEx keyRow,
            @Nullable InternalTransaction tx,
            @NotNull ClusterNode recipientNode
    );
 
    CompletableFuture> getAll(
            Collection keyRows,
            @Nullable InternalTransaction tx,
            @NotNull ClusterNode recipientNode
    );
 
    Publisher scan(
            int p,
            @Nullable InternalTransaction tx,
            @NotNull ClusterNode recipientNode
    );
{code}
Please, pay attention, that new parameter  @NotNull ClusterNode recipientNode 
is added.

  was:
It's required to explicitly register an intent of starting readOnly 
transaction, so following decorator producer is expected in IgniteTransactions
{code:java}
/**
 * Decorated {@code IgniteTransactions} instance that will start read-only 
transactions.
 *
 * @return Decorated {@code IgniteTransactions} instance that will start 
read-only transactions.
 */
IgniteTransactions readOnly(); {code}
Besides that Transaction interface should be extended with
{code:java}
boolean isReadOnly();{code}
and
{code:java}
HybridTimestamp timestamp();{code}
methods.

And finally three more overloaded methods will be added to the InternalTable

 
{code:java}
    CompletableFuture get(
            BinaryRowEx keyRow,
            @Nullable InternalTransaction tx,
            @NotNull ClusterNode recipientNode
    );
 
    CompletableFuture> getAll(
            Collection keyRows,
            @Nullable InternalTransaction tx,
            @NotNull ClusterNode recipientNode
    );
 
    Publisher scan(
            int p,
            @Nullable InternalTransaction tx,
            @NotNull ClusterNode recipientNode
    );
{code}
 

Please, pay attention, that new parameter  @NotNull ClusterNode recipientNode 
is added.


> Enrich IgniteTransactions and Transaction interfaces with RO related methods
> 
>
> Key: IGNITE-17260
> URL: https://issues.apache.org/jira/browse/IGNITE-17260
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
>  Labels: ignite-3, transaction3_ro
>
> It's required to explicitly register an intent of starting readOnly 
> transaction, so following decorator producer is expected in IgniteTransactions
> {code:java}
> /**
>  * Decorated {@code IgniteTransactions} instance that will start read-only 
> transactions.
>  *
>  * @return Decorated {@code IgniteTransactions} instance that will start 
> read-only transactions.
>  */
> IgniteTransactions readOnly(); {code}
> Besides that Transaction interface should be extended with
> {code:java}
> boolean isReadOnly();{code}
> and
> {code:java}
> HybridTimestamp timestamp();{code}
> methods.
> And finally three more overloaded methods will be added to the InternalTable
> {code:java}
>     CompletableFuture get(
>             BinaryRowEx keyRow,
>             @Nullable InternalTransaction tx,
>             @NotNull ClusterNode recipientNode
>     );
>  
>     CompletableFuture> getAll(
>             Collection keyRows,
>             @Nullable InternalTransaction tx,
>             @NotNull ClusterNode recipientNode
>     );
>  
>     Publisher scan(
>             int p,
>             @Nullable InternalTransaction tx,
>             @NotNull ClusterNode recipientNode
>     );
> {code}
> Please, pay attention, that new parameter  @NotNull ClusterNode recipientNode 
> is added.



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

[jira] [Updated] (IGNITE-17260) Enrich IgniteTransactions and Transaction interfaces with RO related methods

2022-10-17 Thread Alexander Lapin (Jira)



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

Alexander Lapin updated IGNITE-17260:
-
Description: 
It's required to explicitly register an intent of starting readOnly 
transaction, so following decorator producer is expected in IgniteTransactions
{code:java}
/**
 * Decorated {@code IgniteTransactions} instance that will start read-only 
transactions.
 *
 * @return Decorated {@code IgniteTransactions} instance that will start 
read-only transactions.
 */
IgniteTransactions readOnly(); {code}
Besides that Transaction interface should be extended with
{code:java}
boolean isReadOnly();{code}
and
{code:java}
HybridTimestamp timestamp();{code}
methods.

And finally three more overloaded methods will be added to the InternalTable

 
{code:java}
    CompletableFuture get(
            BinaryRowEx keyRow,
            @Nullable InternalTransaction tx,
            @NotNull ClusterNode recipientNode
    );
 
    CompletableFuture> getAll(
            Collection keyRows,
            @Nullable InternalTransaction tx,
            @NotNull ClusterNode recipientNode
    );
 
    Publisher scan(
            int p,
            @Nullable InternalTransaction tx,
            @NotNull ClusterNode recipientNode
    );
{code}
 

Please, pay attention, that new parameter  @NotNull ClusterNode recipientNode 
is added.

  was:
It's required to explicitly register an intent of starting readOnly 
transaction, so following decorator producer is expected in IgniteTransactions
{code:java}
/**
 * Decorated {@code IgniteTransactions} instance that will start read-only 
transactions.
 *
 * @return Decorated {@code IgniteTransactions} instance that will start 
read-only transactions.
 */
IgniteTransactions readOnly(); {code}
Besides that Transaction interface should be extended with
{code:java}
boolean isReadOnly();{code}
and
{code:java}
HybridTimestamp timestamp();{code}
methods.

And finally three more overloaded methods will be added to the InternalTable

```

    CompletableFuture get(
            BinaryRowEx keyRow,
            @Nullable InternalTransaction tx,
            @NotNull ClusterNode recipientNode
    );

 

    CompletableFuture> getAll(
            Collection keyRows,
            @Nullable InternalTransaction tx,
            @NotNull ClusterNode recipientNode
    );

 

    Publisher scan(
            int p,
            @Nullable InternalTransaction tx,
            @NotNull ClusterNode recipientNode
    );

```

Please, pay attention, that new parameter  @NotNull ClusterNode recipientNode 
is added.


> Enrich IgniteTransactions and Transaction interfaces with RO related methods
> 
>
> Key: IGNITE-17260
> URL: https://issues.apache.org/jira/browse/IGNITE-17260
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
>  Labels: ignite-3, transaction3_ro
>
> It's required to explicitly register an intent of starting readOnly 
> transaction, so following decorator producer is expected in IgniteTransactions
> {code:java}
> /**
>  * Decorated {@code IgniteTransactions} instance that will start read-only 
> transactions.
>  *
>  * @return Decorated {@code IgniteTransactions} instance that will start 
> read-only transactions.
>  */
> IgniteTransactions readOnly(); {code}
> Besides that Transaction interface should be extended with
> {code:java}
> boolean isReadOnly();{code}
> and
> {code:java}
> HybridTimestamp timestamp();{code}
> methods.
> And finally three more overloaded methods will be added to the InternalTable
>  
> {code:java}
>     CompletableFuture get(
>             BinaryRowEx keyRow,
>             @Nullable InternalTransaction tx,
>             @NotNull ClusterNode recipientNode
>     );
>  
>     CompletableFuture> getAll(
>             Collection keyRows,
>             @Nullable InternalTransaction tx,
>             @NotNull ClusterNode recipientNode
>     );
>  
>     Publisher scan(
>             int p,
>             @Nullable InternalTransaction tx,
>             @NotNull ClusterNode recipientNode
>     );
> {code}
>  
> Please, pay attention, that new parameter  @NotNull ClusterNode recipientNode 
> is added.



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

[jira] [Updated] (IGNITE-17260) Enrich IgniteTransactions and Transaction interfaces with RO related methods

2022-10-17 Thread Alexander Lapin (Jira)



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

Alexander Lapin updated IGNITE-17260:
-
Description: 
It's required to explicitly register an intent of starting readOnly 
transaction, so following decorator producer is expected in IgniteTransactions
{code:java}
/**
 * Decorated {@code IgniteTransactions} instance that will start read-only 
transactions.
 *
 * @return Decorated {@code IgniteTransactions} instance that will start 
read-only transactions.
 */
IgniteTransactions readOnly(); {code}
Besides that Transaction interface should be extended with
{code:java}
boolean isReadOnly();{code}
and
{code:java}
HybridTimestamp timestamp();{code}
methods.

And finally three more overloaded methods will be added to the InternalTable

```

    CompletableFuture get(
            BinaryRowEx keyRow,
            @Nullable InternalTransaction tx,
            @NotNull ClusterNode recipientNode
    );

 

    CompletableFuture> getAll(
            Collection keyRows,
            @Nullable InternalTransaction tx,
            @NotNull ClusterNode recipientNode
    );

 

    Publisher scan(
            int p,
            @Nullable InternalTransaction tx,
            @NotNull ClusterNode recipientNode
    );

```

Please, pay attention, that new parameter  @NotNull ClusterNode recipientNode 
is added.

  was:
It's required to explicitly register an intent of starting readOnly 
transaction, so following decorator producer is expected in IgniteTransactions
{code:java}
/**
 * Decorated {@code IgniteTransactions} instance that will start read-only 
transactions.
 *
 * @return Decorated {@code IgniteTransactions} instance that will start 
read-only transactions.
 */
IgniteTransactions readOnly(); {code}
Besides that Transaction interface should be extended with
{code:java}
boolean isReadOnly();{code}
and
{code:java}
HybridTimestamp timestamp();{code}
methods.


> Enrich IgniteTransactions and Transaction interfaces with RO related methods
> 
>
> Key: IGNITE-17260
> URL: https://issues.apache.org/jira/browse/IGNITE-17260
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Alexander Lapin
>Priority: Major
>  Labels: ignite-3, transaction3_ro
>
> It's required to explicitly register an intent of starting readOnly 
> transaction, so following decorator producer is expected in IgniteTransactions
> {code:java}
> /**
>  * Decorated {@code IgniteTransactions} instance that will start read-only 
> transactions.
>  *
>  * @return Decorated {@code IgniteTransactions} instance that will start 
> read-only transactions.
>  */
> IgniteTransactions readOnly(); {code}
> Besides that Transaction interface should be extended with
> {code:java}
> boolean isReadOnly();{code}
> and
> {code:java}
> HybridTimestamp timestamp();{code}
> methods.
> And finally three more overloaded methods will be added to the InternalTable
> ```
>     CompletableFuture get(
>             BinaryRowEx keyRow,
>             @Nullable InternalTransaction tx,
>             @NotNull ClusterNode recipientNode
>     );
>  
>     CompletableFuture> getAll(
>             Collection keyRows,
>             @Nullable InternalTransaction tx,
>             @NotNull ClusterNode recipientNode
>     );
>  
>     Publisher scan(
>             int p,
>             @Nullable InternalTransaction tx,
>             @NotNull ClusterNode recipientNode
>     );
> ```
> Please, pay attention, that new parameter  @NotNull ClusterNode recipientNode 
> is added.



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

[jira] [Created] (IGNITE-17911) Wal isn't enabled for some caches after cancelling of rebalance

2022-10-17 Thread Aleksandr Polovtcev (Jira)

Aleksandr Polovtcev created IGNITE-17911:


 Summary: Wal isn't enabled for some caches after cancelling of 
rebalance
 Key: IGNITE-17911
 URL: https://issues.apache.org/jira/browse/IGNITE-17911
 Project: Ignite
  Issue Type: Task
Reporter: Aleksandr Polovtcev
Assignee: Aleksandr Polovtcev


WAL can be disabled during a rebalance if a node does not own any partitions. 
When stopping a node, a shutdown hook is used, which calls {{IgniteionEx#stop}} 
with the {{cancel}} flag set to {{true}}. This wakes up the checkpoint thread 
and starts doing a checkpoint, which creates a checkpoint start marker. 
However, since the {{cancel}} flag was set to {{true}}, 
{{Checkpointer#writePages}} finishes immediately and the checkpoint end marker 
is not created.

This means that we have not enabled WAL again, since the rebalance was 
interrupted, and we created a checkpoint start marker, but not the end marker. 
This leads to the node being started in maintenance mode.



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

[jira] [Updated] (IGNITE-17893) Implement RAFT snapshot streaming sender



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

Roman Puchkovskiy updated IGNITE-17893:
---
Fix Version/s: 3.0.0-beta2
   (was: 3.0.0-beta1)

> Implement RAFT snapshot streaming sender
> 
>
> Key: IGNITE-17893
> URL: https://issues.apache.org/jira/browse/IGNITE-17893
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> See IGNITE-17262



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

[jira] [Commented] (IGNITE-15245) JDBC connection leak with cache.invoke() over cache store with external JDBC storage



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

Yury Gerzhedovich commented on IGNITE-15245:


[~xtern] , LGTM, thanks for the contribution!

> JDBC connection leak with cache.invoke() over cache store with external JDBC 
> storage
> 
>
> Key: IGNITE-15245
> URL: https://issues.apache.org/jira/browse/IGNITE-15245
> Project: Ignite
>  Issue Type: Bug
>  Components: cache
>Affects Versions: 2.10
>Reporter: Ilya Korol
>Assignee: Pavel Pereslegin
>Priority: Major
> Fix For: 2.15
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Given following snippet:
> {code:java}
> try (Transaction tx = 
> ignite.transactions().txStart(TransactionConcurrency.PESSIMISTIC, 
> TransactionIsolation.REPEATABLE_READ)) {
> cache.invoke(pojo.getId(), entryProcessor, pojo);
> tx.commit();
> }
> {code}
> If we run this over the cache that uses external storage (e.g. mysql), we may 
> get exceptions like:
> {code:java}
> org.apache.ignite.IgniteCheckedException: Failed to load object ...
>  at 
> org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.loadFromStore(GridCacheStoreManagerAdapter.java:334)
>  at 
> org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.load(GridCacheStoreManagerAdapter.java:292)
>  at 
> org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.loadAllFromStore(GridCacheStoreManagerAdapter.java:433)
>  at 
> org.apache.ignite.internal.processors.cache.store.GridCacheStoreManagerAdapter.loadAll(GridCacheStoreManagerAdapter.java:399)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.loadMissingFromStore(GridDhtLockFuture.java:)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.onComplete(GridDhtLockFuture.java:790)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.onDone(GridDhtLockFuture.java:758)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.onDone(GridDhtLockFuture.java:91)
>  at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.onDone(GridFutureAdapter.java:475)
>  at 
> org.apache.ignite.internal.util.future.GridCompoundFuture.checkComplete(GridCompoundFuture.java:284)
>  at 
> org.apache.ignite.internal.util.future.GridCompoundFuture.markInitialized(GridCompoundFuture.java:273)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.map(GridDhtLockFuture.java:1052)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.onOwnerChanged(GridDhtLockFuture.java:709)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheMvccManager.notifyOwnerChanged(GridCacheMvccManager.java:226)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheMvccManager.access$200(GridCacheMvccManager.java:81)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheMvccManager$3.onOwnerChanged(GridCacheMvccManager.java:163)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkOwnerChanged(GridCacheMapEntry.java:5043)
>  at 
> org.apache.ignite.internal.processors.cache.GridCacheMapEntry.checkOwnerChanged(GridCacheMapEntry.java:4995)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.GridDistributedCacheEntry.readyLock(GridDistributedCacheEntry.java:515)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.readyLocks(GridDhtLockFuture.java:617)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtLockFuture.map(GridDhtLockFuture.java:825)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.lockAllAsyncInternal(GridDhtTransactionalCacheAdapter.java:1027)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocalAdapter.obtainLockAsync(GridDhtTxLocalAdapter.java:720)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTxLocalAdapter.lockAllAsync(GridDhtTxLocalAdapter.java:665)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.lockAllAsync(GridDhtTransactionalCacheAdapter.java:1238)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processNearLockRequest0(GridDhtTransactionalCacheAdapter.java:823)
>  at 
> org.apache.ignite.internal.processors.cache.distributed.dht.GridDhtTransactionalCacheAdapter.processNearLockRequest(GridDhtTransactionalCacheAdapter.java:801)
>  at 
>

[jira] [Created] (IGNITE-17910) .NET: Thin 3.0: Add KeyValueView

Pavel Tupitsyn created IGNITE-17910:
---

 Summary: .NET: Thin 3.0: Add KeyValueView
 Key: IGNITE-17910
 URL: https://issues.apache.org/jira/browse/IGNITE-17910
 Project: Ignite
  Issue Type: Improvement
  Components: platforms, thin client
Reporter: Pavel Tupitsyn
Assignee: Pavel Tupitsyn
 Fix For: 3.0.0-beta2


Following tuple-based KeyvalueBinaryView in IGNITE-16226, add KeyValueView with 
object mapping.



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

[jira] [Commented] (IGNITE-16226) .NET: Thin 3.0: Add KeyValueBinaryView



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

Pavel Tupitsyn commented on IGNITE-16226:
-

Merged to main: 5ff6f1ecb981b379f591b922759c9676e1e6f38a

> .NET: Thin 3.0: Add KeyValueBinaryView
> --
>
> Key: IGNITE-16226
> URL: https://issues.apache.org/jira/browse/IGNITE-16226
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms, thin client
>Affects Versions: 3.0.0-alpha3
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, ignite-3
> Fix For: 3.0.0-beta1
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> Implement *IKeyValueView*.



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

[jira] [Assigned] (IGNITE-17806) Rollback SQL automatically created transaction when an error has happened

2022-10-17 Thread Sergey Uttsel (Jira)



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

Sergey Uttsel reassigned IGNITE-17806:
--

Assignee: Sergey Uttsel

> Rollback SQL automatically created transaction when an error has happened
> -
>
> Key: IGNITE-17806
> URL: https://issues.apache.org/jira/browse/IGNITE-17806
> Project: Ignite
>  Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Assignee: Sergey Uttsel
>Priority: Major
>  Labels: ignite-3
>
> In some cases, when the used does not pass a transaction explicit to SQL, the 
> engine (SQLProcessor) creates a new one transaction automatically. When 
> during the execution an exception is thrown, the automatically created 
> transaction is not rolled back and freezes in pending state.
> Look at the test to find out the issue: _ItSqlSynchronousApiTest#errors_



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

[jira] [Updated] (IGNITE-17598) Unbind some JDBC/ODBC metadata requests from the ignite-indexing module



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

Ivan Daschinsky updated IGNITE-17598:
-
Ignite Flags: Release Notes Required  (was: Docs Required,Release Notes 
Required)

> Unbind some JDBC/ODBC metadata requests from the ignite-indexing module
> ---
>
> Key: IGNITE-17598
> URL: https://issues.apache.org/jira/browse/IGNITE-17598
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.14
>Reporter: Aleksey Plekhanov
>Assignee: Ivan Daschinsky
>Priority: Major
>  Labels: ise
> Fix For: 2.15
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> After IGNITE-15424 some JDBC/ODBC metadata requests still require indexing 
> module (Methods {{IgniteH2Indexing.resultMetaData}} and 
> \{{IgniteH2Indexing.parameterMetaData}} are used). If query engine used 
> without ignite-indexing module such requests can fail.



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

[jira] [Updated] (IGNITE-17598) Unbind some JDBC/ODBC metadata requests from the ignite-indexing module



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

Ivan Daschinsky updated IGNITE-17598:
-
Release Note: * SQL Calcite: implemented query metadata, required for odbc 
and jdbc.

> Unbind some JDBC/ODBC metadata requests from the ignite-indexing module
> ---
>
> Key: IGNITE-17598
> URL: https://issues.apache.org/jira/browse/IGNITE-17598
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.14
>Reporter: Aleksey Plekhanov
>Assignee: Ivan Daschinsky
>Priority: Major
>  Labels: ise
> Fix For: 2.15
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> After IGNITE-15424 some JDBC/ODBC metadata requests still require indexing 
> module (Methods {{IgniteH2Indexing.resultMetaData}} and 
> \{{IgniteH2Indexing.parameterMetaData}} are used). If query engine used 
> without ignite-indexing module such requests can fail.



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

[jira] [Updated] (IGNITE-17598) Unbind some JDBC/ODBC metadata requests from the ignite-indexing module



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

Ivan Daschinsky updated IGNITE-17598:
-
Ignite Flags: Docs Required,Release Notes Required  (was: Release Notes 
Required)

> Unbind some JDBC/ODBC metadata requests from the ignite-indexing module
> ---
>
> Key: IGNITE-17598
> URL: https://issues.apache.org/jira/browse/IGNITE-17598
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.14
>Reporter: Aleksey Plekhanov
>Assignee: Ivan Daschinsky
>Priority: Major
>  Labels: ise
> Fix For: 2.15
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> After IGNITE-15424 some JDBC/ODBC metadata requests still require indexing 
> module (Methods {{IgniteH2Indexing.resultMetaData}} and 
> \{{IgniteH2Indexing.parameterMetaData}} are used). If query engine used 
> without ignite-indexing module such requests can fail.



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

[jira] [Commented] (IGNITE-17598) Unbind some JDBC/ODBC metadata requests from the ignite-indexing module



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

Ivan Daschinsky commented on IGNITE-17598:
--

[~alex_pl] Thanks for review, merged to master

> Unbind some JDBC/ODBC metadata requests from the ignite-indexing module
> ---
>
> Key: IGNITE-17598
> URL: https://issues.apache.org/jira/browse/IGNITE-17598
> Project: Ignite
>  Issue Type: Improvement
>Affects Versions: 2.14
>Reporter: Aleksey Plekhanov
>Assignee: Ivan Daschinsky
>Priority: Major
>  Labels: ise
> Fix For: 2.15
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> After IGNITE-15424 some JDBC/ODBC metadata requests still require indexing 
> module (Methods {{IgniteH2Indexing.resultMetaData}} and 
> \{{IgniteH2Indexing.parameterMetaData}} are used). If query engine used 
> without ignite-indexing module such requests can fail.



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

[jira] [Updated] (IGNITE-17894) Implement RAFT snapshot streaming receiver



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

Kirill Tkalenko updated IGNITE-17894:
-
Fix Version/s: 3.0.0-beta2
   (was: 3.0.0-beta1)

> Implement RAFT snapshot streaming receiver
> --
>
> Key: IGNITE-17894
> URL: https://issues.apache.org/jira/browse/IGNITE-17894
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Roman Puchkovskiy
>Assignee: Kirill Tkalenko
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> See IGNITE-17262



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

[jira] [Updated] (IGNITE-17671) Implement BinaryTuple inlining in a sorted index B+Tree



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

Kirill Tkalenko updated IGNITE-17671:
-
Fix Version/s: 3.0.0-beta2
   (was: 3.0.0-beta1)

> Implement BinaryTuple inlining in a sorted index B+Tree
> ---
>
> Key: IGNITE-17671
> URL: https://issues.apache.org/jira/browse/IGNITE-17671
> Project: Ignite
>  Issue Type: Task
>Reporter: Kirill Tkalenko
>Assignee: Kirill Tkalenko
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> In a simple implementation, instead of a *BinaryTuple*, we store its link 
> from the *FreeList* in the key, this is not optimal and we need to inline the 
> *BinaryTuple* in the key, for starters, you can see how to do this in 2.0.



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

[jira] [Updated] (IGNITE-17907) Extract Table and Storage configuration into corresponding modules



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

Kirill Tkalenko updated IGNITE-17907:
-
Fix Version/s: 3.0.0-beta2

> Extract Table and Storage configuration into corresponding modules
> --
>
> Key: IGNITE-17907
> URL: https://issues.apache.org/jira/browse/IGNITE-17907
> Project: Ignite
>  Issue Type: Task
>Reporter: Aleksandr Polovtcev
>Assignee: Aleksandr Polovtcev
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This is part of the work related to removing configuration from the 
> ignite-api module. The following configurations should be moved:
> * Table configuration to {{ignite-schema}}.
> * Storage configuration to {{ignite-storage-api}}. However, this may 
> currently be impossible, because Table configuration depends on the storage 
> configuration, {{ignite-storage-api}} already depends on the 
> {{ignite-schema}} module.



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

[jira] [Updated] (IGNITE-17907) Extract Table and Storage configuration into corresponding modules