[
https://issues.apache.org/jira/browse/IGNITE-24363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-24363:
-------------------------------------
Description:
h3. Motivation
Within colocation track we should reasonably move table-not-specific requests
and commands processing from PartitionReplicaListener and PartitionListener to
ZonePartitionReplicaListener and ZonePartitionRaftListener.
TxCleanupRecoveryRequest is one of such requests to be moved. In this
particular case TxRecoveryMessage is expected to be moved.
h3. Definition of Done
* After both given ticket and
[IGNITE-24361|https://issues.apache.org/jira/browse/IGNITE-24361] (and all
dependencies of course) are implemented transaction recovery should be
available within colocation track.
h3. Implementation Notes
* Initial source for groupId to recover is PRIMARY_REPLICA_ELECTED See
TxManagerImpl#primaryReplicaElectedListener for more details. Thus, besides
ensuring that corresponding event is fired in case of zone primary replica
(meaning checking that TestPlacementDriver does fire such event) it's also
required to properly convert TablePartitionId to ZonePartitionId like we did
previously in similar tickets.
{code:java}
.groupId(toTablePartitionIdMessage(REPLICA_MESSAGES_FACTORY,
tablePartitionId)){code}
* Copy PartitionReplicaListener#processCleanupRecoveryMessage along with
corresponding trigger to ZonePartitionReplicaListener.
* Hide original PartitionReplicaListener#processCleanupRecoveryMessage under
colocation feature flag.
* Implement corresponding smoke test to ensure that transaction recovery works
properly.
was:
h3. Motivation
Within colocation track we should reasonably move table-not-specific requests
and commands processing from PartitionReplicaListener and PartitionListener to
ZonePartitionReplicaListener and ZonePartitionRaftListener.
TxCleanupRecoveryRequest is one of such requests to be moved. In this
particular case TxRecoveryMessage is expected to be moved.
h3. Definition of Done
* After both given ticket and
[IGNITE-24361|https://issues.apache.org/jira/browse/IGNITE-24361] (and all
dependencies of course) are implemented transaction recovery should be
available within colocation track.
h3. Implementation Notes
> Implement TxCleanupRecoveryRequest processing for zone replica
> --------------------------------------------------------------
>
> Key: IGNITE-24363
> URL: https://issues.apache.org/jira/browse/IGNITE-24363
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexander Lapin
> Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> Within colocation track we should reasonably move table-not-specific requests
> and commands processing from PartitionReplicaListener and PartitionListener
> to ZonePartitionReplicaListener and ZonePartitionRaftListener.
> TxCleanupRecoveryRequest is one of such requests to be moved. In this
> particular case TxRecoveryMessage is expected to be moved.
> h3. Definition of Done
> * After both given ticket and
> [IGNITE-24361|https://issues.apache.org/jira/browse/IGNITE-24361] (and all
> dependencies of course) are implemented transaction recovery should be
> available within colocation track.
> h3. Implementation Notes
> * Initial source for groupId to recover is PRIMARY_REPLICA_ELECTED See
> TxManagerImpl#primaryReplicaElectedListener for more details. Thus, besides
> ensuring that corresponding event is fired in case of zone primary replica
> (meaning checking that TestPlacementDriver does fire such event) it's also
> required to properly convert TablePartitionId to ZonePartitionId like we did
> previously in similar tickets.
> {code:java}
> .groupId(toTablePartitionIdMessage(REPLICA_MESSAGES_FACTORY,
> tablePartitionId)){code}
> * Copy PartitionReplicaListener#processCleanupRecoveryMessage along with
> corresponding trigger to ZonePartitionReplicaListener.
> * Hide original PartitionReplicaListener#processCleanupRecoveryMessage under
> colocation feature flag.
> * Implement corresponding smoke test to ensure that transaction recovery
> works properly.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
