Loss of ability by ProfileService to connect to its persiste

[brian.stansberry]

An issue I remember seeing in a 4.x support case was a lost connection to an NFS share where deploy/ was located led to the undeploy of all content from the server. Does the ProfileService have any logic to defend against this kind of thing?

I'm wondering because people are asking about an AS 5 alternative to farming, and using a shared repository is one possible approach.

[starksm64]

No, if the check of the vfs file says its gone the deployment is undeployed. Now that the control of what has changed, been removed is a function of the profile, this can be easily changed, but what's the logic that differentiates someone removing deploy vs it simply being unavailable?

[starksm64]

I guess there could be a check if the common root (deploy) is gone vs only the deployment being removed.

If we move to a proper notion of subprofiles, then an ha-profile could have completely different logic for determining removed deployments as well.

[brian.stansberry]

Yeah, I was thinking in terms of treating the root being gone as being an exception condition that leaves the runtime state in place.

Can you give an example of how the logic would be different for an ha-profile?

[starksm64]

Just that the ha-profile would use the logic while the local ones would not.