Description

Right now when an extension install job is started other cluster members are notified to apply it too.

The remaining limitation is that if a member is down when an extension is installed it won't know about it.

The is two use cases:

• the member looses the network: it needs to detect when it get back and ask for new extension installed/removed
• the member is down: it should have access to the "right" installed extensions index

A - Re-send messages when cluster member comes back

No matter how long they have to wait. It's possible there is something in JGroups for that, at worst it's easy to do our own protocol extending some other like TPC and adding serialized message queues and fixed list of members. Another possibility is to add a JMS network adapter (see Remote Observation documentation) and let JMS server take care of that.

• pros:
  • nothing special to worry about in XWiki modules (except for the network adapter itself of course)
• cons:
  • if something bad happen to however have not sent messages (local queue, JMS server, etc.) some member could be out of sync for good
  • JMS based solution require more setup since a JMS server has to be installed somewhere

• JGroups configuration: nothing to do on XWiki side if the right JGroups setup can be found so I guess a few days of reading the documentation or probably better simply ask JGroups guys that are probably much more competent than we are on the subject
• JMS client network adapter: JMS API does not seems too complicated and XWiki message already have the constraint of being Serializable.
• Custom JGroups protocol: this one is mostly about serializing messages to send to the filesystem to not loose them and having one thread per configured cluster member sending and removing them one by one until the member answer it got it.

B - Store installed extensions index in a common database

Store the installed extension index in the database instead of the local repository.

• pros
  • reuse XWiki database
  • nothing to setup for the user
  • make backups easier (no need to backup extension from permdir anymore)
  • easier to search in it
  • not matter how badly out of sync the node is restarting it will fix it
• cons
  • when the standard XWiki database access is ready it's too late for a lot of extensions (listener, etc) so the installed extensions repository will needs its own database access
  • does not support simple network loss (the node has to be restarted to get back in sync)

• implementation:
  • write a whole new org.xwiki.extension.repository.InstalledExtensionRepository component. The simplest is to reuse org.xwiki.extension.repository.internal.installed.DefaultInstalledExtensionRepository and just change the way to store and load installed extension metadata
  • either expose a dedicated database configuration or extract needed information from the standard hibernate.cfg.xml (database, user, pass, driver, etc.) configuration file
  • the installed extension index will probably just need 1 table with extension id, namespace, boolean to indicate if it's been installed as dependency

C - Share filesystem extensions index between cluster members

Using something like NFS. org.xwiki.extension.repository.internal.local.DefaultLocalExtensionRepository will need some bulletproofing to better support file locking related issues (download in temporary file and then copy, etc.).

• pros
  • not much to do
  • not matter how badly out of sync the node is restarting it will fix it
• cons
  • more setup work for the user
  • does not support simple network loss (the node has to be restarted to get back in sync)
  • a bit hackish

Need to bulletproof org.xwiki.extension.repository.internal.local.DefaultLocalExtensionRepository and org.xwiki.extension.repository.internal.local.LocalExtensionStorage to not worry too much about locked files and test a bit more existing stuff