date:20221013



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

Pavel Tupitsyn updated IGNITE-17901:

Fix Version/s: 3.0.0-beta1

> .NET: Tests fail on TC due to Gradle daemon
> ---
>
> Key: IGNITE-17901
> URL: https://issues.apache.org/jira/browse/IGNITE-17901
> Project: Ignite
>  Issue Type: Bug
>  Components: build, ignite-3
>Reporter: Mikhail Pochatkin
>Assignee: Mikhail Pochatkin
>Priority: Major
>  Labels: .NET, ignite-3
> Fix For: 3.0.0-beta1
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




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

[jira] [Updated] (IGNITE-17901) .NET: Tests fail on TC due to Gradle daemon



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

Pavel Tupitsyn updated IGNITE-17901:

Description: .NET tests fail with "Starting a Gradle Daemon, 5 busy Daemons 
could not be reused, use --status for details" error.

> .NET: Tests fail on TC due to Gradle daemon
> ---
>
> Key: IGNITE-17901
> URL: https://issues.apache.org/jira/browse/IGNITE-17901
> Project: Ignite
>  Issue Type: Bug
>  Components: build, ignite-3
>Reporter: Mikhail Pochatkin
>Assignee: Mikhail Pochatkin
>Priority: Major
>  Labels: .NET, ignite-3
> Fix For: 3.0.0-beta1
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> .NET tests fail with "Starting a Gradle Daemon, 5 busy Daemons could not be 
> reused, use --status for details" error.



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

[jira] [Updated] (IGNITE-17901) .NET: Tests fail on TC due to Gradle daemon



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

Pavel Tupitsyn updated IGNITE-17901:

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

> .NET: Tests fail on TC due to Gradle daemon
> ---
>
> Key: IGNITE-17901
> URL: https://issues.apache.org/jira/browse/IGNITE-17901
> Project: Ignite
>  Issue Type: Bug
>  Components: build, ignite-3
>Reporter: Mikhail Pochatkin
>Assignee: Mikhail Pochatkin
>Priority: Major
>  Labels: .NET, ignite-3
> Fix For: 3.0.0-beta1
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




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

[jira] [Resolved] (IGNITE-17901) .NET: Tests fail on TC due to Gradle daemon



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

Pavel Tupitsyn resolved IGNITE-17901.
-
Resolution: Fixed

> .NET: Tests fail on TC due to Gradle daemon
> ---
>
> Key: IGNITE-17901
> URL: https://issues.apache.org/jira/browse/IGNITE-17901
> Project: Ignite
>  Issue Type: Bug
>  Components: build, ignite-3
>Reporter: Mikhail Pochatkin
>Assignee: Mikhail Pochatkin
>Priority: Major
>  Labels: .NET, ignite-3
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




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

[jira] [Commented] (IGNITE-17901) .NET: Tests fail on TC due to Gradle daemon



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

Pavel Tupitsyn commented on IGNITE-17901:
-

Merged to main: 0f777fa77be55e11fbfc408239c515a3e7707682

> .NET: Tests fail on TC due to Gradle daemon
> ---
>
> Key: IGNITE-17901
> URL: https://issues.apache.org/jira/browse/IGNITE-17901
> Project: Ignite
>  Issue Type: Bug
>  Components: build, ignite-3
>Reporter: Mikhail Pochatkin
>Assignee: Mikhail Pochatkin
>Priority: Major
>  Labels: .NET, ignite-3
>  Time Spent: 20m
>  Remaining Estimate: 0h
>




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

[jira] [Updated] (IGNITE-17901) .NET: Tests fail on TC due to Gradle daemon



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

Pavel Tupitsyn updated IGNITE-17901:

Summary: .NET: Tests fail on TC due to Gradle daemon  (was: Fix .NET tests)

> .NET: Tests fail on TC due to Gradle daemon
> ---
>
> Key: IGNITE-17901
> URL: https://issues.apache.org/jira/browse/IGNITE-17901
> Project: Ignite
>  Issue Type: Bug
>  Components: build, ignite-3
>Reporter: Mikhail Pochatkin
>Assignee: Mikhail Pochatkin
>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-17901) .NET: Tests fail on TC due to Gradle daemon



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

Pavel Tupitsyn updated IGNITE-17901:

Labels: .NET ignite-3  (was: ignite-3)

> .NET: Tests fail on TC due to Gradle daemon
> ---
>
> Key: IGNITE-17901
> URL: https://issues.apache.org/jira/browse/IGNITE-17901
> Project: Ignite
>  Issue Type: Bug
>  Components: build, ignite-3
>Reporter: Mikhail Pochatkin
>Assignee: Mikhail Pochatkin
>Priority: Major
>  Labels: .NET, ignite-3
>  Time Spent: 10m
>  Remaining Estimate: 0h
>




--
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=17617281#comment-17617281
 ] 

Ignite TC Bot commented on IGNITE-17870:


