Queue Server and Queue Server Failover
The queue server is a server process in the PeopleSoft application domain that routes email, chat, and generic tasks to the agent based on the agent properties, such as state and skill set, and task routing properties, such as priority, language, and cost.
The queue server process (PSUQSRV) is a Tuxedo-managed server with a standard PeopleSoft database connection. Each queue server process is the central routing point for one or more physical queues. The queue server maintains state information for work requests, work in progress, agent availability, and agent workload. Queue server state is written to database records, except for the assignment of chat to agents.
The queue server can recover from a crash because most of its state is written to the database. When a queue server reboots, it checks the database and loads state information for open work tasks. The queue server connects to its REN server and issues restart queries to each console so that it can rebuild agent assignment information, which may have changed while the queue server was down.
Although a single queue server can recover state after recovering from software failure, this does not guard against hardware failure. Multiple queue server processes running on multiple host machines and configured in a cluster provide failover for hardware failure. Unlike the REN server cluster, the clustered queue servers operate as one primary and many secondaries. The primary handles all routing decisions, while secondary processes monitor the primary and step in only if it fails. Any rebooted queue server rejoins the cluster in a secondary role. Any secondary that is promoted to primary loads state from the database and issues queries to consoles as if it were the only process in the cluster.
Each queue server process follows a fixed procedure to ensure that the cluster has at most one functioning primary. Database locks eliminate possible race conditions, and the primary periodically writes a timestamp to indicate its health. The masterinterval parameter controls the frequency at which the primary process must update the timestamp in the cluster table. The masterinterval parameter corresponds to the maximum time after a primary queue server fails before another queue server process takes over. Minimizing this value provides rapid failover response time but also requires frequent database updates.
See Tuning Cluster Parameters.
Each queue server must be part of an MCF cluster, and each MCF cluster must include at least one queue server. An MCF cluster of only one queue server provides no redundancy against hardware failure.
Create a queue server that starts when an application domain is started by selecting MCF servers from the quick-configure menu during application domain configuration.
In summary, configure queue servers to provide hardware failover. Each queue server is part of an MCF cluster. To support hardware failover, distribute primary and secondary queue servers over multiple hosts. Every queue server in an MCF cluster communicates with the same REN server ID. Therefore, REN server failover is also crucial.
The first queue server that places a valid primary entry for itself in the cluster table becomes the primary queue server. In most cases, the primary queue server is the first queue server started. No configuration parameter exists to designate primary or secondary queue server within a cluster.
After an MCF cluster's primary queue server is established, all other cluster members become secondary queue servers. If the secondary queue servers within a cluster detect a failure of the primary queue server, the remaining secondary servers compete to become the primary queue server. If the primary queue server reboots before a secondary takes over, the primary queue server also competes. No configuration parameter exists to designate priority among secondary servers.