GeoServer is most often deployed as a single server application. Several extensions introduce clustering to GeoServer using a form of event notification to communicate application configuration / status to nodes in the cluster.

Since clustering is an advanced deployment operation new functionality is not necessary being tested/designed with clustering in mind. This puts the application in position to wrack up technical debt when new features are deployed in a clustered environment.

Here are examples of stateful features along with options for making them work in a clustered environment:

• config / catalog events:

  • jms cluster notification - events include enough detail to keep catalog data structure up to date

  • hz cluster plugin - events invalidate catalog data structure, allowing it be lazily restored from jdbc config

• resources - looks like a ResourceNotificationDispatcher based on hazelcast is taking shape

• geofence - stores security configuration in a BDB database

• importer - store status in a BDB backend

• gwc cluster - TBD

• wps hazelcast - uses a distributed hz hashmap to preserve asynchronous job status across nodes in cluster

Some work has already been started, both jms and hz clustering listen to catalog change events and react accordingly.

If we general this approach:

1. Review each of the of the integration points above and construct a list of the events we need to distribute
2. If it helps we can consider this a "GeoServer Message Bus" used to carry events
3. Wire catalog, resource, import, wps status, gwc status events to "GeoServer Message Bus"
4. Refactor existing jms cluster implementation into a partial implementation handling catalog change events
5. Refactor hz cluster to handle catalog and resource changes

The GeoServer integration code makes use of the GeoServer Catalog Change events and provides its own implementation of GWCConfiguration.

• Internally GWC has a partial event system - used to monitor disk quota (and is not cluster aware).
• Alternatively GWC has been clustered with a shared in memory cache.

The recent changes to use ResourceStore API may of improved this story (via resource change events on config file).