Description

Right now, if multiple users are editing the same page in real-time in a cluster setup, they may end up in different real-time sessions depending on the cluster node they are served by. Basically, each cluster node will have its own real-time session. We need to find a way to make sure all users editing the same documents are sharing the same editing session.

Trick the load balancer

The idea would be to force the load balancer to direct any user who starts editing a document which always have an editing session to the right instance.

With XWiki, load balancer are supposed to be configured to be sticky (various features expect a stable session/instance currently). This generally means they put a cookie to remember to which instance the HTTP client was previous sent and keep using this instance (unless the instance does not work, of course).

The idea here would be to share among instance a mapping between open editing session and the instance id and then automatically set the cookie to force going to the right instance one a user starts editing a document with a session open on any instance.

Sharing the mapping should be easy (using jgroup's Map implementation, for example).

The slight challenge comes from knowing:

• the name of the cookie indicating the instance: there is no standard on this, so it means that
  • we should recommend one that XWiki supports by default
  • we should allow indicating in an XWiki configuration what is the cookie, in case the standard XWiki one cannot be used
• the value of the cookie indicating the instance:
  • if the load balancer let the cookie go through to XWiki: we could maintain a mapping between the instance and the value of the cookie
  • if the load balancer removes the cookie before sending the request to XWiki: we could automaticlaly gather and share that values with other cluster members (in the shared mapping mentionned above, for example)
    • Recommend to use the actual observation/cluster id as cookie value if the load balancer can be configured
    • Configure XWiki to indicate the mapping between an instance and its corresponding cookie value

•  Special setup required (but not that complex, especially for someone who is in charge of configuring a load balancer)
•  Very simple
•  No conflict
•  If the main instance crashes, the edit session is lost (but the realtime editor does regular autosaves)
•  If any other tab is currently in the middle of something which require a stable session/instance, it will be broken

•  Can be used for various other use cases, until they have proper clustering setup

Replicate editing session

The idea here is to keep having an editing session in each instance, but they would be replicated between instances.

The problem is that this can produce a lot of conflicts because the protocol is not designed for this kind of decentralized setup.

•  No special setup required
•  Very complex implementation
•  Important risk of conflicts
•  If an instance crashes, it does not have any impact on the realtime edition
•  No impact on the user session/instance

Single editing session

The idea here is to, like in the case of the load balancer hack, decide which instance hold the editing session. But instead of directing all clients to it, we could make all instances act as proxies to the instance which is holding the editing session.

•  No special setup needed
•  Complex implementation (but a lot less complex than replication). Pentially makes editing slower on the "wrong" instances (but maybe it won't be noticeable with a good network between nodes since patches are usually small)
•  No conflicts
•  If the main instance crashes, the edit session is lost (but the realtime editor does regular autosaves, so the content is usually not lost)
•  No impact on the user session/instance