date:20221018



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

Ignite TC Bot commented on IGNITE-17351:


{panel:title=Branch: [pull/10331/head] Base: [master] : Possible Blockers 
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}
{color:#d04437}Platform .NET (Core Linux){color} [[tests 0 TIMEOUT , Exit Code 
, TC_SERVICE_MESSAGE 
|https://ci.ignite.apache.org/viewLog.html?buildId=6846819]]

{color:#d04437}PDS 3{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=6846807]]
* IgnitePdsTestSuite3: 
IgnitePdsContinuousRestartTestWithExpiryPolicy.testRebalancingDuringLoad_8000_500_8_16
 - Test has low fail rate in base branch 0,0% and is not flaky

{color:#d04437}Queries 1{color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=6846821]]
* IgniteBinaryCacheQueryTestSuite: 
DynamicIndexServerCoordinatorBasicSelfTest.testCreateReplicatedAtomic - Test 
has low fail rate in base branch 0,0% and is not flaky

{panel}
{panel:title=Branch: [pull/10331/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=6846852buildTypeId=IgniteTests24Java8_RunAll]

> Java thin: Implement logging
> 
>
> Key: IGNITE-17351
> URL: https://issues.apache.org/jira/browse/IGNITE-17351
> Project: Ignite
>  Issue Type: New Feature
>  Components: thin client
>Reporter: Igor Sapego
>Assignee: Pavel Tupitsyn
>Priority: Major
>
> We need to provide support for logging for Java thin client.
> Make sure that it is easy to turn on full logging without re-compiling for 
> debugging purposes.



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

[jira] [Updated] (IGNITE-17383) IdleVerify hangs when called on inactive cluster with persistence



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

Julia Bakulina updated IGNITE-17383:

Release Note: Fixed IdleVerify process not responding for an inactive 
cluster with persistent data regions.

> IdleVerify hangs when called on inactive cluster with persistence
> -
>
> Key: IGNITE-17383
> URL: https://issues.apache.org/jira/browse/IGNITE-17383
> Project: Ignite
>  Issue Type: Bug
>  Components: control.sh
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Minor
>  Labels: ise
> Fix For: 2.15
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> When you call {{control.sh --cache idle_verify}} on inactive cluster with 
> persistence, control script hangs and no actions are performed. As you can 
> see below in 'rest' thread dump, {{VerifyBackupPartitionsTaskV2}} waits for 
> checkpoint start in {{GridCacheDatabaseSharedManager#waitForCheckpoint}}.
> It seems, that we can interrupt task execution and print message in control 
> script output, that IdleVerify can't work on inactive cluster.
> {code:title=Thread dump}
> "rest-#82%ignite-server%" #146 prio=5 os_prio=31 tid=0x7fe0cf97c000 
> nid=0x3607 waiting on condition [0x700010149000]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.waitForCheckpoint(GridCacheDatabaseSharedManager.java:1869)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.waitForCheckpoint(IgniteCacheDatabaseSharedManager.java:1107)
>   at 
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:199)
>   at 
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:171)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1444)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:674)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:540)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:860)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:470)
>   at 
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync0(IgniteComputeImpl.java:514)
>   at 
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync(IgniteComputeImpl.java:496)
>   at 
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:70)
>   at 
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:35)
>   at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
>   at 
>

[jira] [Updated] (IGNITE-17383) IdleVerify hangs when called on inactive cluster with persistence



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

Julia Bakulina updated IGNITE-17383:

Fix Version/s: 2.15

> IdleVerify hangs when called on inactive cluster with persistence
> -
>
> Key: IGNITE-17383
> URL: https://issues.apache.org/jira/browse/IGNITE-17383
> Project: Ignite
>  Issue Type: Bug
>  Components: control.sh
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Minor
>  Labels: ise
> Fix For: 2.15
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> When you call {{control.sh --cache idle_verify}} on inactive cluster with 
> persistence, control script hangs and no actions are performed. As you can 
> see below in 'rest' thread dump, {{VerifyBackupPartitionsTaskV2}} waits for 
> checkpoint start in {{GridCacheDatabaseSharedManager#waitForCheckpoint}}.
> It seems, that we can interrupt task execution and print message in control 
> script output, that IdleVerify can't work on inactive cluster.
> {code:title=Thread dump}
> "rest-#82%ignite-server%" #146 prio=5 os_prio=31 tid=0x7fe0cf97c000 
> nid=0x3607 waiting on condition [0x700010149000]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.waitForCheckpoint(GridCacheDatabaseSharedManager.java:1869)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.waitForCheckpoint(IgniteCacheDatabaseSharedManager.java:1107)
>   at 
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:199)
>   at 
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:171)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1444)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:674)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:540)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:860)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:470)
>   at 
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync0(IgniteComputeImpl.java:514)
>   at 
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync(IgniteComputeImpl.java:496)
>   at 
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:70)
>   at 
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:35)
>   at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1444)
>   at 
>

[jira] [Commented] (IGNITE-17383) IdleVerify hangs when called on inactive cluster with persistence



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

Ignite TC Bot commented on IGNITE-17383:


{panel:title=Branch: [pull/10328/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10328/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=6841329buildTypeId=IgniteTests24Java8_RunAll]

> IdleVerify hangs when called on inactive cluster with persistence
> -
>
> Key: IGNITE-17383
> URL: https://issues.apache.org/jira/browse/IGNITE-17383
> Project: Ignite
>  Issue Type: Bug
>  Components: control.sh
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Julia Bakulina
>Priority: Minor
>  Labels: ise
>
> When you call {{control.sh --cache idle_verify}} on inactive cluster with 
> persistence, control script hangs and no actions are performed. As you can 
> see below in 'rest' thread dump, {{VerifyBackupPartitionsTaskV2}} waits for 
> checkpoint start in {{GridCacheDatabaseSharedManager#waitForCheckpoint}}.
> It seems, that we can interrupt task execution and print message in control 
> script output, that IdleVerify can't work on inactive cluster.
> {code:title=Thread dump}
> "rest-#82%ignite-server%" #146 prio=5 os_prio=31 tid=0x7fe0cf97c000 
> nid=0x3607 waiting on condition [0x700010149000]
>java.lang.Thread.State: WAITING (parking)
>   at sun.misc.Unsafe.park(Native Method)
>   at java.util.concurrent.locks.LockSupport.park(LockSupport.java:304)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get0(GridFutureAdapter.java:178)
>   at 
> org.apache.ignite.internal.util.future.GridFutureAdapter.get(GridFutureAdapter.java:141)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.GridCacheDatabaseSharedManager.waitForCheckpoint(GridCacheDatabaseSharedManager.java:1869)
>   at 
> org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager.waitForCheckpoint(IgniteCacheDatabaseSharedManager.java:1107)
>   at 
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:199)
>   at 
> org.apache.ignite.internal.processors.cache.verify.VerifyBackupPartitionsTaskV2$VerifyBackupPartitionsJobV2.execute(VerifyBackupPartitionsTaskV2.java:171)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
>   at 
> org.apache.ignite.internal.processors.job.GridJobProcessor.processJobExecuteRequest(GridJobProcessor.java:1343)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.sendRequest(GridTaskWorker.java:1444)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.processMappedJobs(GridTaskWorker.java:674)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskWorker.body(GridTaskWorker.java:540)
>   at 
> org.apache.ignite.internal.util.worker.GridWorker.run(GridWorker.java:125)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.startTask(GridTaskProcessor.java:860)
>   at 
> org.apache.ignite.internal.processors.task.GridTaskProcessor.execute(GridTaskProcessor.java:470)
>   at 
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync0(IgniteComputeImpl.java:514)
>   at 
> org.apache.ignite.internal.IgniteComputeImpl.executeAsync(IgniteComputeImpl.java:496)
>   at 
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:70)
>   at 
> org.apache.ignite.internal.visor.verify.VisorIdleVerifyJob.run(VisorIdleVerifyJob.java:35)
>   at org.apache.ignite.internal.visor.VisorJob.execute(VisorJob.java:69)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker$2.call(GridJobWorker.java:620)
>   at 
> org.apache.ignite.internal.util.IgniteUtils.wrapThreadLoader(IgniteUtils.java:7366)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.execute0(GridJobWorker.java:614)
>   at 
> org.apache.ignite.internal.processors.job.GridJobWorker.body(GridJobWorker.java:539)
>   at 
>

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

Julia Bakulina commented on IGNITE-8801:


As decided on DevList, the ticket is divided into two parts:
- IGNITE-17916 - deprecates IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property in 
version 2.15.0.
- IGNITE-8801 - deletes IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property in 
version 2.16.0.

That is why this ticket is still unresolved and waits for 2.16.0 version

> 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] (IGNITE-17351) Java thin: Implement logging

2022-10-18 Thread Pavel Tupitsyn (Jira)



[ https://issues.apache.org/jira/browse/IGNITE-17351 ]


Pavel Tupitsyn deleted comment on IGNITE-17351:
-

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{color:#d04437}JDBC Driver{color}

[jira] [Commented] (IGNITE-17351) Java thin: Implement logging



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

Ignite TC Bot commented on IGNITE-17351:


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

{color:#d04437}Cache 12{color} [[tests 0

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

Fix Version/s: 2.15

> 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
> Fix For: 2.15
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> 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:

   Flags: Important
Release Note: Deprecated IGNITE_ALLOW_ATOMIC_OPS_IN_TX system property.

> 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
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> 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] [Commented] (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:comment-tabpanel=17619740#comment-17619740
 ] 

Ignite TC Bot commented on IGNITE-17916:


{panel:title=Branch: [pull/10327/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10327/head] Base: [master] : New Tests 
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Queries 1{color} [[tests 
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6823554]]
* {color:#013220}IgniteBinaryCacheQueryTestSuite: 
SqlParserMultiStatementSelfTest.testEmptyTransaction - PASSED{color}

{color:#8b}Queries 1 (lazy=true){color} [[tests 
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6823555]]
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite: 
SqlParserMultiStatementSelfTest.testEmptyTransaction - PASSED{color}

{color:#8b}SPI (URI Deploy){color} [[tests 
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6823570]]
* {color:#013220}IgniteUriDeploymentTestSuite: 
GridUriDeploymentConfigSelfTest.testClientSpiConsistencyChecked - PASSED{color}

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

> 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
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> 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:

Ignite Flags: 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
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> 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:

Reviewer: Maksim Timonin

> 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
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> 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-17927) After updating Ignite-2.12.0 to ignite-2.14.0 ] throws [TcpDiscoverySpi] Failed to get registered addresses from IP finder

2022-10-18 Thread Amit (Jira)

Amit created IGNITE-17927:
-

 Summary: After updating Ignite-2.12.0 to ignite-2.14.0 ] throws 
[TcpDiscoverySpi] Failed to get registered addresses from IP finder 
 Key: IGNITE-17927
 URL: https://issues.apache.org/jira/browse/IGNITE-17927
 Project: Ignite
  Issue Type: Bug
  Components: cache
Affects Versions: 2.14
Reporter: Amit


To fix IGNITE-17481 issue “Ignite shutdown sequence throws a ClassCastException 
from inside GridManagerAdapter on latest Java 11.0.16 and 17.0.4 point releases”

We have updated ignite-2.12.0 to ignite-2.14.0 (no configuration change) and we 
are getting below error at ignite server

Stack trace

 

[06:06:13,083][SEVERE][main][TcpDiscoverySpi] Failed to get registered 
addresses from IP finder (retrying every 2000ms; change 'reconnectDelay' to 
configure the frequency of retries) [maxTimeout=0]

class org.apache.ignite.spi.IgniteSpiException: Failed to retrieve Ignite pods 
IP addresses.

    at 
