Asset create, update, and delete operations are much slower than the read operation. Sometimes, you may prefer that these operations occur at a future time with the guarantee of eventual consistency. That is, in case of a delayed (buffered) operation, the WebCenter Sites platform surely receives the change at some finite, undetermined period of time. Although buffering operations are extremely fast, they do not speed up the total time that you need to create, update, and delete assets in the platform.
Topics:
The current implementation of buffering subsystem relies on Java Messaging Service (JMS) technology. It has two components, buffering producer and buffering consumer. The producer produces messages and puts them into the Messaging Queue (MQ). The consumer picks messages from MQ and persists them in the platform.
Figure 64-1 Buffering System Architecture
The buffering producer can be used on both WebCenter Sites and Remote Satellite Server, where the asset REST service <BaseURI>/sites/<sitename>/types/<assettype>/assets/<id>
is available. When used on Remote Satellite Server, the buffering producer does not communicate with WebCenter Sites, which ensures linear scalability of the entire system.
Note:
The buffering consumer is available only on WebCenter Sites. We recommend enabling the buffering consumer only on the primary cluster member. Enabling on multiple cluster members cannot guarantee that the sequence of CRUD operations will be preserved.
If you would like to use buffering, go ahead and enable the buffering option in the BufferingConfig.xml
file.
The default BufferingConfig.xml
file, provided with WebCenter Sites, contains the sample configuration for Apache ActiveMQ. The BufferingConfig.xml
file is similar for both WebCenter Sites and Remote Satellite Server, except that the list of message consumers for Remote Satellite Server is empty.