[jira] [Updated] (IGNITE-17406) SQL "select by key" performance 50-60 times slower than key-value get
[ https://issues.apache.org/jira/browse/IGNITE-17406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Gusakov updated IGNITE-17406: Attachment: cpu.html > SQL "select by key" performance 50-60 times slower than key-value get > - > > Key: IGNITE-17406 > URL: https://issues.apache.org/jira/browse/IGNITE-17406 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Priority: Major > Attachments: cpu.html > > > During the https://issues.apache.org/jira/browse/IGNITE-17220 benchmarks runs > we found out, that YCSB benchmarks show very slow performance. > 1. After some investigations under > https://issues.apache.org/jira/browse/IGNITE-17379 we found out, that SQL > select by key performance significantly slower, than the same key-value get: > 1-2ms vs 40-50ms. > Step to reproduce: > * clone branch > [https://github.com/gridgain/apache-ignite-3/tree/ignite-17379] > * run test ItBenchmarkTest#testYCSBLikeKV > 2. Also, at the same time it looks like performance degradation depends on > the size of table data > Step to reproduce: > * run the test ItBenchmarkTest#testReadDegradationSqlApi > > According to these points, it seems that the cause of these issues: "rocksdb > full scan and post-filtering" pattern, which we are using in SQL API (fix me, > if I'm wrong). You can check async-profile cpu flamegraph from the benchmarks > run on my machine (RocksIterator#seek0 column, I guess) > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-15931) Implement storage for tx states
[ https://issues.apache.org/jira/browse/IGNITE-15931?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569495#comment-17569495 ] Alexander Lapin commented on IGNITE-15931: -- [~Denis Chudov] LGTM > Implement storage for tx states > --- > > Key: IGNITE-15931 > URL: https://issues.apache.org/jira/browse/IGNITE-15931 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Scherbakov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3, transaction3_rw > > Occurred that ParitionStorage will be removed soon, so it's required to > implement explicit tx state persistent storage. Generally speaking it'll > store map of txId to transaction meta, that will include > txnState(committed/aborted), list of enlisted partition ids and commit > timestamp. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15931) Implement storage for tx states
[ https://issues.apache.org/jira/browse/IGNITE-15931?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-15931: - Reviewer: Alexander Lapin > Implement storage for tx states > --- > > Key: IGNITE-15931 > URL: https://issues.apache.org/jira/browse/IGNITE-15931 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Scherbakov >Assignee: Denis Chudov >Priority: Major > Labels: ignite-3, transaction3_rw > > Occurred that ParitionStorage will be removed soon, so it's required to > implement explicit tx state persistent storage. Generally speaking it'll > store map of txId to transaction meta, that will include > txnState(committed/aborted), list of enlisted partition ids and commit > timestamp. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17406) SQL "select by key" performance 50-60 times slower than key-value get
Kirill Gusakov created IGNITE-17406: --- Summary: SQL "select by key" performance 50-60 times slower than key-value get Key: IGNITE-17406 URL: https://issues.apache.org/jira/browse/IGNITE-17406 Project: Ignite Issue Type: Task Reporter: Kirill Gusakov During the https://issues.apache.org/jira/browse/IGNITE-17220 benchmarks runs we found out, that YCSB benchmarks show very slow performance. 1. After some investigations under https://issues.apache.org/jira/browse/IGNITE-17379 we found out, that SQL select by key performance significantly slower, than the same key-value get: 1-2ms vs 40-50ms. Step to reproduce: * clone branch [https://github.com/gridgain/apache-ignite-3/tree/ignite-17379] * run test ItBenchmarkTest#testYCSBLikeKV 2. Also, at the same time it looks like performance degradation depends on the size of table data Step to reproduce: * run the test ItBenchmarkTest#testReadDegradationSqlApi According to these points, it seems that the cause of these issues: "rocksdb full scan and post-filtering" pattern, which we are using in SQL API (fix me, if I'm wrong). You can check async-profile cpu flamegraph from the benchmarks run on my machine (RocksIterator#seek0 column, I guess) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17403) SQL "select by key" performance 50-60 times slower than key-value get
Kirill Gusakov created IGNITE-17403: --- Summary: SQL "select by key" performance 50-60 times slower than key-value get Key: IGNITE-17403 URL: https://issues.apache.org/jira/browse/IGNITE-17403 Project: Ignite Issue Type: Task Reporter: Kirill Gusakov During the https://issues.apache.org/jira/browse/IGNITE-17220 benchmarks runs we found out, that YCSB benchmarks show very slow performance. 1. After some investigations under https://issues.apache.org/jira/browse/IGNITE-17379 we found out, that SQL select by key performance significantly slower, than the same key-value get: 1-2ms vs 40-50ms. Step to reproduce: * clone branch [https://github.com/gridgain/apache-ignite-3/tree/ignite-17379] * run test ItBenchmarkTest#testYCSBLikeKV 2. Also, at the same time it looks like performance degradation depends on the size of table data Step to reproduce: * run the test ItBenchmarkTest#testReadDegradationSqlApi According to these points, it seems that the cause of these issues: "rocksdb full scan and post-filtering" pattern, which we are using in SQL API (fix me, if I'm wrong). You can check async-profile cpu flamegraph from the benchmarks run on my machine (RocksIterator#seek0 column, I guess) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17405) SQL "select by key" performance 50-60 times slower than key-value get
Kirill Gusakov created IGNITE-17405: --- Summary: SQL "select by key" performance 50-60 times slower than key-value get Key: IGNITE-17405 URL: https://issues.apache.org/jira/browse/IGNITE-17405 Project: Ignite Issue Type: Task Reporter: Kirill Gusakov During the https://issues.apache.org/jira/browse/IGNITE-17220 benchmarks runs we found out, that YCSB benchmarks show very slow performance. 1. After some investigations under https://issues.apache.org/jira/browse/IGNITE-17379 we found out, that SQL select by key performance significantly slower, than the same key-value get: 1-2ms vs 40-50ms. Step to reproduce: * clone branch [https://github.com/gridgain/apache-ignite-3/tree/ignite-17379] * run test ItBenchmarkTest#testYCSBLikeKV 2. Also, at the same time it looks like performance degradation depends on the size of table data Step to reproduce: * run the test ItBenchmarkTest#testReadDegradationSqlApi According to these points, it seems that the cause of these issues: "rocksdb full scan and post-filtering" pattern, which we are using in SQL API (fix me, if I'm wrong). You can check async-profile cpu flamegraph from the benchmarks run on my machine (RocksIterator#seek0 column, I guess) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17404) SQL "select by key" performance 50-60 times slower than key-value get
Kirill Gusakov created IGNITE-17404: --- Summary: SQL "select by key" performance 50-60 times slower than key-value get Key: IGNITE-17404 URL: https://issues.apache.org/jira/browse/IGNITE-17404 Project: Ignite Issue Type: Task Reporter: Kirill Gusakov During the https://issues.apache.org/jira/browse/IGNITE-17220 benchmarks runs we found out, that YCSB benchmarks show very slow performance. 1. After some investigations under https://issues.apache.org/jira/browse/IGNITE-17379 we found out, that SQL select by key performance significantly slower, than the same key-value get: 1-2ms vs 40-50ms. Step to reproduce: * clone branch [https://github.com/gridgain/apache-ignite-3/tree/ignite-17379] * run test ItBenchmarkTest#testYCSBLikeKV 2. Also, at the same time it looks like performance degradation depends on the size of table data Step to reproduce: * run the test ItBenchmarkTest#testReadDegradationSqlApi According to these points, it seems that the cause of these issues: "rocksdb full scan and post-filtering" pattern, which we are using in SQL API (fix me, if I'm wrong). You can check async-profile cpu flamegraph from the benchmarks run on my machine (RocksIterator#seek0 column, I guess) -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17385) Frequent commits of single cache transactions can lead GridCacheAdapter#asyncOpsSem permits overflow
[
https://issues.apache.org/jira/browse/IGNITE-17385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Timonin updated IGNITE-17385:
Reviewer: Ivan Daschinsky
> Frequent commits of single cache transactions can lead
> GridCacheAdapter#asyncOpsSem permits overflow
>
>
> Key: IGNITE-17385
> URL: https://issues.apache.org/jira/browse/IGNITE-17385
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Maksim Timonin
>Priority: Major
> Labels: ise
> Fix For: 2.14
>
> Attachments: SemaphorePermitsExceeded.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When you commit a transaction, which was _explicitly started only over a
> single cache_, then {{GridCacheAdapter#asyncOpRelease}} is called without
> {{GridCacheAdapter#asyncOpAcquire}}. This situation can lead to continuous
> grow of permits count in {{GridCacheAdapter#asyncOpsSem}} and to overflow
> with a further failure of node started the transaction:
> {code}
> Critical system error detected. Will be handled accordingly to configured
> handler
> [hnd=o.a.i.i.processors.cache.transactions.TxAsyncOpsSemaphorePermitsExeededTest$$Lambda$42/1924582348@7379bebb,
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=java.lang.Error: Maximum
> permit count exceeded]]
> {code}
> As you can see in [1], in case of the single cache context, transaction will
> be commited by calling of {{GridCacheAdapter#commitTxAsync}}, which invokes
> {{GridCacheAdapter#asyncOpRelease}} later. But, when multiple caches affected
> by transaction, {{GridNearTxLocal#commitNearTxLocalAsync}} is called to
> commit transaction, and no invokes of {{GridCacheAdapter#asyncOpRelease}}
> occur.
> So, the greater the load (RPS / TPS) with a such single cache transactions,
> the faster the failure of a node will happen.
> Reproducer of the problem: [^SemaphorePermitsExceeded.patch]. It prints
> additional messages, when semaphore is released, or acquired.
> Links:
> #
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheSharedContext.java#L1122
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17385) Frequent commits of single cache transactions can lead GridCacheAdapter#asyncOpsSem permits overflow
[
https://issues.apache.org/jira/browse/IGNITE-17385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569416#comment-17569416
]
Maksim Timonin commented on IGNITE-17385:
-
[~ivandasch] thanks for review! Merged to master
> Frequent commits of single cache transactions can lead
> GridCacheAdapter#asyncOpsSem permits overflow
>
>
> Key: IGNITE-17385
> URL: https://issues.apache.org/jira/browse/IGNITE-17385
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Maksim Timonin
>Priority: Major
> Labels: ise
> Fix For: 2.14
>
> Attachments: SemaphorePermitsExceeded.patch
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> When you commit a transaction, which was _explicitly started only over a
> single cache_, then {{GridCacheAdapter#asyncOpRelease}} is called without
> {{GridCacheAdapter#asyncOpAcquire}}. This situation can lead to continuous
> grow of permits count in {{GridCacheAdapter#asyncOpsSem}} and to overflow
> with a further failure of node started the transaction:
> {code}
> Critical system error detected. Will be handled accordingly to configured
> handler
> [hnd=o.a.i.i.processors.cache.transactions.TxAsyncOpsSemaphorePermitsExeededTest$$Lambda$42/1924582348@7379bebb,
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=java.lang.Error: Maximum
> permit count exceeded]]
> {code}
> As you can see in [1], in case of the single cache context, transaction will
> be commited by calling of {{GridCacheAdapter#commitTxAsync}}, which invokes
> {{GridCacheAdapter#asyncOpRelease}} later. But, when multiple caches affected
> by transaction, {{GridNearTxLocal#commitNearTxLocalAsync}} is called to
> commit transaction, and no invokes of {{GridCacheAdapter#asyncOpRelease}}
> occur.
> So, the greater the load (RPS / TPS) with a such single cache transactions,
> the faster the failure of a node will happen.
> Reproducer of the problem: [^SemaphorePermitsExceeded.patch]. It prints
> additional messages, when semaphore is released, or acquired.
> Links:
> #
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheSharedContext.java#L1122
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17278) TableManager#directTableIds can't be implemented effectively
[ https://issues.apache.org/jira/browse/IGNITE-17278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ivan Bessonov updated IGNITE-17278: --- Reviewer: Kirill Tkalenko > TableManager#directTableIds can't be implemented effectively > > > Key: IGNITE-17278 > URL: https://issues.apache.org/jira/browse/IGNITE-17278 > Project: Ignite > Issue Type: Improvement >Reporter: Ivan Bessonov >Assignee: Ivan Bessonov >Priority: Major > Labels: ignite-3 > Time Spent: 10m > Remaining Estimate: 0h > > I propose adding a special method "internalIds" to direct proxy, so that > there won't be the case for reading all tables. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17399) CDC: expiration of entries are not applied on destination cluster
[
https://issues.apache.org/jira/browse/IGNITE-17399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Timonin updated IGNITE-17399:
Fix Version/s: 2.14
> CDC: expiration of entries are not applied on destination cluster
> -
>
> Key: IGNITE-17399
> URL: https://issues.apache.org/jira/browse/IGNITE-17399
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Maksim Timonin
>Priority: Minor
> Labels: IEP-59, ise
> Fix For: 2.14
>
> Attachments: ExpiryCdcReproducer.patch
>
>
> There are two points, which should be noted:
> # Removes of entries on expiration are not captured by {{CdcConsumer}} and
> {{WalRecordsConsumer}}. So, removes are not propagated to a destination
> cluster.
> # Entries, which was put via the {{CdcEventsApplier}} are not expired in
> destination cluster, even if cache is configured with expiry policy.
> Reproducer: [^ExpiryCdcReproducer.patch]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17385) Frequent commits of single cache transactions can lead GridCacheAdapter#asyncOpsSem permits overflow
[
https://issues.apache.org/jira/browse/IGNITE-17385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569373#comment-17569373
]
Ivan Daschinsky commented on IGNITE-17385:
--
[~timonin.maksim] Looks good, please proceed with merge
> Frequent commits of single cache transactions can lead
> GridCacheAdapter#asyncOpsSem permits overflow
>
>
> Key: IGNITE-17385
> URL: https://issues.apache.org/jira/browse/IGNITE-17385
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Maksim Timonin
>Priority: Major
> Labels: ise
> Fix For: 2.14
>
> Attachments: SemaphorePermitsExceeded.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When you commit a transaction, which was _explicitly started only over a
> single cache_, then {{GridCacheAdapter#asyncOpRelease}} is called without
> {{GridCacheAdapter#asyncOpAcquire}}. This situation can lead to continuous
> grow of permits count in {{GridCacheAdapter#asyncOpsSem}} and to overflow
> with a further failure of node started the transaction:
> {code}
> Critical system error detected. Will be handled accordingly to configured
> handler
> [hnd=o.a.i.i.processors.cache.transactions.TxAsyncOpsSemaphorePermitsExeededTest$$Lambda$42/1924582348@7379bebb,
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=java.lang.Error: Maximum
> permit count exceeded]]
> {code}
> As you can see in [1], in case of the single cache context, transaction will
> be commited by calling of {{GridCacheAdapter#commitTxAsync}}, which invokes
> {{GridCacheAdapter#asyncOpRelease}} later. But, when multiple caches affected
> by transaction, {{GridNearTxLocal#commitNearTxLocalAsync}} is called to
> commit transaction, and no invokes of {{GridCacheAdapter#asyncOpRelease}}
> occur.
> So, the greater the load (RPS / TPS) with a such single cache transactions,
> the faster the failure of a node will happen.
> Reproducer of the problem: [^SemaphorePermitsExceeded.patch]. It prints
> additional messages, when semaphore is released, or acquired.
> Links:
> #
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheSharedContext.java#L1122
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17385) Frequent commits of single cache transactions can lead GridCacheAdapter#asyncOpsSem permits overflow
[
https://issues.apache.org/jira/browse/IGNITE-17385?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569370#comment-17569370
]
Ignite TC Bot commented on IGNITE-17385:
{panel:title=Branch: [pull/10160/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10160/head] Base: [master] : New Tests
(3)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Cache 13{color} [[tests
3|https://ci.ignite.apache.org/viewLog.html?buildId=6691365]]
* {color:#013220}IgniteCacheTestSuite13:
TxAsyncOpsSemaphorePermitsExceededTest.testSyncPutOps - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
TxAsyncOpsSemaphorePermitsExceededTest.testImplicitAsyncPutOps - PASSED{color}
* {color:#013220}IgniteCacheTestSuite13:
TxAsyncOpsSemaphorePermitsExceededTest.testAsyncPutOps - PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci.ignite.apache.org/viewLog.html?buildId=6688316buildTypeId=IgniteTests24Java8_RunAll]
> Frequent commits of single cache transactions can lead
> GridCacheAdapter#asyncOpsSem permits overflow
>
>
> Key: IGNITE-17385
> URL: https://issues.apache.org/jira/browse/IGNITE-17385
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Maksim Timonin
>Priority: Major
> Labels: ise
> Fix For: 2.14
>
> Attachments: SemaphorePermitsExceeded.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When you commit a transaction, which was _explicitly started only over a
> single cache_, then {{GridCacheAdapter#asyncOpRelease}} is called without
> {{GridCacheAdapter#asyncOpAcquire}}. This situation can lead to continuous
> grow of permits count in {{GridCacheAdapter#asyncOpsSem}} and to overflow
> with a further failure of node started the transaction:
> {code}
> Critical system error detected. Will be handled accordingly to configured
> handler
> [hnd=o.a.i.i.processors.cache.transactions.TxAsyncOpsSemaphorePermitsExeededTest$$Lambda$42/1924582348@7379bebb,
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=java.lang.Error: Maximum
> permit count exceeded]]
> {code}
> As you can see in [1], in case of the single cache context, transaction will
> be commited by calling of {{GridCacheAdapter#commitTxAsync}}, which invokes
> {{GridCacheAdapter#asyncOpRelease}} later. But, when multiple caches affected
> by transaction, {{GridNearTxLocal#commitNearTxLocalAsync}} is called to
> commit transaction, and no invokes of {{GridCacheAdapter#asyncOpRelease}}
> occur.
> So, the greater the load (RPS / TPS) with a such single cache transactions,
> the faster the failure of a node will happen.
> Reproducer of the problem: [^SemaphorePermitsExceeded.patch]. It prints
> additional messages, when semaphore is released, or acquired.
> Links:
> #
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheSharedContext.java#L1122
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17385) Frequent commits of single cache transactions can lead GridCacheAdapter#asyncOpsSem permits overflow
[
https://issues.apache.org/jira/browse/IGNITE-17385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Timonin updated IGNITE-17385:
Fix Version/s: 2.14
> Frequent commits of single cache transactions can lead
> GridCacheAdapter#asyncOpsSem permits overflow
>
>
> Key: IGNITE-17385
> URL: https://issues.apache.org/jira/browse/IGNITE-17385
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Maksim Timonin
>Priority: Major
> Labels: ise
> Fix For: 2.14
>
> Attachments: SemaphorePermitsExceeded.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When you commit a transaction, which was _explicitly started only over a
> single cache_, then {{GridCacheAdapter#asyncOpRelease}} is called without
> {{GridCacheAdapter#asyncOpAcquire}}. This situation can lead to continuous
> grow of permits count in {{GridCacheAdapter#asyncOpsSem}} and to overflow
> with a further failure of node started the transaction:
> {code}
> Critical system error detected. Will be handled accordingly to configured
> handler
> [hnd=o.a.i.i.processors.cache.transactions.TxAsyncOpsSemaphorePermitsExeededTest$$Lambda$42/1924582348@7379bebb,
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=java.lang.Error: Maximum
> permit count exceeded]]
> {code}
> As you can see in [1], in case of the single cache context, transaction will
> be commited by calling of {{GridCacheAdapter#commitTxAsync}}, which invokes
> {{GridCacheAdapter#asyncOpRelease}} later. But, when multiple caches affected
> by transaction, {{GridNearTxLocal#commitNearTxLocalAsync}} is called to
> commit transaction, and no invokes of {{GridCacheAdapter#asyncOpRelease}}
> occur.
> So, the greater the load (RPS / TPS) with a such single cache transactions,
> the faster the failure of a node will happen.
> Reproducer of the problem: [^SemaphorePermitsExceeded.patch]. It prints
> additional messages, when semaphore is released, or acquired.
> Links:
> #
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheSharedContext.java#L1122
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17385) Frequent commits of single cache transactions can lead GridCacheAdapter#asyncOpsSem permits overflow
[
https://issues.apache.org/jira/browse/IGNITE-17385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Timonin updated IGNITE-17385:
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> Frequent commits of single cache transactions can lead
> GridCacheAdapter#asyncOpsSem permits overflow
>
>
> Key: IGNITE-17385
> URL: https://issues.apache.org/jira/browse/IGNITE-17385
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Maksim Timonin
>Priority: Major
> Labels: ise
> Attachments: SemaphorePermitsExceeded.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When you commit a transaction, which was _explicitly started only over a
> single cache_, then {{GridCacheAdapter#asyncOpRelease}} is called without
> {{GridCacheAdapter#asyncOpAcquire}}. This situation can lead to continuous
> grow of permits count in {{GridCacheAdapter#asyncOpsSem}} and to overflow
> with a further failure of node started the transaction:
> {code}
> Critical system error detected. Will be handled accordingly to configured
> handler
> [hnd=o.a.i.i.processors.cache.transactions.TxAsyncOpsSemaphorePermitsExeededTest$$Lambda$42/1924582348@7379bebb,
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=java.lang.Error: Maximum
> permit count exceeded]]
> {code}
> As you can see in [1], in case of the single cache context, transaction will
> be commited by calling of {{GridCacheAdapter#commitTxAsync}}, which invokes
> {{GridCacheAdapter#asyncOpRelease}} later. But, when multiple caches affected
> by transaction, {{GridNearTxLocal#commitNearTxLocalAsync}} is called to
> commit transaction, and no invokes of {{GridCacheAdapter#asyncOpRelease}}
> occur.
> So, the greater the load (RPS / TPS) with a such single cache transactions,
> the faster the failure of a node will happen.
> Reproducer of the problem: [^SemaphorePermitsExceeded.patch]. It prints
> additional messages, when semaphore is released, or acquired.
> Links:
> #
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheSharedContext.java#L1122
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17399) CDC: expiration of entries are not applied on destination cluster
[
https://issues.apache.org/jira/browse/IGNITE-17399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Timonin updated IGNITE-17399:
Ignite Flags: Release Notes Required (was: Docs Required,Release Notes
Required)
> CDC: expiration of entries are not applied on destination cluster
> -
>
> Key: IGNITE-17399
> URL: https://issues.apache.org/jira/browse/IGNITE-17399
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Maksim Timonin
>Priority: Minor
> Labels: IEP-59, ise
> Attachments: ExpiryCdcReproducer.patch
>
>
> There are two points, which should be noted:
> # Removes of entries on expiration are not captured by {{CdcConsumer}} and
> {{WalRecordsConsumer}}. So, removes are not propagated to a destination
> cluster.
> # Entries, which was put via the {{CdcEventsApplier}} are not expired in
> destination cluster, even if cache is configured with expiry policy.
> Reproducer: [^ExpiryCdcReproducer.patch]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-16650) Exclude ignite-log4j, log4j 1.2.17
[
https://issues.apache.org/jira/browse/IGNITE-16650?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569348#comment-17569348
]
Amelchev Nikita commented on IGNITE-16650:
--
Merged into the master.
[~RyzhovSV], thank you for the initial contribution!
[~PetrovMikhail], thank you for the contribution!
> Exclude ignite-log4j, log4j 1.2.17
> --
>
> Key: IGNITE-16650
> URL: https://issues.apache.org/jira/browse/IGNITE-16650
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergei Ryzhov
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: important, ise
> Fix For: 2.14
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> log4j 1.2.17 is not supported and contains critical vulnerabilities
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> I suggest excluding the ignite-log4j module from ignite
> Direct vulnerabilities:
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23305
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23302
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4104
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17571
> As a result of the mentioned migration, the following changes will be applied:
> 1. ignite-log4j.xml will be migrated to log4j2 format. Unfortunately after
> the refactoring we will get two configuration ignite-log4j.xml and
> ignite-log4j2.xml both in log4j2 format because ignite-log4j2.xml is in use
> now and but provide log formatitng different from ignite-log4j.xml.
> 2. core/src/test/config/log4j-test.xml will not be migrated to log4j2 because
> it is used with compatibility tests.
> 3. core/src/test/config/log4j2-test.xml is refactored to suite current log4j
> format. The current version of core/src/test/config/log4j2-test.xml is
> moved to the log4j2/src/test/config folder.
> 4. osgi-paxlogging will be removed because it's only meant to provide some
> log4j dependencies. We have no need in them now.
> 5. Exception logging format will change slightly:
> Before:
> {code:java}
> class org.apache.ignite.IgniteException: Platform error:System.Exception:
> EXCEPTION_TEST_Warn
> at
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.loggerLog(PlatformProcessorImpl.java:449)
> at
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:511)
> at
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:575)
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutLong(PlatformTargetProxyImpl.java:67)
> {code}
> After:
> {code:java}
> org.apache.ignite.IgniteException: Platform error:System.Exception:
> EXCEPTION_TEST_Warn
> at
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.loggerLog(PlatformProcessorImpl.java:449)
> at
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:511)
> at
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:575)
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutLong(PlatformTargetProxyImpl.java:67)
> {code}
> As you can see, only the first word "class" is omitted.
> 6. All other files containing log4j configuration will be refactored to suite
> log4j2 and will be renamed if previously their name allowed log4j to
> automatically find them in the class path (e.g. log4j.xml -> log4j2.xml and
> so on)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-16650) Exclude ignite-log4j, log4j 1.2.17
[
https://issues.apache.org/jira/browse/IGNITE-16650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita resolved IGNITE-16650.
--
Release Note: Removed deprecated log4j 1.x module
Resolution: Fixed
> Exclude ignite-log4j, log4j 1.2.17
> --
>
> Key: IGNITE-16650
> URL: https://issues.apache.org/jira/browse/IGNITE-16650
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergei Ryzhov
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: important, ise
> Fix For: 2.14
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> log4j 1.2.17 is not supported and contains critical vulnerabilities
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> I suggest excluding the ignite-log4j module from ignite
> Direct vulnerabilities:
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23305
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23302
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4104
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17571
> As a result of the mentioned migration, the following changes will be applied:
> 1. ignite-log4j.xml will be migrated to log4j2 format. Unfortunately after
> the refactoring we will get two configuration ignite-log4j.xml and
> ignite-log4j2.xml both in log4j2 format because ignite-log4j2.xml is in use
> now and but provide log formatitng different from ignite-log4j.xml.
> 2. core/src/test/config/log4j-test.xml will not be migrated to log4j2 because
> it is used with compatibility tests.
> 3. core/src/test/config/log4j2-test.xml is refactored to suite current log4j
> format. The current version of core/src/test/config/log4j2-test.xml is
> moved to the log4j2/src/test/config folder.
> 4. osgi-paxlogging will be removed because it's only meant to provide some
> log4j dependencies. We have no need in them now.
> 5. Exception logging format will change slightly:
> Before:
> {code:java}
> class org.apache.ignite.IgniteException: Platform error:System.Exception:
> EXCEPTION_TEST_Warn
> at
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.loggerLog(PlatformProcessorImpl.java:449)
> at
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:511)
> at
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:575)
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutLong(PlatformTargetProxyImpl.java:67)
> {code}
> After:
> {code:java}
> org.apache.ignite.IgniteException: Platform error:System.Exception:
> EXCEPTION_TEST_Warn
> at
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.loggerLog(PlatformProcessorImpl.java:449)
> at
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:511)
> at
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:575)
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutLong(PlatformTargetProxyImpl.java:67)
> {code}
> As you can see, only the first word "class" is omitted.
> 6. All other files containing log4j configuration will be refactored to suite
> log4j2 and will be renamed if previously their name allowed log4j to
> automatically find them in the class path (e.g. log4j.xml -> log4j2.xml and
> so on)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17402) Thin 3.0: testClientSendsComputeJobToTargetNodeWhenDirectConnectionExists is flaky
[ https://issues.apache.org/jira/browse/IGNITE-17402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn updated IGNITE-17402: Description: Failed then succeeded without changes: https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_RunUnitTests/6691262 was:https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_RunUnitTests/6691262 > Thin 3.0: testClientSendsComputeJobToTargetNodeWhenDirectConnectionExists is > flaky > -- > > Key: IGNITE-17402 > URL: https://issues.apache.org/jira/browse/IGNITE-17402 > Project: Ignite > Issue Type: Bug > Components: thin client >Affects Versions: 3.0.0-alpha6 >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-alpha6 > > > Failed then succeeded without changes: > https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_RunUnitTests/6691262 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17402) Thin 3.0: testClientSendsComputeJobToTargetNodeWhenDirectConnectionExists is flaky
Pavel Tupitsyn created IGNITE-17402: --- Summary: Thin 3.0: testClientSendsComputeJobToTargetNodeWhenDirectConnectionExists is flaky Key: IGNITE-17402 URL: https://issues.apache.org/jira/browse/IGNITE-17402 Project: Ignite Issue Type: Bug Components: thin client Affects Versions: 3.0.0-alpha6 Reporter: Pavel Tupitsyn Assignee: Pavel Tupitsyn Fix For: 3.0.0-alpha6 https://ci.ignite.apache.org/buildConfiguration/ignite3_Test_RunUnitTests/6691262 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17399) CDC: expiration of entries are not applied on destination cluster
[
https://issues.apache.org/jira/browse/IGNITE-17399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Timonin reassigned IGNITE-17399:
---
Assignee: Maksim Timonin
> CDC: expiration of entries are not applied on destination cluster
> -
>
> Key: IGNITE-17399
> URL: https://issues.apache.org/jira/browse/IGNITE-17399
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Maksim Timonin
>Priority: Minor
> Labels: IEP-59, ise
> Attachments: ExpiryCdcReproducer.patch
>
>
> There are two points, which should be noted:
> # Removes of entries on expiration are not captured by {{CdcConsumer}} and
> {{WalRecordsConsumer}}. So, removes are not propagated to a destination
> cluster.
> # Entries, which was put via the {{CdcEventsApplier}} are not expired in
> destination cluster, even if cache is configured with expiry policy.
> Reproducer: [^ExpiryCdcReproducer.patch]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17125) Advanced completion for option values
[ https://issues.apache.org/jira/browse/IGNITE-17125?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-17125: -- Assignee: Aleksandr > Advanced completion for option values > - > > Key: IGNITE-17125 > URL: https://issues.apache.org/jira/browse/IGNITE-17125 > Project: Ignite > Issue Type: Improvement >Reporter: Mikhail Pochatkin >Assignee: Aleksandr >Priority: Major > Labels: ignite-3, ignite-3-cli-tool > > Currently cli completer has possibility to complete only commands names and > options. It would be helpful and user friendly to add possibility to complete > options value. To more understandable, currently cli has command "config show > --selector 'key'", where key is property name in ignite configuration. This > is possible to complete this key by "cached representation" of Ignite > configuration. > The solution should be customazable to use it in all commands which require > option value completion. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17385) Frequent commits of single cache transactions can lead GridCacheAdapter#asyncOpsSem permits overflow
[
https://issues.apache.org/jira/browse/IGNITE-17385?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Timonin reassigned IGNITE-17385:
---
Assignee: Maksim Timonin
> Frequent commits of single cache transactions can lead
> GridCacheAdapter#asyncOpsSem permits overflow
>
>
> Key: IGNITE-17385
> URL: https://issues.apache.org/jira/browse/IGNITE-17385
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Assignee: Maksim Timonin
>Priority: Major
> Labels: ise
> Attachments: SemaphorePermitsExceeded.patch
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> When you commit a transaction, which was _explicitly started only over a
> single cache_, then {{GridCacheAdapter#asyncOpRelease}} is called without
> {{GridCacheAdapter#asyncOpAcquire}}. This situation can lead to continuous
> grow of permits count in {{GridCacheAdapter#asyncOpsSem}} and to overflow
> with a further failure of node started the transaction:
> {code}
> Critical system error detected. Will be handled accordingly to configured
> handler
> [hnd=o.a.i.i.processors.cache.transactions.TxAsyncOpsSemaphorePermitsExeededTest$$Lambda$42/1924582348@7379bebb,
> failureCtx=FailureContext [type=CRITICAL_ERROR, err=java.lang.Error: Maximum
> permit count exceeded]]
> {code}
> As you can see in [1], in case of the single cache context, transaction will
> be commited by calling of {{GridCacheAdapter#commitTxAsync}}, which invokes
> {{GridCacheAdapter#asyncOpRelease}} later. But, when multiple caches affected
> by transaction, {{GridNearTxLocal#commitNearTxLocalAsync}} is called to
> commit transaction, and no invokes of {{GridCacheAdapter#asyncOpRelease}}
> occur.
> So, the greater the load (RPS / TPS) with a such single cache transactions,
> the faster the failure of a node will happen.
> Reproducer of the problem: [^SemaphorePermitsExceeded.patch]. It prints
> additional messages, when semaphore is released, or acquired.
> Links:
> #
> https://github.com/apache/ignite/blob/master/modules/core/src/main/java/org/apache/ignite/internal/processors/cache/GridCacheSharedContext.java#L1122
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17092) Implement topology command
[ https://issues.apache.org/jira/browse/IGNITE-17092?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr reassigned IGNITE-17092: -- Assignee: Aleksandr > Implement topology command > -- > > Key: IGNITE-17092 > URL: https://issues.apache.org/jira/browse/IGNITE-17092 > Project: Ignite > Issue Type: Task >Reporter: Aleksandr >Assignee: Aleksandr >Priority: Major > Labels: ignite-3, ignite-3-cli-tool > > The topology commandd should call a special endpoint for getting the cluster > topology. > There are two kinds of topology: physical and logical. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17346) Ignite3 CLI long output not readable in windows terminal
[
https://issues.apache.org/jira/browse/IGNITE-17346?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vadim Pakhnushev reassigned IGNITE-17346:
-
Assignee: Vadim Pakhnushev
> Ignite3 CLI long output not readable in windows terminal
>
>
> Key: IGNITE-17346
> URL: https://issues.apache.org/jira/browse/IGNITE-17346
> Project: Ignite
> Issue Type: Task
> Components: cli
>Reporter: Yury Yudin
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3
>
> When output of ignite3 command does not fit the window it scrolls and it's
> history is lost in the windows terminal. Scrolling up shows previous commands
> but not the output...
> {noformat}
> [disconnected]>
>
> "memoryAllocator" : {
> "type" : "unsafe"
> },
> "replacementMode" : "CLOCK",
> "size" : 268435456
> },
> "pageSize" : 16384,
> "regions" : [ ]
> },
> "rocksDb" : {
> "defaultRegion" : {
> "cache" : "lru",
> "numShardBits" : -1,
> "size" : 268435456,
> "writeBufferSize" : 67108864
> },
> "regions" : [ ]
> },
> "table" : {
> "defaultDataStorage" : "rocksdb",
> "tables" : [ ]
> }
> }
> [test1]>{noformat}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-17110) Auto-connect on the REPL start
[
https://issues.apache.org/jira/browse/IGNITE-17110?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vadim Pakhnushev reassigned IGNITE-17110:
-
Assignee: Vadim Pakhnushev
> Auto-connect on the REPL start
> --
>
> Key: IGNITE-17110
> URL: https://issues.apache.org/jira/browse/IGNITE-17110
> Project: Ignite
> Issue Type: Task
>Reporter: Aleksandr
>Assignee: Vadim Pakhnushev
>Priority: Major
> Labels: ignite-3, ignite-3-cli-tool
>
> h2. Description
> When a user starts REPL by the {{ignite}} command they get
> {{{}[disconnected]{}}}> prompt by default. Even if the user already connected
> to the cluster node in the previous session.
> h2. To-Do
> Implement the auto-connect logic for the case described below. The URL for
> the connect command can be taken from the defaults. If the user previously
> connected to the URL that differs from the default one then suggest using the
> last URL as a default.
> {code:bash}
> $ ignite
> > connect to http://host.from.previous.session:10300 ? # this is asked only
> > if the default url is not possible to connect
> > yes
> [http://host.from.previous.session:10300]> would you like to use
> http://host.from.previous.session:10300 as the default URL?
> [http://host.from.previous.session:10300]> no
> [http://host.from.previous.session:10300]> {code}
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-16650) Exclude ignite-log4j, log4j 1.2.17
[
https://issues.apache.org/jira/browse/IGNITE-16650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-16650:
-
Labels: important ise (was: ise)
> Exclude ignite-log4j, log4j 1.2.17
> --
>
> Key: IGNITE-16650
> URL: https://issues.apache.org/jira/browse/IGNITE-16650
> Project: Ignite
> Issue Type: Bug
>Reporter: Sergei Ryzhov
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: important, ise
> Fix For: 2.14
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> log4j 1.2.17 is not supported and contains critical vulnerabilities
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> I suggest excluding the ignite-log4j module from ignite
> Direct vulnerabilities:
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23305
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23302
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4104
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17571
> As a result of the mentioned migration, the following changes will be applied:
> 1. ignite-log4j.xml will be migrated to log4j2 format. Unfortunately after
> the refactoring we will get two configuration ignite-log4j.xml and
> ignite-log4j2.xml both in log4j2 format because ignite-log4j2.xml is in use
> now and but provide log formatitng different from ignite-log4j.xml.
> 2. core/src/test/config/log4j-test.xml will not be migrated to log4j2 because
> it is used with compatibility tests.
> 3. core/src/test/config/log4j2-test.xml is refactored to suite current log4j
> format. The current version of core/src/test/config/log4j2-test.xml is
> moved to the log4j2/src/test/config folder.
> 4. osgi-paxlogging will be removed because it's only meant to provide some
> log4j dependencies. We have no need in them now.
> 5. Exception logging format will change slightly:
> Before:
> {code:java}
> class org.apache.ignite.IgniteException: Platform error:System.Exception:
> EXCEPTION_TEST_Warn
> at
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.loggerLog(PlatformProcessorImpl.java:449)
> at
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:511)
> at
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:575)
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutLong(PlatformTargetProxyImpl.java:67)
> {code}
> After:
> {code:java}
> org.apache.ignite.IgniteException: Platform error:System.Exception:
> EXCEPTION_TEST_Warn
> at
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.loggerLog(PlatformProcessorImpl.java:449)
> at
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:511)
> at
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:575)
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutLong(PlatformTargetProxyImpl.java:67)
> {code}
> As you can see, only the first word "class" is omitted.
> 6. All other files containing log4j configuration will be refactored to suite
> log4j2 and will be renamed if previously their name allowed log4j to
> automatically find them in the class path (e.g. log4j.xml -> log4j2.xml and
> so on)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-16650) Exclude ignite-log4j, log4j 1.2.17
[
https://issues.apache.org/jira/browse/IGNITE-16650?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Amelchev Nikita updated IGNITE-16650:
-
Issue Type: Improvement (was: Bug)
> Exclude ignite-log4j, log4j 1.2.17
> --
>
> Key: IGNITE-16650
> URL: https://issues.apache.org/jira/browse/IGNITE-16650
> Project: Ignite
> Issue Type: Improvement
>Reporter: Sergei Ryzhov
>Assignee: Mikhail Petrov
>Priority: Major
> Labels: important, ise
> Fix For: 2.14
>
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> log4j 1.2.17 is not supported and contains critical vulnerabilities
> https://blogs.apache.org/foundation/entry/apache_logging_services_project_announces
> I suggest excluding the ignite-log4j module from ignite
> Direct vulnerabilities:
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23305
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-23302
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-4104
> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17571
> As a result of the mentioned migration, the following changes will be applied:
> 1. ignite-log4j.xml will be migrated to log4j2 format. Unfortunately after
> the refactoring we will get two configuration ignite-log4j.xml and
> ignite-log4j2.xml both in log4j2 format because ignite-log4j2.xml is in use
> now and but provide log formatitng different from ignite-log4j.xml.
> 2. core/src/test/config/log4j-test.xml will not be migrated to log4j2 because
> it is used with compatibility tests.
> 3. core/src/test/config/log4j2-test.xml is refactored to suite current log4j
> format. The current version of core/src/test/config/log4j2-test.xml is
> moved to the log4j2/src/test/config folder.
> 4. osgi-paxlogging will be removed because it's only meant to provide some
> log4j dependencies. We have no need in them now.
> 5. Exception logging format will change slightly:
> Before:
> {code:java}
> class org.apache.ignite.IgniteException: Platform error:System.Exception:
> EXCEPTION_TEST_Warn
> at
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.loggerLog(PlatformProcessorImpl.java:449)
> at
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:511)
> at
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:575)
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutLong(PlatformTargetProxyImpl.java:67)
> {code}
> After:
> {code:java}
> org.apache.ignite.IgniteException: Platform error:System.Exception:
> EXCEPTION_TEST_Warn
> at
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.loggerLog(PlatformProcessorImpl.java:449)
> at
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:511)
> at
> org.apache.ignite.internal.processors.platform.PlatformProcessorImpl.processInStreamOutLong(PlatformProcessorImpl.java:575)
> at
> org.apache.ignite.internal.processors.platform.PlatformTargetProxyImpl.inStreamOutLong(PlatformTargetProxyImpl.java:67)
> {code}
> As you can see, only the first word "class" is omitted.
> 6. All other files containing log4j configuration will be refactored to suite
> log4j2 and will be renamed if previously their name allowed log4j to
> automatically find them in the class path (e.g. log4j.xml -> log4j2.xml and
> so on)
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17381) Create docs for Apache Ignite Extensions
[ https://issues.apache.org/jira/browse/IGNITE-17381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Igor Gusev updated IGNITE-17381: Fix Version/s: 2.13 > Create docs for Apache Ignite Extensions > > > Key: IGNITE-17381 > URL: https://issues.apache.org/jira/browse/IGNITE-17381 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > Fix For: 2.13 > > > With a new extension, we need to add docs on how to use it. It should be put > to extensions repo and docs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-17381) Create docs for Apache Ignite Extensions
[ https://issues.apache.org/jira/browse/IGNITE-17381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Semyon Danilov resolved IGNITE-17381. - Resolution: Fixed Looks good to me. Merged to the master branch, thank you for the contribution > Create docs for Apache Ignite Extensions > > > Key: IGNITE-17381 > URL: https://issues.apache.org/jira/browse/IGNITE-17381 > Project: Ignite > Issue Type: Task > Components: documentation >Reporter: Igor Gusev >Assignee: Igor Gusev >Priority: Major > > With a new extension, we need to add docs on how to use it. It should be put > to extensions repo and docs. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Deleted] (IGNITE-17390) .NET: Thin 3.0: Unified exception handling
[ https://issues.apache.org/jira/browse/IGNITE-17390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Tupitsyn deleted IGNITE-17390: > .NET: Thin 3.0: Unified exception handling > -- > > Key: IGNITE-17390 > URL: https://issues.apache.org/jira/browse/IGNITE-17390 > Project: Ignite > Issue Type: Improvement >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, ignite-3 > > Adopt the changes from IGNITE-17312 in .NET client. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17400) Implement basic C++ support of BinaryTuple
[ https://issues.apache.org/jira/browse/IGNITE-17400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Demakov updated IGNITE-17400: - Description: Provide initial C++ implementation of [IEP-92|https://cwiki.apache.org/confluence/display/IGNITE/IEP-92%3A+Binary+Tuple+Format]. Because there is no support in C++ for many things that are already present in Java (e.g. BigInteger) the implementation will lack certain features. This will be resolved later. (was: Provide C++ implementation of [IEP-92|https://cwiki.apache.org/confluence/display/IGNITE/IEP-92%3A+Binary+Tuple+Format].) > Implement basic C++ support of BinaryTuple > -- > > Key: IGNITE-17400 > URL: https://issues.apache.org/jira/browse/IGNITE-17400 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksey Demakov >Assignee: Aleksey Demakov >Priority: Major > Labels: iep-92, ignite-3 > Fix For: 3.0.0-alpha6 > > > Provide initial C++ implementation of > [IEP-92|https://cwiki.apache.org/confluence/display/IGNITE/IEP-92%3A+Binary+Tuple+Format]. > Because there is no support in C++ for many things that are already present > in Java (e.g. BigInteger) the implementation will lack certain features. This > will be resolved later. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17401) Implement full C++ support of BinaryTuple
[ https://issues.apache.org/jira/browse/IGNITE-17401?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Demakov reassigned IGNITE-17401: Assignee: Aleksey Demakov > Implement full C++ support of BinaryTuple > - > > Key: IGNITE-17401 > URL: https://issues.apache.org/jira/browse/IGNITE-17401 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksey Demakov >Assignee: Aleksey Demakov >Priority: Major > Labels: iep-92, ignite-3 > Fix For: 3.0.0-alpha6 > > > Add C++ support of data types from IEP-92 including datetime, timestamp, > big-integer. It is required to support serialization to/de-serialization from > binary form and comparison operators. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17401) Implement full C++ support of BinaryTuple
Aleksey Demakov created IGNITE-17401: Summary: Implement full C++ support of BinaryTuple Key: IGNITE-17401 URL: https://issues.apache.org/jira/browse/IGNITE-17401 Project: Ignite Issue Type: Improvement Reporter: Aleksey Demakov Fix For: 3.0.0-alpha6 Add C++ support of data types from IEP-92 including datetime, timestamp, big-integer. It is required to support serialization to/de-serialization from binary form and comparison operators. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17400) Implement basic C++ support of BinaryTuple
[ https://issues.apache.org/jira/browse/IGNITE-17400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Demakov updated IGNITE-17400: - Summary: Implement basic C++ support of BinaryTuple (was: Implement C++ support of BinaryTuple) > Implement basic C++ support of BinaryTuple > -- > > Key: IGNITE-17400 > URL: https://issues.apache.org/jira/browse/IGNITE-17400 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksey Demakov >Assignee: Aleksey Demakov >Priority: Major > Labels: iep-92, ignite-3 > Fix For: 3.0.0-alpha6 > > > Provide C++ implementation of > [IEP-92|https://cwiki.apache.org/confluence/display/IGNITE/IEP-92%3A+Binary+Tuple+Format]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17400) Implement C++ support of BinaryTuple
[ https://issues.apache.org/jira/browse/IGNITE-17400?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Demakov updated IGNITE-17400: - Fix Version/s: 3.0.0-alpha6 > Implement C++ support of BinaryTuple > > > Key: IGNITE-17400 > URL: https://issues.apache.org/jira/browse/IGNITE-17400 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksey Demakov >Assignee: Aleksey Demakov >Priority: Major > Labels: iep-92, ignite-3 > Fix For: 3.0.0-alpha6 > > > Provide C++ implementation of > [IEP-92|https://cwiki.apache.org/confluence/display/IGNITE/IEP-92%3A+Binary+Tuple+Format]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17192) Implement BinaryTuple
[ https://issues.apache.org/jira/browse/IGNITE-17192?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksey Demakov updated IGNITE-17192: - Ignite Flags: (was: Docs Required,Release Notes Required) > Implement BinaryTuple > - > > Key: IGNITE-17192 > URL: https://issues.apache.org/jira/browse/IGNITE-17192 > Project: Ignite > Issue Type: Improvement >Reporter: Aleksey Demakov >Assignee: Aleksey Demakov >Priority: Major > Labels: iep-92, ignite-3 > Fix For: 3.0.0-alpha6 > > Time Spent: 5h > Remaining Estimate: 0h > > Provide Java implementation of > [IEP-92|https://cwiki.apache.org/confluence/display/IGNITE/IEP-92%3A+Binary+Tuple+Format] > following the discussion on the [dev > list|https://lists.apache.org/thread/0m14y1y25krompm0d2vsbmc5lo8727zy]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-17400) Implement C++ support of BinaryTuple
Aleksey Demakov created IGNITE-17400: Summary: Implement C++ support of BinaryTuple Key: IGNITE-17400 URL: https://issues.apache.org/jira/browse/IGNITE-17400 Project: Ignite Issue Type: Improvement Reporter: Aleksey Demakov Assignee: Aleksey Demakov Provide C++ implementation of [IEP-92|https://cwiki.apache.org/confluence/display/IGNITE/IEP-92%3A+Binary+Tuple+Format]. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17399) CDC: expiration of entries are not applied on destination cluster
[
https://issues.apache.org/jira/browse/IGNITE-17399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-17399:
---
Affects Version/s: 2.13
> CDC: expiration of entries are not applied on destination cluster
> -
>
> Key: IGNITE-17399
> URL: https://issues.apache.org/jira/browse/IGNITE-17399
> Project: Ignite
> Issue Type: Bug
>Affects Versions: 2.13
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: IEP-59, ise
> Attachments: ExpiryCdcReproducer.patch
>
>
> There are two points, which should be noted:
> # Removes of entries on expiration are not captured by {{CdcConsumer}} and
> {{WalRecordsConsumer}}. So, removes are not propagated to a destination
> cluster.
> # Entries, which was put via the {{CdcEventsApplier}} are not expired in
> destination cluster, even if cache is configured with expiry policy.
> Reproducer: [^ExpiryCdcReproducer.patch]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17399) CDC: expiration of entries are not applied on destination cluster
[
https://issues.apache.org/jira/browse/IGNITE-17399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-17399:
---
Summary: CDC: expiration of entries are not applied on destination cluster
(was: CDC: expiration of entries is not applied on destination cluster)
> CDC: expiration of entries are not applied on destination cluster
> -
>
> Key: IGNITE-17399
> URL: https://issues.apache.org/jira/browse/IGNITE-17399
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: IEP-59, ise
> Attachments: ExpiryCdcReproducer.patch
>
>
> There are two points, which should be noted:
> # Removes of entries on expiration are not captured by {{CdcConsumer}} and
> {{WalRecordsConsumer}}. So, removes are not propagated to a destination
> cluster.
> # Entries, which was put via the {{CdcEventsApplier}} are not expired in
> destination cluster, even if cache is configured with expiry policy.
> Reproducer: [^ExpiryCdcReproducer.patch]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-17215) Write ClusterSnapshotRecord to WAL
[ https://issues.apache.org/jira/browse/IGNITE-17215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17569287#comment-17569287 ] Maksim Timonin commented on IGNITE-17215: - Hi [~xtern] thanks for catching that, I'll have a look > Write ClusterSnapshotRecord to WAL > -- > > Key: IGNITE-17215 > URL: https://issues.apache.org/jira/browse/IGNITE-17215 > Project: Ignite > Issue Type: New Feature >Reporter: Maksim Timonin >Assignee: Maksim Timonin >Priority: Major > Labels: IEP-89 > Fix For: 2.14 > > Time Spent: 50m > Remaining Estimate: 0h > > For PITR [1] process of recovering based on ClusterSnapshot + archived WALs. > It's required to have a point in WAL which splits whole WAL on 2 areas: > # Before this point all data changes are contained within ClusterSnapshot, > and no need to recover them from WAL archived files. > # After this point all data need to be recovered from WAL archived files. > It's proposed to write ClusterSnapshotRecord while the checkpoint is running > (cp#writeLock has acquired). ClusterSnapshot process guarantees: > # there is no active transactions (or any data changes) in moment of running > checkpoint. > # ClusterSnapshot contains all data pages that will be persisted within this > checkpoint process. > Then every logical record after begin CheckointRecord doesn't belong to > ClusterSnapshot. Then it's safe to write ClusterSnapshotRecord within the > checkpoint process. > [1] > [https://cwiki.apache.org/confluence/pages/editpage.action?pageId=211884314] -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-17399) CDC: expiration of entries is not applied on destination cluster
[
https://issues.apache.org/jira/browse/IGNITE-17399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-17399:
---
Description:
There are two points, which should be noted:
# Removes of entries on expiration are not captured by {{CdcConsumer}} and
{{WalRecordsConsumer}}. So, removes are not propagated to a destination cluster.
# Entries, which was put via the {{CdcEventsApplier}} are not expired in
destination cluster, even if cache is configured with expiry policy.
Reproducer: [^ExpiryCdcReproducer.patch]
was:
There are two points, which should be noted:
# Removes of entries on expiration are not captured by {{CdcConsumer}} and
{{WalRecordsConsumer}}. So, removes are not propagated to a destination cluster.
# Entries, which was put via {{CdcEventsApplier}} are not expired in
destination cluster, even if cache is configured with expiry policy.
Reproducer: [^ExpiryCdcReproducer.patch]
> CDC: expiration of entries is not applied on destination cluster
>
>
> Key: IGNITE-17399
> URL: https://issues.apache.org/jira/browse/IGNITE-17399
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: IEP-59, ise
> Attachments: ExpiryCdcReproducer.patch
>
>
> There are two points, which should be noted:
> # Removes of entries on expiration are not captured by {{CdcConsumer}} and
> {{WalRecordsConsumer}}. So, removes are not propagated to a destination
> cluster.
> # Entries, which was put via the {{CdcEventsApplier}} are not expired in
> destination cluster, even if cache is configured with expiry policy.
> Reproducer: [^ExpiryCdcReproducer.patch]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17399) CDC: expiration of entries is not applied on destination cluster
[
https://issues.apache.org/jira/browse/IGNITE-17399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-17399:
---
Description:
There are two points, which should be noted:
# Removes of entries on expiration are not captured by {{CdcConsumer}} and
{{WalRecordsConsumer}}. So, removes are not propagated to a destination cluster.
# Entries, which was put via {{CdcEventsApplier}} are not expired in
destination cluster, even if cache is configured with expiry policy.
Reproducer: [^ExpiryCdcReproducer.patch]
was:
There are two points, which should be noted:
# Removes of entries on expiration are not captured by {{CdcConsumer}} and
{{WalRecordsConsumer}}. So, removes are not propagated to destination cluster.
# Entries, which was put via {{CdcEventsApplier}} are not expired in
destination cluster, even if cache is configured with expiry policy.
Reproducer: [^ExpiryCdcReproducer.patch]
> CDC: expiration of entries is not applied on destination cluster
>
>
> Key: IGNITE-17399
> URL: https://issues.apache.org/jira/browse/IGNITE-17399
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: IEP-59, ise
> Attachments: ExpiryCdcReproducer.patch
>
>
> There are two points, which should be noted:
> # Removes of entries on expiration are not captured by {{CdcConsumer}} and
> {{WalRecordsConsumer}}. So, removes are not propagated to a destination
> cluster.
> # Entries, which was put via {{CdcEventsApplier}} are not expired in
> destination cluster, even if cache is configured with expiry policy.
> Reproducer: [^ExpiryCdcReproducer.patch]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17399) CDC: expiration of entries is not applied on destination cluster
[
https://issues.apache.org/jira/browse/IGNITE-17399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-17399:
---
Description:
There are two points, which should be noted:
# Removes of entries on expiration are not captured by {{CdcConsumer}} and
{{WalRecordsConsumer}}. So, removes are not propagated to destination cluster.
# Entries, which was put via {{CdcEventsApplier}} are not expired in
destination cluster, even if cache is configured with expiry policy.
Reproducer: [^ExpiryCdcReproducer.patch]
was:
There are two points, which should be noted:
# Removes of entries on expiration are not captured by {{CdcConsumer}} and
{{WalRecordsConsumer}}. So, removes are not propagated to destination cluster.
# Entries, which was put via {{CdcApplier}} are not expired in destination
cluster, even if cache is configured with expiry policy.
Reproducer: [^ExpiryCdcReproducer.patch]
> CDC: expiration of entries is not applied on destination cluster
>
>
> Key: IGNITE-17399
> URL: https://issues.apache.org/jira/browse/IGNITE-17399
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: IEP-59, ise
> Attachments: ExpiryCdcReproducer.patch
>
>
> There are two points, which should be noted:
> # Removes of entries on expiration are not captured by {{CdcConsumer}} and
> {{WalRecordsConsumer}}. So, removes are not propagated to destination cluster.
> # Entries, which was put via {{CdcEventsApplier}} are not expired in
> destination cluster, even if cache is configured with expiry policy.
> Reproducer: [^ExpiryCdcReproducer.patch]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17399) CDC: expiration of entries is not applied on destination cluster
[
https://issues.apache.org/jira/browse/IGNITE-17399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-17399:
---
Description:
There are two points, which should be noted:
# Removes of entries on expiration are not captured by {{CdcConsumer}} and
{{WalRecordsConsumer}}. So, removes are not propagated to destination cluster.
# Entries, which was put via {{CdcApplier}} are not expired in destination
cluster, even if cache is configured with expiry policy.
Reproducer: [^ExpiryCdcReproducer.patch]
was:
There are two points, which should be noted:
# Removes of entries on expiration are not captured by {{CdcConsumer}} and
{{WalRecordsConsumer}}.
# Entries, which was put via {{CdcApplier}} are not expired in destination
cluster.
Reproducer: [^ExpiryCdcReproducer.patch]
> CDC: expiration of entries is not applied on destination cluster
>
>
> Key: IGNITE-17399
> URL: https://issues.apache.org/jira/browse/IGNITE-17399
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: IEP-59, ise
> Attachments: ExpiryCdcReproducer.patch
>
>
> There are two points, which should be noted:
> # Removes of entries on expiration are not captured by {{CdcConsumer}} and
> {{WalRecordsConsumer}}. So, removes are not propagated to destination cluster.
> # Entries, which was put via {{CdcApplier}} are not expired in destination
> cluster, even if cache is configured with expiry policy.
> Reproducer: [^ExpiryCdcReproducer.patch]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17399) CDC: expiration of entries is not applied on destination cluster
[
https://issues.apache.org/jira/browse/IGNITE-17399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-17399:
---
Summary: CDC: expiration of entries is not applied on destination cluster
(was: CDC expiration of entries is not applied on destination cluster)
> CDC: expiration of entries is not applied on destination cluster
>
>
> Key: IGNITE-17399
> URL: https://issues.apache.org/jira/browse/IGNITE-17399
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: IEP-59, ise
> Attachments: ExpiryCdcReproducer.patch
>
>
> There are two points, which should be noted:
> # Removes of entries on expiration are not captured by {{CdcConsumer}} and
> {{WalRecordsConsumer}}.
> # Entries, which was put via {{CdcApplier}} are not expired in destination
> cluster.
> Reproducer: [^ExpiryCdcReproducer.patch]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17399) CDC expiration of entries is not applied on destination cluster
[
https://issues.apache.org/jira/browse/IGNITE-17399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-17399:
---
Labels: IEP-59 ise (was: ise)
> CDC expiration of entries is not applied on destination cluster
> ---
>
> Key: IGNITE-17399
> URL: https://issues.apache.org/jira/browse/IGNITE-17399
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: IEP-59, ise
> Attachments: ExpiryCdcReproducer.patch
>
>
> There are two points, which should be noted:
> # Removes of entries on expiration are not captured by {{CdcConsumer}} and
> {{WalRecordsConsumer}}.
> # Entries, which was put via CdcStreamer are not expired in destination
> cluster.
> Reproducer: [^ExpiryCdcReproducer.patch]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17399) CDC expiration of entries is not applied on destination cluster
[
https://issues.apache.org/jira/browse/IGNITE-17399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-17399:
---
Description:
There are two points, which should be noted:
# Removes of entries on expiration are not captured by {{CdcConsumer}} and
{{WalRecordsConsumer}}.
# Entries, which was put via {{CdcApplier}} are not expired in destination
cluster.
Reproducer: [^ExpiryCdcReproducer.patch]
was:
There are two points, which should be noted:
# Removes of entries on expiration are not captured by {{CdcConsumer}} and
{{WalRecordsConsumer}}.
# Entries, which was put via {{CdcStreamer}} are not expired in destination
cluster.
Reproducer: [^ExpiryCdcReproducer.patch]
> CDC expiration of entries is not applied on destination cluster
> ---
>
> Key: IGNITE-17399
> URL: https://issues.apache.org/jira/browse/IGNITE-17399
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: IEP-59, ise
> Attachments: ExpiryCdcReproducer.patch
>
>
> There are two points, which should be noted:
> # Removes of entries on expiration are not captured by {{CdcConsumer}} and
> {{WalRecordsConsumer}}.
> # Entries, which was put via {{CdcApplier}} are not expired in destination
> cluster.
> Reproducer: [^ExpiryCdcReproducer.patch]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17399) CDC expiration of entries is not applied on destination cluster
[
https://issues.apache.org/jira/browse/IGNITE-17399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-17399:
---
Description:
There are two points, which should be noted:
# Removes of entries on expiration are not captured by {{CdcConsumer}} and
{{WalRecordsConsumer}}.
# Entries, which was put via {{CdcStreamer}} are not expired in destination
cluster.
Reproducer: [^ExpiryCdcReproducer.patch]
was:
There are two points, which should be noted:
# Removes of entries on expiration are not captured by {{CdcConsumer}} and
{{WalRecordsConsumer}}.
# Entries, which was put via CdcStreamer are not expired in destination cluster.
Reproducer: [^ExpiryCdcReproducer.patch]
> CDC expiration of entries is not applied on destination cluster
> ---
>
> Key: IGNITE-17399
> URL: https://issues.apache.org/jira/browse/IGNITE-17399
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: IEP-59, ise
> Attachments: ExpiryCdcReproducer.patch
>
>
> There are two points, which should be noted:
> # Removes of entries on expiration are not captured by {{CdcConsumer}} and
> {{WalRecordsConsumer}}.
> # Entries, which was put via {{CdcStreamer}} are not expired in destination
> cluster.
> Reproducer: [^ExpiryCdcReproducer.patch]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17399) CDC expiration of entries is not applied on destination cluster
[
https://issues.apache.org/jira/browse/IGNITE-17399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-17399:
---
Attachment: ExpiryCdcReproducer.patch
> CDC expiration of entries is not applied on destination cluster
> ---
>
> Key: IGNITE-17399
> URL: https://issues.apache.org/jira/browse/IGNITE-17399
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: ise
> Attachments: ExpiryCdcReproducer.patch
>
>
> There are two points, which should be noted:
> # Removes of entries on expiration are not captured by {{CdcConsumer}} and
> {{WalRecordsConsumer}}.
> # Entries, which was put via CdcStreamer are not expired in destination
> cluster.
> Reproducer:
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-17399) CDC expiration of entries is not applied on destination cluster
[
https://issues.apache.org/jira/browse/IGNITE-17399?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ilya Shishkov updated IGNITE-17399:
---
Description:
There are two points, which should be noted:
# Removes of entries on expiration are not captured by {{CdcConsumer}} and
{{WalRecordsConsumer}}.
# Entries, which was put via CdcStreamer are not expired in destination cluster.
Reproducer: [^ExpiryCdcReproducer.patch]
was:
There are two points, which should be noted:
# Removes of entries on expiration are not captured by {{CdcConsumer}} and
{{WalRecordsConsumer}}.
# Entries, which was put via CdcStreamer are not expired in destination cluster.
Reproducer:
> CDC expiration of entries is not applied on destination cluster
> ---
>
> Key: IGNITE-17399
> URL: https://issues.apache.org/jira/browse/IGNITE-17399
> Project: Ignite
> Issue Type: Bug
>Reporter: Ilya Shishkov
>Priority: Minor
> Labels: ise
> Attachments: ExpiryCdcReproducer.patch
>
>
> There are two points, which should be noted:
> # Removes of entries on expiration are not captured by {{CdcConsumer}} and
> {{WalRecordsConsumer}}.
> # Entries, which was put via CdcStreamer are not expired in destination
> cluster.
> Reproducer: [^ExpiryCdcReproducer.patch]
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-17399) CDC expiration of entries is not applied on destination cluster
Ilya Shishkov created IGNITE-17399:
--
Summary: CDC expiration of entries is not applied on destination
cluster
Key: IGNITE-17399
URL: https://issues.apache.org/jira/browse/IGNITE-17399
Project: Ignite
Issue Type: Bug
Reporter: Ilya Shishkov
Attachments: ExpiryCdcReproducer.patch
There are two points, which should be noted:
# Removes of entries on expiration are not captured by {{CdcConsumer}} and
{{WalRecordsConsumer}}.
# Entries, which was put via CdcStreamer are not expired in destination cluster.
Reproducer:
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