org.apache.ignite.spi.discovery.tcp.ipfinder.kubernetes.TcpDiscoveryKubernetesIpFinder.getRegisteredAddresses(TcpDiscoveryKubernetesIpFinder.java:81)

    at 
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.registeredAddresses(TcpDiscoverySpi.java:2057)

    at 
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.resolvedAddresses(TcpDiscoverySpi.java:1992)

    at 
org.apache.ignite.spi.discovery.tcp.ServerImpl.sendJoinRequestMessage(ServerImpl.java:1283)

    at 
org.apache.ignite.spi.discovery.tcp.ServerImpl.joinTopology(ServerImpl.java:1120)

    at 
org.apache.ignite.spi.discovery.tcp.ServerImpl.spiStart(ServerImpl.java:472)

    at 
org.apache.ignite.spi.discovery.tcp.TcpDiscoverySpi.spiStart(TcpDiscoverySpi.java:2212)

    at 
org.apache.ignite.internal.managers.GridManagerAdapter.startSpi(GridManagerAdapter.java:278)

    at 
org.apache.ignite.internal.managers.discovery.GridDiscoveryManager.start(GridDiscoveryManager.java:1089)

    at 
org.apache.ignite.internal.IgniteKernal.startManager(IgniteKernal.java:1766)

    at org.apache.ignite.internal.IgniteKernal.start(IgniteKernal.java:1147)

    at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start0(IgnitionEx.java:1757)

    at 
org.apache.ignite.internal.IgnitionEx$IgniteNamedInstance.start(IgnitionEx.java:1679)

    at org.apache.ignite.internal.IgnitionEx.start0(IgnitionEx.java:1121)

    at 
org.apache.ignite.internal.IgnitionEx.startConfigurations(IgnitionEx.java:1015)

    at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:921)

    at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:840)

    at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:710)

    at org.apache.ignite.internal.IgnitionEx.start(IgnitionEx.java:679)

    at org.apache.ignite.Ignition.start(Ignition.java:353)

    at 
org.apache.ignite.startup.cmdline.CommandLineStartup.main(CommandLineStartup.java:365)

Caused by: class org.apache.ignite.IgniteException: Failed to retrieve Ignite 
pods IP addresses.

    at 
org.apache.ignite.internal.kubernetes.connection.KubernetesServiceAddressResolver.getServiceAddresses(KubernetesServiceAddressResolver.java:123)

    at 
org.apache.ignite.spi.discovery.tcp.ipfinder.kubernetes.TcpDiscoveryKubernetesIpFinder.getRegisteredAddresses(TcpDiscoveryKubernetesIpFinder.java:76)

    ... 20 more

Caused by: javax.net.ssl.SSLHandshakeException: Received fatal alert: 
handshake_failure

    at sun.security.ssl.Alert.createSSLException(Alert.java:131)

    at sun.security.ssl.Alert.createSSLException(Alert.java:117)

    at sun.security.ssl.TransportContext.fatal(TransportContext.java:311)

    at sun.security.ssl.Alert$AlertConsumer.consume(Alert.java:293)

    at sun.security.ssl.TransportContext.dispatch(TransportContext.java:185)

    at sun.security.ssl.SSLTransport.decode(SSLTransport.java:152)

    at sun.security.ssl.SSLSocketImpl.decode(SSLSocketImpl.java:1397)

    at 
sun.security.ssl.SSLSocketImpl.readHandshakeRecord(SSLSocketImpl.java:1305)

    at sun.security.ssl.SSLSocketImpl.startHandshake(SSLSocketImpl.java:440)

    at 
sun.net.www.protocol.https.HttpsClient.afterConnect(HttpsClient.java:559)

    at 
sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:197)

    at 
sun.net.www.protocol.http.HttpURLConnection.getInputStream0(HttpURLConnection.java:1572)

    at 
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1500)

    at 
sun.net.www.protocol.https.HttpsURLConnectionImpl.getInputStream(HttpsURLConnectionImpl.java:268)

    at 
org.apache.ignite.internal.kubernetes.connection.KubernetesServiceAddressResolver.getServiceAddresses(KubernetesServiceAddressResolver.java:111)

    ... 21 more

[jira] [Comment Edited] (IGNITE-17735) Datastreamer may consume heap with default settings.

2022-10-18 Thread Vladimir Steshin (Jira)



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

Vladimir Steshin edited comment on IGNITE-17735 at 10/18/22 4:33 PM:
-

Datastreamer with Individual receiver and ATOMIC/PRIMARY_SYNC persistent cache 
may consume heap. It has related 'perNodeParallelOperations()' setting. But it 
doesn't depend on StreamReceiver. User can experience heap issues with a 
trivial case.

The problem is that the streamer doesn't wait for backup updates on primary 
node and keep sending update batches again and again. Individual receiver uses 
cache.put(). Every put creates a future for primary update and future and 
update update request for the backups. Nodes start accumulating related  to 
single update objects in the heap (`processDhtAtomicUpdateRequest()`).

There is no reason to send more than 2-3-4 unresponded batches because they 
stuck at disk writes, WAL writes, page replacements, WAL rolling, GCs and so 
on. Why so many parallel batches by default? Especially for persistent caches. 
IgniteDataStreamer.DFLT_PARALLEL_OPS_MULTIPLIER=8 is weird to me. With 8 CPUs 
and 16 threads I get 128 parallel batches. 

Proposal: reduce default max parallel batches for a nod. Make this value depend 
on the persistence.

Some JFR screens attached.

See `JmhStreamerReceiverBenchmark.bchIndividual_512_1()`, 
`DataStreamProcessorSelfTest.testAtomicPrimarySyncStability()`.


was (Author: vladsz83):
Datastreamer with Individual receiver and ATOMIC/PRIMARY_SYNC persistent cache 
may consume heap. The test case is simple: 2 or 3 servers, 2 or 1 backups and 
Datastreamer from client loading significant amount of data. Around 1G of heap. 
Tested with 6 (16) CPU's, 6-16 streamer threads.

See `JmhStreamerReceiverBenchmark.bchIndividual_512_1()`, 
`DataStreamProcessorSelfTest.testAtomicPrimarySyncStability()`.

The problem is that the streamer doesn't wait for backup updates on primary 
node and keep sending update batches again and again. Individual receiver uses 
cache.put(). Every put creates a future for primary update and future and 
update update request for the backups. Nodes start accumulating related  to 
single update objects in the heap (`processDhtAtomicUpdateRequest()`).

There is no reason to send more than 2-3-4 unresponded batches because they 
stuck at disk writes, WAL writes, page replacements, WAL rolling, GCs and so 
on. Why so many parallel batches by default? Especially for persistent caches. 
IgniteDataStreamer.DFLT_PARALLEL_OPS_MULTIPLIER=8 is weird to me. With 8 CPUs 
and 16 threads I get 128 parallel batches. 

Solution: reduce default max parallel batches for a nod. Make this value depend 
on the persistence.

Some JFR screens attached.

> Datastreamer may consume heap with default settings.
> 
>
> Key: IGNITE-17735
> URL: https://issues.apache.org/jira/browse/IGNITE-17735
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>  Labels: ise
> Attachments: DS_heap_no_events_no_wal.png, 
> DS_heap_no_events_no_wal_2.png
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>




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

[jira] [Updated] (IGNITE-17735) Datastreamer may consume heap with default settings.

2022-10-18 Thread Vladimir Steshin (Jira)



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

Vladimir Steshin updated IGNITE-17735:
--
Summary: Datastreamer may consume heap with default settings.  (was: 
Datastreamer may consume whole heap.)

> Datastreamer may consume heap with default settings.
> 
>
> Key: IGNITE-17735
> URL: https://issues.apache.org/jira/browse/IGNITE-17735
> Project: Ignite
>  Issue Type: Sub-task
>Reporter: Vladimir Steshin
>Assignee: Vladimir Steshin
>Priority: Major
>  Labels: ise
> Attachments: DS_heap_no_events_no_wal.png, 
> DS_heap_no_events_no_wal_2.png
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>




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

[jira] [Commented] (IGNITE-17263) Implement leader to replica safe time propagation

2022-10-18 Thread Denis Chudov (Jira)



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

Denis Chudov commented on IGNITE-17263:
---

The fact that safe time sync command that is used for idle safe time 
propagation is a write command, can cause some problems on idle cluster, 
because even on idle cluster raft log will constantly grow up. It will increase 
the join time of a node that was offline for some time, and will cause loading 
of a snapshot of whole raft storage if the log was compacted. We can put up 
with this problem for now, but in future we can think about some optimizations.

Possibly we can come up with some heuristics depending on read-only load on 
idle cluster. Possibly, most idle safe time propagation commands can be 
triggered by read-only requests.

When we implement the lease-based primary replicas, we will be able to 
propagate safe time via messaging, as lease mechanism will guarantee that there 
will be no primary replica that is able to send its HLC value as safe time that 
is less than the safe time sent by previous primary replica.


