Using shadows

Neutrino's pathname space gives us some interesting choices when the time comes to design our warm or hot standby servers. Recall that the pathname space is maintained by the process manager, which is also the entity responsible for creation and cleanup of processes. One thing that's not immediately apparent is that you can have multiple processes registered for the same pathname, and that you can have a specific order assigned to pathname resolution.

Shadow paths Figure 1. Primary and secondary servers registered for the same pathname.

A common trick for designing warm and hot standby servers is for the secondary to register the same pathname as the primary, but to tell the process manager to register it behind the existing pathname. Any requests to the pathname will be satisfied by the primary (because its pathname is "in front" of the secondary's pathname). When the primary fails, the process manager cleans up the process and also cleans up the pathname registered by the primary — this uncovers the pathname registered by the secondary.

Secondary pathname Figure 2. The secondary server is exposed when the primary fails.

When we say that a client reconnects to the server, we mean that literally. The client may notice that its connection to /dev/ser1 has encountered a problem, and as part of its recovery it tries to open /dev/ser1 again — it can assume that the standby module's registered pathname will be exposed by the failure of the primary.