{panel:title=Branch: [pull/10303/head] Base: [master] : Possible Blockers 
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Cache 2{color} [[tests 0 TIMEOUT , Exit Code 
|https://ci.ignite.apache.org/viewLog.html?buildId=6830730]]

{panel}
{panel:title=Branch: [pull/10303/head] Base: [master] : New Tests 
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Queries 1 (lazy=true){color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=6826808]]
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite: 
SqlParserMultiStatementSelfTest.testEmptyTransaction - PASSED{color}

{color:#8b}Queries 1{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=6825430]]
* {color:#013220}IgniteBinaryCacheQueryTestSuite: 
SqlParserMultiStatementSelfTest.testEmptyTransaction - PASSED{color}

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

> 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] [Assigned] (IGNITE-17759) Need to pass commitTableId and commitPartitionId to MvPartitionStorage#addWrite

2022-10-13 Thread Denis Chudov (Jira)



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

Denis Chudov reassigned IGNITE-17759:
-

Assignee: (was: Denis Chudov)

> Need to pass commitTableId and commitPartitionId to 
> MvPartitionStorage#addWrite
> ---
>
> Key: IGNITE-17759
> URL: https://issues.apache.org/jira/browse/IGNITE-17759
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Sergey Uttsel
>Priority: Major
>  Labels: ignite-3, transaction3_ro
>
> Currently when PartitionListener invokes MvPartitionStorage#addWrite it 
> passes 
> UUID.randomUUID() as commitTableId and 0 as commitPartitionId. Need pass 
> appropriate values.
>  
> For this:
>  # Need to create
> {code:java}
> class PartitionId {
>     UUID tableId;
>     int partId;
> }{code}
>  # In InternalTableImpl#enlistInTx need to save PartitionId of the first 
> operation to the Transaction.
>  # Need to change {color:#172b4d}Map Long>> enlisted = new ConcurrentSkipListMap<>(){color} to Map IgniteBiTuple> enlisted = new ConcurrentHashMap<>();
>  # Need to change String groupId to PartitionId groupId in all places.
>  # In InternalTableImpl#enlistInTx need to pass PartitionId into 
> ReplicaRequest (ReadWriteSingleRowReplicaRequest, 
> ReadWriteSwapRowReplicaRequest, ReadWriteMultiRowReplicaRequest)
>  # In PartitionReplicaListener need to pass PartitionId from ReplicaRequest 
> to UpdateCommand and UpdateAllCommand.



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

[jira] [Created] (IGNITE-17901) Fix .NET tests

2022-10-13 Thread Mikhail Pochatkin (Jira)

Mikhail Pochatkin created IGNITE-17901:
--

 Summary: Fix .NET tests
 Key: IGNITE-17901
 URL: https://issues.apache.org/jira/browse/IGNITE-17901
 Project: Ignite
  Issue Type: Bug
  Components: build, ignite-3
Reporter: Mikhail Pochatkin






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

[jira] [Assigned] (IGNITE-17901) Fix .NET tests

2022-10-13 Thread Mikhail Pochatkin (Jira)



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

Mikhail Pochatkin reassigned IGNITE-17901:
--

Assignee: Mikhail Pochatkin

> Fix .NET tests
> --
>
> Key: IGNITE-17901
> URL: https://issues.apache.org/jira/browse/IGNITE-17901
> Project: Ignite
>  Issue Type: Bug
>  Components: build, ignite-3
>Reporter: Mikhail Pochatkin
>Assignee: Mikhail Pochatkin
>Priority: Major
>  Labels: ignite-3
>




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

[jira] [Commented] (IGNITE-17736) Consistency repair should support multiply partitions specification

2022-10-13 Thread Nikolay Izhikov (Jira)



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

Nikolay Izhikov commented on IGNITE-17736:
--

Failures unrelated

> Consistency repair should support multiply partitions specification
> ---
>
> Key: IGNITE-17736
> URL: https://issues.apache.org/jira/browse/IGNITE-17736
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: iep-31, ise
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> Checks should be performed in parallel.
>  
> Also, this issue is a good place for repformance tuning.
> We have some information from test environment:
> idle_verify for *641* partitions with *3* backups with *~ 600k* entries per 
> partition tooks {*}11 minutes{*}, but fix with RELATIVE_MAJORITY strategy 
> tooks {*}16 hours{*}.
> Parallel execution should decrease the duration significantly.
>  



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

[jira] [Updated] (IGNITE-17736) Consistency repair should support multiply partitions specification

2022-10-13 Thread Nikolay Izhikov (Jira)



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

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

> Consistency repair should support multiply partitions specification
> ---
>
> Key: IGNITE-17736
> URL: https://issues.apache.org/jira/browse/IGNITE-17736
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: iep-31, ise
> Fix For: 2.15
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> Checks should be performed in parallel.
>  
> Also, this issue is a good place for repformance tuning.
> We have some information from test environment:
> idle_verify for *641* partitions with *3* backups with *~ 600k* entries per 
> partition tooks {*}11 minutes{*}, but fix with RELATIVE_MAJORITY strategy 
> tooks {*}16 hours{*}.
> Parallel execution should decrease the duration significantly.
>  



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

[jira] [Commented] (IGNITE-17736) Consistency repair should support multiply partitions specification



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

Ignite TC Bot commented on IGNITE-17736:


{panel:title=Branch: [pull/10304/head] Base: [master] : Possible Blockers 
(2)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Control Utility 2{color} [[tests 
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6817887]]
* IgniteControlUtilityTestSuite2: 
GridCommandHandlerDefragmentationTest.testDefragmentationStatus - History for 
base branch is absent.

{color:#d04437}Queries 3 (lazy=true){color} [[tests 
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6817930]]
* IgniteBinaryCacheQueryLazyTestSuite3: SystemViewSelfTest.testScanQuery - Test 
has low fail rate in base branch 0,0% and is not flaky

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

> Consistency repair should support multiply partitions specification
> ---
>
> Key: IGNITE-17736
> URL: https://issues.apache.org/jira/browse/IGNITE-17736
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Assignee: Nikolay Izhikov
>Priority: Major
>  Labels: iep-31, ise
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> Checks should be performed in parallel.
>  
> Also, this issue is a good place for repformance tuning.
> We have some information from test environment:
> idle_verify for *641* partitions with *3* backups with *~ 600k* entries per 
> partition tooks {*}11 minutes{*}, but fix with RELATIVE_MAJORITY strategy 
> tooks {*}16 hours{*}.
> Parallel execution should decrease the duration significantly.
>  



--
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=17617185#comment-17617185
 ] 

Ignite TC Bot commented on IGNITE-15245:


{panel:title=Branch: [pull/10302/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10302/head] Base: [master] : New Tests 
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 1{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=6830188]]
* {color:#013220}IgniteBinaryCacheTestSuite: 
CacheJdbcPojoWriteBehindConnectionLeakTest.testInvoke - PASSED{color}

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

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

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



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

  was:
It's required to explicitly register an intent of starting readOnly 
transaction, so that new methods similar to
{code:java}
Transaction begin(boolean readOnly){code}
 and
{code:java}
CompletableFuture beginAsync(boolean readOnly){code}
should be added to IgniteTransactions together with corresponding 
implementation.

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.



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

[jira] [Resolved] (IGNITE-17486) Enable Gradle build on CI



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

Pavel Tupitsyn resolved IGNITE-17486.
-
Resolution: Fixed

> Enable Gradle build on CI
> -
>
> Key: IGNITE-17486
> URL: https://issues.apache.org/jira/browse/IGNITE-17486
> Project: Ignite
>  Issue Type: New Feature
>  Components: build
>Reporter: Mikhail Pochatkin
>Assignee: Mikhail Pochatkin
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta1
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Start run build verifications for Gradle on CI.
> It should be separate verification pipeline with Maven.
> IMPORTANT: Maven build scripts should NOT removed in this ticket.



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

[jira] [Commented] (IGNITE-17486) Enable Gradle build on CI



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

Pavel Tupitsyn commented on IGNITE-17486:
-

Merged to main: 92c0282a2059e958e0398433fb4b1d30a946b127

> Enable Gradle build on CI
> -
>
> Key: IGNITE-17486
> URL: https://issues.apache.org/jira/browse/IGNITE-17486
> Project: Ignite
>  Issue Type: New Feature
>  Components: build
>Reporter: Mikhail Pochatkin
>Assignee: Mikhail Pochatkin
>Priority: Major
>  Labels: ignite-3
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Start run build verifications for Gradle on CI.
> It should be separate verification pipeline with Maven.
> IMPORTANT: Maven build scripts should NOT removed in this ticket.



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

[jira] [Updated] (IGNITE-17486) Enable Gradle build on CI



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

Pavel Tupitsyn updated IGNITE-17486:

Fix Version/s: 3.0.0-beta1

> Enable Gradle build on CI
> -
>
> Key: IGNITE-17486
> URL: https://issues.apache.org/jira/browse/IGNITE-17486
> Project: Ignite
>  Issue Type: New Feature
>  Components: build
>Reporter: Mikhail Pochatkin
>Assignee: Mikhail Pochatkin
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta1
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> Start run build verifications for Gradle on CI.
> It should be separate verification pipeline with Maven.
> IMPORTANT: Maven build scripts should NOT removed in this 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)

2022-10-13 Thread Yury Gerzhedovich (Jira)



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

  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-16836
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
>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] [Assigned] (IGNITE-13024) Calcite integration. Support and simplification of complex expressions in index conditions



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

Aleksey Plekhanov reassigned IGNITE-13024:
--

Assignee: Aleksey Plekhanov

> Calcite integration. Support and simplification of complex expressions in 
> index conditions
> --
>
> Key: IGNITE-13024
> URL: https://issues.apache.org/jira/browse/IGNITE-13024
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Roman Kondakov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: calcite2-required, calcite3-required
>
> Current implementation supports only trivial expressions in index conditions, 
> i.e. {{x=1}}. We need to support all evaluatable expressions (which not 
> depends on input/table references) like {{x=?+10}}. Also we need to ensure 
> that complex expressions in index filters are simplified (see 
> {{RexSimplify}}).



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

[jira] [Updated] (IGNITE-13022) Calcite integration. Merge index conditions for the same field.



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

Aleksey Plekhanov updated IGNITE-13022:
---
Labels: calcite calcite3-required  (was: calcite2-required 
calcite3-required)

> Calcite integration. Merge index conditions for the same field.
> ---
>
> Key: IGNITE-13022
> URL: https://issues.apache.org/jira/browse/IGNITE-13022
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Roman Kondakov
>Assignee: Aleksey Plekhanov
>Priority: Minor
>  Labels: calcite, calcite3-required
> Fix For: 2.15
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Index scans should be able to merge index conditions. For example query
> {code:java}
> SELECT * FROM tbl WHERE a<5 AND a<10
> {code}
> should be reduced to
>  
> {code:java}
> SELECT * FROM tbl WHERE a<5
> {code}
> Parameters should be handled in a more tricky way:
> {code:java}
> SELECT * FROM tbl WHERE a {code}
> can be rewritten as
> {code:java}
> SELECT * FROM tbl WHERE a where the expression {{MIN(?1, ?2)}} should be evaluated right before the 
> execution when parameters are known.
>  
>  



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

[jira] [Commented] (IGNITE-17849) Remove filter from partition fullscan



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

Roman Puchkovskiy commented on IGNITE-17849:


Thank you!

> Remove filter from partition fullscan
> -
>
> Key: IGNITE-17849
> URL: https://issues.apache.org/jira/browse/IGNITE-17849
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta1
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> See these methods:
> {code:java}
> MvPartitionStorage#scan(Predicate, HybridTimestamp)
> MvPartitionStorage#scan(Predicate, UUID){code}
> This parameter turned out to be useless in current design.



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

[jira] [Commented] (IGNITE-17254) Storage API for RAFT snapshot streaming



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

Roman Puchkovskiy commented on IGNITE-17254:


Thank you!

> Storage API for RAFT snapshot streaming
> ---
>
> Key: IGNITE-17254
> URL: https://issues.apache.org/jira/browse/IGNITE-17254
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta1
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Current PartitionStorage has a method for taking snapshots (and a method for 
> restoring from them). The  methods work with files. In IGNITE-17253, we are 
> going to switch to streaming protocol (which does not use files at all). So 
> we need streaming snapshot-related methods on MvPartitionStorage.
> h3. UPDATE
> From my understanding, we basically need two more methods in the MV partition 
> storage to manipulate data:
> {code:java}
> // This one represents a combination of "addWrite" and "commitWrite", but a 
> faster one.
> // It will be used in incoming snapshot copier to write data.
> void addWriteCommitted(RowId rowId, BinaryRow row, HybridTimestamp 
> commitTimestamp);
> // This one will be used to get all versions of a particular row and form a 
> SnapshotMvDataResponse message.
> Cursor scanVersionsEx(RowId rowId);{code}
> Both of them are very simple and, for the most part, match their counterparts 
> in every storage.
> What's not as simple is the fail-over scenario. We shouldn't treat 
> partially-downloaded partition as a valid set of data. So, the easiest was 
> (in My opinion) to achieve this is to:
>  * set "lastAppliedIndex" value to "-1" before writing any the data
>  * drop old data (these two steps may be swapped, it's not that important)
>  * download and write everything
>  * set valid value for "lastAppliedIndex"
> This is a crude solution, but should work well, especially if properly 
> documented.



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

[jira] [Comment Edited] (IGNITE-17369) Snapshot is inconsistent under streamed loading with 'allowOverwrite==false'.

2022-10-13 Thread Vladimir Steshin (Jira)

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

Vladimir Steshin edited comment on IGNITE-17369 at 10/13/22 2:30 PM:
-

Snapshot can begin work with different state of kin partitions. The shapshot
process waits for the datastreamer futures.
(_GridCacheMvccManager.addDataStreamerFuture()_). The problem is that these
futures are created separately and concurrently on primary and backups nodes by
_IsolatedUpdater_. As result, at the checkpoint some backups might be written
without the primaries. And opposite. There are no updates accepted during
checkpoint. Late streamer updates is not written to snapshoting partitions.
This verification could produce a warninf of active streamer.

Solutions:

1) V1 (PR 10285).
PR brings watching _DataStreamer_ futures in snapshot process. The futures are
created before writing streamer batch on any node. We cannot relay on the
future as on final and consistent write for streamer batch or certain entry.
But we know that datastreamer is in progress at the checkpoint and that it is
on pause. We can invalidate snapshot at this moment.
In theory the solution is not resilent. On streamer batch could've been
entirely written before snapshot. Second batch after. First batch writes
partition on primaries or backups. Second writes the rest. Snapshot is
inconsistent.

2) V2 (PR 10286).
_IsolatedUpdater_ could just notify snapshot process, if exists, that
concurrent inconsistent update is on. A notification of at least one entry on
any node wound be enough. Should work in practice. In theory the solution is
not resilent. On streamer batch could've been entirely written before snapshot.
Second batch after. First batch writes partition on primaries or backups.
Second writes the rest. Snapshot is inconsistent.

3) V3 (PR 10284).
We could mark that _DataStreamer_ is on on any first streamer batch received.
And unmark somehow later. If _DataStreamer_ is marked as active, the snapshot
process could check this mark. Since the mark is set before writting data, it
is set before the datastreamer future which is being waited for in the snapshot
process. This guaraties the mark are visible before the snapshot.

