h2. Empty Topologies
When all container of a dynamic domain are detached from it, then the topology is empty.
In that case, the empty topology is automatically removed from the registry cluster.
h1. Static Topologies
By definition, static topologies can't be modified once registered in a registry cluster the first time.
But for administrative reasons, it can be desired to clean a topology by deleting it from the registry cluster.
This can be done using the command '{{delete-topology}}' of [Petals Registry CLI|petalsregclisnapshot:Petals Registry CLI 1.3.0-SNAPSHOT]).
h1. Appendix: under the hood
h2. Topology storage
At runtime, the topologies are in practice stored on the registry.
The containers store them there, read them from there, and potentially modify them, which notify the other containers of the topology of the modification.
This is how dynamic topologies are implemented for example.
h2. Standalone container
A container that is alone in its static topology is a standalone container.
It uses a specific in-memory implementation of the registry client which works without an actual running registry.
It can still leave it to join another dynamic topology, see below.
h2. Starting a new topology
When the first container of a topology is started, the topology is not yet stored on the registry, the following thus happens:
- the container reads its own {{topology.xml}} file, and extract the registry information from it,
- it connects to the registry and registers there the topology.
When the other containers of the topology are started, the following happens:
- the container reads its own {{topology.xml}} file, and extract the registry information from it,
- it connects to the registry and read there the topology,
- it ensures it is coherent with its own {{topology.xml}} file to prevent misconfigurations,
- from there on, it uses the data in the topology stored on the registry only.
h2. Joining a topology
When a container joins a topology, it is already in another topology, and the following happens:
- it retrieves the remote topology from another container belonging to it,
- it validates that it can leave its current topology (i.e, if it's dynamic) and join the new one (i.e., if it's dynamic or static but belongs to it),
- it pauses endpoint resolution: no new exchange will be sent by this container,
- it leaves its current topology (other containers of the topology will be notified by the registry): no new exchanges will be received by this container,
- it waits for exchanges to finish being processed,
- it joins the new topology (other containers of the topology will be notified by the registry),
- it registers its endpoints their and exchanges communications are re-established.