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.
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.