[jira] [Updated] (IGNITE-18497) Read only get returns a first one value getting from primary index
[
https://issues.apache.org/jira/browse/IGNITE-18497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-18497:
---
Description:
*Motivation*
Indexes store all value associated with different versions of one entry. By the
reason, for getting value by primary index, we scan the index with the specific
key. If we insert, delete and again insert an entry with the same indexed
fields, the entry can resolve in versioned storage for different row ids. But
only one resolution should return not empty value, because only one entry can
exist by the unique index.
*Implementation notes*
The resolution happens here:
{code:java}
PartitionReplicaListener#resolveRowByPk(BinaryRow, HybridTimestamp){code}
But in case when a read result is resolved to null, need to continue the loop,
because the actual value associated with the key may be removed (this is the
null value, but it is not actual) and inserted again.
was:
*Motivation*
Indexes store all value associated with different versions of one entry. By the
reason, for getting value by primary index, we scan the index with the specific
key. If we insert, delete and again insert an entry with the same indexed
fields, the entry can resolve in versioned storage for different row ids. But
only one resolution should return not empty value, because only one entry can
exist by the unique index.
*Implementation notes*
The resolution happens here:
PartitionReplicaListener#resolveRowByPk(BinaryRow, HybridTimestamp)
But in case when a read result is resolved to null, need to continue the loop,
because the actual value associated with the key may be removed (this is the
null value, but it is not actual) and inserted again.
> Read only get returns a first one value getting from primary index
> --
>
> Key: IGNITE-18497
> URL: https://issues.apache.org/jira/browse/IGNITE-18497
> Project: Ignite
> Issue Type: Bug
>Reporter: Vladislav Pyatkov
>Priority: Major
> Labels: ignite-3
>
> *Motivation*
> Indexes store all value associated with different versions of one entry. By
> the reason, for getting value by primary index, we scan the index with the
> specific key. If we insert, delete and again insert an entry with the same
> indexed fields, the entry can resolve in versioned storage for different row
> ids. But only one resolution should return not empty value, because only one
> entry can exist by the unique index.
> *Implementation notes*
> The resolution happens here:
> {code:java}
> PartitionReplicaListener#resolveRowByPk(BinaryRow, HybridTimestamp){code}
> But in case when a read result is resolved to null, need to continue the
> loop, because the actual value associated with the key may be removed (this
> is the null value, but it is not actual) and inserted again.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18497) Read only get returns a first one value getting from primary index
[ https://issues.apache.org/jira/browse/IGNITE-18497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vladislav Pyatkov updated IGNITE-18497: --- Description: *Motivation* Indexes store all value associated with different versions of one entry. By the reason, for getting value by primary index, we scan the index with the specific key. If we insert, delete and again insert an entry with the same indexed fields, the entry can resolve in versioned storage for different row ids. But only one resolution should return not empty value, because only one entry can exist by the unique index. *Implementation notes* The resolution happens here: PartitionReplicaListener#resolveRowByPk(BinaryRow, HybridTimestamp) But in case when a read result is resolved to null, need to continue the loop, because the actual value associated with the key may be removed (this is the null value, but it is not actual) and inserted again. was: The resolution happens here: PartitionReplicaListener#resolveRowByPk(BinaryRow, HybridTimestamp) But in case when a read result is resolved to null, need to continue the loop, because the actual value associated with the key may be removed (this is the null value, but it is not actual) and inserted again. > Read only get returns a first one value getting from primary index > -- > > Key: IGNITE-18497 > URL: https://issues.apache.org/jira/browse/IGNITE-18497 > Project: Ignite > Issue Type: Bug >Reporter: Vladislav Pyatkov >Priority: Major > Labels: ignite-3 > > *Motivation* > Indexes store all value associated with different versions of one entry. By > the reason, for getting value by primary index, we scan the index with the > specific key. If we insert, delete and again insert an entry with the same > indexed fields, the entry can resolve in versioned storage for different row > ids. But only one resolution should return not empty value, because only one > entry can exist by the unique index. > *Implementation notes* > The resolution happens here: > PartitionReplicaListener#resolveRowByPk(BinaryRow, HybridTimestamp) > But in case when a read result is resolved to null, need to continue the > loop, because the actual value associated with the key may be removed (this > is the null value, but it is not actual) and inserted again. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18084) .NET: Thin 3.0: LINQ: Async materialization
[ https://issues.apache.org/jira/browse/IGNITE-18084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17654805#comment-17654805 ] Igor Sapego commented on IGNITE-18084: -- Looks good to me. Left single minor comment. > .NET: Thin 3.0: LINQ: Async materialization > --- > > Key: IGNITE-18084 > URL: https://issues.apache.org/jira/browse/IGNITE-18084 > Project: Ignite > Issue Type: Improvement > Components: platforms, thin client >Reporter: Pavel Tupitsyn >Assignee: Pavel Tupitsyn >Priority: Major > Labels: .NET, LINQ, ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 10m > Remaining Estimate: 0h > > Support *ToListAsync*, *ToArrayAsync*, *CountAsync*, etc. > * Check how EF does this with *EntityFrameworkQueryableExtensions* -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18500) HybridTimestamp defines equals(), but not hashCode()
[ https://issues.apache.org/jira/browse/IGNITE-18500?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17654503#comment-17654503 ] Sergey Uttsel commented on IGNITE-18500: [~rpuch] LGTM > HybridTimestamp defines equals(), but not hashCode() > > > Key: IGNITE-18500 > URL: https://issues.apache.org/jira/browse/IGNITE-18500 > 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 > -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18470) Exception handling for DistributionZoneManager
[ https://issues.apache.org/jira/browse/IGNITE-18470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17654487#comment-17654487 ] Vyacheslav Koptilin commented on IGNITE-18470: -- LGTM! > Exception handling for DistributionZoneManager > -- > > Key: IGNITE-18470 > URL: https://issues.apache.org/jira/browse/IGNITE-18470 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3 > Time Spent: 50m > Remaining Estimate: 0h > > h3. Motivation > We have broken exception handling in DistributionZoneManager. Some exceptions > are thrown from methods, other exceptions fail future. Need to refactor it. > Currently DdlCommandHandler handles DistributionZoneAlreadyExistsException > and DistributionZoneNotFoundException incorrectly because it wrapped into > ConfigurationChangeException. Seems that they are wrapped because they are > checked exceptions. There are no tests for it. Also methods of > DistributionZoneManager throw other exceptions. > h3. Definition of Done > # Exception handling in DistributionZoneManager is reworked. > # DdlCommandHandler handles all exception produced by methods of > DistributionZoneManager. > h3. Implementation notes > # createZone, alterZone, dropZone must don't wrap NodeStoppingException. > # Need to check if we can unwrap DistributionZoneAlreadyExistsException and > DistributionZoneNotFoundException from ConfigurationChangeException. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18470) Exception handling for DistributionZoneManager
[ https://issues.apache.org/jira/browse/IGNITE-18470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-18470: - Fix Version/s: 3.0.0-beta2 > Exception handling for DistributionZoneManager > -- > > Key: IGNITE-18470 > URL: https://issues.apache.org/jira/browse/IGNITE-18470 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 50m > Remaining Estimate: 0h > > h3. Motivation > We have broken exception handling in DistributionZoneManager. Some exceptions > are thrown from methods, other exceptions fail future. Need to refactor it. > Currently DdlCommandHandler handles DistributionZoneAlreadyExistsException > and DistributionZoneNotFoundException incorrectly because it wrapped into > ConfigurationChangeException. Seems that they are wrapped because they are > checked exceptions. There are no tests for it. Also methods of > DistributionZoneManager throw other exceptions. > h3. Definition of Done > # Exception handling in DistributionZoneManager is reworked. > # DdlCommandHandler handles all exception produced by methods of > DistributionZoneManager. > h3. Implementation notes > # createZone, alterZone, dropZone must don't wrap NodeStoppingException. > # Need to check if we can unwrap DistributionZoneAlreadyExistsException and > DistributionZoneNotFoundException from ConfigurationChangeException. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-18470) Exception handling for DistributionZoneManager
[ https://issues.apache.org/jira/browse/IGNITE-18470?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vyacheslav Koptilin updated IGNITE-18470: - Ignite Flags: (was: Docs Required,Release Notes Required) > Exception handling for DistributionZoneManager > -- > > Key: IGNITE-18470 > URL: https://issues.apache.org/jira/browse/IGNITE-18470 > Project: Ignite > Issue Type: Improvement >Reporter: Sergey Uttsel >Assignee: Sergey Uttsel >Priority: Major > Labels: ignite-3 > Time Spent: 50m > Remaining Estimate: 0h > > h3. Motivation > We have broken exception handling in DistributionZoneManager. Some exceptions > are thrown from methods, other exceptions fail future. Need to refactor it. > Currently DdlCommandHandler handles DistributionZoneAlreadyExistsException > and DistributionZoneNotFoundException incorrectly because it wrapped into > ConfigurationChangeException. Seems that they are wrapped because they are > checked exceptions. There are no tests for it. Also methods of > DistributionZoneManager throw other exceptions. > h3. Definition of Done > # Exception handling in DistributionZoneManager is reworked. > # DdlCommandHandler handles all exception produced by methods of > DistributionZoneManager. > h3. Implementation notes > # createZone, alterZone, dropZone must don't wrap NodeStoppingException. > # Need to check if we can unwrap DistributionZoneAlreadyExistsException and > DistributionZoneNotFoundException from ConfigurationChangeException. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18501) Sql. QueryChecker still use deprecated QueryProcessor#queryAsync method
[
https://issues.apache.org/jira/browse/IGNITE-18501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich reassigned IGNITE-18501:
--
Assignee: (was: Yury Gerzhedovich)
> Sql. QueryChecker still use deprecated QueryProcessor#queryAsync method
> ---
>
> Key: IGNITE-18501
> URL: https://issues.apache.org/jira/browse/IGNITE-18501
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> We still using QueryProcessor#queryAsync method in our test framework
> (QueryChecker).
> As of now there are some test which fails during migrate to
> {code:java}
> QueryProcessor#querySingleAsync{code}
>
> As example such test can be used
> org.apache.ignite.internal.sql.engine.ItSecondaryIndexTest#testSelectWithRanges
> Let's investigate the reason, fix it and migrate QueryChecker to
> querySingleAsync method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18501) Sql. QueryChecker still use deprecated QueryProcessor#queryAsync method
[
https://issues.apache.org/jira/browse/IGNITE-18501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18501:
---
Summary: Sql. QueryChecker still use deprecated QueryProcessor#queryAsync
method (was: Sql. QueryChecker still use deprecated
QueryProcessor#querySingleAsync method)
> Sql. QueryChecker still use deprecated QueryProcessor#queryAsync method
> ---
>
> Key: IGNITE-18501
> URL: https://issues.apache.org/jira/browse/IGNITE-18501
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> We still using QueryProcessor#querySingleAsync method in our test framework
> (QueryChecker).
> As of now there are some test which fails during migrate to
> {code:java}
> QueryProcessor#queryAsync{code}
>
> As example such test can be used
> org.apache.ignite.internal.sql.engine.ItSecondaryIndexTest#testSelectWithRanges
> Let's investigate the reason, fix it and migrate QueryChecker to queryAsync
> method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18501) Sql. QueryChecker still use deprecated QueryProcessor#queryAsync method
[
https://issues.apache.org/jira/browse/IGNITE-18501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18501:
---
Description:
We still using QueryProcessor#queryAsync method in our test framework
(QueryChecker).
As of now there are some test which fails during migrate to
{code:java}
QueryProcessor#querySingleAsync{code}
As example such test can be used
org.apache.ignite.internal.sql.engine.ItSecondaryIndexTest#testSelectWithRanges
Let's investigate the reason, fix it and migrate QueryChecker to
querySingleAsync method.
was:
We still using QueryProcessor#querySingleAsync method in our test framework
(QueryChecker).
As of now there are some test which fails during migrate to
{code:java}
QueryProcessor#queryAsync{code}
As example such test can be used
org.apache.ignite.internal.sql.engine.ItSecondaryIndexTest#testSelectWithRanges
Let's investigate the reason, fix it and migrate QueryChecker to queryAsync
method.
> Sql. QueryChecker still use deprecated QueryProcessor#queryAsync method
> ---
>
> Key: IGNITE-18501
> URL: https://issues.apache.org/jira/browse/IGNITE-18501
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> We still using QueryProcessor#queryAsync method in our test framework
> (QueryChecker).
> As of now there are some test which fails during migrate to
> {code:java}
> QueryProcessor#querySingleAsync{code}
>
> As example such test can be used
> org.apache.ignite.internal.sql.engine.ItSecondaryIndexTest#testSelectWithRanges
> Let's investigate the reason, fix it and migrate QueryChecker to
> querySingleAsync method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-18501) Sql. QueryChecker still use deprecated QueryProcessor#querySingleAsync method
[
https://issues.apache.org/jira/browse/IGNITE-18501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich updated IGNITE-18501:
---
Labels: ignite-3 (was: )
> Sql. QueryChecker still use deprecated QueryProcessor#querySingleAsync method
> -
>
> Key: IGNITE-18501
> URL: https://issues.apache.org/jira/browse/IGNITE-18501
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
> Labels: ignite-3
>
> We still using QueryProcessor#querySingleAsync method in our test framework
> (QueryChecker).
> As of now there are some test which fails during migrate to
> {code:java}
> QueryProcessor#queryAsync{code}
>
> As example such test can be used
> org.apache.ignite.internal.sql.engine.ItSecondaryIndexTest#testSelectWithRanges
> Let's investigate the reason, fix it and migrate QueryChecker to queryAsync
> method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Assigned] (IGNITE-18501) Sql. QueryChecker still use deprecated QueryProcessor#querySingleAsync method
[
https://issues.apache.org/jira/browse/IGNITE-18501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yury Gerzhedovich reassigned IGNITE-18501:
--
Assignee: Yury Gerzhedovich
> Sql. QueryChecker still use deprecated QueryProcessor#querySingleAsync method
> -
>
> Key: IGNITE-18501
> URL: https://issues.apache.org/jira/browse/IGNITE-18501
> Project: Ignite
> Issue Type: Bug
> Components: sql
>Reporter: Yury Gerzhedovich
>Assignee: Yury Gerzhedovich
>Priority: Major
>
> We still using QueryProcessor#querySingleAsync method in our test framework
> (QueryChecker).
> As of now there are some test which fails during migrate to
> {code:java}
> QueryProcessor#queryAsync{code}
>
> As example such test can be used
> org.apache.ignite.internal.sql.engine.ItSecondaryIndexTest#testSelectWithRanges
> Let's investigate the reason, fix it and migrate QueryChecker to queryAsync
> method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18501) Sql. QueryChecker still use deprecated QueryProcessor#querySingleAsync method
Yury Gerzhedovich created IGNITE-18501:
--
Summary: Sql. QueryChecker still use deprecated
QueryProcessor#querySingleAsync method
Key: IGNITE-18501
URL: https://issues.apache.org/jira/browse/IGNITE-18501
Project: Ignite
Issue Type: Bug
Components: sql
Reporter: Yury Gerzhedovich
We still using QueryProcessor#querySingleAsync method in our test framework
(QueryChecker).
As of now there are some test which fails during migrate to
{code:java}
QueryProcessor#queryAsync{code}
As example such test can be used
org.apache.ignite.internal.sql.engine.ItSecondaryIndexTest#testSelectWithRanges
Let's investigate the reason, fix it and migrate QueryChecker to queryAsync
method.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-18289) Try native-image compilation for Ignite CLI
[ https://issues.apache.org/jira/browse/IGNITE-18289?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Aleksandr resolved IGNITE-18289. Resolution: Fixed > Try native-image compilation for Ignite CLI > --- > > Key: IGNITE-18289 > URL: https://issues.apache.org/jira/browse/IGNITE-18289 > Project: Ignite > Issue Type: Improvement > Components: cli >Reporter: Mikhail Pochatkin >Assignee: Aleksandr >Priority: Major > Labels: ignite-3, ignite-3-cli-tool > > * Check GraalVM native-image compilation for Ignite CLI > * Provide metrics of start time, command execution, compilation time -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18289) Try native-image compilation for Ignite CLI
[ https://issues.apache.org/jira/browse/IGNITE-18289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17654436#comment-17654436 ] Aleksandr commented on IGNITE-18289: Compilation time changed from ~6-10s to ~2 mins. > Try native-image compilation for Ignite CLI > --- > > Key: IGNITE-18289 > URL: https://issues.apache.org/jira/browse/IGNITE-18289 > Project: Ignite > Issue Type: Improvement > Components: cli >Reporter: Mikhail Pochatkin >Assignee: Aleksandr >Priority: Major > Labels: ignite-3, ignite-3-cli-tool > > * Check GraalVM native-image compilation for Ignite CLI > * Provide metrics of start time, command execution, compilation time -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18289) Try native-image compilation for Ignite CLI
[ https://issues.apache.org/jira/browse/IGNITE-18289?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17654433#comment-17654433 ] Aleksandr commented on IGNITE-18289: Some basic measurements showed ~x100 performance boost in case GraalVM was used. It requires some additional annotations for Micronaut beans, generated pojos, and resources. Also, some logger configurations should be changed. > Try native-image compilation for Ignite CLI > --- > > Key: IGNITE-18289 > URL: https://issues.apache.org/jira/browse/IGNITE-18289 > Project: Ignite > Issue Type: Improvement > Components: cli >Reporter: Mikhail Pochatkin >Assignee: Aleksandr >Priority: Major > Labels: ignite-3, ignite-3-cli-tool > > * Check GraalVM native-image compilation for Ignite CLI > * Provide metrics of start time, command execution, compilation time -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-17951) Sql. Enlist partitions to rw transaction
[ https://issues.apache.org/jira/browse/IGNITE-17951?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pavel Pereslegin reassigned IGNITE-17951: - Assignee: Pavel Pereslegin > Sql. Enlist partitions to rw transaction > > > Key: IGNITE-17951 > URL: https://issues.apache.org/jira/browse/IGNITE-17951 > Project: Ignite > Issue Type: Improvement > Components: sql >Reporter: Konstantin Orlov >Assignee: Pavel Pereslegin >Priority: Major > Labels: ignite-3 > > In order to support distributed query execution with RW transaction, we need > prepare the transaction before actual execution. > Looks like we only need to enlist the involved partitions to the transaction. > That could be made right after the query mapping phase. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Assigned] (IGNITE-18500) HybridTimestamp defines equals(), but not hashCode()
[ https://issues.apache.org/jira/browse/IGNITE-18500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Roman Puchkovskiy reassigned IGNITE-18500: -- Assignee: Roman Puchkovskiy > HybridTimestamp defines equals(), but not hashCode() > > > Key: IGNITE-18500 > URL: https://issues.apache.org/jira/browse/IGNITE-18500 > Project: Ignite > Issue Type: Improvement >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] [Created] (IGNITE-18500) HybridTimestamp defines equals(), but not hashCode()
Roman Puchkovskiy created IGNITE-18500: -- Summary: HybridTimestamp defines equals(), but not hashCode() Key: IGNITE-18500 URL: https://issues.apache.org/jira/browse/IGNITE-18500 Project: Ignite Issue Type: Improvement Reporter: Roman Puchkovskiy Fix For: 3.0.0-beta2 -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-18496) Handle documentation feedback
[ https://issues.apache.org/jira/browse/IGNITE-18496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17654387#comment-17654387 ] Igor Gusev commented on IGNITE-18496: - * Feedback 100 - removed Deployment from kubernetes configuration * Feedback 99 - fixed an SQL example on affinity collocation page * Feedback 98 - changed text to reflect three data points in CDC doc * Feedback 96 - changed CDC doc to be per data region * Feedback 94 - fixed a link * Feedback 93, 92 - changed CDC doc to be per data region * Feedback 91 - fixed a typo on network configuration page * Feedback 88 - added a missed dependency to spring data doc * Feedback 86, 85 - fixed links to examples on index page * Feedback 82 - fixed queryParallelism typo > Handle documentation feedback > - > > Key: IGNITE-18496 > URL: https://issues.apache.org/jira/browse/IGNITE-18496 > Project: Ignite > Issue Type: Task >Reporter: Igor Gusev >Priority: Major > Time Spent: 10m > Remaining Estimate: 0h > > We have had bugyard for a while, and there is a lot of useful feedback on > documentation. Its time to go through it and fix all issues. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-15568) Striped Disruptor doesn't work with JRaft event handlers properly
[
https://issues.apache.org/jira/browse/IGNITE-15568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladislav Pyatkov updated IGNITE-15568:
---
Description:
The following scenario is broken:
# Two raft groups are started and mapped to the same stripe.
# Two LogEntryAndClosure events are added in quick succession so they form
distruptor batch: first for group 1, second for group 2.
First event is delivered to group 1 with endOfBatch=false, so it's cached in
org.apache.ignite.raft.jraft.core.NodeImpl.LogEntryAndClosureHandler#tasks and
is not processed.
Second event is delivered to group 2 with endOfBatch=true and processed, but
first event will remain in queue unprocessed forever, because
LogEntryAndClosureHandler are different instances per raft group.
The possible WA for this is to set
org.apache.ignite.raft.jraft.option.RaftOptions#applyBatch=1
Reproducible by
org.apache.ignite.internal.table.TxDistributedTest_1_1_1#testCrossTable +
applyBatch=32 in ignite-15085 branch
*Implementation notes*
My proposal goes bound Disruptor. The striped disruptor implementation has an
interceptor that proposes an event to a specific interceptor. Only the last
event in the batch has a completion batch flag. For the other RAFT groups,
which has been notified in the striped disruptor, required to create an event
to fix a batch into the specific group. The new event will be created in the
common striped disruptor interceptor, and it will send to a specific
interceptor with flag about batch completion.
The rule of handling the new event is differenced for various interceptor:
{code:java|title=title=ApplyTaskHandler (FSMCallerImpl#runApplyTask)}
if (maxCommittedIndex >= 0) {
doCommitted(maxCommittedIndex);
return -1;
}
{code}
{code:java|title=LogEntryAndClosureHandler(LogEntryAndClosureHandler#onEvent)}
if (this.tasks.size() > 0) {
executeApplyingTasks(this.tasks);
this.tasks.clear();
}
{code}
{code:java|title=ReadIndexEventHandler(ReadIndexEventHandler#onEvent)}
if (this.events.size() > 0) {
executeReadIndexEvents(this.events);
this.events.clear();
}
{code}
{code:java|title=StableClosureEventHandler(StableClosureEventHandler#onEvent)}
if (this.ab.size > 0) {
this.lastId = this.ab.flush();
setDiskId(this.lastId);
}
{code}
Also in bound of this issue, required to rerun benchmarks. Those are expected
to dhow increasing in case with high parallelism in one partition.
There is [an example of the
benchmark|https://github.com/gridgain/apache-ignite-3/tree/4b9de922caa4aef97a5e8e159d5db76a3fc7a3ad/modules/runner/src/test/java/org/apache/ignite/internal/benchmark].
was:
The following scenario is broken:
# Two raft groups are started and mapped to the same stripe.
# Two LogEntryAndClosure events are added in quick succession so they form
distruptor batch: first for group 1, second for group 2.
First event is delivered to group 1 with endOfBatch=false, so it's cached in
org.apache.ignite.raft.jraft.core.NodeImpl.LogEntryAndClosureHandler#tasks and
is not processed.
Second event is delivered to group 2 with endOfBatch=true and processed, but
first event will remain in queue unprocessed forever, because
LogEntryAndClosureHandler are different instances per raft group.
The possible WA for this is to set
org.apache.ignite.raft.jraft.option.RaftOptions#applyBatch=1
Reproducible by
org.apache.ignite.internal.table.TxDistributedTest_1_1_1#testCrossTable +
applyBatch=32 in ignite-15085 branch
*Implementation notes*
My proposal goes bound Disruptor. The striped disruptor implementation has an
interceptor that proposes an event to a specific interceptor. Only the last
event in the batch has a completion batch flag. For the other RAFT groups,
which has been notified in the striped disruptor, required to create an event
to fix a batch into the specific group. The new event will be created in the
common striped disruptor interceptor, and it will send to a specific
interceptor with flag about batch completion.
The rule of handling the new event is differenced for various interceptor:
{code:java|title=title=ApplyTaskHandler (FSMCallerImpl#runApplyTask)}
if (maxCommittedIndex >= 0) {
doCommitted(maxCommittedIndex);
return -1;
}
{code}
{code:java|title=LogEntryAndClosureHandler(LogEntryAndClosureHandler#onEvent)}
if (this.tasks.size() > 0) {
executeApplyingTasks(this.tasks);
this.tasks.clear();
}
{code}
{code:java|title=ReadIndexEventHandler(ReadIndexEventHandler#onEvent)}
if (this.events.size() > 0) {
executeReadIndexEvents(this.events);
this.events.clear();
}
{code}
{code:java|title=StableClosureEventHandler(StableClosureEventHandler#onEvent)}
if (this.ab.size > 0) {
this.lastId = this.ab.flush();
setDiskId(this.lastId);
}
{code}
> Striped Disruptor doesn't work with JRaft event handlers properly
> -
>
> Key:
[jira] [Created] (IGNITE-18499) Make IncomingSnapshotCopier behave closer to LocalSnapshotCopier
Roman Puchkovskiy created IGNITE-18499:
--
Summary: Make IncomingSnapshotCopier behave closer to
LocalSnapshotCopier
Key: IGNITE-18499
URL: https://issues.apache.org/jira/browse/IGNITE-18499
Project: Ignite
Issue Type: Improvement
Reporter: Roman Puchkovskiy
Fix For: 3.0.0-beta2
There are a few differences between {{IncomingSnapshotCopier}} and
{{{}LocalSnapshotCopier{}}}. JRaft seems to be very sensitive to little changes
in behavior because it relies on many invariants, some of them implicit, to
function correctly. Hence it is best to have our copier mimic the stock one as
fully as possible (where it's feasible).
Here are the differences:
# On cancellation, the copier should be transferred to an erroneous state
(using {{{}setError(){}}})
# On closure, the copier should be cancelled
# The stock copier does not invoke {{join()}} on cancellation, but our
implementation does. On the one hand, waiting seems to make sense because it
allows to save retries, but it's a difference from the stock logic which might
be dangerous.
# We should only set error if it has not been set yet; but our copier
implementation usually does the opposite: if there is an error, it sets some
other error
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Created] (IGNITE-18498) InstallSnapshot request might be retried immediately
Roman Puchkovskiy created IGNITE-18498:
--
Summary: InstallSnapshot request might be retried immediately
Key: IGNITE-18498
URL: https://issues.apache.org/jira/browse/IGNITE-18498
Project: Ignite
Issue Type: Bug
Reporter: Roman Puchkovskiy
{{InstallSnapshot}} request is repeated after the corresponding timeout if a
response to the first request is not received in time. But in one test run,
second {{InstallSnapshot}} request was sent 1 millisecond after the first one
(before the response from the first one was received). This needs an
investigation.
See {{{}ItTableRaftSnapshotsTest{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Resolved] (IGNITE-17262) Implement RAFT snapshot streamer
[
https://issues.apache.org/jira/browse/IGNITE-17262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roman Puchkovskiy resolved IGNITE-17262.
Fix Version/s: 3.0.0-beta2
Resolution: Done
Closing as this is an umbrella ticket and all its sub-tickets are resolved.
> Implement RAFT snapshot streamer
>
>
> Key: IGNITE-17262
> URL: https://issues.apache.org/jira/browse/IGNITE-17262
> Project: Ignite
> Issue Type: Improvement
>Reporter: Roman Puchkovskiy
>Assignee: Roman Puchkovskiy
>Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Infrastructure for this should be implemented in IGNITE-17253 .
> In this ticket, streaming using this infrastructure (along with changes to
> write commands/their handling) should be implemented.
> See IGNITE-17083
> h3. UPDATE
> Infrastructure is ready in IGNITE-17083, streaming can be implemented right
> now even without storage API (with non-implemented storage methods or even
> placeholders). Please see {{IncomingSnapshotCopier}} and related classes in
> other packages for details.
>
> This is an umbrella ticket.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Commented] (IGNITE-18199) Make punch holes in partitions files during restoration of snapshot
[
https://issues.apache.org/jira/browse/IGNITE-18199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17654344#comment-17654344
]
Ignite TC Bot commented on IGNITE-18199:
{panel:title=Branch: [pull/10468/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/10468/head] Base: [master] : New Tests
(1)|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}
{color:#8b}Disk Page Compressions 1{color} [[tests
1|https://ci2.ignite.apache.org/viewLog.html?buildId=6978817]]
* {color:#013220}IgnitePdsCompressionTestSuite:
SnapshotCompressionBasicTest.testRestoreFullSnapshot_OnLargerTopology[Encryption=false]
- PASSED{color}
{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=6978819buildTypeId=IgniteTests24Java8_RunAll]
> Make punch holes in partitions files during restoration of snapshot
> ---
>
> Key: IGNITE-18199
> URL: https://issues.apache.org/jira/browse/IGNITE-18199
> Project: Ignite
> Issue Type: Improvement
>Affects Versions: 2.14
>Reporter: Ivan Daschinsky
>Assignee: Ivan Daschinsky
>Priority: Major
> Labels: ise
> Fix For: 2.15
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
