Task #1782: CN Replication components should be separated for scalability
CN SystemMetadata synchronization when an offline CN comes online
Although updates to the hzSystemMetadata map will be reflected in memory across the Hazelcast storage cluster, only the backing store on the local Metacat (the one that 'owns' the entry in the cluster) will be updated. I confirmed this by looking at the Hazelcast code and documentation, which states that the MapStore interface is intended to update a centralized database backend.
To remedy this, use the ExecutorService in Hazelcast to submit a CNReplicationTask to each CN in the cluster (except the local CN). This task should create/update the Metacat system metadata backing store with the new SystemMetadata object. If the PID exists in the map and doesn't exist the pgsql table, it should be a create, but if it exists in the pgsql table, it should be an update.
Use Hazelcast to lock the object prior to writing to the table.
#2 Updated by Ben Leinfelder about 12 years ago
- Status changed from New to Closed
- Assignee changed from Chris Jones to Ben Leinfelder
I opted for an alternative - I hope simpler - implementation. We use the custom MapStore and MapLoader implementation on the local node, but the other nodes are all listening for entryAdded/entryUpdated calls. When either even occurs, the other nodes check if they have the System Metadata entry locally. If not, the node writes it locally (or updates it if it is an update).
#3 Updated by Ben Leinfelder about 12 years ago
- Status changed from Closed to In Progress
Matt is concerned about what happens when a node is offline - it cannot listen for the add/update. Either: a) we need a robust re-synch process or b) he CNReplicationTask queue approach needs to be used and it too needs a persistent backing store in case every node goes down