Wiki source code of Distributed Events
Last modified by Vincent Massol on 2024/11/19 16:12
Show last authors
| author | version | line-number | content |
|---|---|---|---|
| 1 | {{toc/}} | ||
| 2 | |||
| 3 | == Goal == | ||
| 4 | |||
| 5 | Make all the XWikis instances in the same network group share the events. When something append on a wiki instance it automatically send the same event which is used internally to react to this modification to other clients of the same network group. | ||
| 6 | |||
| 7 | == Why == | ||
| 8 | |||
| 9 | There is several use cases for it: | ||
| 10 | |||
| 11 | (% style="list-style-type: square" %) | ||
| 12 | * clustering: basically most of the code in XWiki react or produce events linked to the cache management, when a document is deleted an event is generated, etc... so making event synchronization make clustering based on the same database which basically mean make sure that all the cache of all the forms are synchronised between all the XWiki instances in the same cluster | ||
| 13 | * another communication canal with xwiki: we could have any kind of tools which would like to receive events of the XWiki instance to update itself to print something like the IRC bot of #xwiki chan which print any modification made in xwiki.org | ||
| 14 | |||
| 15 | == Proposal == | ||
| 16 | |||
| 17 | No need to change anything to the current events API since Observation Manager is very generic. Also it's better to make distribution events component a separated component to make sure Observation Manager does not depends on it. | ||
| 18 | |||
| 19 | Lets call it Remote Observation Manager. | ||
| 20 | |||
| 21 | === Events transport === | ||
| 22 | |||
| 23 | ==== Send events ==== | ||
| 24 | |||
| 25 | Each events generated by Observation Manager is encapsulated and sent: | ||
| 26 | |||
| 27 | (% style="list-style-type: square" %) | ||
| 28 | * if this event is not a distributed event | ||
| 29 | * if this events is not disabled for remote distribution | ||
| 30 | |||
| 31 | ==== Receive events ==== | ||
| 32 | |||
| 33 | Each received remote event is injected using Observation Manager. | ||
| 34 | |||
| 35 | ==== Events filters/configuration ==== | ||
| 36 | |||
| 37 | Need to fine a clean and generic way to transform local event to remote event. A remote event need to be serializable and lot's of data in local events should not be sent, for example we send only document name and version or it will be too much information. The goal is not to do another P2P system. | ||
| 38 | |||
| 39 | It should be possible to configure for each kind of events if it has to be send remotely or not (we could even imagine events to send only remotely maybe). For example the component manager events or viewed pages are useless for a cluster and will only generate a lots of useless network traffic. | ||
| 40 | |||
| 41 | The idea is to have events converters called by Remote Observation Manager to convert local events to remote events and the other way around. A set of standard converter is provided for the standard events. That way it's very easy to enable/disable an event and filter anything we want to transport exactly what is needed. When no converter is provided the event is sent as it is. | ||
| 42 | |||
| 43 | Latter we could make possible for instance of a same network groups to send each other their own converters. A non XWiki instance could want to receive viewing events and only them for example to do some authoring or anything we can imagine. But it's really not strongly needed yet. | ||
| 44 | |||
| 45 | ==== Create a communication canal to send and receive actual network events ==== | ||
| 46 | |||
| 47 | There are lots of existing tools to easily do this. We need to decide which one to choose. | ||
| 48 | |||
| 49 | Here are some of them: | ||
| 50 | |||
| 51 | (% style="list-style-type: square" %) | ||
| 52 | * [[jgroups>>http://www.jgroups.org/]]: this is lowest level one. Support a lot of options and protocols. | ||
| 53 | * [[hazelcast>>http://www.hazelcast.com/]]: looks like the easiest to use and it is focused on our main needs. It's the little new one which produce some good noise around in forums and articles. | ||
| 54 | |||
| 55 | JMS implemntations: | ||
| 56 | |||
| 57 | (% style="list-style-type: square" %) | ||
| 58 | * [[ActiveMQ>>http://activemq.apache.org/]]: standard events system implementing [[JSR JMS>>http://jcp.org/en/jsr/detail?id=914]], seems the biggest one (community, activity, features) | ||
| 59 | * [[OpenMQ>>https://mq.dev.java.net/]]: younger concurrent of ActiveMQ. Seems great but it's not fully java (there is some native parts) so it would make distribution in XE a pain even if it's make it have better performances than ActiveMQ. | ||
| 60 | * [[JBoss Messaging>>http://jboss.org/jbossmessaging/]]: another JMS implementation from JBoss | ||
| 61 | * [[JORAM>>http://joram.ow2.org/]]: another JMS implementation | ||
| 62 | * ... | ||
| 63 | |||
| 64 | JGoups is very light and contains everything we need with a simple interface (see http://www.jgroups.org/api.html) so for now it's the winner for me. | ||
| 65 | |||
| 66 | Here is a great configuration files documentation for JGroups: http://www.jboss.org/community/wiki/JGroups | ||
| 67 | |||
| 68 | === Register to remote event === | ||
| 69 | |||
| 70 | Remote Observation Manager should provide some remote version of the Observation Manager standard events matchers (FixedNameEventFilter, RegexEventFilter, etc.) to make easier to register. | ||
| 71 | |||
| 72 | === Make sure everything is using Observation manager instead of the old event system === | ||
| 73 | |||
| 74 | There is still a lot of code using the old events system in xwiki-core. this need to be updated especially for code with cache which need to update it with remote events. |
