The Nuxeo Drive synchronized roots cache is not cluster aware and might cause inconsistencies for the sync client

NuxeoDriveManagerImpl#cache is a JVM hosted map hence not shared between the nodes of a Nuxeo cluster: this might hide new root registrations or root unregistration changes hence make the output of the GetChangeSummary inconsistent.

Quick possible workarounds:

• make the nuxeo drive client cookie aware and configure the Elastic Load Balancer to set sticky sessions cookies to ensure that each client will always end up in the same node and hence cache instance. This will make the inconsistency problem disappear when there is 1 device configured per client but there could still be delays when the user selects a new workspace to be synchronized from the Nuxeo User interface.

• add the username as a new http header and configure any non ELB load balancer to use that header to have node affinity to get a consistent cache view from the client point of view but there could still be delays when the user selects a new workspace to be synchronized.

Possible real fixes:

• Make the NuxeoDriveManagerImpl.getSynchronizationRoots perform a hopefully cheap audit query (with a monotonic timestamp incremented each time) to detect rootRegistered and rootUnregistered events and hence ensure cache consistency explicitly: this adds a new SQL query to the audit table.

• Use a dedicated document model marker in the VCS just to store cache invalidation info (for instance a facet on the user workspace of each user that would store the date of the last registration / unregistration event): the VCS cache should be able to and we would benefit from the cluster awareness of the VCS to ensure consistency in of the cache invalidation in NuxeoDriveManagerImpl.getSynchronizationRoots.

• Disable the cache of NuxeoDriveManagerImpl.getSynchronizationRoots: this can have big negative impact on the load of the server and DB as it would add many more non cacheable NXQL queries to the repo: it would require some benchmark and profiling to tell whether this is an issue

• Refactor the way we store the root registration info in a way that makes it possible to use cheap NXQL queries that can leverage the VCS cache: possibly much wider impact on the code and I am not sure that the VCS cache will be able to absorb all unnecessary DB access (need investigation).