Tuesday, 17 March 2009
Ajax Push - ZK versus ICEfaces
« ICEfaces Becoming Integral To Sun's RIA Technology Stack | Main | Easy Ajax just got even easier - ICEfaces 1.8 is now available! »The folks at ZK have made a habit out of borrowing from the ICEfaces messaging related to the benefits of server-centric Ajax, and directly comparing their capabilities with ICEfaces using a seriously slanted bias towards ZK. No real surprise there, but how credible are their claims? Recently, they have claimed that ZK supports Ajax Push, so I thought I would take a look under the hood and see how it compares with ICEfaces Ajax Push.
By reviewing the documentation I was able to determine that ZK supports Ajax Push using a long polling technique similar to how ICEfaces does it, but I wanted to understand if they have tackled any of the intricacies associated with this mechanism. I started with their simple chat room demo. The first thing I tested was their handling of the push connection(s) when the application is viewed in multiple browser tabs or windows. I fired it up in multiple windows on IE, and as suspected, ZK does no connection sharing between the 2 windows, so you end up having contention for the availably browser connections (maximum of 2 for IE). As the screen capture below illustrates, the right hand window is attempting to send a message, but is unable to process the entry due to lack of a connection. It just sits there spinning the processing indicator.
With ICEfaces, the Ajax Bridge handles connection sharing between multiple views onto the same application, so it will never exceed 2 connections, regardless of how many views are open. We can extrapolate from this that the ZK mechanism will not work in portal environments either, as each portlet requires its own push connection.
Next I wanted to understand if ZK had addressed the long-lived connection stability problem by adding some kind of keep alive or heartbeating strategy. I used Wireshark to look at the traffic patterns in the chat demo to determine if any type of heartbeating was running while the application sat idle. While I was not able to detect any type of heartbeating mechanism, I did notice some very strange behavior.
If you leave the application sitting idle for a few minutes, I noticed some sort of condition where a tight loop of failed requests occurs and continues indefinitely. The image below shows a snippet of these messages.
While the client is in this state, it will not receive chat messages from other clients, as illustrated in the screen shot below where you can see it has received only 1 of the 2 chat messages sent.
The bottom line here is that the ZK push mechanism is not reliable, and there is no indication to the user that the application has failed.
While this anomaly obscured my ability to look for a heartbeating mechanism, my suspicion is that there is not one. Our experience with ICEfaces, however, showed that without one you cannot guarantee a reliable long-lived push connection. Again, ICEfaces has addressed this with a configurable heartbeating mechanism that maintains the health of the connection, and can also determine if the connection has failed. The ICEfaces connection status component keeps the user informed about the health of the connection, and provides for a client-side redirect in the case of a persistent connection problem.
Next I wanted to understand if ZK had addressed any of the scalability issues associated with long polling. We examined the source code to see if any Asynchronous Request Processing (ARP) mechanism was being used to mitigate thread exhaustion in the application server. While Tomcat, Glassfish, and Jetty all provide ARP mechanisms, ZK does not integrate with any of them and does not appear to provide its own, so the ZK solution will not scale. With ICEfaces we have painstakingly addressed the scalability issues with long polling, and provide native ARP integration across application server environments.
With all these serious deficiencies uncovered, it hardly seemed worth continuing, but I wanted to examine the programing model as the final part of my analysis. Both approaches use server-side Java APIs to expose push capabilities. ZK provides a minimalistic API that allows you to configure the desktop for push, and then request a render to that desktop from some triggering thread. It does nothing to coordinate render requests between multiple sources, and it provides no client grouping mechanism to organize what clients get what types of updates. The developer is left to do all this work, but it can become very complex problem without further support from the framework.
With ICEfaces the Render Hub manages all the intricacies associated with processing of updates from multiple sources, coalescing of render requests, and synchronization required to efficiently and reliably control the push mechanism. Additionally, ICEfaces provides RenderGroup APIs that manage groups of clients that receive specific types of updates.
So while ZK claims Ajax Push capabilities, it is pretty clear that ICEfaces offers a far more mature, stable, scalable solution. In summary here is my comparison matrix for Ajax Push - ICEfaces versus ZK:
For reliable, scalable Ajax Push suitable for enterprise-grade deployments there is one credible choice here and that is ICEfaces. Makes you wonder about the credibility of the rest of their claims, doesn't it?
Posted by at 6:55 PM in Entries by Steve Maryka