[jira] [Commented] (IGNITE-22101) Performance drop for thin client requests
[
https://issues.apache.org/jira/browse/IGNITE-22101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841494#comment-17841494
]
Ignite TC Bot commented on IGNITE-22101:
{panel:title=Branch: [pull/11328/head] Base: [master] : No blockers
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#D6F7C1}{panel}
{panel:title=Branch: [pull/11328/head] Base: [master] : No new tests
found!|borderStyle=dashed|borderColor=#ccc|titleBGColor=#F7D6C1}{panel}
[TeamCity *-- Run :: All*
Results|https://ci2.ignite.apache.org/viewLog.html?buildId=7843453buildTypeId=IgniteTests24Java8_RunAll]
> Performance drop for thin client requests
> -
>
> Key: IGNITE-22101
> URL: https://issues.apache.org/jira/browse/IGNITE-22101
> Project: Ignite
> Issue Type: Bug
>Reporter: Aleksey Plekhanov
>Assignee: Aleksey Plekhanov
>Priority: Major
> Labels: ise
> Attachments: perf_drop.png
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> After IGNITE-21183 there is performance drop for thin client transactional
> operations up to 38%:
> !perf_drop.png|width=1083,height=168!
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
[jira] [Updated] (IGNITE-22130) Fix retry logic for transactions
[ https://issues.apache.org/jira/browse/IGNITE-22130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-22130: --- Description: Recently (IGNITE-21540) retries was introduced for transactions, both explicit and implicit. But the current implementation has flaws: # In embedded mode retries cause recursion (because the future is completed on the same thread), which can lead to stack overflow. # Retries are executed without delay in a loop, which might not give enough time for conflicting lock release, making retries almost useless. # Read operations are not retried but need to. To fix 1 and 2 I suggest to submit a response for retryable operation (if retry is required) to another thread to avoid recursion and introduce retry delay for retriable operations, preferrably with exponential back-off. Fix for 3 is obvious. was: Recently (IGNITE-21540) retries was introduced for transactions, both explicit and implicit. But the current implementation has flaws: # In embedded mode retries cause recursion (because the future is completed on the same thread), which can lead to stack overflow. # Retries executed without delay in a loop, which might not give enough time for conflicting lock release, making retries almost useless. # Read operations are not retried but need to. To fix 1 and 2 I suggest to submit a response for retryable operation (if retry is required) to another thread to avoid recursion and introduce retry delay for retriable operations, preferrably with exponential back-off. Fix for 3 is obvious. > Fix retry logic for transactions > > > Key: IGNITE-22130 > URL: https://issues.apache.org/jira/browse/IGNITE-22130 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > > Recently (IGNITE-21540) retries was introduced for transactions, both > explicit and implicit. > But the current implementation has flaws: > # In embedded mode retries cause recursion (because the future is completed > on the same thread), which can lead to stack overflow. > # Retries are executed without delay in a loop, which might not give enough > time for conflicting lock release, making retries almost useless. > # Read operations are not retried but need to. > To fix 1 and 2 I suggest to submit a response for retryable operation (if > retry is required) to another thread to avoid recursion and introduce retry > delay for retriable operations, preferrably with exponential back-off. > Fix for 3 is obvious. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22130) Fix retry logic for transactions
[ https://issues.apache.org/jira/browse/IGNITE-22130?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-22130: --- Fix Version/s: 3.0 > Fix retry logic for transactions > > > Key: IGNITE-22130 > URL: https://issues.apache.org/jira/browse/IGNITE-22130 > Project: Ignite > Issue Type: Improvement >Reporter: Alexey Scherbakov >Priority: Major > Labels: ignite-3 > Fix For: 3.0 > > > Recently (IGNITE-21540) retries was introduced for transactions, both > explicit and implicit. > But the current implementation has flaws: > # In embedded mode retries cause recursion (because the future is completed > on the same thread), which can lead to stack overflow. > # Retries executed without delay in a loop, which might not give enough time > for conflicting lock release, making retries almost useless. > # Read operations are not retried but need to. > To fix 1 and 2 I suggest to submit a response for retryable operation (if > retry is required) to another thread to avoid recursion and introduce retry > delay for retriable operations, preferrably with exponential back-off. > Fix for 3 is obvious. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Created] (IGNITE-22130) Fix retry logic for transactions
Alexey Scherbakov created IGNITE-22130: -- Summary: Fix retry logic for transactions Key: IGNITE-22130 URL: https://issues.apache.org/jira/browse/IGNITE-22130 Project: Ignite Issue Type: Improvement Reporter: Alexey Scherbakov Recently (IGNITE-21540) retries was introduced for transactions, both explicit and implicit. But the current implementation has flaws: # In embedded mode retries cause recursion (because the future is completed on the same thread), which can lead to stack overflow. # Retries executed without delay in a loop, which might not give enough time for conflicting lock release, making retries almost useless. # Read operations are not retried but need to. To fix 1 and 2 I suggest to submit a response for retryable operation (if retry is required) to another thread to avoid recursion and introduce retry delay for retriable operations, preferrably with exponential back-off. Fix for 3 is obvious. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-21806) Design one PrimaryReplica for many tables partitions inside the one zone
[ https://issues.apache.org/jira/browse/IGNITE-21806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin updated IGNITE-21806: - Issue Type: Task (was: Improvement) > Design one PrimaryReplica for many tables partitions inside the one zone > > > Key: IGNITE-21806 > URL: https://issues.apache.org/jira/browse/IGNITE-21806 > Project: Ignite > Issue Type: Task >Reporter: Kirill Gusakov >Assignee: Alexander Lapin >Priority: Major > Labels: ignite-3 > > *Motivation* > When the IGNITE-18991 we will have ZonePartitionId oriented management inside > the PlacementDriver, but still have the number of replicas, which equals to > the number of tables per partition in the zone. As a iterative step on the > road of "zone based collocation (one RAFT group per zone partition" we must > implement the another approach: one PrimaryReplica for many tables partitions > inside the zone. So, in the case of 2 tables inside the 1 zone we must have 1 > PrimaryReplica per partition. > *Definition of done* > Prepare design and according ticket breakdown for the feature implementation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Resolved] (IGNITE-21806) Design one PrimaryReplica for many tables partitions inside the one zone
[ https://issues.apache.org/jira/browse/IGNITE-21806?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexander Lapin resolved IGNITE-21806. -- Resolution: Fixed > Design one PrimaryReplica for many tables partitions inside the one zone > > > Key: IGNITE-21806 > URL: https://issues.apache.org/jira/browse/IGNITE-21806 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Gusakov >Assignee: Alexander Lapin >Priority: Major > Labels: ignite-3 > > *Motivation* > When the IGNITE-18991 we will have ZonePartitionId oriented management inside > the PlacementDriver, but still have the number of replicas, which equals to > the number of tables per partition in the zone. As a iterative step on the > road of "zone based collocation (one RAFT group per zone partition" we must > implement the another approach: one PrimaryReplica for many tables partitions > inside the zone. So, in the case of 2 tables inside the 1 zone we must have 1 > PrimaryReplica per partition. > *Definition of done* > Prepare design and according ticket breakdown for the feature implementation -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Updated] (IGNITE-22039) Do not allow the index to be scanned in an inconsistent state
[ https://issues.apache.org/jira/browse/IGNITE-22039?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kirill Tkalenko updated IGNITE-22039: - Description: We need to throw an exception if the index is globally (in the catalog) in readable status (AVAILABLE or STOPPING) but locally has not yet been built. See TODO. Upd: I don’t quite understand the task of disaster recovery of indexes; I don’t need this functionality from this ticket and it’s enough to get rid of InconsistentIndexStateException for SortedIndexStorage#tolerantScan. was:We need to throw an exception if the index is globally (in the catalog) in readable status (AVAILABLE or STOPPING) but locally has not yet been built. See TODO. > Do not allow the index to be scanned in an inconsistent state > - > > Key: IGNITE-22039 > URL: https://issues.apache.org/jira/browse/IGNITE-22039 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > We need to throw an exception if the index is globally (in the catalog) in > readable status (AVAILABLE or STOPPING) but locally has not yet been built. > See TODO. > Upd: > I don’t quite understand the task of disaster recovery of indexes; I don’t > need this functionality from this ticket and it’s enough to get rid of > InconsistentIndexStateException for SortedIndexStorage#tolerantScan. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] [Commented] (IGNITE-22039) Do not allow the index to be scanned in an inconsistent state
[ https://issues.apache.org/jira/browse/IGNITE-22039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17841410#comment-17841410 ] Kirill Tkalenko commented on IGNITE-22039: -- I don’t quite understand the task of disaster recovery of indexes; I don’t need this functionality from this ticket and it’s enough to get rid of InconsistentIndexStateException for SortedIndexStorage#tolerantScan. > Do not allow the index to be scanned in an inconsistent state > - > > Key: IGNITE-22039 > URL: https://issues.apache.org/jira/browse/IGNITE-22039 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > We need to throw an exception if the index is globally (in the catalog) in > readable status (AVAILABLE or STOPPING) but locally has not yet been built. > See TODO. -- This message was sent by Atlassian Jira (v8.20.10#820010)
[jira] (IGNITE-22039) Do not allow the index to be scanned in an inconsistent state
[ https://issues.apache.org/jira/browse/IGNITE-22039 ] Kirill Tkalenko deleted comment on IGNITE-22039: -- was (Author: ktkale...@gridgain.com): I don’t quite understand the task of disaster recovery of indexes; I don’t need this functionality from this ticket and it’s enough to get rid of InconsistentIndexStateException for SortedIndexStorage#tolerantScan. > Do not allow the index to be scanned in an inconsistent state > - > > Key: IGNITE-22039 > URL: https://issues.apache.org/jira/browse/IGNITE-22039 > Project: Ignite > Issue Type: Improvement >Reporter: Kirill Tkalenko >Assignee: Kirill Tkalenko >Priority: Major > Labels: ignite-3 > Fix For: 3.0.0-beta2 > > Time Spent: 0.5h > Remaining Estimate: 0h > > We need to throw an exception if the index is globally (in the catalog) in > readable status (AVAILABLE or STOPPING) but locally has not yet been built. > See TODO. -- This message was sent by Atlassian Jira (v8.20.10#820010)
