Products » Connect2id server » Documentation » Guides »

How to set up a dedicated Connect2id server node for object expiration

Connect2id server deployments in a stateless cluster with multiple nodes and persistence to an SQL database can implement a strategy where the task of object expiration is dedicated to a single node, leaving the remaining nodes to service API requests only.

The Connect2id server manages several object types that have expiration, such as subject sessions. In a replication cluster the Infinispan layer determines automatically which node to run the expiration task on. In a stateless cluster, where the nodes are not aware of one another and hence cannot coordinate their actions, the Infinispan layer will run the expiration task on every node. In a stateless clusters with many nodes this can lead to a waste of CPU and network resources.

A good strategy to optimise stateless clusters with multiple nodes is to dedicate a single Connect2id server node to the task of object expiration, and leave the rest to service API requests only.

This brings the following useful properties:

  • Spikes in CPU and SQL connection pool utilisation during an expiration task run will not affect the servicing of regular API requests.

  • The individual nodes that handle API requests need not be provisioned with the extra CPU capacity to handle the periodic object expiration and can be scaled independently of this concern.

  • Reduced overall CPU bill.

  • Reduced overall network traffic.

  • Reduced overall DB use.

To disable the expiration tasks on the API servicing Connect2id server nodes set the infinispan.defaultExpirationInterval and sessionStore.sessionMap.expirationInterval Java system properties to zero.

Example:

-Dinfinispan.defaultExpirationInterval=0
-DsessionStore.sessionMap.expirationInterval=0

During startup the Connect2id server will log a set of messages, one for each Infinispan map / cache, where the periodic expiration task is disabled:

INFO main CONTAINER - ISPN000025: wakeUpInterval is <= 0, not starting expired purge thread
INFO main CONTAINER - ISPN000025: wakeUpInterval is <= 0, not starting expired purge thread
INFO main CONTAINER - ISPN000025: wakeUpInterval is <= 0, not starting expired purge thread
...

As of Connect2id server 14.x the log messages will appear for a total of 13 object structures:

grep ISPN000025 logs/c2id-server.log | wc -l
13

Note, this strategy is primarily intended for stateless Connect2id server clusters with persistence to an SQL database.

Stateless clusters with persistence to DynamoDB will not benefit since the object expiration there is handled internally by the database (using a special TTL attribute). The only exception to that is deployments with DynamoDB where the subject session expiration is done by Infinispan at the application layer, in order to support session logout notifications.