Mikhail Pochatkin created IGNITE-19708:
------------------------------------------
Summary: Check refcounter of unit before undeploy
Key: IGNITE-19708
URL: https://issues.apache.org/jira/browse/IGNITE-19708
Project: Ignite
Issue Type: Improvement
Reporter: Mikhail Pochatkin
# Change clusterDURecord.status to OBSOLETE value. This operation could fail
because another process has already changed status to OBSOLETE or REMOVING
value. It is also impossible to start an undeployment process in case the
deployment process is still in progress.
After this step the deployment unit is not available for new code execution.
Code execution in progress still can use this deployment unit.
# Meta storage event must be fired to all target nodes due to a change of
clusterDURecord.status.
# After receiving this event by the target node the system must change
nodeDURecord.status to OBSOLETE value.
# The node waits for finishing of all code executions in progress that depend
on this deployment unit. As soon as all code executions are finished
nodeDURecord.status must be changed to REMOVING value.
>From this point it is impossible to use the deployment unit for code execution
>neither for new tasks nor for old tasks (the second is impossible due to the
>invariant that all old tasks are finished).
# For each change of nodeDURecord.status to REMOVING value the system is able
to receive an event from meta storage and check that all nodes have
nodeDURecord.status == REMOVING. If the condition is met then
clusterDURecord.status must be changed to REMOVING too.
# Now the deployment unit can be removed from each target node and, after it,
remove corresponding status records.
# For each removal of nodeDURecord record from meta storage the system is able
to receive an event from meta storage and check that there are no any
nodeDURecord records for the given deployment unit. Now the system must remove
the clusterDURecord record for the deployment unit.
Note that If the deployment unit was removed then there are no any class
loaders associated with this deployment unit. Eventually the class loader
should be collected by GC and all classes must be unloaded from JVM. It is the
critical requirement in order to avoid memory leaks related to multiple class
loading/unloading.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
