Use the circular buffer for events in ModeShape 4.0

Use the circular buffer for events in ModeShape 4.0

Events are critical to ModeShape. When your application saves some changes to the page, ModeShape will generate events describing those changes and send those events to all your registered application listeners. No matter which cluster generates these changes or which part of your listener in the cluster listens to, make sure that each listener listens to all the changed events as much as possible.

However, your application cannot only respond to events: ModeShape itself has a considerable number of listeners that are allowed to listen and feedback those consistent changes. Many ModeShape listeners respond to those changes on your page, and other built-in listeners also reply to those changes through ModeShape. How can we do this? ModeShape stores metadata of various types of systems in its storage areas (namespace, definition of node types, locks, versions, index definitions, federated projections, and so on. When any metadata is changed and remains in a cluster process, it will only notify other processes in the cluster through the event.

For example, when your application registers a new namespace prefix/URI pair, ModeShape is reflected in the local namespace (NamespaceRegistry) register the instance to the cache in the memory and immediately start the continuous information (forwarding ). But what about NamespaceRegistry instances in other clusters? They use a listener to view changes to system metadata in the namespace area, and they can immediately observe a new namespace for event description (remote) NamespaceRegistry) the instance can immediately update their cache in the memory. Therefore, all sessions are registered in the same namespace as the cluster from start to end.

ModeShape has many components that use events in the same way: Index, lock, version, workspace addition/removal, and full-storage settings.

ChangeSet and ChangeBus

To register a listener, the application must implement the javax. jcr. observation. EventListener interface, and then register an instance using the ObservationManager In the workspace. Standard JCR events can be used to describe the basic information for creating, moving, or deleting a node. This is also true when an attribute is added, changed, or deleted. But that's all.

Internally, ModeShape adopts richer and finer-grained events. Each time a transaction is committed (whether a single session is saved or multiple stores), the description of all changes made by the commit is bound to a single ChangeSet. These changesets are actually carried in the cluster in ModeShape. All the internal components of ModeShape are written to respond to them by implementing and registering the internal ChangeSetListener interface. Interestingly, every time your application registers an instance with a new event listener, ModeShape registers an internal ChangeSetListener implementation, but instead sets each ChangeSet (and the changes described) convert to a set of standard JCREvent objects.

 

Each Repository instance has a ChangeBus component that tracks all ChangeSet listeners and directs all changesets to those listeners. Multiple internal components first send ChangeSet objects to ChangeBus, and then ChangeBus send these ChangeSet objects to each listener. It is vital to complete these actions quickly and accurately. For example, a listener should not interfere with or interfere with other listeners. In addition, a listener should listen to all events in the same command.

If ModeShape is used as a cluster, ChangeBus must meet the same requirements, but there is a difference: When a component sends a ChangeSet, this ChangeSet will be immediately sent to all members of the Cluster through JGroups. On each process, JGroups sends the ChangeSet object to ChangeBus, and ChangeBus sends the ChangeSet to all local listeners in sequence. In this way, JGroups ensures that all processes see the same command of the ChangeSet object.

Needless to say, ChangeBus is very important and complex. In version 2.x, the initial design occupies a small space in version 3.x, but we will show in version 4.0 that it has been completely patched.

2. x and 3.x ChangeBus

ModeShape 2. x and 3.x use a fairly simple design implementation of ChangeBus: each listener has a "consumer" thread that is constantly running. The ChangeSet object pops up in the queue first after the listener is blocked, and call the actual listener. When a new ChangeSet is added to the bus, ChangeBus adds the ChangeSet to the front of the queue for each listener.

 

Each listener thread consumes ChangeSet objects from its own blocking queue

This design has some good advantages:

1. The design is quite simple.

2. Each listener is visible to the objects in the ChangeSet in the same order.

3. Each listener runs an independent thread. Therefore, in most cases, each listener is completely isolated from all other listeners (see below ).

4. Because of the blocking queue, if a listener is really slow and the queue is full, ChangeBus will block the attempt to add changeset to the queue. However, this slows down the system (especially the modified sessions), resulting in some backend pressure, even though the listener can keep up with it.

For more details, please continue to read the highlights on the next page:

1 2 3 Next Page