[
https://issues.apache.org/jira/browse/IGNITE-27466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-27466:
-------------------------------------
Labels: ignite-3 (was: )
> Handle abandoned resources for destroyed zones in catalog
> ---------------------------------------------------------
>
> Key: IGNITE-27466
> URL: https://issues.apache.org/jira/browse/IGNITE-27466
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexander Lapin
> Priority: Major
> Labels: ignite-3
>
> On node restart, in case of not null LWM earliest catalog version will be
> calculated as
> {code:java}
> catalogService.activeCatalogVersion(lwm.longValue(){code}
> In that case, destructionEventsQueue won't be populated with
> DestroyZoneEvent, and thus abandoned zone resources won't be handled. Proper
> abandoned resource handling assumes corresponding zone partitions startup if
> there are records in txStateStorage (it's required since corresponding
> records might be used for WI resolution), otherwise all zone resources should
> be dropped.
> * TableManager#cleanUpResourcesForDroppedTablesOnRecoveryBusy might be used
> as a reference of how to detect abandoned resources.
> * PartitionReplicaLifecycleManager#removeZonePartitionsIfPossible might be
> used as a reference of resources to be dropped on cleanup.
> There are at least two alternative approaches:
> * Prevent catalog compaction, if there are non-handled dropped resources and
> evaluate earliestCatalogVersion as
> catalogService.earliestCatalogVersion(). In that case destructionEventsQueue
> repopulation will do the trick:
> {code:java}
> if (nextCatalog0 != null && nextCatalog0.zone(zoneId) == null) {
> destructionEventsQueue.enqueue(new
> DestroyZoneEvent(nextCatalog0.version(), zoneId));
> }{code}
> * Or it's possible to persist destructionEventsQueue on it's own.
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
