Push Server

The Push Server serves as a single-point-of-contact by managing a single Ajax Push blocking connection with a client browser and sharing that connection between all of the ICEfaces applications deployed on an application server. Additionally, it utilizes native Asynchronous Request Processing (ARP) capabilities in order to provide single node scalability to Ajax Push deployments. ARP helps in the scalability of long-lived asynchronous requests.

A basic deployment of the Push Server is illustrated below, and shows how a single Ajax Push blocking connection is shared between multiple ICEfaces applications, multiple views onto the same application, and portal pages with multiple ICEfaces portlets.

The primary purpose of the Push Server is to eliminate the client browser connection limit associated with a single host-port combination. Each web application archive containing an asynchronous ICEfaces application or portlet requires a single Ajax Push blocking connection for the long-lived asynchronous requests. If each page in a client browser maintained its own blocking connection by means of the ICEfaces Ajax Bridge, the connection limit is easily exceeded. The Ajax Bridge performs blocking connection sharing at the client browser side, whereas the Push Server manages that connection at the server side, sharing it with the deployed ICEfaces applications and portlets. Regardless of the number of deployed applications and portlets, and the number of page views onto those applications and portlets, only two connections to the server are required: a non-blocking and a blocking connection. Using the Push Server as a single-point-of-contact for the blocking connection, the client browser connection limit will never be exceeded.

The nature of Ajax Push requires a blocking connection per client session. In the standard Servlet model, this results in each blocking connection occupying its own thread during the entire request/response lifecycle. With the usage of long-lived requests, this mechanism does not scale well under the standard Servlet model. Most application servers overcome this deficiency in the Servlet specification by augmenting the web container with an ARP mechanism capable of freeing up threads for the duration of the blocking period of blocking requests. The Push Server automatically detects and utilizes the native ARP mechanism in the application server if one exists, in order for Ajax Push to scale well in a single node deployment. The following open source application servers are supported:

In most cases, the Push Server does not require any specific configuration. It is implemented as a web application that should be deployed together with any asynchronous ICEfaces applications or portlets. Additionally, no configuration of these applications and portlets is required. During application startup, the ICEfaces application(s) will automatically detect the Push Server and self-configure to use it to manage the blocking connections associated with Ajax Push.

The Push Server is packaged in the push-server.war file, located in the .../icefaces/push-server/ directory.

In the following specific case it is necessary to manually configure the Push Server:

In this case the local IP address of the application/portal server and the port number must be specified using the following configuration parameters in the web.xml files of both the ICEfaces application(s) and the push-server.war:

In addition, it is possible to override the default auto-detection of the Push Server using the com.icesoft.faces.blockingRequestHandler configuration parameter. This parameter can be specified in the application/portlet web.xml file using one of the following values:

The ICEfaces application will try to auto-detect the Push Server, as described previously. If the Push Server is not found, ICEfaces will use its built-in push mechanism. This is the default value.

The ICEfaces application will try to use the Push Server. If the Push Server cannot be found a WARNing message will be logged and the ICEfaces application will fallback to the built-in ICEfaces Push mechanism.

The ICEfaces application will not use the Push Server (even if it is present), but will use the built-in ICEfaces Push mechanism instead.

Note: ICEfaces will log INFO level messages confirming which Push configuration is being used. It is recommended that you review the log files to confirm that the desired configuration is being used successfully at deployment time.

Note: If there is the possibility of multiple Push applications being deployed to the same server (including future deployments), it is recommended that the Push Server also be deployed to that server. Even though accessing a single ICEfaces asynchronous application from a browser will function correctly without the Push Server, making a habit of deploying the push-server.war along with your ICEfaces applications will avoid any issues if a second asynchronous ICEfaces application is deployed at a later time. By default ICEfaces is configured for asynchronous mode. See Asynchronous vs. Synchronous Updates, for details.