Configure Redirection

It is possible for an OmniGroupServer repository to be updated and queried at the same time. However, in theory this could cause the results of queries to be incorrect. This is because OmniGroupServer could be part way through processing a new user or group as the query is processed.

OmniGroupServer can redirect queries from one repository to another. You can use this feature to prevent OmniGroupServer simultaneously updating and querying a repository. This section explains how to configure redirection.


An easier approach than setting up redirection is to configure one task to crawl a repository for updates, and then copy the information into another OmniGroupServer repository that can receive queries from IDOL. You can do this using GroupServerJobType=combine, for example:

// Task settings


To set up redirection, you must set up multiple OmniGroupServer repositories to retrieve user and group information from the same source. One of these repositories can be queried while the others are updated.

You can use redirection with any type of repository, however it is most useful in cases where OmniGroupServer takes a significant amount of time to update a repository.

The following example configuration shows how to configure redirection. Queries are directed to MainRepository and SecondaryRepository.





The following steps explain how this configuration works:

  1. When OmniGroupServer is started, both MainRepository and SecondaryRepository are empty. Queries are directed to MainRepository.
  2. At 06:00 OmniGroupServer attempts to run the MainRepository job, but the job is skipped. This is because GroupServerSkipIfCanQuery=true, and the repository can be queried. Queries continue to be directed to MainRepository.
  3. At 18:00 OmniGroupServer attempts to run the SecondaryRepository job. Although GroupServerSkipIfCanQuery=true, the repository cannot currently be queried (due to GroupServerRedirectedQueriesOnly=TRUE), so the job is allowed to run.
  4. Some time later the SecondaryRepository job completes. Queries to MainRepository are now redirected to the datastore for SecondaryRepository (due to GroupServerRedirectOnCompletion=MainRepository).
  5. The next day at 06:00, OmniGroupServer attempts to run the MainRepository job. The job runs this time because queries to it are currently redirected to SecondaryRepository.
  6. Some time later, the MainRepository job completes. Queries to MainRepository are now redirected back to the datastore for MainRepository (due to GroupServerRedirectOnCompletion=MainRepository).
  7. At 18:00, the SecondaryRepository job runs. Before the job starts the datastore is cleared (due to GroupServerClearDatastoreOnStart=TRUE). On completion queries to MainRepository are redirected to the SecondaryRepository datastore.
  8. The next day at 06:00, the MainRepository job runs. Before starting the datastore is cleared (due to GroupServerClearDatastoreOnStart=TRUE). On completion, queries to MainRepository are redirected to the MainRepository datastore.
  9. Steps 7 and 8 repeat until the service is stopped or an error occurs.

    If an error occurs which means that the update was not successful (for example the job could not connect to the data source), redirection does not occur. The next job does not run because its datastore is being used for queries. This means that there is no break in service, however until a job is successful OmniGroupServer will not have the latest user and group data.

    If OmniGroupServer is stopped, when it restarts it begins again from step 1. However, the MainRepository datastore is already populated so can immediately return results (though the information does not include the latest changes).

The example configuration above could be extended to more than two repositories by creating copies of the SecondaryRepository job and adjusting the start times accordingly.