> Implement leader to replica safe time propagation
> -
>
> Key: IGNITE-17263
> URL: https://issues.apache.org/jira/browse/IGNITE-17263
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Denis Chudov
>Priority: Major
>  Labels: ignite-3, transaction3_ro
> Attachments: Screenshot from 2022-07-06 16-48-30.png, Screenshot from 
> 2022-07-06 16-48-41.png
>
>
> In order to perform replica reads, it's required either to use read index or 
> check the safe time. Let's recall corresponding section from tx design 
> document.
> RO transactions can be executed on non-primary replicas. write intent 
> resolution doesn’t help because a write intent for a committed transaction 
> may not be yet replicated to the replica. To mitigate this issue, it’s enough 
> to run readIndex on each mapped partition leader, fetch the commit index and 
> wait on a replica until it’s applied. This will guarantee that all required 
> write intents are replicated and present locally. After that the normal write 
> intern resolution should do the job.
> There is a second option, which doesn’t require the network RTT. We can use a 
> special low watermark timestamp (safeTs) per replication group, which 
> corresponds to the apply index of a replicated entry, so then an apply index 
> is advanced during the replication, then the safeTs is monotonically 
> incremented too. The HLC used for safeTs advancing is assigned to a 
> replicated entry in an ordered way.
> Special measures are needed to periodically advance the safeTs if no updates 
> are happening. It’s enough to use a special replication command for this 
> purpose.
> All we need during RO txn is to wait until a safeTs advances past the RO txn 
> readTs. 
>  !Screenshot from 2022-07-06 16-48-30.png! 
> In the picture we have two concurrent transactions mapped to the same 
> partition: T1 and T2.
> OpReq(w1(x)) and OpReq(w2(x)) are received concurrently. Each write intent is 
> assigned a timestamp in a monotonic order consistent with the replication 
> order. This can be for example done when replication entries are dequeued for 
> processing by replication protocol (we assume entries are replicated 
> successively.
> It’s not enough only to wait for safeTs - it may never happen due to absence 
> of activity in the partition. Consider the next diagram:
>  !Screenshot from 2022-07-06 16-48-41.png! 
> We need an additional safeTsSync command to propagate a safeTs event in case 
> there are no updates in the partition.
> We need to linerialize safe time updates in all cases including leader 
> change. So we need a guarantee that safe time on non-primary replicas never 
> will be greater than HLC on leader (as we assume that primary replica is 
> colocated with leader). We are going to solve this problem by associating 
> every potential value of safeTime (propagated to the replica from leader via 
> appendEntries) with some log index, and this value (safe time candidate) 
> should be applied as new safe time value at the moment when corresponding 
> index is committed.
> Hence, the safeTimeSyncCommand also should be a Raft write command.



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



[ 
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/18/22 3:49 PM:
--

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

Above failures are unrelated to the fix.


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

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-17263) Implement leader to replica safe time propagation

2022-10-18 Thread Denis Chudov (Jira)

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

Denis Chudov updated IGNITE-17263:
--
Description:
In order to perform replica reads, it's required either to use read index or
check the safe time. Let's recall corresponding section from tx design document.

RO transactions can be executed on non-primary replicas. write intent
resolution doesn’t help because a write intent for a committed transaction may
not be yet replicated to the replica. To mitigate this issue, it’s enough to
run readIndex on each mapped partition leader, fetch the commit index and wait
on a replica until it’s applied. This will guarantee that all required write
intents are replicated and present locally. After that the normal write intern
resolution should do the job.

There is a second option, which doesn’t require the network RTT. We can use a
special low watermark timestamp (safeTs) per replication group, which
corresponds to the apply index of a replicated entry, so then an apply index is
advanced during the replication, then the safeTs is monotonically incremented
too. The HLC used for safeTs advancing is assigned to a replicated entry in an
ordered way.

Special measures are needed to periodically advance the safeTs if no updates
are happening. It’s enough to use a special replication command for this
purpose.

All we need during RO txn is to wait until a safeTs advances past the RO txn
readTs.
!Screenshot from 2022-07-06 16-48-30.png!
In the picture we have two concurrent transactions mapped to the same
partition: T1 and T2.
OpReq(w1(x)) and OpReq(w2(x)) are received concurrently. Each write intent is
assigned a timestamp in a monotonic order consistent with the replication
order. This can be for example done when replication entries are dequeued for
processing by replication protocol (we assume entries are replicated
successively.

It’s not enough only to wait for safeTs - it may never happen due to absence of
activity in the partition. Consider the next diagram:
!Screenshot from 2022-07-06 16-48-41.png!
We need an additional safeTsSync command to propagate a safeTs event in case
there are no updates in the partition.

We need to linerialize safe time updates in all cases including leader change.
So we need a guarantee that safe time on non-primary replicas never will be
greater than HLC on leader (as we assume that primary replica is colocated with
leader). We are going to solve this problem by associating every potential
value of safeTime (propagated to the replica from leader via appendEntries)
with some log index, and this value (safe time candidate) should be applied as
new safe time value at the moment when corresponding index is committed.

Hence, the safeTimeSyncCommand also should be a Raft write command.

was:
In order to perform replica reads, it's required either to use read index or
check the safe time. Let's recall corresponding section from tx design document.

Special measures are needed to periodically advance the safeTs if no updates
are happening. It’s enough to use a special replication command for this
purpose.

Actually, it seems that it's

[jira] [Comment Edited] (IGNITE-17263) Implement leader to replica safe time propagation

2022-10-18 Thread Denis Chudov (Jira)



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

Denis Chudov edited comment on IGNITE-17263 at 10/18/22 3:44 PM:
-

Raft vote/prevote requests appeared to be unsuitable for safe time purposes, as 
their handlers use common thread pool and requests are not linearized.


was (Author: denis chudov):
Raft vote/prevote requests appeared to be unsuitable for safe time purposes, as 
their handlers use common thread pool and requests are not linearized.
Sync command also isn't implemented as raft heartbeats serve for this purpose 
in idle cluster.

[~alapin] could you review the PR?

> Implement leader to replica safe time propagation
> -
>
> Key: IGNITE-17263
> URL: https://issues.apache.org/jira/browse/IGNITE-17263
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Alexander Lapin
>Assignee: Denis Chudov
>Priority: Major
>  Labels: ignite-3, transaction3_ro
> Attachments: Screenshot from 2022-07-06 16-48-30.png, Screenshot from 
> 2022-07-06 16-48-41.png
>
>
> In order to perform replica reads, it's required either to use read index or 
> check the safe time. Let's recall corresponding section from tx design 
> document.
> RO transactions can be executed on non-primary replicas. write intent 
> resolution doesn’t help because a write intent for a committed transaction 
> may not be yet replicated to the replica. To mitigate this issue, it’s enough 
> to run readIndex on each mapped partition leader, fetch the commit index and 
> wait on a replica until it’s applied. This will guarantee that all required 
> write intents are replicated and present locally. After that the normal write 
> intern resolution should do the job.
> There is a second option, which doesn’t require the network RTT. We can use a 
> special low watermark timestamp (safeTs) per replication group, which 
> corresponds to the apply index of a replicated entry, so then an apply index 
> is advanced during the replication, then the safeTs is monotonically 
> incremented too. The HLC used for safeTs advancing is assigned to a 
> replicated entry in an ordered way.
> Special measures are needed to periodically advance the safeTs if no updates 
> are happening. It’s enough to use a special replication command for this 
> purpose.
> All we need during RO txn is to wait until a safeTs advances past the RO txn 
> readTs. 
>  !Screenshot from 2022-07-06 16-48-30.png! 
> In the picture we have two concurrent transactions mapped to the same 
> partition: T1 and T2.
> OpReq(w1(x)) and OpReq(w2(x)) are received concurrently. Each write intent is 
> assigned a timestamp in a monotonic order consistent with the replication 
> order. This can be for example done when replication entries are dequeued for 
> processing by replication protocol (we assume entries are replicated 
> successively.
> It’s not enough only to wait for safeTs - it may never happen due to absence 
> of activity in the partition. Consider the next diagram:
>  !Screenshot from 2022-07-06 16-48-41.png! 
> We need an additional safeTsSync command to propagate a safeTs event in case 
> there are no updates in the partition.
> We need to linerialize safe time updates in all cases including leader 
> change. So we need a guarantee that safe time on non-primary replicas never 
> will be greater than HLC on leader (as we assume that primary replica is 
> colocated with leader). We are going to solve this problem by associating 
> every potential value of safeTime (propagated to the replica from leader via 
> appendEntries) with some log index, and this value (safe time candidate) 
> should be applied as new safe time value at the moment when corresponding 
> index is committed.
> Hence, the safeTimeSyncCommand also should be a Raft write command.



--
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-18 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/18/22 3:25 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.

5) V5 (PR 10330)
We could quickly check partition counters at the start stage. That would cover
case when Datastremer failed or canceled before snapshot.

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:

[jira] [Updated] (IGNITE-17926) Update Ignite dependency: Jetty

2022-10-18 Thread Aleksandr (Jira)



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

Aleksandr updated IGNITE-17926:
---
Labels: ise  (was: )

> Update Ignite dependency: Jetty
> ---
>
> Key: IGNITE-17926
> URL: https://issues.apache.org/jira/browse/IGNITE-17926
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Aleksandr
>Assignee: Aleksandr
>Priority: Minor
>  Labels: ise
> Fix For: 2.15
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Update Jetty dependency 9.4.43.v20210629 to 9.4.49.v20220914



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

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

2022-10-18 Thread Sergey Uttsel (Jira)



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

Sergey Uttsel edited comment on IGNITE-17806 at 10/18/22 3:06 PM:
--

The test checks that there are no tx with PENDING state in 
TxManagerImpl#states. Now tx coordinator put PENDING state on 
TxManagerImpl#begin. But not removed if tx doesn't enlist partitions.

I think no need to save state on tx begin and we can remove PENDING status.


was (Author: sergey uttsel):
The test checks that there are no tx with PENDING state in 
TxManagerImpl#states. Now tx coordinator put PENDING state on 
TxManagerImpl#begin. But not removed if tx doesn't enlist partitions.

I think no need to save state on tx begin.

> 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
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> 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-17926) Update Ignite dependency: Jetty

2022-10-18 Thread Aleksandr (Jira)



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

Aleksandr updated IGNITE-17926:
---
Fix Version/s: 2.15

> Update Ignite dependency: Jetty
> ---
>
> Key: IGNITE-17926
> URL: https://issues.apache.org/jira/browse/IGNITE-17926
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Aleksandr
>Assignee: Aleksandr
>Priority: Minor
> Fix For: 2.15
>
>
> Update Jetty dependency 9.4.43.v20210629 to 9.4.49.v20220914



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

[jira] [Created] (IGNITE-17926) Update Ignite dependency: Jetty

2022-10-18 Thread Aleksandr (Jira)

Aleksandr created IGNITE-17926:
--

 Summary: Update Ignite dependency: Jetty
 Key: IGNITE-17926
 URL: https://issues.apache.org/jira/browse/IGNITE-17926
 Project: Ignite
  Issue Type: Improvement
Reporter: Aleksandr
Assignee: Aleksandr


Update Jetty dependency 9.4.43.v20210629 to 9.4.49.v20220914



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

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

2022-10-18 Thread Alexander Lapin (Jira)



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

Alexander Lapin commented on IGNITE-17806:
--

[~Sergey Uttsel] LGTM

> 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
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> 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] [Commented] (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:comment-tabpanel=17619607#comment-17619607
 ] 

Julia Bakulina commented on IGNITE-17916:
-

@timoninmaxim Hi Maxim, could you please review the changes?

> 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
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> 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] [Commented] (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:comment-tabpanel=17619605#comment-17619605
 ] 

Ignite TC Bot commented on IGNITE-17916:


