NetScaler is a high performance load balancer or Application Delivery Controller (ADC) designed to scale up to millions of client TCP connections. NetScaler 9.x introduced a new technique called Web 2.0 Push to scale the performance of Comet applications. To use Web 2.0 Push, server applications must communicate with the NetScaler using a REST API. This article describes a implementation in Java that implements the REST API and can be used in J2EE applications to do NetScaler Push. Full source code as well as a JAR file are available.

Getting Started

Overview of NetScaler Push
NetScaler Push REST API
Push feature configuration steps (v9.1)
NetScaler Push Tech overview in pptx (slideshare)
NetScaler product documentation

Implementing the Push API

We wrote this Java implementation to ease solution development using the Push technology. Full source code and a JAR file are provided. The implementation defines two interfaces that can be used by the calling application. The ConnectionLabel interface is used at the initial request time to transfer the label information and indicate to the NetScaler that it should hold the connection. The MessagePush interface implements various methods to format the URL for different API methods.

The full article detailing the interface is available here. Full source code as well as a compiled jar file are available for download.

How to use the code

The compiled jar file can be included in any J2EE application. To use this, the following changes need to be made to the application:

1. Call the hasNSPushEnabled method to check if Push is enabled on the NetScaler device fronting the application.
2. Call the getServerLocationFromRequest method to get the destination to send asynchronous updates.
3. Call the setAsyncResponse method to tell the NetScaler that this client connection can be deferred. This request is completed. The server can free any resources related to this request.
4. Call the sendPostReqToPushVserver method to send asynchronous updates to the NetScaler. This generates a POST request to the NetScaler destination identified in #2.

For steps 3 and 4, the server application needs to generate a unique label to identify the client. This can be a client-id or session-id as applicable.

Caveats

This sample code is for illustration purposes only. High performance applications would need to tune this implementation. Specifically, the code opens a new connection for every update sent. This can easily be improved by having a pool of connections available to send updates to the Push destination.