Request forwarding

Request forwarding enables data requests to be serviced by a site that is geographically closest to the object store database. With request forwarding, a Content Platform Engine server communicates with an object store database over a local high-speed LAN instead of a remote server accessing the object store database over a lower-speed WAN, thus reducing network traffic and improving performance.

The following figure illustrates this process:

Illustration of request forwarding

In this example, Site B (with request forwarding enabled) forwards a GetObjects request for 1001 objects to Site A. This request results in 1001 round trips between the server and the database in Site A over a high-speed LAN to collect the GetObjects request's result set, and a single round trip over the slow-speed WAN from Site B to Site A.

In contrast, Site C does not have request forwarding enabled. Site C must service the GetObjects request locally, which results in 1001 round trips from Site C to the database in Site A across the slow-speed WAN in order to collect the same result set.

By servicing the database request locally across the high-speed LAN, and returning the result in only one round trip across the WAN, network traffic is reduced and performance is increased.

Request forwarding has the following characteristics:

  • Request forwarding must be enabled at the site level (both for forwarding requests and for receiving forwarded requests), and each server within the site must have a Request Forwarding Endpoint defined for it to be able to receive forwarded requests.
  • A site can be configured to enable requests to be forwarded to another site (as in the previous bullet), but it can also be configured to not accept any incoming requests. This allows accepting requests to be disabled at the site level and eases server maintenance.
  • Requests that are not specific to an object store, such as retrieving GCD objects, are handled locally and never forwarded.
  • GetObjects, GetSearchMetadata, ExecuteChanges, and ExecuteSearch requests can involve one object store or multiple object stores. In either case, the request can be handled locally or forwarded to an object store in the site that is referenced frequently. However, a request is never broken up, parceled out to multiple object stores and then reassembled, even if this results in some database calls being sent across a WAN.
  • Content-related requests such as GetContent, PutContent, and MoveContent, are never forwarded. In the case where advanced storage areas with content replication are not available to all deployments and there is no content cache present, the local object store retrieves the security and content elements from the remote database server and retrieves the content directly from the remote server.
  • If an incoming set of requests accesses multiple object stores, and any request accesses an object store in the current site, the request is not forwarded.
  • If an incoming request arrives over the Java™ technology Enterprise JavaBeans (EJB) transport for a server that does not support forward over the EJB transport, the request is handled by the local server.
  • There is no performance impact in the case where no additional sites have been defined; for example, only the default site exists.
  • If a request has been forwarded to another server, that server makes no attempt to forward the request again.
  • For a deployment using traditional WebSphere® Application Server, request forwarding is supported across either the EJB transport layer or the WSI transport layer. For WebSphere containerized deployments, request forwarding is only supported across the WSI transport layer.
  • Request forwarding is only supported across homogeneous application servers. Request forwarding across different application server vendors is not supported.