[opencms-dev] more barriers to running in a cluster

[Jason Trump]

I agree that your model is much simpler.  I also think it will be the most useful in many environments (including my own).

Yours is the model that I had in mind.  But instead of having 'mastercms' publish files and data to the other nodes, all nodes share data out of a single database, and the event service is the synchronization tool.  

For example, when a document is published on mastercms, cms1...N all receive the 'publish' CmsEvent from a JMS queue and can clear their memory and export caches.

I wanted to centralize UUID service not for database records, but so that each server in the cluster could obtain a unique identifier for itself.  Then each CmsEvent could have a 'source' attribute identifying which server the event came from.

All nodes point to the same database (or replicated database cluster).  A master copy of the search index could be stored in the database.  Thus when mastercms updates the search index, cms1..N can all download the new copy, again using the event service to decide when to do it.

Everything else about the application can remain the same; I had previously suggested making CmsLockManager distributed, but clearly this is not necessary if only one server is being used to update content.

-jason

> -----Original Message-----
> From: opencms-dev-bounces at opencms.org [mailto:opencms-dev-
> bounces at opencms.org] On Behalf Of Jorge González
> Sent: Tuesday, September 06, 2005 1:28 PM
> To: 'The OpenCms mailing list'
> Subject: RE: [opencms] RE: [opencms-dev] more barriers to running in a
> cluster
> 
> In this scenario, the cms is modified on any node of the cluster.
> 
> 
> One can think about other scenarios where the clustering helps to scale
> the system up when the number of concurrent users "reading" contents
> raise. This clustering scenario is simpler and could be implemented with
> db replication, directory replication and one master cms server.
> 
> To change the contents, one must login on the master server. To read the
> contents, the rest of the servers will do the work. So this reduces the
> problem to manage the concurrent user publishing operations. If this
> number is very high, in a user directed document repository for example,
> the problem persists. Also master server is a single point of failure :(
> 
> 
> 	www.		Round Robin ---------  	cms1 	(shared session)
> 						---	...	(shared session)
> 						---	cmsN	(shared session)
> 
> 	master.	---------------------	mastercms	-- synchronize (db,
> webapp) on publish