Understanding REN Servers

This section discusses REN servers.

The REN server, an application server domain process, is essential to PeopleSoft MultiChannel Framework (MCF) architecture. MCF events are sent to REN servers, which deliver them to recipients of those topics.

REN servers are also used by other PeopleSoft applications to push event notifications to users, such as the Reporting Window output option and the Optimization Progress Window.

The REN server is a modified web server using the HTTP 1.0 or 1.1 communications protocol. Communication with MCF server processes and browser windows is bidirectional because they maintain persistent connections to the REN server. Events can be sent proactively to browser windows without polling or page refreshes.

Image: REN server configuration example

REN servers can be configured to support both failover and scalability, and should be protected with firewalls and appropriate security measures, as illustrated in the following diagram.

REN server configuration example

Although the REN server is integrated into an application server domain, it is not a standard PeopleTools server process (it has no database connection) and therefore has a separate failover mechanism. Two scenarios exist for failure recovery:

  • For a standalone REN server, Oracle Tuxedo restarts the server if it fails.

    MCF servers and consoles reconnect to the REN server. However, any active browser sessions (such as MCF chat) are interrupted until a connection can be reestablished between the chat console and the restarted REN server.

  • For clustered REN servers, each REN server in the cluster is a peer that mirrors the current state.

    This configuration has two advantages over a standalone REN server:

    • Clustered REN servers guard against hardware failure (provided that the clustered REN servers are on different host machines).

    • Active browser sessions are not lost.

You can configure a REN server cluster with only one REN server member. However, a REN server cluster that is configured with two or more REN servers provides failover.

All REN servers in a cluster mirror each other and appear to external processes as a single URL. The REN server cluster must have an HTTP load balancer or switch as its front end. All connections with browsers and application server processes address the front end’s URL. The load balancer should use an active standby content-switching rule to route all traffic to a designated REN server in the cluster. The front end selects an alternate member of the cluster only when the designated REN server fails to respond.

The REN server cluster maintains mirrored state in all members by relaying events with HTTP messages. Increasing the number of servers within a REN server cluster therefore does not address scalability issues. Clustering REN servers does not improve performance and may increase processing overhead and internal network traffic. The internal HTTP connections between cluster members should be high speed for best performance. Because of the overhead involved in synchronous cluster members, each member of a cluster can handle less load than a REN server in a cluster with only one REN server.

Note: In an environment in which multiple REN servers exist within a single cluster, the primary REN server sends synchronization data to the other members of the cluster. If any of these synchronization messages fail, then the primary REN server retries up to cluster_retry_count times. The minimum value of this parameter, cluster_retry_count, in psrenconfig.txt is 0, which means that the REN server does not retry.

If a REN server crashes, it does not rejoin the cluster because it would not be synchronized with the other clustered REN servers. The entire cluster must be shut down and rebooted to restore all members back to full participation.

Incoming cluster requests must eventually route to the front end's HTTP address. Queue servers and application servers use the cluster URL, which is typically set to be the URL of the front end. Browser clients make requests using the browser URL, which may be set to the front end, or to a server that proxies to the load balancer. If browser transactions are encrypted with SSL, then the browser URL is an HTTPS address to a reverse proxy server or SSL accelerator.

Note: If you use SSL between the browser and REN server, then you must use a reverse proxy server or SSL accelerator, unless you have configured an SSL-enabled REN server.

Note: When clustering multiple REN servers, typically there is some performance degradation.

Note: Periodically, Javsacript-based clients to the REN server, such as our MCF and CTI consoles, will perform a clean up cycle. This clean up cycle, called a "tunnel refresh" will cause the client to disconnect temporarily from the REN server. Depending on the implementation of the client, this may cause a message to be presented to the user, and reconnection may or may not be automatic.