-
Notifications
You must be signed in to change notification settings - Fork 15
Active Cluster Extension
Go to the source dir:
cd src
To build geoserver with the cluster extension you need to activate its profile:
mvn clean install -Pcluster
If you also need the standalone ActiveMQ web application use also the activemq profile:
mvn clean install -Pcluster,activemq
You'll get two distinct war:
- The standalone ActiveMQ broker:
./community/cluster/activemqBroker/activemq_webapp/target/activemq.war
- The geoserver including the cluster plugin:
./web/app/target/geoserver.war
The community plugin is composed by 3 different modules (plus one which can be used as external broker):
- jms-commons
- jms-geoserver
- jms-activeMQ
- activemqBroker
Contains only the low level definition of all the used interface. Depends from Spring JMS.
Is the geoserver cluster core plugin, it implements the Master and the Slave and all the needed GeoServer event listeners (currently this is done for configuration and catalog). Define a set of classes and methods to serialize or wrap those events to produce valid JMS messages. For each incoming event type the module will apply the assigned method (from the above set) obtaining a valid JMS message which are sent to a durable topic queue. The messages from the topic can be consumed by a set of classes and methods to perform message de-serialization accordingly to the incoming message type and properties. For each incoming message the module will apply the assigned method (from the above set) obtaining a valid Object (f.e.: CatalogEvent). The object will be used to apply changes to the target component (for instance the configuration or the catalog). It also ships an GUI interface to handle the various components and to check the status Depends from geoserver and the jms-commons module.
Is a the activeMQ implementation of a factory used to instantiate the needed JMS components (essentially 2 Destination and 1 Connection). Depends from ActiveMQ and jms-commons.
It is however possible as indicated above that an instance of GeoServer would work both as master as well as Slave (looking at events coming from other GeoServer(s)). This is useful to setup a multimaster enviroment that allows the modification to keep flowing even in face of failure of one of the masters (using a failover approach).