The problem is how to close such mark. When the streaming node left? Node can
live forever. Send special closing request? The streamer node can do not close
streamer at all. Meaning no _close()_ is invoked. Moreoever, _DataStreamer_
works through _CommunicationSPI_. Which doesn't guarantee delivery. We can't be
sure that closing request is delivered and streamer is unmarked on the
accepting node. Do we need to set this mark with a timeout and re-set with next
datastreamer batche? Which timeout? Bind to what?
On closing requests, a rebalance can happen. Should be processed too. Looks
like we need a discovery closing message. Much simpler and reliable.
Also, datastreamer can be canceled. Meaning one batches were written before
snapshot. Other won't ever.

4) V4 (PR 10299).
We could watch streamer is already registered before snapshot and
simultaneously. The problem is that we need to monitor even client at the
snapshot beginning and make sure they answered whether streamer is on. We could
adjust snapshot process so that it would gather client responses at the start
stage. The process is already has snapshot verification routines.

A shared problem is that streamer could fail, be canceled or lost long ago,
before the snapshot. The data is alredy corrupted and streamer is gone, is not
seen.

was (Author: vladsz83):
Snapshot can begin work with different state of kin partitions. The shapshot
process waits for the datastreamer futures.
(_GridCacheMvccManager.addDataStreamerFuture()_). The problem is that these
futures are created separately and concurrently on primary and backups nodes by
_IsolatedUpdater_. As result, at the checkpoint some backups might be written
without the primaries. And opposite. There are no updates accepted during
checkpoint. Late streamer updates is not written to snapshoting partitions.
This verification could produce a warninf of active streamer.

Solutions:

2) V2 (PR 10286).
_IsolatedUpdater_ could just notify snapshot process, if

[jira] [Assigned] (IGNITE-17873) [Ignite Website] Ignite Summit 2022 Europe_Update website banners

2022-10-13 Thread Erlan Aytpaev (Jira)



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

