Child pages
  • Multiple web front ends to single XNAT database or archive
Skip to end of metadata
Go to start of metadata

WARNING:  Please review the discussion on problems and pitfalls carefully.  When experiments/assessors are created on multiple servers, currently experiment ID's cannot be guaranteed to be unique, even across projects.  It is strongly recommended that all processes that create new experiments should be directed towards the primary server.  Secondary servers should be used for activities that don't result in the creation of new experiments such as receiving of DICOM and processing files and data within existing sessions.  A fix for this issue is forthcoming.

It can be useful to set up multiple XNAT web front-end servers to point to a single XNAT back-end database and archive.  This setup of multiple web front ends can be used to offload handling of some requests from the primary XNAT web instance in order to maintain performance of the primary web application.  These secondary servers commonly are referred to as  "shadow servers" and are often used to handle application server intensive requests such as the receiving of DICOM and the handling REST communications with pipelines or other batch processing jobs.  Typically, these shadow servers are running the identical version of the XNAT web application as the primary server and are often placed behind the organization's firewall, since they're expected to handle internal processing and receiving of sessions rather than usage by standard users.  This is not a load balanced set up, as described in this article, where requests to the same URL are passed among a number of identical back end nodes.  Rather, in this case, each server is reached by a different URL, so the determination of which server to use is determined by the pipeline, process, or configured in the scanner or CTP.  The setup of shadow servers is simple, however there are some potential problems and pitfalls which must be considered.

Problems and pitfalls

  • XNAT cannot guarantee that experiment IDs will be assigned uniquely when a new experiment is created simultaneously across multiple servers.
    • As a result, it is best if experiment creation is done on the primary server.  The shadow servers should be used primarily for reading data or posting data to existing sessions.
      • There could also be issues if there are multiple posts to the same session occurring simultaneously on different servers, however this is a much less likely occurrence.

  • Only one session should be configured to launch session building on incoming sessions.
    • This can be accomplished by removing or commenting out the beans content of WEB-INF/conf/scheduler-context.xml as shown below.


<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="" xmlns:xsi=""
    <bean name="sessionXmlRebuilderJob" class="org.nrg.xnat.helpers.prearchive.SessionXMLRebuilderJob" />
    <bean name="sessionXmlRebuilderJobBean" class="org.springframework.scheduling.quartz.JobDetailBean">
        <property name="jobClass" value="org.nrg.schedule.DelegatingJobBean" />
        <property name="name" value="session-rebuilder"/>
        <property name="group" value="prearchive-jobs"/>
        <property name="jobDataAsMap">
                <entry key="" value="sessionXmlRebuilderJob" />
                <entry key="interval" value="${services.rebuilder.interval}" />
                <entry key="user" value-ref="receivedFileUserProvider" />

    <bean class="org.springframework.scheduling.quartz.SchedulerFactoryBean">
        <property name="triggers">
                <ref bean="sessionXmlRebuilderTrigger" />
                <ref bean="disableInactiveUsersTrigger" />
                <ref bean="resetFailedLoginsTrigger" />
                <ref bean="clearExpiredAliasTokensTrigger" />
                <ref bean="resetEmailRequestsTrigger" />
        <property name="applicationContextSchedulerContextKey" value="applicationContext"/>


The setup the shadow servers is very similar to that of the primary server.  They typically have the same version of the web application deployed.  Only the following files need to be different.

  1.  WEB-INF/conf/scheduler-context.xml  
    1. Per above, only one server should launch session building and rebuilding for incoming sessions
  2. WEB-INF/conf/InstanceSettings.xml
    1. The site_url attribute will be different.  Everything else will be the same.
  3. WEB-INF/conf/
    1. Each of the servers should be configured to log to different files.