Multiple instances of GeoNetwork?

why you can't do this, and what we should change to make it possible

This page lists reasons that make it impossible to use multiple instances of GeoNetwork. It is assumed they share the same database.

• Lucene indexing : a metadata change in one of the instances does not trigger a reindexing in the other instances. An automatic remote-indexing-trigger could address this. Moving to a clustered external index like ES could also solve the problem.

• Database inserts : Jeeves maintains an in-memory counter to create ids for database insertions. This should be changed, using an auto-inc type for the id column in the database (if this is supported in all DBMSs we support) or else by fetching latest id from the DB everytime before inserting.

• uploaded files : Files uploaded with or to a metadata are stored on the filesystem of the instance where they are uploaded. This also affects logos, images used in harvesting, and codelists. You should configure all instances to use the same locations for this -- otherwise one of the instances can't retrieve uploaded files from the other ones. We'd need to check the code though, because files are stored in directories that are numbered, and we don't know off-hand if these numbers are also incremented in memory.

• site uuid : The site uuid is generated at startup. This should be changed to accommodate all instances to use the same site uuid, as it is 1 catalog from a user perspective.

• harvesters : The harvesters would run in each instance, as they're defined in the DB. This would lead to a lot of failed inserts because of uuid restrictions. Best would be to add an instance-uuid parameter to the harvesters configuration, so they only run in the instance where they were defined.

• sticky session required : Because the editor function in GN uses an in-memory counter. This will be a problem if you don't use sticky sessions.