Erlan Aytpaev reassigned IGNITE-17873:
--

Assignee: Erlan Aytpaev

> [Ignite Website] Ignite Summit 2022 Europe_Update website banners
> -
>
> Key: IGNITE-17873
> URL: https://issues.apache.org/jira/browse/IGNITE-17873
> Project: Ignite
>  Issue Type: Task
>  Components: website
>Reporter: Evgenia
>Assignee: Erlan Aytpaev
>Priority: Major
> Attachments: Event page.jpg, docs.jpg, ignite-Summit.jpg
>
>
> Please add a new Ignite Summit and update event banners.
>  
> All the links should lead to [Ignite Summit November 9, 2022 
> |https://ignite-summit.org/2022-november/]
> Places to update banners:
> 1) Featured events
> [Distributed Database - Apache Ignite|https://ignite.apache.org/]
> 2) Doc's banner
> [https://ignite.apache.org/docs/latest/]
> 3) Text banner at the top (doc's page)
> Ignite Summit Europe — November 9 — Join virtually! 
> 4) Update event page with a new image
> [Apache Ignite Events - Meetups, Summit, 
> Conference|https://ignite.apache.org/events.html#summit]



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

[jira] [Comment Edited] (IGNITE-17865) Disable partition ranges in log messages about rebalance or PME

2022-10-13 Thread Ilya Shishkov (Jira)



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

Ilya Shishkov edited comment on IGNITE-17865 at 10/13/22 1:20 PM:
--

[~slava.koptilin], hi!

I agree, that blowing up of logs is not a good idea, but are there any 
practical results, when such optimization can significantly reduce size of 
message and logs?
As I see, most of time lists of partitions in these messages do not form a 
continuous sequence, and even if so, only 2, and less often 3 and more 
partitions form continuous sequence. And for two partitions real economy is a 
whitespace symbol.


was (Author: shishkovilja):
[~slava.koptilin], hi!

I agree, that blowing up of logs is not a good idea, but are there any 
practical results, when such optimization can significantly reduce size of 
message and logs?
As I see, most of time lists of partitions in these messages does not form a 
continuous sequence, and even if so, only 2, and less often 3 and more 
partitions form continuous sequence. And for two partitions real economy is a 
whitespace symbol.

> Disable partition ranges in log messages about rebalance or PME
> ---
>
> Key: IGNITE-17865
> URL: https://issues.apache.org/jira/browse/IGNITE-17865
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Ilya Shishkov
>Priority: Minor
>  Labels: ise, newbie
>
> When you need to analyze cases of partitions inconsistency, full list of 
> partitions is needed, but there is an optimization which replaces list of 
> consecutive partitions with ranges. So, as you can see below, we can not find 
> partition 2 by simple text search:
> {quote}
> 2021-08-11 23:12:11.338 [WARN 
> ]\[sys-#213\][org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl]
>  Partitions have been scheduled for rebalancing due to outdated update 
> counter [grp=group, readyTopVer=AffinityTopologyVersion [topVer=33, 
> minorTopVer=0], topVer=AffinityTopologyVersion [topVer=33, minorTopVer=0], 
> nodeId=8e05997a-4ff7-4fdb-9480-cfbcefa8bbf5, 
> partsFull=[{color:red}*1-3*{color}, ...], partsHistorical=[]]
> {quote}
> {quote}
> 2021-08-11 23:12:11.338 [WARN 
> ]\[sys-#213\][org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture]
>  Partitions weren't present in any history reservation: [[[grp=grp2 
> part=[[{color:red}*1-3*{color}]]]
> {quote}
> We need to remove this optimization, because it can lead to mistakes in logs 
> analysis.



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

[jira] [Created] (IGNITE-17900) Very slow SQL execution with LEFT JOIN and subquery after upgrade from 2.7.6

2022-10-13 Thread Dren (Jira)

Dren created IGNITE-17900:
-

 Summary: Very slow SQL execution with LEFT JOIN and subquery after 
upgrade from 2.7.6
 Key: IGNITE-17900
 URL: https://issues.apache.org/jira/browse/IGNITE-17900
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.14, 2.13
 Environment: One node test instalation, 6 vCPU 8GB RAM.

Ignite 2.14.0

jdk-13.0.2

 

 
Reporter: Dren
 Attachments: CREATE_TABLE1.sql, explain_plan.txt, ignite_log.txt, 
insert_data.sql

After migration form Ignite 2.7.6 to Ignite 2.13 I noticed that the query below 
executes very slowly. A big difference in execution time can be seen already in 
tables with several thousands of records. If table have more than 100,000 
records, the query will never finish.

select T0.* , T1.HIDE
from TABLE1 as T0
left JOIN
( select key1, key2, count(*) AS HIDE  
    from TABLE1
    GROUP BY key1, key2
) as T1
ON T0.key1 = T1.key1 AND T0.key2 = T1.key2;

 

-- Ignite v2.13.0 and v2.14.0 
-- execution time  8 seconds with 2100 records
-- execution time 22 seconds with 4400 records

 

-- Ignite v 2.7.6 
-- execution time  3ms with 2100 records
-- execution time  4ms seconds with 4400 records

 

All DDL and test data can be found in attachment.

I tried adding indexes to the key1 and key2 columns, but the result is always 
the same.



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

[jira] [Commented] (IGNITE-17898) [TC Bot] Many duplicates of the same test on the board page



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

Sergey Uttsel commented on IGNITE-17898:


The amount of duplicates was reduced by checking the issue in the defect and 
adding in the defect only issues which it doesn't contain.

> [TC Bot] Many duplicates of the same test on the board page
> ---
>
> Key: IGNITE-17898
> URL: https://issues.apache.org/jira/browse/IGNITE-17898
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Uttsel
>Assignee: Sergey Uttsel
>Priority: Major
>
> Many duplicates of the same test on the board page. Еspecially for 
> newAlwaysFailure tests.



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

[jira] [Updated] (IGNITE-17875) TX counters with gaps must be logged on every PME

2022-10-13 Thread Anton Vinogradov (Jira)



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

Anton Vinogradov updated IGNITE-17875:
--
Description: 
TX counters on PME (when all operations are finished) must contain no gaps.
Such partitions should be listed (with counters) with a special warning.

Currently, we already have a "Failed to update the counter ..." warning which 
is logged when the primary tries to set the backup's update counter to its LWM 
which is less than the backup's HWM.

But, the better case is to list all broken partitions during the full message 
calculation during the PME at the coordinator.
All counters must be listed for every partition which has at least one counter 
with gaps.

  was:
TX counters on PME (when all operations are finished) must contain no gaps.
Such partitions should be listed (with counters) with a special warning.
This warning will help to determine that consistency recovery is required.

Currently, we already have a warning "Failed to update the counter ..." which 
is logged when the primary tries to set backup's update counter to its LWM 
which is less than backups's HWM.
But there will be no warning when primary and backups have the same LWM and 
some gaps.


> TX counters with gaps must be logged on every PME
> -
>
> Key: IGNITE-17875
> URL: https://issues.apache.org/jira/browse/IGNITE-17875
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Priority: Major
>  Labels: ise
>
> TX counters on PME (when all operations are finished) must contain no gaps.
> Such partitions should be listed (with counters) with a special warning.
> Currently, we already have a "Failed to update the counter ..." warning which 
> is logged when the primary tries to set the backup's update counter to its 
> LWM which is less than the backup's HWM.
> But, the better case is to list all broken partitions during the full message 
> calculation during the PME at the coordinator.
> All counters must be listed for every partition which has at least one 
> counter with gaps.



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

[jira] [Updated] (IGNITE-17897) [TC Bot] Slack notification doesn't work



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

Sergey Uttsel updated IGNITE-17897:
---
Description: 
TC bot doesn't send slack notification. There is "Failed to send test Slack 
message" in the log.

The root cause is changes in Slack api. So Slack api version which the TC Bot 
uses was increased.

  was:TC bot doesn't send slack notification. There is "Failed to send test 
Slack message" in the log.


> [TC Bot] Slack notification doesn't work
> 
>
> Key: IGNITE-17897
> URL: https://issues.apache.org/jira/browse/IGNITE-17897
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Uttsel
>Assignee: Sergey Uttsel
>Priority: Major
>
> TC bot doesn't send slack notification. There is "Failed to send test Slack 
> message" in the log.
> The root cause is changes in Slack api. So Slack api version which the TC Bot 
> uses was increased.



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

[jira] [Assigned] (IGNITE-17886) Convert Table RAFT commands to NetworkMessage-s



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

Sergey Chugunov reassigned IGNITE-17886:


Assignee: Sergey Chugunov

> Convert Table RAFT commands to NetworkMessage-s
> ---
>
> Key: IGNITE-17886
> URL: https://issues.apache.org/jira/browse/IGNITE-17886
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Sergey Chugunov
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta1
>
>
> Please refer to IGNITE-17871 for description



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

[jira] [Assigned] (IGNITE-17888) Convert Metastorage RAFT commands to NetworkMessage-s



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

Sergey Chugunov reassigned IGNITE-17888:


Assignee: (was: Sergey Chugunov)

> Convert Metastorage RAFT commands to NetworkMessage-s
> -
>
> Key: IGNITE-17888
> URL: https://issues.apache.org/jira/browse/IGNITE-17888
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Bessonov
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta1
>
>
> Please refer to IGNITE-17871 for description



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

[jira] [Assigned] (IGNITE-17887) Convert CMG RAFT commands to NetworkMessage-s

2022-10-13 Thread Ivan Bessonov (Jira)



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

Ivan Bessonov reassigned IGNITE-17887:
--

Assignee: Ivan Bessonov

> Convert CMG RAFT commands to NetworkMessage-s
> -
>
> Key: IGNITE-17887
> URL: https://issues.apache.org/jira/browse/IGNITE-17887
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Ivan Bessonov
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta1
>
>
> Please refer to IGNITE-17871 for description



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

[jira] [Updated] (IGNITE-17880) Topology version must be extended with topology epoch

2022-10-13 Thread Anton Vinogradov (Jira)



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

Anton Vinogradov updated IGNITE-17880:
--
Description: 
Epoch must be presented as a timestamp and version pair.

Epoch timestamp must represent epoch start time.
Epoch version must be incremented each time when topology version changed from 
0 to 1 (when the cluster started or restarted).
Each epoch version decrease or invariance on join must be logged as a warning.

Epoch (version and timestamp) must be logged at every topology version change.

This will 
- help to determine how many times the cluster was restarted (and make it 
easier to determine when)
- checks that the part of the cluster which was restarted several times as a 
standalone cluster will never join the rest of the cluster with the lower epoch 
(check some segmentation and management problems)

  was:
Epoch must be incremented each time when topology version changed from 0 to 1 
(when the cluster started or restarted).
Each epoch decrease or invariance on join must be logged as a warning.
Epoch must be logged at every topology version change.

This will 
- help to determine how many times the cluster was restarted (and make it 
easier to determine when)
- checks that the part of the cluster which was restarted several times as a 
standalone cluster will never join the rest of the cluster with the lower epoch 
(check some segmentation and management problems)


> Topology version must be extended with topology epoch
> -
>
> Key: IGNITE-17880
> URL: https://issues.apache.org/jira/browse/IGNITE-17880
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Anton Vinogradov
>Priority: Major
>
> Epoch must be presented as a timestamp and version pair.
> Epoch timestamp must represent epoch start time.
> Epoch version must be incremented each time when topology version changed 
> from 0 to 1 (when the cluster started or restarted).
> Each epoch version decrease or invariance on join must be logged as a warning.
> Epoch (version and timestamp) must be logged at every topology version change.
> This will 
> - help to determine how many times the cluster was restarted (and make it 
> easier to determine when)
> - checks that the part of the cluster which was restarted several times as a 
> standalone cluster will never join the rest of the cluster with the lower 
> epoch (check some segmentation and management problems)



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

[jira] [Created] (IGNITE-17899) Properly stop resources in TableManager

2022-10-13 Thread Mirza Aliev (Jira)

Mirza Aliev created IGNITE-17899:


 Summary: Properly stop resources in TableManager
 Key: IGNITE-17899
 URL: https://issues.apache.org/jira/browse/IGNITE-17899
 Project: Ignite
  Issue Type: Task
Reporter: Mirza Aliev


It's required to add sort of stopAll logic that will try to stop all resources 
even if some of them throws an exception on stop in 
{{org.apache.ignite.internal.table.distributed.TableManager#cleanUpTablesResources}}.
  Currently, if some components throws exception during `TableManager` stop, 
other components won't be stopped.

I'd rather use something similar to 
{{org.apache.ignite.internal.util.IgniteUtils#closeAll(java.util.Collection)}}.

Also `MvTableStorage` must be `AutoClosable`



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

[jira] [Assigned] (IGNITE-17813) Sql. Introduce sorted reducer for IndexScanNode

2022-10-13 Thread Pavel Pereslegin (Jira)



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

Pavel Pereslegin reassigned IGNITE-17813:
-

Assignee: Pavel Pereslegin

> Sql. Introduce sorted reducer for IndexScanNode
> ---
>
> Key: IGNITE-17813
> URL: https://issues.apache.org/jira/browse/IGNITE-17813
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql
>Reporter: Konstantin Orlov
>Assignee: Pavel Pereslegin
>Priority: Major
>  Labels: ignite-3
>
> This task is derived from IGNITE-17655 to reduce its scope.
> Currently, IgniteScanNode reads partition after partition which, obviously, 
> breaks the sorting order. We need to introduce wrapping cursor, which accepts 
> open cursors for every partition, and produce the sorted output.



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

[jira] [Updated] (IGNITE-17897) [TC Bot] Slack notification doesn't work



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

Sergey Uttsel updated IGNITE-17897:
---
Ignite Flags:   (was: Docs Required,Release Notes Required)

> [TC Bot] Slack notification doesn't work
> 
>
> Key: IGNITE-17897
> URL: https://issues.apache.org/jira/browse/IGNITE-17897
> Project: Ignite
>  Issue Type: Bug
>Reporter: Sergey Uttsel
>Assignee: Sergey Uttsel
>Priority: Major
>
> TC bot doesn't send slack notification. There is "Failed to send test Slack 
> message" in the log.



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

[jira] [Assigned] (IGNITE-17888) Convert Metastorage RAFT commands to NetworkMessage-s



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

Sergey Chugunov reassigned IGNITE-17888:


Assignee: Sergey Chugunov

> Convert Metastorage RAFT commands to NetworkMessage-s
> -
>
> Key: IGNITE-17888
> URL: https://issues.apache.org/jira/browse/IGNITE-17888
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Bessonov
>Assignee: Sergey Chugunov
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta1
>
>
> Please refer to IGNITE-17871 for description



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

[jira] [Created] (IGNITE-17898) [TC Bot] Many duplicates of the same test on the board page

Sergey Uttsel created IGNITE-17898:
--

 Summary: [TC Bot] Many duplicates of the same test on the board 
page
 Key: IGNITE-17898
 URL: https://issues.apache.org/jira/browse/IGNITE-17898
 Project: Ignite
  Issue Type: Bug
Reporter: Sergey Uttsel
Assignee: Sergey Uttsel


Many duplicates of the same test on the board page. Еspecially for 
newAlwaysFailure tests.



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

[jira] [Created] (IGNITE-17897) [TC Bot] Slack notification doesn't work

Sergey Uttsel created IGNITE-17897:
--

 Summary: [TC Bot] Slack notification doesn't work
 Key: IGNITE-17897
 URL: https://issues.apache.org/jira/browse/IGNITE-17897
 Project: Ignite
  Issue Type: Bug
Reporter: Sergey Uttsel
Assignee: Sergey Uttsel


TC bot doesn't send slack notification. There is "Failed to send test Slack 
message" in the log.



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

[jira] [Updated] (IGNITE-17839) Improve semantics of implicit txn management for async transactions

2022-10-13 Thread Vyacheslav Koptilin (Jira)



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

Vyacheslav Koptilin updated IGNITE-17839:
-
Fix Version/s: 3.0.0-beta1
   (was: 3.0)

> Improve semantics of implicit txn management for async transactions
> ---
>
> Key: IGNITE-17839
> URL: https://issues.apache.org/jira/browse/IGNITE-17839
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexey Scherbakov
>Assignee: Alexey Scherbakov
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta1
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> There is a usability issue for transaction implicit management API.
> For async transaction tx.commit must be called after all async ops are 
> enlisted to the transaction. This is a responsibility of a user in case of 
> explicit management.
> But, for implicit management, tx.commit must be called automatically. This is 
> not generally not possible for async flows, because by the end of a closure 
> some operations are not yet started.
> The example:
> runInTransactionAsync(tx -> {
> return opAsync().thenComposeAsync(res -> otherOpAsync());
> })
> We can fix this by introducing async context for implicit management and 
> require a user to return last completion stage in the chain, like:
>  CompletableFuture runInTransactionAsync(Function CompletableFuture> clo);



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

[jira] [Updated] (IGNITE-14487) Table view bulk methods refactoring

2022-10-13 Thread Andrey N. Gura (Jira)



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

Andrey N. Gura updated IGNITE-14487:

Fix Version/s: 3.0.0-beta1
   (was: 3.0.0-alpha6)

> Table view bulk methods refactoring
> ---
>
> Key: IGNITE-14487
> URL: https://issues.apache.org/jira/browse/IGNITE-14487
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Andrey Mashenkov
>Assignee: Andrey Mashenkov
>Priority: Major
>  Labels: iep-54, ignite-3
> Fix For: 3.0.0-beta1
>
>   Original Estimate: 120h
>  Time Spent: 20m
>  Remaining Estimate: 119h 40m
>
> org.apache.ignite.internal.table.RecordBinaryViewImpl#wrap use streams that 
> have performance impact. Let's rewrite it.



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

[jira] [Updated] (IGNITE-17896) Create storage related error group



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

Alexander Lapin updated IGNITE-17896:
-
Reviewer: Alexander Lapin

> Create storage related error group
> --
>
> Key: IGNITE-17896
> URL: https://issues.apache.org/jira/browse/IGNITE-17896
> Project: Ignite
>  Issue Type: Task
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> According to the new exception structure model, any component has to have his 
> own error group. In this ticket we need to provide new error group for 
> storage related errors   



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

[jira] [Updated] (IGNITE-17896) Create storage related error group



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

Alexander Lapin updated IGNITE-17896:
-
Fix Version/s: 3.0.0-alpha6

> Create storage related error group
> --
>
> Key: IGNITE-17896
> URL: https://issues.apache.org/jira/browse/IGNITE-17896
> Project: Ignite
>  Issue Type: Task
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> According to the new exception structure model, any component has to have his 
> own error group. In this ticket we need to provide new error group for 
> storage related errors   



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

[jira] [Assigned] (IGNITE-17896) Create storage related error group



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

Alexander Lapin reassigned IGNITE-17896:


Assignee: Mirza Aliev  (was: Alexander Lapin)

> Create storage related error group
> --
>
> Key: IGNITE-17896
> URL: https://issues.apache.org/jira/browse/IGNITE-17896
> Project: Ignite
>  Issue Type: Task
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
>  Labels: ignite-3
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> According to the new exception structure model, any component has to have his 
> own error group. In this ticket we need to provide new error group for 
> storage related errors   



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

[jira] [Assigned] (IGNITE-17896) Create storage related error group



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

Alexander Lapin reassigned IGNITE-17896:


Assignee: Alexander Lapin  (was: Mirza Aliev)

> Create storage related error group
> --
>
> Key: IGNITE-17896
> URL: https://issues.apache.org/jira/browse/IGNITE-17896
> Project: Ignite
>  Issue Type: Task
>Reporter: Mirza Aliev
>Assignee: Alexander Lapin
>Priority: Major
>  Labels: ignite-3
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> According to the new exception structure model, any component has to have his 
> own error group. In this ticket we need to provide new error group for 
> storage related errors   



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

[jira] [Commented] (IGNITE-17896) Create storage related error group



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

Alexander Lapin commented on IGNITE-17896:
--

[~maliev] LGTM

> Create storage related error group
> --
>
> Key: IGNITE-17896
> URL: https://issues.apache.org/jira/browse/IGNITE-17896
> Project: Ignite
>  Issue Type: Task
>Reporter: Mirza Aliev
>Assignee: Mirza Aliev
>Priority: Major
>  Labels: ignite-3
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> According to the new exception structure model, any component has to have his 
> own error group. In this ticket we need to provide new error group for 
> storage related errors   



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

[jira] [Resolved] (IGNITE-17850) Release Apache Ignite 2.14

2022-10-13 Thread Taras Ledkov (Jira)



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

Taras Ledkov resolved IGNITE-17850.
---
Resolution: Fixed

> Release Apache Ignite 2.14
> --
>
> Key: IGNITE-17850
> URL: https://issues.apache.org/jira/browse/IGNITE-17850
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation
>Reporter: Taras Ledkov
>Assignee: Taras Ledkov
>Priority: Major
>
> Update documentation on ignite-website for 2.14.0 release



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

[jira] [Commented] (IGNITE-17857) The native client does not need to verify the configuration consistency of the DeploymentSpi



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

Sergey Chugunov commented on IGNITE-17857:
--

[~liyuj]

I did a review and left one comment, could you please take a look?

Thank you!

> The native client does not need to verify the configuration consistency of 
> the DeploymentSpi
> 
>
> Key: IGNITE-17857
> URL: https://issues.apache.org/jira/browse/IGNITE-17857
> Project: Ignite
>  Issue Type: Improvement
>  Components: clients
>Affects Versions: 2.13
>Reporter: YuJue Li
>Assignee: YuJue Li
>Priority: Minor
> Fix For: 2.15
>
> Attachments: IgniteClient.java, e.log, example-deploy.xml
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> start a server node with example-deploy.xml by ignite.sh
> start a native client with IgniteClient.java
> then error.
> Normally, the client node does not need to verify the configuration 
> consistency of the DeploymentSpi.
> Whether the client needs to configure DeploymentSpi should be decided by the 
> user.



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

[jira] [Updated] (IGNITE-17895) Assertion on histogram update if currentTimeMillis decreases



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

Aleksey Plekhanov updated IGNITE-17895:
---
Labels: ise  (was: )

> Assertion on histogram update if currentTimeMillis decreases
> 
>
> Key: IGNITE-17895
> URL: https://issues.apache.org/jira/browse/IGNITE-17895
> Project: Ignite
>  Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
>  Labels: ise
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Histogram metric classes (\{{HistogramMetricImpl}}, 
> \{{PeriodicHistogramMetricImpl}}) assume that timestamp is always increasing, 
> but in some cases method {{U.currentTimeMillis()}} can return decreasing 
> values (for example, if time was set manually or on NTP sync). In these cases 
> assertion can be thrown on histogram update:
> {noformat}
> java.lang.AssertionError: null
> at 
> org.apache.ignite.internal.processors.metric.impl.HistogramMetricImpl.value(HistogramMetricImpl.java:61)
>  ~[classes/:?]
> at 
> org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:643)
>  [classes/:?]
> at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125) 
> [classes/:?]
> at java.lang.Thread.run(Thread.java:750) [?:1.8.0_322]{noformat}
> We should fix {{PeriodicHistogramMetricImpl#add}} and 
> {{HistogramMetricImpl#value}} methods to work correctly with decreasing 
> timestamps.



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

[jira] [Created] (IGNITE-17896) Create storage related error group

2022-10-13 Thread Mirza Aliev (Jira)

Mirza Aliev created IGNITE-17896:


 Summary: Create storage related error group
 Key: IGNITE-17896
 URL: https://issues.apache.org/jira/browse/IGNITE-17896
 Project: Ignite
  Issue Type: Task
Reporter: Mirza Aliev
Assignee: Mirza Aliev


According to the new exception structure model, any component has to have his 
own error group. In this ticket we need to provide new error group for storage 
related errors   



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

[jira] [Created] (IGNITE-17895) Assertion on histogram update if currentTimeMillis decreases

Aleksey Plekhanov created IGNITE-17895:
--

 Summary: Assertion on histogram update if currentTimeMillis 
decreases
 Key: IGNITE-17895
 URL: https://issues.apache.org/jira/browse/IGNITE-17895
 Project: Ignite
  Issue Type: Bug
Reporter: Aleksey Plekhanov
Assignee: Aleksey Plekhanov


Histogram metric classes (\{{HistogramMetricImpl}}, 
\{{PeriodicHistogramMetricImpl}}) assume that timestamp is always increasing, 
but in some cases method {{U.currentTimeMillis()}} can return decreasing values 
(for example, if time was set manually or on NTP sync). In these cases 
assertion can be thrown on histogram update:
{noformat}
java.lang.AssertionError: null
at 
org.apache.ignite.internal.processors.metric.impl.HistogramMetricImpl.value(HistogramMetricImpl.java:61)
 ~[classes/:?]
at 
org.apache.ignite.internal.util.StripedExecutor$Stripe.body(StripedExecutor.java:643)
 [classes/:?]
at org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125) 
[classes/:?]
at java.lang.Thread.run(Thread.java:750) [?:1.8.0_322]{noformat}
We should fix {{PeriodicHistogramMetricImpl#add}} and 
{{HistogramMetricImpl#value}} methods to work correctly with decreasing 
timestamps.



--
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)



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

Roman Puchkovskiy updated IGNITE-17864:
---
Epic Link: IGNITE-16923

> 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
>
> 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] [Comment Edited] (IGNITE-17760) Integrate C++ infrastructure and code for Binary Tuple and Thin Client in AI-3.0

2022-10-13 Thread Igor Sapego (Jira)



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

Igor Sapego edited comment on IGNITE-17760 at 10/13/22 9:38 AM:


Looks good to me. Merged to main.


was (Author: isapego):
Looks good to me. Merged to master.

> Integrate C++ infrastructure and code for Binary Tuple and Thin Client in 
> AI-3.0
> 
>
> Key: IGNITE-17760
> URL: https://issues.apache.org/jira/browse/IGNITE-17760
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms
>Reporter: Aleksey Demakov
>Assignee: Aleksey Demakov
>Priority: Major
>  Labels: iep-92, ignite-3
> Fix For: 3.0.0-alpha6
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> * Use gtest instead of boost test
>  * Unify duplicated functionality implemented for Binary Tuple and Thin 
> Client tasks
>  * Unify and fix where needed general source tree layout
>  * Come up with common conventions for all C++ code in ignite-3
>  * Update code taken from ignite-2 for new rules and requirements wherever it 
> is not too much of a burden
>  * etc



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

[jira] [Comment Edited] (IGNITE-17865) Disable partition ranges in log messages about rebalance or PME

2022-10-13 Thread Ilya Shishkov (Jira)



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

Ilya Shishkov edited comment on IGNITE-17865 at 10/13/22 8:15 AM:
--

[~slava.koptilin], hi!

I agree, that blowing up of logs is not a good idea, but are there any 
practical results, when such optimization can significantly reduce size of 
message and logs?
As I see, most of time lists of partitions in these messages does not form a 
continuous sequence, and even if so, only 2, and less often 3 and more 
partitions form continuous sequence. And for two partitions real economy is a 
whitespace symbol.


was (Author: shishkovilja):
[~slava.koptilin], hi!

I agree, that blowing up of logs is not a god idea, but are there any practical 
results, when such optimization can significantly reduce size of message and 
logs?
As I see, most of time lists of partitions in these messages does not form a 
continuous sequence, and even if so, only 2, and less often 3 and more 
partitions form continuous sequence. And for two partitions real economy is a 
whitespace symbol.

> Disable partition ranges in log messages about rebalance or PME
> ---
>
> Key: IGNITE-17865
> URL: https://issues.apache.org/jira/browse/IGNITE-17865
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Ilya Shishkov
>Priority: Minor
>  Labels: ise, newbie
>
> When you need to analyze cases of partitions inconsistency, full list of 
> partitions is needed, but there is an optimization which replaces list of 
> consecutive partitions with ranges. So, as you can see below, we can not find 
> partition 2 by simple text search:
> {quote}
> 2021-08-11 23:12:11.338 [WARN 
> ]\[sys-#213\][org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl]
>  Partitions have been scheduled for rebalancing due to outdated update 
> counter [grp=group, readyTopVer=AffinityTopologyVersion [topVer=33, 
> minorTopVer=0], topVer=AffinityTopologyVersion [topVer=33, minorTopVer=0], 
> nodeId=8e05997a-4ff7-4fdb-9480-cfbcefa8bbf5, 
> partsFull=[{color:red}*1-3*{color}, ...], partsHistorical=[]]
> {quote}
> {quote}
> 2021-08-11 23:12:11.338 [WARN 
> ]\[sys-#213\][org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture]
>  Partitions weren't present in any history reservation: [[[grp=grp2 
> part=[[{color:red}*1-3*{color}]]]
> {quote}
> We need to remove this optimization, because it can lead to mistakes in logs 
> analysis.



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

[jira] [Comment Edited] (IGNITE-17865) Disable partition ranges in log messages about rebalance or PME

2022-10-13 Thread Ilya Shishkov (Jira)



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

Ilya Shishkov edited comment on IGNITE-17865 at 10/13/22 8:15 AM:
--

[~slava.koptilin], hi!

I agree, that blowing up of logs is not a god idea, but are there any practical 
results, when such optimization can significantly reduce size of message and 
logs?
As I see, most of time lists of partitions in these messages does not form a 
continuous sequence, and even if so, only 2, and less often 3 and more 
partitions form continuous sequence. And for two partitions real economy is a 
whitespace symbol.


was (Author: shishkovilja):
[~slava.koptilin], hi!

I understand, that blowing up of logs is not a god idea, but are there any 
practical results, when such optimization can significantly reduce size of 
message and logs?
As I see, most of time lists of partitions in these messages does not form a 
continuous sequence, and even if so, only 2, and less often 3 and more 
partitions are forms continuous sequence. And for two partitions real economy 
is a whitespace symbol.

> Disable partition ranges in log messages about rebalance or PME
> ---
>
> Key: IGNITE-17865
> URL: https://issues.apache.org/jira/browse/IGNITE-17865
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Ilya Shishkov
>Priority: Minor
>  Labels: ise, newbie
>
> When you need to analyze cases of partitions inconsistency, full list of 
> partitions is needed, but there is an optimization which replaces list of 
> consecutive partitions with ranges. So, as you can see below, we can not find 
> partition 2 by simple text search:
> {quote}
> 2021-08-11 23:12:11.338 [WARN 
> ]\[sys-#213\][org.apache.ignite.internal.processors.cache.distributed.dht.topology.GridDhtPartitionTopologyImpl]
>  Partitions have been scheduled for rebalancing due to outdated update 
> counter [grp=group, readyTopVer=AffinityTopologyVersion [topVer=33, 
> minorTopVer=0], topVer=AffinityTopologyVersion [topVer=33, minorTopVer=0], 
> nodeId=8e05997a-4ff7-4fdb-9480-cfbcefa8bbf5, 
> partsFull=[{color:red}*1-3*{color}, ...], partsHistorical=[]]
> {quote}
> {quote}
> 2021-08-11 23:12:11.338 [WARN 
> ]\[sys-#213\][org.apache.ignite.internal.processors.cache.distributed.dht.preloader.GridDhtPartitionsExchangeFuture]
>  Partitions weren't present in any history reservation: [[[grp=grp2 
> part=[[{color:red}*1-3*{color}]]]
> {quote}
> We need to remove this optimization, because it can lead to mistakes in logs 
> analysis.



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

[jira] [Assigned] (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 reassigned IGNITE-17671:


Assignee: Kirill Tkalenko

> 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-alpha6
>
>
> 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] [Assigned] (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 reassigned IGNITE-17894:


Assignee: Kirill Tkalenko

> 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-alpha6
>
>
> See IGNITE-17262



--
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
 ]

Kirill Tkalenko updated IGNITE-17893:
-
Epic Link: IGNITE-17774

> 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-alpha6
>
>
> See IGNITE-17262



--
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:
-
Epic Link: IGNITE-17774

> 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
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-alpha6
>
>
> See IGNITE-17262



--
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:
---
Ignite Flags:   (was: Docs Required,Release Notes Required)

> 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-alpha6
>
>
> See IGNITE-17262



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

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

Roman Puchkovskiy created IGNITE-17894:
--

 Summary: 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
 Fix For: 3.0.0-alpha6


See IGNITE-17262



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

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

Roman Puchkovskiy created IGNITE-17893:
--

 Summary: 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
 Fix For: 3.0.0-alpha6


See IGNITE-17262



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

[jira] [Created] (IGNITE-17892) Ignite doc: cdcEnabled parameter is in the DataRegionConfiguration

2022-10-13 Thread YuJue Li (Jira)

YuJue Li created IGNITE-17892:
-

 Summary: Ignite doc: cdcEnabled parameter is in the 
DataRegionConfiguration
 Key: IGNITE-17892
 URL: https://issues.apache.org/jira/browse/IGNITE-17892
 Project: Ignite
  Issue Type: Bug
  Components: documentation
Affects Versions: 2.14
Reporter: YuJue Li
 Fix For: 2.15


[https://ignite.apache.org/docs/latest/persistence/change-data-capture|https://ignite.apache.org/docs/latest/persistence/change-data-capture#ignite-node]

DataStorageConfiguration#cdcEnabled

should be:
DataRegionConfiguration#cdcEnabled



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

[jira] [Assigned] (IGNITE-17892) Ignite doc: cdcEnabled parameter is in the DataRegionConfiguration

2022-10-13 Thread YuJue Li (Jira)



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

YuJue Li reassigned IGNITE-17892:
-

Assignee: YuJue Li

> Ignite doc: cdcEnabled parameter is in the DataRegionConfiguration
> --
>
> Key: IGNITE-17892
> URL: https://issues.apache.org/jira/browse/IGNITE-17892
> Project: Ignite
>  Issue Type: Bug
>  Components: documentation
>Affects Versions: 2.14
>Reporter: YuJue Li
>Assignee: YuJue Li
>Priority: Minor
> Fix For: 2.15
>
>
> [https://ignite.apache.org/docs/latest/persistence/change-data-capture|https://ignite.apache.org/docs/latest/persistence/change-data-capture#ignite-node]
> DataStorageConfiguration#cdcEnabled
> should be:
> DataRegionConfiguration#cdcEnabled



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

[jira] [Commented] (IGNITE-17876) .NET: Thin 3.0: Single column mapping



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

Pavel Tupitsyn commented on IGNITE-17876:
-

Merged to main: 11387af5258c69843ef083f2cedadd18b3cfa7c0

> .NET: Thin 3.0: Single column mapping
> -
>
> Key: IGNITE-17876
> URL: https://issues.apache.org/jira/browse/IGNITE-17876
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, ignite-3
> Fix For: 3.0.0-alpha6
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Allow single-column mapping:
> {code}
> var view = Table.GetRecordView();
> await view.UpsertAsync(null, 123);
> {code}



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

[jira] [Commented] (IGNITE-17876) .NET: Thin 3.0: Single column mapping

2022-10-13 Thread Igor Sapego (Jira)



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

Igor Sapego commented on IGNITE-17876:
--

[~ptupitsyn] looks good to me

> .NET: Thin 3.0: Single column mapping
> -
>
> Key: IGNITE-17876
> URL: https://issues.apache.org/jira/browse/IGNITE-17876
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, ignite-3
> Fix For: 3.0.0-alpha6
>
>
> Allow single-column mapping:
> {code}
> var view = Table.GetRecordView();
> await view.UpsertAsync(null, 123);
> {code}



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

[jira] [Assigned] (IGNITE-17786) Add --verbose option to all commands

2022-10-13 Thread Vadim Pakhnushev (Jira)



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

Vadim Pakhnushev reassigned IGNITE-17786:
-

Assignee: Vadim Pakhnushev

> Add --verbose option to all commands
> 
>
> Key: IGNITE-17786
> URL: https://issues.apache.org/jira/browse/IGNITE-17786
> Project: Ignite
>  Issue Type: Improvement
>  Components: cli
>Reporter: Aleksandr
>Assignee: Vadim Pakhnushev
>Priority: Major
>  Labels: ignite-3
>
> Users of CLI should have the ability to go deeper if they face issues with 
> CLI.  
> The goal of this ticket is to add {{--verbose}} option to all commands and 
> print additional debug information to the terminal if this flag is set to 
> true.



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

[jira] [Commented] (IGNITE-13022) Calcite integration. Merge index conditions for the same field.