Known Caveats and Limitations of the Event Service

Performance Cost of Running the Event Service

Enabling Event Service in XNAT 1.8 incurs a small performance penalty. This base-level performance cost is the result of performing several additional database queries on each XNAT object create/update/delete operation. Much of this performance penalty can be overcome with a properly tuned database configuration.

There is no additional performance cost associated with XNAT object read operations.

Known Potential for Event Handling Bottlenecks

The XNAT Event Service processes event subscriptions and executes actions as quickly as it can. As soon as an event trigger is matched to an active subscription, the corresponding action is launched in a new thread. This results in a rapid response to events without back-pressure on subscription handling. This can also cause an undesirable processing load on the Tomcat server, especially if subscription filter constraints are too loose and if action processing is performed on a shared server.

This cascade of event-handling threads can become especially burdensome when paired with Container Executions. There are a couple of ways to reduce the risk of hitting these bottlenecks.

Using Filter Constraints on Event Subscriptions

When creating Event Subscriptions for a production environment, consider setting restrictive filter constraints in order to guard against unintended Action execution.

See: Using Data Filters on Event Subscriptions

Enabling Swarm Mode on the Container Service Host

Even if you operate Docker Swarm mode using a single processing node, the "swarm" functionality has built-in container launch queuing capabilities that will greatly reduce the risk of overloading your system with event-driven container launch requests.

See: Configuring a Compute Backend

Multi-node Considerations

A multi-node XNAT setup contains multiple front end web servers connected to a single back end. Each node in a multi-node deployment maintains an equivalent, but independent, version of the Reactor Registry that powers the XNAT Event Service. Actions are processed within the same Tomcat instance that triggered the subscribed Event.

Multi-node XNAT support is built-in by way of the shared database common to multi-node deployments. Upon Subscription creation, a row is added to the subscriptions DB table and Reactor Consumers are activated on the current node. Periodically (10-second intervals ), all nodes in the shared-database cluster align active Reactor Consumers and active entries in the subscription table. Missing Consumers are activated as needed. Likewise, Consumers without corresponding active entries in the subscription table are removed.