Web messaging service challenges

There are several challenges when deploying Web messaging enabled applications using the Bayeux protocol. Any Comet style application that uses long-lived connections face these challenges. Many of these difficulties deal with the strain that Comet style communications causes on the synchronous nature of various pieces of the Internet infrastructure. The Web messaging service, through the use of the channel framework, can scale above a single thread per request, but many other pieces of the Internet infrastructure have difficulties doing so.

One area that might have difficulty scaling is a Web server. When IBM® HTTP Server for WebSphere® Application Server is fronting Web messaging enabled applications, IBM HTTP Server for WebSphere Application Server needs to be configured to handle more requests than a typical application because requests spend more time waiting for an event. IBM HTTP server for WebSphere Application Server ties a single waiting request to a single thread and is constrained by the maximum number of threads availalable to the Web server. In most Web messaging installations, the number of IBM HTTP Server for WebSphere Application Server installations fronting a Web messaging enabled application will need to be increased.

The proxy server for WebSphere Application Server is an alternative to IBM HTTP Server for WebSphere Application Server for fronting a Web messaging enabled application. The proxy server for WebSphere Application Server does not use a thread for each incoming request and should be able to handle a higher number of concurrent clients than IBM HTTP Server for WebSphere Application Server. Issues might arise in replacing IBM HTTP Server for WebSphere Application Server with the proxy server for WebSphere Application Server. Refer to the Know your proxy basics developerWorks article for more information on fronting a Web messaging enabled application with the proxy server for WebSphere Application Server. Other hardware based solutions might be used to front a Web messaging solution. The importing thing to remember is session affinity is required to bring requests back to the same server in a clustering environment.

Two connection limit

An Ajax Bayeux client in a Web browser will be the most common client connecting to the Web messaging service. Browsers have certain limitations when connecting to a server. One limitation is a two connection limit to a single server. When a Bayeux connection is established, one of these connections is used, leaving one other connection free. Since one connection is used a single browser instance, including multiple tabs and windows, will only be able to establish one Bayeux connection to a server. When a second browser window or tabs tries to establish a long lived connection, this connection must be denied or reverted to traditional polling. When developing a Web messaging enabled application, you must understand and plan for this limitation.

You must also take care when performing other time sensitive browser communication to the same server a Bayeux connection is established. The Bayeux protocol uses the second available connection to subscribe, unsubscribe, and publish information to the server. Other operations that consume a connection include: Ajax XmlHttpRequest operations, image or HTML downloading, and file uploading. When multiple operations to a server are occurring over the same browser instance, your Bayeux client application can encounter slow downs and strange behavior while waiting for a connection to be released.



Terms of Use | Feedback