{panel:title=Branch: [pull/10327/head] Base: [master] : No blockers 
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10327/head] Base: [master] : New Tests 
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}SPI (URI Deploy){color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=6844956]]
* {color:#013220}IgniteUriDeploymentTestSuite: 
GridUriDeploymentConfigSelfTest.testClientSpiConsistencyChecked - PASSED{color}

{color:#8b}Queries 1 (lazy=true){color} [[tests 
1|https://ci.ignite.apache.org/viewLog.html?buildId=6844941]]
* {color:#013220}IgniteBinaryCacheQueryLazyTestSuite: 
SqlParserMultiStatementSelfTest.testEmptyTransaction - PASSED{color}

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

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

> 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
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> 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] [Commented] (IGNITE-17807) OutOfMemoryException in RebalanceIteratorLargeEntriesOOMTest on TC

2022-10-18 Thread Roman Puchkovskiy (Jira)



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

Roman Puchkovskiy commented on IGNITE-17807:


Thanks!

> OutOfMemoryException in RebalanceIteratorLargeEntriesOOMTest on TC
> --
>
> Key: IGNITE-17807
> URL: https://issues.apache.org/jira/browse/IGNITE-17807
> Project: Ignite
>  Issue Type: Bug
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Fix For: 2.15
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> [https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_Cache2/6801420?logFilter=debug]
> The OOME exception seems to be thrown by the remote JVM, which is probably of 
> version higher than 8 (probably 17, see IGNITE-17805).
> The TC build contains a heap dump, but judging by its size (5.3Gb) and the 
> configuration for the remove JVM (-Xmx256m), the dump is made on the original 
> JVM that runs the test, so it is not relevant to the issue (as the OOME 
> happens on the remote JVM).



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

[jira] [Updated] (IGNITE-17925) Ability to use configured FailureHandler for segmentation handling



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

Ilya Shishkov updated IGNITE-17925:
---
Description: 
Now, we have 3 possible ways to process segmentation by means of 
{{{}SegmentationPolicy{}}}:
 # Stop segmented node - {{SegmentationPolicy#STOP}}
 # Restart segmented node - {{SegmentationPolicy#RESTART_JVM}}
 # Do nothing - {{SegmentationPolicy#NOOP}}

Under the hood, behavior of segmentation handling (i.e. failure handling) is 
overridden [1, 2]. 
For example, instead of using {{StopNodeOrHaltFailureHandler}} configured by 
default, default segmentation handling will use {{StopNodeFailureHandler}} 
which can hang during stop process.

As a solution, we can add extra {{SegmentationPolicy#USE_FAILURE_HANDLER}} 
which will be used by default.

Links:
 # 
[https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java#L3300]
 # 
[https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java#L2983]

  was:
Now, by means of {{SegmentationPolicy}} we have 3 possible ways to process 
segmentation:
# Stop segmented node - {{SegmentationPolicy#STOP}}
# Restart segmented node - {{SegmentationPolicy#RESTART_JVM}}
# Do nothing - {{SegmentationPolicy#NOOP}}

Under the hood, behavior of segmentation handling (i.e. failure handling) is 
overridden [1, 2]. 
For example, instead of using {{StopNodeOrHaltFailureHandler}} configured by 
default, default segmentation handling will use {{StopNodeFailureHandler}} 
which can hang during stop process.

As a solution, we can add extra {{SegmentationPolicy#USE_FAILURE_HANDLER}} 
which will be used by default.

Links:
# 
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java#L3300
# 
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java#L2983
 


> Ability to use configured FailureHandler for segmentation handling
> --
>
> Key: IGNITE-17925
> URL: https://issues.apache.org/jira/browse/IGNITE-17925
> Project: Ignite
>  Issue Type: Task
>Reporter: Ilya Shishkov
>Priority: Minor
>  Labels: ise
>
> Now, we have 3 possible ways to process segmentation by means of 
> {{{}SegmentationPolicy{}}}:
>  # Stop segmented node - {{SegmentationPolicy#STOP}}
>  # Restart segmented node - {{SegmentationPolicy#RESTART_JVM}}
>  # Do nothing - {{SegmentationPolicy#NOOP}}
> Under the hood, behavior of segmentation handling (i.e. failure handling) is 
> overridden [1, 2]. 
> For example, instead of using {{StopNodeOrHaltFailureHandler}} configured by 
> default, default segmentation handling will use {{StopNodeFailureHandler}} 
> which can hang during stop process.
> As a solution, we can add extra {{SegmentationPolicy#USE_FAILURE_HANDLER}} 
> which will be used by default.
> Links:
>  # 
> [https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java#L3300]
>  # 
> [https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java#L2983]



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

[jira] [Updated] (IGNITE-17925) Ability to use configured FailureHandler for segmentation handling



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

Ilya Shishkov updated IGNITE-17925:
---
Description: 
Now, by means of {{SegmentationPolicy}} we have 3 possible ways to process 
segmentation:
# Stop segmented node - {{SegmentationPolicy#STOP}}
# Restart segmented node - {{SegmentationPolicy#RESTART_JVM}}
# Do nothing - {{SegmentationPolicy#NOOP}}

Under the hood, behavior of segmentation handling (i.e. failure handling) is 
overridden [1, 2]. 
For example, instead of using {{StopNodeOrHaltFailureHandler}} configured by 
default, default segmentation handling will use {{StopNodeFailureHandler}} 
which can hang during stop process.

As a solution, we can add extra {{SegmentationPolicy#USE_FAILURE_HANDLER}} 
which will be used by default.

Links:
# 
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java#L3300
# 
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java#L2983
 

  was:
Now, by means of {{SegmentationPolicy}} we have 3 possible ways to process 
segmentation:
# Stop segmented node - {{SegmentationPolicy#STOP}}
# Restart segmented node - {{SegmentationPolicy#RESTART_JVM}}
# Do nothing - {{SegmentationPolicy#NOOP}}

Under the hood, behavior of segmentation handling (i.e. failure handling) is 
overridden [1, 2]. 
For example, instead of using {{StopNodeOrHaltFailureHandler}} configured by 
default, default segmentation handling will use {{StopNodeFailureHandler}} 
which can hang during stop process.

Links:
# 
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java#L3300
# 
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java#L2983
 


> Ability to use configured FailureHandler for segmentation handling
> --
>
> Key: IGNITE-17925
> URL: https://issues.apache.org/jira/browse/IGNITE-17925
> Project: Ignite
>  Issue Type: Task
>Reporter: Ilya Shishkov
>Priority: Minor
>  Labels: ise
>
> Now, by means of {{SegmentationPolicy}} we have 3 possible ways to process 
> segmentation:
> # Stop segmented node - {{SegmentationPolicy#STOP}}
> # Restart segmented node - {{SegmentationPolicy#RESTART_JVM}}
> # Do nothing - {{SegmentationPolicy#NOOP}}
> Under the hood, behavior of segmentation handling (i.e. failure handling) is 
> overridden [1, 2]. 
> For example, instead of using {{StopNodeOrHaltFailureHandler}} configured by 
> default, default segmentation handling will use {{StopNodeFailureHandler}} 
> which can hang during stop process.
> As a solution, we can add extra {{SegmentationPolicy#USE_FAILURE_HANDLER}} 
> which will be used by default.
> Links:
> # 
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java#L3300
> # 
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java#L2983
>  



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

[jira] [Updated] (IGNITE-17925) Ability to use configured FailureHandler for segmentation handling



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

Ilya Shishkov updated IGNITE-17925:
---
Description: 
Now, by means of {{SegmentationPolicy}} we have 3 possible ways to process 
segmentation:
# Stop segmented node - {{SegmentationPolicy#STOP}}
# Restart segmented node - {{SegmentationPolicy#RESTART_JVM}}
# Do nothing - {{SegmentationPolicy#NOOP}}

Under the hood, behavior of segmentation handling (i.e. failure handling) is 
overridden [1, 2]. 
For example, instead of using {{StopNodeOrHaltFailureHandler}} configured by 
default, default segmentation handling will use {{StopNodeFailureHandler}} 
which can hang during stop process.

Links:
# 
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java#L3300
# 
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java#L2983
 

  was:
Now, by means of {{SegmentationPolicy}} we have 3 possible ways to process 
segmentation:
# Stop segmented node - {{SegmentationPolicy#STOP}}
# Restart segmented node - {{SegmentationPolicy#RESTART_JVM}}
# Do nothing - {{SegmentationPolicy#NOOP}}

Under the hood, behavior of segmentation handling (i.e. failure handling) is 
overridden [1, 2]. 
For example, instead of using {{StopNodeOrHaltFailureHandler}} configured by 
default, segmentation handling will use {{StopNodeFailureHandler}} which can 
hang during stop process.

Links:
# 
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java#L3300
# 
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java#L2983
 


> Ability to use configured FailureHandler for segmentation handling
> --
>
> Key: IGNITE-17925
> URL: https://issues.apache.org/jira/browse/IGNITE-17925
> Project: Ignite
>  Issue Type: Task
>Reporter: Ilya Shishkov
>Priority: Minor
>  Labels: ise
>
> Now, by means of {{SegmentationPolicy}} we have 3 possible ways to process 
> segmentation:
> # Stop segmented node - {{SegmentationPolicy#STOP}}
> # Restart segmented node - {{SegmentationPolicy#RESTART_JVM}}
> # Do nothing - {{SegmentationPolicy#NOOP}}
> Under the hood, behavior of segmentation handling (i.e. failure handling) is 
> overridden [1, 2]. 
> For example, instead of using {{StopNodeOrHaltFailureHandler}} configured by 
> default, default segmentation handling will use {{StopNodeFailureHandler}} 
> which can hang during stop process.
> Links:
> # 
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java#L3300
> # 
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java#L2983
>  



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

[jira] [Updated] (IGNITE-17925) Ability to use configured FailureHandler for segmentation handling



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

Ilya Shishkov updated IGNITE-17925:
---
Labels: ise  (was: )

> Ability to use configured FailureHandler for segmentation handling
> --
>
> Key: IGNITE-17925
> URL: https://issues.apache.org/jira/browse/IGNITE-17925
> Project: Ignite
>  Issue Type: Task
>Reporter: Ilya Shishkov
>Priority: Minor
>  Labels: ise
>
> Now, by means of {{SegmentationPolicy}} we have 3 possible ways to process 
> segmentation:
> # Stop segmented node - {{SegmentationPolicy#STOP}}
> # Restart segmented node - {{SegmentationPolicy#RESTART_JVM}}
> # Do nothing - {{SegmentationPolicy#NOOP}}
> Under the hood, behavior of segmentation handling (i.e. failure handling) is 
> overridden [1, 2]. 
> For example, instead of using {{StopNodeOrHaltFailureHandler}} configured by 
> default, segmentation handling will use {{StopNodeFailureHandler}} which can 
> hang during stop process.
> Links:
> # 
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java#L3300
> # 
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java#L2983
>  



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

[jira] [Created] (IGNITE-17925) Ability to use configured FailureHandler for segmentation handling

Ilya Shishkov created IGNITE-17925:
--

 Summary: Ability to use configured FailureHandler for segmentation 
handling
 Key: IGNITE-17925
 URL: https://issues.apache.org/jira/browse/IGNITE-17925
 Project: Ignite
  Issue Type: Task
Reporter: Ilya Shishkov


Now, by means of {{SegmentationPolicy}} we have 3 possible ways to process 
segmentation:
# Stop segmented node - {{SegmentationPolicy#STOP}}
# Restart segmented node - {{SegmentationPolicy#RESTART_JVM}}
# Do nothing - {{SegmentationPolicy#NOOP}}

Under the hood, behavior of segmentation handling (i.e. failure handling) is 
overridden [1, 2]. 
For example, instead of using {{StopNodeOrHaltFailureHandler}} configured by 
default, segmentation handling will use {{StopNodeFailureHandler}} which can 
hang during stop process.

Links:
# 
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java#L3300
# 
https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/managers/discovery/GridDiscoveryManager.java#L2983
 



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

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

2022-10-18 Thread Roman Puchkovskiy (Jira)



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

Roman Puchkovskiy commented on IGNITE-17911:


The patch looks good to me

> 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
>Priority: Major
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> 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] [Resolved] (IGNITE-15780) ITDistributedConfigurationPropertiesTest#testFallingBehindDistributedStorageValue is flaky



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

Vyacheslav Koptilin resolved IGNITE-15780.
--
Resolution: Cannot Reproduce

> ITDistributedConfigurationPropertiesTest#testFallingBehindDistributedStorageValue
>  is flaky
> --
>
> Key: IGNITE-15780
> URL: https://issues.apache.org/jira/browse/IGNITE-15780
> Project: Ignite
>  Issue Type: Bug
>Reporter: Ivan Bessonov
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta1
>
> Attachments: ITDistributedConfigurationPropertiesTest.log
>
>
> Test fails locally after a few runs.



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

[jira] [Updated] (IGNITE-15944) [Networking] User object serialization



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

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

> [Networking] User object serialization
> --
>
> Key: IGNITE-15944
> URL: https://issues.apache.org/jira/browse/IGNITE-15944
> Project: Ignite
>  Issue Type: Epic
>Reporter: Semyon Danilov
>Priority: Major
>  Labels: iep-67, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Arbitrary objects serialization must be provided by Apache Ignite. Unlike 
> {{NetworkMessage}} descendants, user objects are not known to the system in 
> advance, and serialization layout must be resolved at runtime.
> For more information look at the 
> https://github.com/gridgain/gridgain-9-ce/blob/iep-67/modules/network/README.md



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

[jira] [Updated] (IGNITE-15782) User POJO mapping.



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

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

> User POJO mapping.
> --
>
> Key: IGNITE-15782
> URL: https://issues.apache.org/jira/browse/IGNITE-15782
> Project: Ignite
>  Issue Type: New Feature
>Reporter: Andrey Mashenkov
>Priority: Major
>  Labels: iep-54, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Umbrella ticket
> Please, refer to {{org.apache.ignite.internal.table.Example}} for details.



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

[jira] [Updated] (IGNITE-15944) [Networking] User object serialization



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

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

> [Networking] User object serialization
> --
>
> Key: IGNITE-15944
> URL: https://issues.apache.org/jira/browse/IGNITE-15944
> Project: Ignite
>  Issue Type: Epic
>Reporter: Semyon Danilov
>Priority: Major
>  Labels: iep-67, ignite-3
>
> Arbitrary objects serialization must be provided by Apache Ignite. Unlike 
> {{NetworkMessage}} descendants, user objects are not known to the system in 
> advance, and serialization layout must be resolved at runtime.
> For more information look at the 
> https://github.com/gridgain/gridgain-9-ce/blob/iep-67/modules/network/README.md



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

[jira] [Updated] (IGNITE-16230) .NET: Thin 3.0: Implement transaction timeouts



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

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

> .NET: Thin 3.0: Implement transaction timeouts
> --
>
> Key: IGNITE-16230
> URL: https://issues.apache.org/jira/browse/IGNITE-16230
> Project: Ignite
>  Issue Type: Improvement
>  Components: platforms, thin client
>Affects Versions: 3.0.0-alpha3
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Add a way to specify timeout for transactions.
> Java uses *withTimeout*, in .NET we should probably add a parameter to 
> *BeginAsync*.



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

[jira] [Updated] (IGNITE-16094) Mapper and Marshaller caching



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

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

> Mapper and Marshaller caching
> -
>
> Key: IGNITE-16094
> URL: https://issues.apache.org/jira/browse/IGNITE-16094
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Pavel Tupitsyn
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> *Mapper* and *Marshaller* implementations use reflection to retrieve 
> object fields. We should cache results when possible. 
> For example:
> * *IdentityMapper* instances can be cached by Class
> * *Marshaller* instances can be cached by Class + Schema when using 
> IdentityMapper
> See TODOs in code with "IGNITE-16094".



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

[jira] [Updated] (IGNITE-16082) Thin 3.0: Avoid array allocation when serializing tuples on client



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

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

> Thin 3.0: Avoid array allocation when serializing tuples on client
> --
>
> Key: IGNITE-16082
> URL: https://issues.apache.org/jira/browse/IGNITE-16082
> Project: Ignite
>  Issue Type: Improvement
>  Components: thin client
>Affects Versions: 3.0.0-alpha3
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Optimize *writeTuple* overloads in *ClientTable*.



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

[jira] [Updated] (IGNITE-16152) Thin 3.0: Optimize server-side Tuple handling using known schema version



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

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

> Thin 3.0: Optimize server-side Tuple handling using known schema version
> 
>
> Key: IGNITE-16152
> URL: https://issues.apache.org/jira/browse/IGNITE-16152
> Project: Ignite
>  Issue Type: Improvement
>  Components: thin client
>Affects Versions: 3.0.0-alpha3
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Thin client protocol is schema-aware, but the known schema is thrown away on 
> the server after deserialization, and Table API has to match it against 
> schemas again.
> *SchemaAware* interface can be used to preserve known schema when passing 
> tuples to the Table API (see how TupleMarshallerImpl checks for SchemaAware).
> *Example: table.Upsert(Tuple t)*
> # Client: match user tuple to schema, serialize with schema version, send to 
> server
> # Server: read schema version, read tuple data, create Tuple, throw away 
> schema version, pass to Table API
> # Server: match tuple to schema



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

[jira] [Updated] (IGNITE-16022) Thin 3.0: Optimize multi-row responses using guaranteed order



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

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

> Thin 3.0: Optimize multi-row responses using guaranteed order
> -
>
> Key: IGNITE-16022
> URL: https://issues.apache.org/jira/browse/IGNITE-16022
> Project: Ignite
>  Issue Type: Improvement
>  Components: thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> IGNITE-16004 introduces guaranteed row order for multi-row operations, like 
> *GetAll*, *InsertAll*, *DeleteAll*. We can leverage this fact to optimize the 
> thin client protocol:
> * *GetAll* can return values without keys (keys are known on the client), and 
> without size (it is the same as input collection size)
> * *InsertAll* and *DeleteAll* can return a bit set to indicate which items 
> were skipped.



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

[jira] [Updated] (IGNITE-16350) [Native Persistence 3.0] Post-porting renames and improvements



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

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

> [Native Persistence 3.0] Post-porting renames and improvements
> --
>
> Key: IGNITE-16350
> URL: https://issues.apache.org/jira/browse/IGNITE-16350
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Ivan Bessonov
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> This task should be used for TODO links in code. All suggestions must be 
> stated in the list below or in TODO in code, or both:
>  * {{IgniteUtils#hexInt}} and {{IgniteUtils#hexLong}} should be moved to 
> other class like {{IgniteStringUtils}} and possible renamed;
>  * Improve javadoc on the {{PageMemory}} class;
>  * Describe {{page}} and {{pageAddr}} naming convention in 
> {{{}PageSupport{}}};
>  * Rename and properly document {{PageMemory#systemPageSize}} and 
> {{{}PageMemory#realPageSize{}}};
> * Replace *DataStructure#rnd* to {{private final IntUnaryOperator rng;}}
> * Get rid of *AbstractFreeList#minSizeForDataPage*;
> * Consider not blocking all pages in *PagesList#putReuseBag*;
> * Think about all the system properties from *PagesList.PagesCache*;
> * Optimize *PagesListNodeIo#removePage*;
> * Refactor *BplusIo#canGetRow*;
> * Output all first page ID by levels in *BplusMetaIo#printPage*;
> * Make *BplusTree#minFill* and *BplusTree#maxFill* configurable (0 <= minFill 
> <= maxFill <= 1);
> * Make *BplusTree#IGNITE_BPLUS_TREE_LOCK_RETRIES* configurable;
> * Make *BplusTree#innerIos* and *BplusTree#leafIos* final;
> * Add *ConcurrentLinkedHashMap* implementation to 
> *BplusTreeSelfTest.TestPageLockListener#locks*;



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

[jira] [Updated] (IGNITE-16234) Implement injection of Ignite resources on unmarshalling



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

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

> Implement injection of Ignite resources on unmarshalling
> 
>
> Key: IGNITE-16234
> URL: https://issues.apache.org/jira/browse/IGNITE-16234
> Project: Ignite
>  Issue Type: Improvement
>  Components: networking
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> User Object Serialization (IGNITE-15944) might be used to serialize compute 
> tasks and other components supplied by a user, sent via network, unmarshalled 
> and executed on Ignite nodes.
> Such serialized components may need access to Ignite resources. It makes 
> sense to inject them to fields annotated with a special-purpose annotation 
> (like it was it Ignite 2).
> An example of such annotation in Ignite 2 is @TaskSessionResource.



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

[jira] [Updated] (IGNITE-16356) .NET: Thin 3.0: Customizable user type mapping



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

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

> .NET: Thin 3.0: Customizable user type mapping
> --
>
> Key: IGNITE-16356
> URL: https://issues.apache.org/jira/browse/IGNITE-16356
> 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
>
>
> IGNITE-16227 introduced basic POCO mapping when table column names match user 
> type field names exactly. Provide APIs to customize the mapping. Some 
> possibilities are:
> * Attributes on properties and fields to alter column name
> * Pluggable mapper or serializer interface that gives full control to the 
> user (we require schema order, so that may be complicated)



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

[jira] [Updated] (IGNITE-16464) Remove Class objects from internal maps when classes are unloaded



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

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

> Remove Class objects from internal maps when classes are unloaded
> -
>
> Key: IGNITE-16464
> URL: https://issues.apache.org/jira/browse/IGNITE-16464
> Project: Ignite
>  Issue Type: Improvement
>  Components: networking
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Currently, some classes (for example, ClassDescriptorRegistry) keep 
> references to classes forever. That would interfere with class unloading if a 
> class was tried to be unloaded.



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

[jira] [Updated] (IGNITE-16466) User Object Serialization Security



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

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

> User Object Serialization Security
> --
>
> Key: IGNITE-16466
> URL: https://issues.apache.org/jira/browse/IGNITE-16466
> Project: Ignite
>  Issue Type: Improvement
>  Components: networking
>Reporter: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Recently, there were a lot of vulnerabilities related to the JDK 
> Serialization. User Object Seriailzation supports Serializable and its 
> callbacks, so it is probably also susceptible to the same attacks.
> We could, for example, implement white-lists of the classes we are allowed to 
> deserialize.
> Also, we could restrict ourselves to only allowing classes from known 
> classloaders.



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

[jira] [Updated] (IGNITE-16520) Refactor IgniteCliInterfaceTest



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

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

> Refactor IgniteCliInterfaceTest
> ---
>
> Key: IGNITE-16520
> URL: https://issues.apache.org/jira/browse/IGNITE-16520
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Reporter: Roman Puchkovskiy
>Priority: Minor
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> IgniteCliInterfaceTest is already pretty long and it will become even longer 
> when we add more commands. It makes sense to pull the test classes (like 
> Config, Node, etc) to the upper level and make them independent from each 
> other.



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

[jira] [Updated] (IGNITE-16477) Compress wrapper Boolean arrays in User Object Serialization



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

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

> Compress wrapper Boolean arrays in User Object Serialization
> 
>
> Key: IGNITE-16477
> URL: https://issues.apache.org/jira/browse/IGNITE-16477
> Project: Ignite
>  Issue Type: Improvement
>  Components: networking
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Boolean[] arrays can be efficiently compressed by using 2 bits per element 
> (because each element could be true, false or null).



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

[jira] [Updated] (IGNITE-16512) Change the style of named options in the CLI



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

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

> Change the style of named options in the CLI
> 
>
> Key: IGNITE-16512
> URL: https://issues.apache.org/jira/browse/IGNITE-16512
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Reporter: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Some named CLI options may have multiple values. There are few different ways 
> to use such multi-valued options from the CLI:
>  # --nodes "one two three" (that is, put all the values in the same command 
> line argument)
>  # --nodes one two three (that is, put each value as a separate command line 
> argument)
>  # --node one --node two --node three (repeat the option name with each 
> value; please note that here the option name is in singular form)
> A team-wide discussion was caried on in a Slack channel, and it was suggested 
> that we use option 2. But the existing commands (like 'module add ' with 
> --repo option) already use option 3.
> The style needs to be changed.



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

[jira] [Updated] (IGNITE-16535) Put @Generated annotation on generated program elements



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

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

> Put @Generated annotation on generated program elements
> ---
>
> Key: IGNITE-16535
> URL: https://issues.apache.org/jira/browse/IGNITE-16535
> Project: Ignite
>  Issue Type: Improvement
>  Components: general
>Reporter: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Some tooling (like Modernizer Maven plugin) respect the @Generated 
> annotation, it allows to easily distinguish generated program elements 
> (including types) from the ones written by hand.



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

[jira] [Updated] (IGNITE-16538) Enable RocksDB to control memory usage better with stalling write if memory usage exceeds limit



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

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

> Enable RocksDB to control memory usage better with stalling write if memory 
> usage exceeds limit
> ---
>
> Key: IGNITE-16538
> URL: https://issues.apache.org/jira/browse/IGNITE-16538
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Yun Tang
>Priority: Major
>  Labels: iep-74, ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> Currently, Ignite choose RocksDB-6.20.3 and let all RocksDB table storages 
> share same {{WriteBufferManager}} within a data region. This could limit the 
> memory of all storage instances in a way, however, this is still not enough 
> considerring the case that current {{WriteBufferManager}} cannot not limit 
> the memory even memory_usage exceeds buffer_size with multi rocksdb instances.
> We can refer to this feature descriptions:
> "When WriteBufferManager is shared across DBs and column families
> to maintain memory usage under a limit, OOMs have been observed when flush 
> cannot
> finish but writes continuously insert to memtables.
> In order to avoid OOMs, when memory usage goes beyond buffer_limit_ and DBs 
> tries to write,
> this change will stall incoming writers until flush is completed and 
> memory_usage
> drops." (see [the PR summary|https://github.com/facebook/rocksdb/pull/7898])
> RocksDB introduce better memory management and public it to java side from 
> RocksDB-6.27.3 (see 
> [commit-dc00e4b120|https://github.com/facebook/rocksdb/commit/dc00e4b1206cba9995fe042ec976df54d0f6e76f])
>  Thus, I suggest to bump the RocksDB version to 6.27.3 and enable this 
> feature by default.



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

[jira] [Updated] (IGNITE-16572) Make UosGetField.getObjectStreamClass() support schema changes



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

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

> Make UosGetField.getObjectStreamClass() support schema changes
> --
>
> Key: IGNITE-16572
> URL: https://issues.apache.org/jira/browse/IGNITE-16572
> Project: Ignite
>  Issue Type: Improvement
>  Components: networking
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Currently, UosGetField.getObjectStreamClass() assumes that the remote and 
> local classes are same.
> The correct thing to do would be to reconstruct/modify ObjectStreamClass so 
> that it matches the remote one. Another option is to serialize the actual 
> remote ObjectStreamClass instance and deserialize it locally.



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

[jira] [Updated] (IGNITE-16564) Automatically convert numerical values if accepting type allows lossless conversion



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

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

> Automatically convert numerical values if accepting type allows lossless 
> conversion
> ---
>
> Key: IGNITE-16564
> URL: https://issues.apache.org/jira/browse/IGNITE-16564
> Project: Ignite
>  Issue Type: Improvement
>  Components: networking
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> SchemaMismatchHandler has a method for handling an incompatible field type 
> change. But in the case when the type change is compatible, we can convert 
> the value automatically.
> One such case is when the accepting type is a supertype of the publishing 
> type (this should be already covered).
> Another case is when both types are numeric and the accepting type is wider 
> than the publishing type and allows a loseless conversion. This second case 
> should be solved under this ticket.



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

[jira] [Updated] (IGNITE-16575) Support readObjectNoData() in User Object Serialization



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

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

> Support readObjectNoData() in User Object Serialization
> ---
>
> Key: IGNITE-16575
> URL: https://issues.apache.org/jira/browse/IGNITE-16575
> Project: Ignite
>  Issue Type: Improvement
>  Components: networking
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The standard Java Serialization defines readObjectNoData() hook for 
> Serializable classes; it is invoked when locally its class is one of ancestor 
> classes of the deserialized object, but remotely it was not in the lineage, 
> so the stream does not contain any data for it. So this method can be used to 
> init class fields to some 'default' state.
> As we support Java Serialization features, we should also invoke this method 
> on Serializable classes in similar circumstances.



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

[jira] [Updated] (IGNITE-16576) Add an integration test for unmarshalling an object with changed schema



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

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

> Add an integration test for unmarshalling an object with changed schema
> ---
>
> Key: IGNITE-16576
> URL: https://issues.apache.org/jira/browse/IGNITE-16576
> Project: Ignite
>  Issue Type: Improvement
>  Components: networking
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> The idea is to marshal an object send it via our network mechanisms and then 
> unmarshal it (on another node) using a different version of the same class 
> (that is, adding some field and removing some other field).



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

[jira] [Updated] (IGNITE-16758) Change configuration for RocksDB



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

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

> Change configuration for RocksDB
> 
>
> Key: IGNITE-16758
> URL: https://issues.apache.org/jira/browse/IGNITE-16758
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> At the moment the configuration for RocksDB is based on the date region from 
> 2.0, we need to change this, but after IGNITE-16691.



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

[jira] [Updated] (IGNITE-16636) Use busy-lock approach to guard stopping RestComponent



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

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

> Use busy-lock approach to guard stopping RestComponent
> --
>
> Key: IGNITE-16636
> URL: https://issues.apache.org/jira/browse/IGNITE-16636
> Project: Ignite
>  Issue Type: Improvement
>  Components: rest
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> We usually use a lock to make sure that
>  # A stop request does not interfere with the component service requests 
> started before the stop request
>  # When a stop request starts being executed, no service request can be 
> executed anymore
> It probably makes sense to implement the same logic in RestComponent as well.



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

[jira] [Updated] (IGNITE-16609) Thin 3.0: Design Cluster Discovery for Java thin client



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

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

> Thin 3.0: Design Cluster Discovery for Java thin client
> ---
>
> Key: IGNITE-16609
> URL: https://issues.apache.org/jira/browse/IGNITE-16609
> Project: Ignite
>  Issue Type: New Feature
>  Components: thin client
>Affects Versions: 3.0.0-alpha4
>Reporter: Igor Sapego
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> We should design and implement a mechanism for thin clients that will provide 
> them with ability to discover nodes in cluster.
> My thoughts on the matter: 
> If we implement this approach (which should be a default I belive) then 
> initial addresses provided to thin client by a user should only be used to 
> establish the first connection to a node of the cluster. After that, thin 
> client should request full list of active nodes of the cluster and use them 
> instead of the initial list to establish new connections.
> The problems that should be considered during desing and implementation steps:
> - How should clients be notified about changes in cluster (should clients 
> send requests for that or should server issue notifications);
> - How should clients handle a situation when they can not reach cluster nodes 
> by addresses provided by server.
> - How should clients behave on connection to nodes from different clusters.
> - How should clients handle different states of the cluster lifecycle.
> These problems should be probably addressed in separate tickets. In this 
> case, those ticket should be created and linked to the current ticket.



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

[jira] [Updated] (IGNITE-16747) Avoid user tasks in following future stages blocking system threads



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

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

> Avoid user tasks in following future stages blocking system threads
> ---
>
> Key: IGNITE-16747
> URL: https://issues.apache.org/jira/browse/IGNITE-16747
> Project: Ignite
>  Issue Type: Improvement
>  Components: compute
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> User job is executed in a dedicated thread pool. We return a 
> CompletableFuture to which the user may add more stages. These stages could 
> still be executed in the same Compute dedicated thread pool, so if a 
> follow-up stages of the returned future run some heavy tasks, they can 
> potentially block the job execution thread pool which may be a problem.



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

[jira] [Updated] (IGNITE-16770) Add a public API method to get cluster nodes



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

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

> Add a public API method to get cluster nodes
> 
>
> Key: IGNITE-16770
> URL: https://issues.apache.org/jira/browse/IGNITE-16770
> Project: Ignite
>  Issue Type: Improvement
>  Components: networking
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>




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

[jira] [Updated] (IGNITE-16782) Revision of work with InternalTableImpl#partitionMap



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

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

> Revision of work with InternalTableImpl#partitionMap
> 
>
> Key: IGNITE-16782
> URL: https://issues.apache.org/jira/browse/IGNITE-16782
> Project: Ignite
>  Issue Type: Bug
>Reporter: Kirill Tkalenko
>Assignee: Vladislav Pyatkov
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> During development, I discovered that we have 
> *org.apache.ignite.internal.table.distributed.storage.InternalTableImpl#partitionMap*
>  and 
> *org.apache.ignite.internal.table.distributed.storage.InternalTableImpl#updatePartMapMux*
>  that do not always go together, which can cause problems when changing this 
> map in parallel and reading it.
>  
> It seems we can eliminate some of the concurrency issues using a 
> ConcurrentHashMap instead of Int2ObjectMap. But to eliminate all of the 
> concurrency issues need to more complex investigation.



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

[jira] [Updated] (IGNITE-16845) RocksSnapshotManager#snapshotIterator() leaks ReadOptions



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

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

> RocksSnapshotManager#snapshotIterator() leaks ReadOptions
> -
>
> Key: IGNITE-16845
> URL: https://issues.apache.org/jira/browse/IGNITE-16845
> Project: Ignite
>  Issue Type: Bug
>  Components: persistence
>Reporter: Roman Puchkovskiy
>Priority: Minor
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>




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

[jira] [Updated] (IGNITE-16925) Thin 3.0: Add partition awareness to executeColocated



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

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

> Thin 3.0: Add partition awareness to executeColocated
> -
>
> Key: IGNITE-16925
> URL: https://issues.apache.org/jira/browse/IGNITE-16925
> Project: Ignite
>  Issue Type: Improvement
>  Components: clients
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> 1. Compute key hash on the client
> 2. Retrieve and maintain up-to-date partitionMap
> 2. Send the request directly to the target node if a connection exists



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

[jira] [Updated] (IGNITE-17010) Move sql It*Test from [Modele Runner] to a separate suite on TeamCity



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

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

> Move sql It*Test from [Modele Runner] to a separate suite on TeamCity
> -
>
> Key: IGNITE-17010
> URL: https://issues.apache.org/jira/browse/IGNITE-17010
> Project: Ignite
>  Issue Type: Task
>Reporter: Kirill Tkalenko
>Assignee: Petr Ivanov
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> At the moment, [[Module] 
> Runner|https://ci.ignite.apache.org/viewType.html?buildTypeId=ignite3_Test_IntegrationTests_ModuleRunner=buildTypeStatusDiv_ignite3_Test_IntegrationTests=__all_branches__]
>  can take more than 20 minutes, not a small part of this time is spent on 
> testing modules related to the SQL. 
> I propose to take out the SQL tests in a separate suite, we can make a 
> selection by following packages:
> * *org.apache.ignite.internal.sql.engine*
> * *org.apache.ignite.internal.runner.app.jdbc*
> * *org.apache.ignite.internal.sql*



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

[jira] [Updated] (IGNITE-16928) Thin 3.0: Implement sessions for Java client



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

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

> Thin 3.0: Implement sessions for Java client
> 
>
> Key: IGNITE-16928
> URL: https://issues.apache.org/jira/browse/IGNITE-16928
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms, thin client
>Affects Versions: 3.0.0-alpha4
>Reporter: Igor Sapego
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: iep-90, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Let's implement local sessions for Java client.
> Sessions AKA logical connections are described in 
> https://cwiki.apache.org/confluence/display/IGNITE/IEP-90+Client+Lifecycle.
> What needs to be implemented is:
> 1. On handshake server should generate a Connection ID and return it in 
> HandshakeRsp;
> 2. Client should save a Connection ID and associate it with a node it 
> connected to;
> 3. If disconnected, server should not at once clean up connection associated 
> data but start timer instead. Timeout should be configurable by server config;
> 4. If client manages to send a proper ConnectionRestoreReq during timeout, 
> the session is restored;
> 5. All results of all operations that were complete while physical connection 
> is broken is stored within session data and sent back to client if connection 
> is restored.



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

[jira] [Updated] (IGNITE-16990) .NET: Thin 3.0: Add partition awareness to ExecuteColocated



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

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

> .NET: Thin 3.0: Add partition awareness to ExecuteColocated
> ---
>
> Key: IGNITE-16990
> URL: https://issues.apache.org/jira/browse/IGNITE-16990
> Project: Ignite
>  Issue Type: Improvement
>  Components: clients
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>
> 1. Compute key hash on the client
> 2. Retrieve and maintain up-to-date partitionMap
> 2. Send the request directly to the target node if a connection exists



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

[jira] [Updated] (IGNITE-16929) .NET: Thin 3.0: Implement sessions for .NET thin client



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

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

> .NET: Thin 3.0: Implement sessions for .NET thin client
> ---
>
> Key: IGNITE-16929
> URL: https://issues.apache.org/jira/browse/IGNITE-16929
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms, thin client
>Affects Versions: 3.0.0-alpha4
>Reporter: Igor Sapego
>Priority: Major
>  Labels: iep-90, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Let's implement sessions support for .NET client.



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

[jira] [Updated] (IGNITE-17017) [Native Persistence 3.0] Move "pageSize" to the common configuration of PageMemory storage engine



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

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

> [Native Persistence 3.0] Move "pageSize" to the common configuration of 
> PageMemory storage engine
> -
>
> Key: IGNITE-17017
> URL: https://issues.apache.org/jira/browse/IGNITE-17017
> Project: Ignite
>  Issue Type: Task
>Reporter: Kirill Tkalenko
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Move the *pageSize* into the common configuration for the *page-memory*, but 
> for this, at the beginning we need to implement a non-internal configuration 
> extension so that we can make a configuration for the *volatile* and the 
> *persistent* configuration of the *page-memory*.



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

[jira] [Updated] (IGNITE-17179) Thin 3.0: SQL metadata caching



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

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

> Thin 3.0: SQL metadata caching
> --
>
> Key: IGNITE-17179
> URL: https://issues.apache.org/jira/browse/IGNITE-17179
> Project: Ignite
>  Issue Type: Improvement
>  Components: thin client
>Affects Versions: 3.0.0-alpha5
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> We send query metadata to the client with every request (IGNITE-17052). It is 
> a waste of resources when the same query is executed frequently.
> * Cache metadata on server, generate unique ID
> * Return the ID to the client
> * Client retrieves cached metadata from server when not known, caches it 
> locally
> However, some queries can be one-off and unique. The cache can grow too big 
> over the lifetime of the application.
> * Use the cache only for queries that have executed N times (detect this on 
> the server)
> * Limit cache size, use LRU eviction (client and server)
> Do not use query text as cache key - column types can change. Use the entire 
> metadata content to check cache entry equality.



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

[jira] [Updated] (IGNITE-17048) Some failing tests make other tests fail too



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

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

> Some failing tests make other tests fail too
> 
>
> Key: IGNITE-17048
> URL: https://issues.apache.org/jira/browse/IGNITE-17048
> Project: Ignite
>  Issue Type: Bug
>Reporter: Aleksandr Polovtcev
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Looks like after some tests fail, they do not correctly free the used ports, 
> because other tests start to fail with a "Failed to start the connection 
> manager: No available port in range [3346-3346]" message.
> This error occurs due to previous test failing to stop a node with 
> AssertionError "Raft groups are still running 
> [602f614c-9d19-4467-bcdf-d248d9e3a410_part_1, 
> 602f614c-9d19-4467-bcdf-d248d9e3a410_part_0, 
> 602f614c-9d19-4467-bcdf-d248d9e3a410_part_6, 
> 602f614c-9d19-4467-bcdf-d248d9e3a410_part_4, 
> 602f614c-9d19-4467-bcdf-d248d9e3a410_part_3, 
> 602f614c-9d19-4467-bcdf-d248d9e3a410_part_8, 
> 602f614c-9d19-4467-bcdf-d248d9e3a410_part_7]"
> Example of a failed build: 
> https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_RunAllTests/6583070
> A possible solution might be to create a diagnostics tool that will print the 
> name of the process that occupies the blocked port.



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

[jira] [Updated] (IGNITE-17104) Organize the prevention of crossing the field PageIo#type



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

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

> Organize the prevention of crossing the field PageIo#type
> -
>
> Key: IGNITE-17104
> URL: https://issues.apache.org/jira/browse/IGNITE-17104
> Project: Ignite
>  Issue Type: Task
>Reporter: Kirill Tkalenko
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Problem:
> When adding a new heir to the 
> {*}org.apache.ignite.internal.pagememory.io.PageIo{*}, we need to determine 
> its {*}PageIo#type{*}, and at first glance it is not clear how to do this, 
> and when testing, it turns out that this type is already taken, which is not 
> convenient. It is necessary to organize a mechanism / methodology for how to 
> do this, since at the moment the next one from all known ones is simply 
> taken. Also, don't forget that these types can be added via modules/plugins.
>  
> Implementation thoughts:
>  * For each structure, we reserve a range of 50 types, and then we get about 
> 1310 (65535 / 50) possible structures, which should be enough;
>  * Somewhere to keep a register of structures to minimize their intersection, 
> for example, make it look like [Community edition features 
> list|https://ggsystems.atlassian.net/wiki/spaces/GG/pages/1192198276/Community+edition+features+list].



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

[jira] [Updated] (IGNITE-17134) Thin 3.0: Implement client SQL session management



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

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

> Thin 3.0: Implement client SQL session management
> -
>
> Key: IGNITE-17134
> URL: https://issues.apache.org/jira/browse/IGNITE-17134
> Project: Ignite
>  Issue Type: Improvement
>  Components: sql, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Minor
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Close all active cursors and cancel queries when client SQL session is closed 



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

[jira] [Updated] (IGNITE-17167) Simplify the configuration asm generator



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

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

> Simplify the configuration asm generator
> 
>
> Key: IGNITE-17167
> URL: https://issues.apache.org/jira/browse/IGNITE-17167
> Project: Ignite
>  Issue Type: Task
>Reporter: Kirill Tkalenko
>Priority: Major
>  Labels: iep-55, ignite-3, technical-debt
> Fix For: 3.0.0-beta2
>
>
> At the moment, the 
> *org.apache.ignite.internal.configuration.asm.ConfigurationAsmGenerator* 
> looks complicated due to the addition of internal, polymorphic and abstract 
> configuration, the code has become harder to read and edit.
> It is proposed to think about how and to divide this class into methods or 
> subclasses for each type of configuration.



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

[jira] [Updated] (IGNITE-17166) Simplify the configuration annotation processor



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

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

> Simplify the configuration annotation processor
> ---
>
> Key: IGNITE-17166
> URL: https://issues.apache.org/jira/browse/IGNITE-17166
> Project: Ignite
>  Issue Type: Task
>Reporter: Kirill Tkalenko
>Priority: Major
>  Labels: iep-55, ignite-3, technical-debt
> Fix For: 3.0.0-beta2
>
>
> At the moment, the 
> *org.apache.ignite.internal.configuration.processor.Processor* looks 
> complicated due to the addition of internal, polymorphic and abstract 
> configuration, the code has become harder to read and edit.
> It is proposed to think about how and to divide this class into methods or 
> subclasses for each type of configuration.
> It would also be nice to write validation for class fields, for example that 
> a field (if not static) can only have one of the annotations *Value*, 
> *ConfigValue* and *NamedConfigValue*, etc.



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

[jira] [Updated] (IGNITE-17197) Change the default storage engine (for tables)



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

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

> Change the default storage engine (for tables)
> --
>
> Key: IGNITE-17197
> URL: https://issues.apache.org/jira/browse/IGNITE-17197
> Project: Ignite
>  Issue Type: Task
>Reporter: Sergey Uttsel
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Currently the default pagememory storage doesn't support MVCC. So it doesn't 
> fit to the transaction protocol. Only RocksDbTableStorage supports now. So 
> after RocksDbTableStorage was integrated in 
> https://issues.apache.org/jira/browse/IGNITE-16881 the 
> TablesConfigurationSchema#defaultDataStorage was set to "rocksdb" and some 
> tests were disabled.
> Need to:
>  # implement MvTableStorage and MvPartitionStorage by other storages.
>  # set TablesConfigurationSchema#defaultDataStorage to "pagememory" or other 
> storage.
>  # enable tests marked by "IGNITE-17197"
>  # check other places marked by IGNITE-17197"



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

[jira] [Updated] (IGNITE-17224) Support eviction for volatile (in-memory) data region



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

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

> Support eviction for volatile (in-memory) data region
> -
>
> Key: IGNITE-17224
> URL: https://issues.apache.org/jira/browse/IGNITE-17224
> Project: Ignite
>  Issue Type: Bug
>Reporter: Kirill Tkalenko
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> I found that the volatile (in memory) data region contains a configuration 
> for eviction, but does not implement it, you need to implement it by analogy 
> with 2.0 and write tests for it. We also need to consider validation for a 
> configuration intended to be evicted.
> See in 3.0:
> * 
> *org.apache.ignite.internal.pagememory.configuration.schema.VolatilePageMemoryDataRegionConfigurationSchema*
> * *org.apache.ignite.internal.storage.pagememory.VolatilePageMemoryDataRegion*
> * *org.apache.ignite.internal.pagememory.inmemory.VolatilePageMemory*
> See in 2.0:
> * 
> *org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager#ensureFreeSpace*
> * 
> *org.apache.ignite.internal.processors.cache.persistence.IgniteCacheDatabaseSharedManager#checkRegionEvictionProperties*



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

[jira] [Updated] (IGNITE-17232) Optimization of DeltaFilePageStore: write new pages directly to FilePageStore



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

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

> Optimization of DeltaFilePageStore: write new pages directly to FilePageStore
> -
>
> Key: IGNITE-17232
> URL: https://issues.apache.org/jira/browse/IGNITE-17232
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> When creating *DelateFilePageStore* at checkpoint, we sort the list of all 
> dirty pages of the partition by *pageIdx*, write to disk the sorted list of 
> *pageIdx* (for *pageId -> pageIdx* binary lookup), the contents of the dirty 
> pages, and the current *pageIdx* of the page allocations.
> I propose to optimize this a bit. 
> In *DelateFilePageStore*, store only changes in existing pages, and write all 
> new pages immediately to *FilePageStore*, so we will reduce the work for the 
> compacter (it will need to write less to the main partition file) and the 
> sorted list of *pageIdx* will be smaller.
> Since the allocation index becomes logical (which is stored in the 
> *FilePageStore*) and depends on the first (newest) *DelateFilePageStore*, 
> then if the checkpoint is not completed, we will not lose or break anything 
> in the *FilePageStore* and on the new checkpoint we will write new pages on 
> over of those that we write on the unfinished previous checkpoint.



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

[jira] [Updated] (IGNITE-17211) Nested polymorphic configuration cannot be without a default type



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

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

> Nested polymorphic configuration cannot be without a default type
> -
>
> Key: IGNITE-17211
> URL: https://issues.apache.org/jira/browse/IGNITE-17211
> Project: Ignite
>  Issue Type: Bug
>Reporter: Kirill Tkalenko
>Priority: Major
>  Labels: iep-55, ignite-3, tech-debt
> Fix For: 3.0.0-beta2
>
>
> *Problem*
> If the polymorphic configuration is nested (sub), then when trying to create 
> an instance of the configuration, we will receive the error *Polymorphic 
> configuration type is not defined*, since the type of the polymorphic 
> configuration is not known and can be changed in the future, in order to get 
> around this limitation, you have to set the default type, which may not 
> always be correct.
> *Stack trace example:*
> {noformat}
> Caused by: java.lang.IllegalStateException: Polymorphic configuration type is 
> not defined: 
> org.apache.ignite.configuration.schemas.table.ColumnDefaultConfigurationSchema.
>  See @PolymorphicConfig documentation.
>   at 
> org.apache.ignite.configuration.schemas.table.ColumnNode.construct(Unknown 
> Source)
>   at 
> org.apache.ignite.internal.configuration.util.ConfigurationUtil$3.visitInnerNode(ConfigurationUtil.java:327)
>   at 
> org.apache.ignite.configuration.schemas.table.ColumnNode.traverseChildren(Unknown
>  Source)
>   at 
> org.apache.ignite.internal.configuration.util.ConfigurationUtil.addDefaults(ConfigurationUtil.java:308)
>   at 
> org.apache.ignite.internal.configuration.tree.NamedListNode.newElementDescriptor(NamedListNode.java:492)
>   at 
> org.apache.ignite.internal.configuration.tree.NamedListNode.create(NamedListNode.java:156)
> {noformat}
> *Configuration scheme example:*
> {code:java}
> @ConfigurationRoot(rootName = "parent", type = LOCAL)
> public static class ParentConfigurationSchema {
> @ConfigValue
> public ChildConfigurationSchema child;
> }
> @PolymorphicConfig
> public static class ChildConfigurationSchema {
> public static final String FIRST = "first";
> public static final String SECOND = "second";
> // When creating a configuration instance, there will be an error if 
> there is no default value.
> @PolymorphicId
> public String type;
> }
> @PolymorphicConfigInstance(ChildConfigurationSchema.FIRST)
> public static class FirstChildConfigurationSchema extends 
> ChildConfigurationSchema {
> }
> @PolymorphicConfigInstance(ChildConfigurationSchema.SECOND)
> public static class SecondChildConfigurationSchema extends 
> ChildConfigurationSchema {
> }
> {code}
> *Notes on a possible implementation*
> * We can consider weakening the condition of necessarily polymorphic 
> configuration type at the stage of adding default values for configuration 
> fields, you can see here 
> *org.apache.ignite.internal.configuration.util.ConfigurationUtil#addDefaults*.



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

[jira] [Updated] (IGNITE-17235) Fix flaky ItBplusTreePageMemoryImplTest#testPutSizeLivelock



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

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

> Fix flaky ItBplusTreePageMemoryImplTest#testPutSizeLivelock
> ---
>
> Key: IGNITE-17235
> URL: https://issues.apache.org/jira/browse/IGNITE-17235
> Project: Ignite
>  Issue Type: Bug
>Reporter: Kirill Tkalenko
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> It is necessary to investigate and fix the falling flaky  
> [ItBplusTreePageMemoryImplTest#testPutSizeLivelock|https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_RunAllTests/6647751?logFilter=debug]
>  test.



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

[jira] [Updated] (IGNITE-17231) Optimization of DeltaFilePageStore: improve mapping of pageIdx to file offset



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

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

> Optimization of DeltaFilePageStore: improve mapping of pageIdx to file offset
> -
>
> Key: IGNITE-17231
> URL: https://issues.apache.org/jira/browse/IGNITE-17231
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> For ease of implementation, a sorted list of *pageIdx* has been added to the 
> *DeltaFilePageStore*, thereby allowing a binary search to find a *pageId -> 
> pageIdx*.
> Perhaps this is not quite optimal, and it can be optimized.
> It is important that we need to find a balance between memory usage and 
> *pageId* lookup speed, since the *DeltaFilePageStore* class can be many (very 
> many) due to the fact that it depends on the checkpoint, compacter, number of 
> partitions and number of groups.
> Before implementation, we need to study the options in more depth and perhaps 
> try a few of them.
> What can we consider:
> * roaring map - this needs to be carefully studied;
> * list of containers (idea) - there are 3 types of container, the first is a 
> bitmask, the second is value intervals (provided that the values are greater 
> than 64 (two integers)), the third is a sorted list (or hash map); then by 
> binary search we find the container (by the first *pageIdx* in this 
> container) and then we query the container.



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

[jira] [Updated] (IGNITE-17319) Remove entries replicated to all nodes from RAFT log in in-memory scenario



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

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

> Remove entries replicated to all nodes from RAFT log in in-memory scenario
> --
>
> Key: IGNITE-17319
> URL: https://issues.apache.org/jira/browse/IGNITE-17319
> Project: Ignite
>  Issue Type: Improvement
>  Components: persistence
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> TBD



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

[jira] [Updated] (IGNITE-17335) Off-heap storage for RAFT log



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

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

> Off-heap storage for RAFT log
> -
>
> Key: IGNITE-17335
> URL: https://issues.apache.org/jira/browse/IGNITE-17335
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> In IGNITE-17334, we'll build a volatile log storage using a simple on-heap 
> data structure. We need to replace it with an off-heap structure (probably, 
> using page memory) to avoid GC pressure.
> When using page memory, we could allocate a single region for all RAFT 
> groups' log storages and allocate some memory budget to each RAFT group.
> The description is not too precise, some research is needed.



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

[jira] [Updated] (IGNITE-17239) Divide [Module] Page Memory into 2



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

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

> Divide [Module] Page Memory into 2
> --
>
> Key: IGNITE-17239
> URL: https://issues.apache.org/jira/browse/IGNITE-17239
> Project: Ignite
>  Issue Type: Task
>Reporter: Kirill Tkalenko
>Assignee: Petr Ivanov
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> To speed up the tests, it would be good to divide [[Module] Page 
> Memory|https://ci.ignite.apache.org/viewType.html?buildTypeId=ignite3_Test_IntegrationTests_ModulePageMemory_ignite3_Test_IntegrationTests=%3Cdefault%3E=buildTypeStatusDiv]
>  by 2:
> * [Module] Page Memory Volatile:
> ** ItBplusTreeReplaceRemoveRaceTest.*
> ** ItBplusTreeFakeReuseVolatilePageMemoryTest.*
> ** ItBplusTreeReuseVolatilePageMemoryTest.*
> ** ItBplusTreeVolatilePageMemoryTest.*
> * [Module] Page Memory Persistent:
> ** ItBplusTreePersistentPageMemoryTest.*
> ** ItBplusTreeReuseListPersistentPageMemoryTest.*



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

[jira] [Updated] (IGNITE-17397) Investigate the ability to read a empty page in FilePageStore



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

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

> Investigate the ability to read a empty page in FilePageStore
> -
>
> Key: IGNITE-17397
> URL: https://issues.apache.org/jira/browse/IGNITE-17397
> Project: Ignite
>  Issue Type: Task
>Reporter: Kirill Tkalenko
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> I found that in *FilePageStore#read(long, java.nio.ByteBuffer, boolean)* 
> there may be a situation that we allocated the page without writing it to 
> disk, tried to read it and instead of an error, we simply write an empty page 
> to the buffer.
> It is necessary to understand better the reason for this behavior and either 
> comment on this moment or redo it.



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

[jira] [Updated] (IGNITE-17446) Determine priority between checkpoint and merge delta files



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

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

> Determine priority between checkpoint and merge delta files
> ---
>
> Key: IGNITE-17446
> URL: https://issues.apache.org/jira/browse/IGNITE-17446
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Kirill Tkalenko
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> When creating delta files in parallel and merging them with the main 
> partition file, the write amplification may increase, and they may begin to 
> interfere with each other. 
> In RocksDb, these processes run in parallel, but checkpoint threads have 
> higher thread priority. 
> I think it can be done by analogy, but without thread priorities, but with 
> slowing down the threads of the delta file merge.



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

[jira] [Updated] (IGNITE-17337) Support limiting volatile RAFT log memory by total entries size



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

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

> Support limiting volatile RAFT log memory by total entries size
> ---
>
> Key: IGNITE-17337
> URL: https://issues.apache.org/jira/browse/IGNITE-17337
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> In IGNITE-17334, we'll build a simple volatile RAFT log storage.
> Here, we need to add ability to judge whether we can accept more entries to 
> the in-memory region based on entries total size.



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

[jira] [Updated] (IGNITE-17343) .NET: Thin 3.0: LINQ provider



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

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

> .NET: Thin 3.0: LINQ provider
> -
>
> Key: IGNITE-17343
> URL: https://issues.apache.org/jira/browse/IGNITE-17343
> Project: Ignite
>  Issue Type: New Feature
>  Components: thin client
>Affects Versions: 3.0.0-beta1
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Add LINQ to SQL provider to Ignite 3.x thin client.
> * Adapt 2.x code to Calcite SQL flavor.
> * Make it async.



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

[jira] [Updated] (IGNITE-17497) Support inheritance of polymorphic configurations



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

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

> Support inheritance of polymorphic configurations
> -
>
> Key: IGNITE-17497
> URL: https://issues.apache.org/jira/browse/IGNITE-17497
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Currently, polymorphic configuration schemas must have exactly one parent 
> class (not Object).
> It is suggested to implement the following logic:
>  # Top config schema must be annotated with PolymorphicConfig (it already 
> works as described here, so nothing needs to be done)
>  # Leaf config schema must be annotated with PolymorphicConfigInstance (it 
> already works as described here, so nothing needs to be done)
>  # Intermediary config schema classes (extending, directly or indirectly, the 
> top config schema and extended, directly or indirectly by leaf config 
> schemas) are allowed. They do not need to be annotated.



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

[jira] [Updated] (IGNITE-17516) Support fields with same name in different members of dynamic config hierarcny



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

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

> Support fields with same name in different members of dynamic config hierarcny
> --
>
> Key: IGNITE-17516
> URL: https://issues.apache.org/jira/browse/IGNITE-17516
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> In IGNITE-17497, an ability to have more than 2 levels of polymorphic 
> configuration classes (base and instance) is introduced. This means that 
> fields with same name might present on several levels of hierarchy. 
> Currently, it's not clear whether it's supported (as we have 2 levels, more 
> than one) or forbidden.



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

[jira] [Updated] (IGNITE-17560) Parameterize raft log spill-out in configuration



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

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

> Parameterize raft log spill-out in configuration
> 
>
> Key: IGNITE-17560
> URL: https://issues.apache.org/jira/browse/IGNITE-17560
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> In VolatileLogStorageFactoryCreator, a lot of parameters related to spill-out 
> RocksDB are hard-coded. They probably need to be adjustable via configuration 
> mechanism.



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

[jira] [Updated] (IGNITE-17540) Create error codes for volatile raft configuration



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

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

> Create error codes for volatile raft configuration
> --
>
> Key: IGNITE-17540
> URL: https://issues.apache.org/jira/browse/IGNITE-17540
> Project: Ignite
>  Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
>  Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> VolatileLogStorageFactory throws deprecated IgniteInternalException without 
> error codes. Explicit error codes need to be used.



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

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



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

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

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



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

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

Vyacheslav Koptilin 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: 5h
>  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-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:all-tabpanel
 ]

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

> 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-beta2
>
>
> 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] [Updated] (IGNITE-17750) .NET: Thin 3.0: Implement Partition Awareness



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

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

> .NET: Thin 3.0: Implement Partition Awareness
> -
>
> Key: IGNITE-17750
> URL: https://issues.apache.org/jira/browse/IGNITE-17750
> Project: Ignite
>  Issue Type: New Feature
>  Components: platforms, thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: .NET, iep-95, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Implement partition awareness in .NET client. See reference implementation in 
> Java: IGNITE-17725



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

[jira] [Updated] (IGNITE-17821) Thin 3.0 Perf: Implement BinaryTupleReader and Builder over ByteBuf



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

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

> Thin 3.0 Perf: Implement BinaryTupleReader and Builder over ByteBuf
> ---
>
> Key: IGNITE-17821
> URL: https://issues.apache.org/jira/browse/IGNITE-17821
> Project: Ignite
>  Issue Type: Improvement
>  Components: thin client
>Reporter: Pavel Tupitsyn
>Assignee: Pavel Tupitsyn
>Priority: Major
>  Labels: iep-92, ignite-3
> Fix For: 3.0.0-beta2
>
>
> Client protocol uses *BinaryTuple* for data transfer (rows, compute args, 
> etc). In many cases we need to read or write *BinaryTuple* from/to *ByteBuf*. 
> Currently this requires conversion between Netty *ByteBuf* to NIO 
> *ByteBuffer*, sometimes involving buffer copy operations (see 
> *ClientMessageUnpacker.readBinaryUnsafe*, 
> *ClientMessagePacker.packBinaryTuple* and their usages).
> Implement BinaryTuple reader and writer that work directly with Netty ByteBuf.



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

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