Based on the Java^SM Developer Connection^SM presentation, Tips and Tricks for Java Developers given at JavaOne 1998, this article offers a variety of performance tuning and firewall tunneling techniques used by the Java Developer Connection (JDC) engineering team. These techniques are illustrated by source code that you can download.

Performance--Applet Download Speed

Normally, if an Applet has six image buttons, that translates to six additional requests sent back to the web server in order to load those image files. That might not seem like much on an internal network, but given connections of lesser speed and reliability, those additional requests can have a significant negative impact. The ultimate goal is to load the Applet as quickly as possible.

One way of storing images into a class file is to use some type of ASCII encoding scheme--such as X-PixMap (XPM). In this way, rather than maintaining the images as GIF files on the server, they are instead encoded as Strings and stored in a single class file.

The following code sample uses packages from the JavaCup winner at JavaOne '96. These classes--XImageSource and XpmParser--provide all that is necessary to read a standard XPM file (and can be found at SunSite). In terms of the initial encoding process, there are many graphics tools one can use to create XPM files. On Solaris there is ImageTool, along with a variety of other GNU image packages.

Below are the button images used in the following example:

These are the same buttons used in the Java Developer Connection GroupReader Applet, and can be seen in their encoded String form in the XPM definition of the images.

It is assumed there are six member variables used in the sample class MyApplet. These variables are: _reply, _post, _reload, _catchup, _back10, _reset, and _faq.

The loading of the images is demonstrated in the following code. For each image, the Toolkit is used to create an Image from the XPM Image Source object.

Toolkit kit = Toolkit.getDefaultToolkit();
Image image;
image = 
  kit.createImage (new XImageSource (_reply));
image = 
  kit.createImage (new XImageSource (_post));
image = 
  kit.createImage (new XImageSource (_reload));
image = 
  kit.createImage (new XImageSource (_catchup));
image = 
  kit.createImage (new XImageSource (_back10));
image = 
  kit.createImage (new XImageSource (_reset));
image = 
  kit.createImage (new XImageSource (_faq));

The above technique reduces network traffic, because each image definition is part of a single class file. The alternative technique, using GIF files (see below), requires a request back to the web server for each image loaded.

  Image image;
  image = getImage ("reply.gif");
  image = getImage ("post.gif");
  image = getImage ("reload.gif");
  image = getImage ("catchup.gif");
  image = getImage ("back10.gif");
  image = getImage ("reset.gif");
  image = getImage ("faq.gif");

These images can then be used to create buttons or other UI components. If you use Java Foundation Class (JFC) components, such as JButton, the Images can be used as follows:

  ImageIcon icon = new ImageIcon (
    kit.createImage 
      (new XImageSource (_reply)));
  JButton button = 
    new JButton (icon, "Reply");

One way to get around the JAR file problem is to put only those files that are frequently used into the archive. That way, the truly necessary files are downloaded in a single request. Removing infrequently used resources from the JAR files ensures that they will only be downloaded when needed.

Thread Pools--Runtime Performance

The Java Developer Connection Applet servers use Thread Pooling extensively in order to improve performance. This technique is also used in the Java Web Server. For a background on multithreading, see A Simple, Multithreaded Web Server.

The driving force behind the Thread Pooling is the fact that the Thread startup process is, in terms of system resources, an expensive operation. Thus, it's more efficient performance-wise to create a ready supply of Threads up-front, and then to store that pool of sleeping Threads. These suspended Threads are then awakened whenever new tasks are ready to be performed.

The following code samples detail one means of implementing Thread Pooling. In the Pool's constructor (see Pool.java, and below), the WorkerThreads are first initialized and started. The call to start() executes WorkerThread's run() method. Within run(), the wait() call causes the Thread to suspend--waiting for future work to arrive. The sleeping Thread is then pushed onto the stack.

   Worker worker;
   WorkerThread w;
   for ( int i = 0; i < _max; i++ )   {
     worker = (Worker)_workerClass.newInstance();
     w = new WorkerThread ("Worker#"+i, worker);
     w.start();
     _waiting.push (w);
   }

   synchronized void wake (Object data) {

     _data = data; 
     notify();
   }
   synchronized public void run(){
   boolean stop = false; 
     while (!stop){ 
       if ( _data == null ){ 
         try{
          wait();
         }catch (InterruptedException e){ 
          e.printStackTrace();


          continue;
         }
       }
       if ( _data != null ){
         _worker.run(_data);
       }
       _data = null;
       stop = !(_push (this));
     }
   }

  public void performWork (Object data) 
    throws InstantiationException{
   WorkerThread w = null;
   synchronized (_waiting){
     if ( _waiting.empty() ){
       try{
         w = new WorkerThread ("additional worker",
(Worker)_workerClass.newInstance());
         w.start();
       }catch (Exception e){
         throw new InstantiationException (
           "Problem creating instance of 
             Worker.class: " 
             + e.getMessage());
       }
     }else{
       w = (WorkerThread)_waiting.pop();
     }
   }
   w.wake (data);
  } 

   try{8888
     _pool = new Pool (poolSize,
HttpServerWorker.class);
   }catch (Exception e){
     e.printStackTrace();
     throw new InternalError (e.getMessage());
   }

The following code appears in the main service routine (run()) of the HttpServer (see HttpServer.java). Each time a request comes in, the data is initialized and the Thread starts it's work. Note: If the process of creating a new Hashtable for each WorkerThread presents too much overhead, simply modify the code so as not to use the Worker abstraction.

     try{
       Socket s = _serverSocket.accept();
       Hashtable data = new Hashtable();
       data.put ("Socket", s); 
       data.put ("HttpServer", this);
       _pool.performWork (data); 
     }catch (Exception e){ 
       e.printStackTrace();
     }88

Firewall Tunneling

The challenge addressed by firewall tunneling is how to offer those users accessing the Internet via an HTTP Proxy the same level of "interaction" available to those with direct connections. Using the following techniques, the JDC achieves "multiplexed" communication for its Applets, letting them send and receive messages through the firewall.

The following sections detail the HTTP tunneling technique.

Client-to-Server Communication

The client first creates a new URLConnection to send the request to the server (see HttpClient.java). The server responds and the connection is then closed. In general, this direction of communication presents very few problems, making the code rather simple.

synchronized public byte[] send (
  byte data[]) throws IOException
{
   byte buffer[];
   // Establish a connection
   URL url = new URL (_url); 
   URLConnection connection = url.openConnection();
   connection.setUseCaches (false); 
   connection.setDoOutput(true); 

   // Write out the data
   DataOutputStream dataOut = 
     new DataOutputStream (
       new BufferedOutputStream (
         connection.getOutputStream()));
   dataOut.writeInt (HttpClient.DATA);
   dataOut.writeInt (data.length);
   dataOut.write (data);
   dataOut.flush();
   dataOut.close();
   int length;

   DataInputStream input = new DataInputStream (
      new BufferedInputStream (
        connection.getInputStream()));
   int type = input.readInt();
   if ( type == HttpClient.DATA ) {
     length = input.readInt();
     buffer = new byte[length];
     input.readFully (buffer);
   } else {
     buffer = null;
     throw new IOException (
       "Unknown Response Type");
   }
   input.close();
   return buffer;
  }

The important things to note in the code are:

• The URLConnection must be configured (as specified in the API) so as not to use caches, and to allow posting - setUseCaches(false) and setDoOutput(true).
• For performance reasons, both the URLConnection's Input/Output streams are accessed using BufferedIO streams.
• The data reads and writes include extra information about the length and type of data being read or written.

public void run(Object data) {
   Socket socket = 
     (Socket)((Hashtable)data).get ("Socket");
   HttpServer server = 
     (HttpServer)((Hashtable)data).get("HttpServer");
   try {
     DataInputStream input = new DataInputStream (new
     BufferedInputStream(socket.getInputStream()));
     String line = input.readLine();
     if (line.toUpperCase().startsWith ("POST") ){
       for ( ; (line=input.readLine()).length() > 0; )
  ;
       int type = input.readInt()
       switch (type){
         case HttpClient.DATA :{ 
  int length = input.readInt();
  byte buffer[] = new byte[length];
  input.readFully (buffer);
  ByteArrayOutputStream dataOut
    = new ByteArrayOutputStream();
  server.notifyListener (new
    ByteArrayInputStream
      (buffer), dataOut); 
  DataOutputStream output = new
    DataOutputStream
      (new BufferedOutputStream(
        socket.getOutputStream()));
  output.writeBytes (_httpResponse);
  output.writeInt (HttpClient.DATA);
  output.writeInt (dataOut.toByteArray().length);
  output.write (dataOut.toByteArray());
  output.flush();
  input.close();
  output.close();
  socket.close();
  break;
         }
         default :{
  System.err.println ("Invalid type:
    " + type);
         }
       }
     } else {
       System.err.println ("Invalid HTTP request: " +
         line); 
     }
   } catch (IOException e) {
     e.printStackTrace();
       try {
  socket.close();
       } catch (Exception e) {
         }
     }


  } 

The HttpWorkerServer class implements Worker from the Thread Pooling package. The data object passed into the run method includes the Socket and other information. The important things to note in the code are:

• The request must be handled as a real HTTP request--checking for proper HTTP headers.
• As in the client-side code, the Socket's IO streams use BufferedIO streams.
• When sending the response, the proper HTTP headers must be included.

Server-to-Client Communication

Setting up the client side is fairly straightforward, as shown in the following code sample (see HttpClient.java).

connection = _sendPending();
DataOutputStream output = new
  DataOutputStream (connection.getOutputStream());
output.writeInt (PENDING);
output.flush();
output.close();
output = null;
int code =
  ((HttpURLConnection)connection).getResponseCode();
switch (code) {
  case 200: // HTTP_OK{
    DataInputStream input = new
      DataInputStream
        (connection.getInputStream());
    length = input.readInt();
    byte buffer[] = new
      byte[length]; 
    if ( length >= 0 ){
      input.readFully (buffer); 
    _listener.service ( new
      ByteArrayInputStream (buffer)); 
  } else {
    System.err.println("Invalid length:
      " + length);
  }
  buffer = null;
  input.close();
  input = null; 
         }
         case 504:
//HTTP_GATEWAY_TIMEOUT{
  connection = _sendPending();
  break;
         }
         default: //OTHER HTTP_SERVER
ERRORS{
  System.out.println ("Invalid
code:"+code);
         }
       }

Several issues must be addressed when using the pending-connection approach. The client's only thread, as shown in the run() method, is responsible for maintaining the pending connection with the server. For resource reasons, this thread isn't started until a listener is first added to the HttpClient (see TestClient.java).

Once started, the pending request is sent using the _sendPending() method. A unique value (PENDING) is sent so the server will know that the message is a pending one. It is then essential that the client respond appropriately to the HTTP response codes which can come back from the many network sources (such as HTTP Proxies).

Note that the above simplified code anticipates only two possible response codes: HTTP_GATEWAY_TIMEOUT and HTTP_OK. These two codes are the most important because they determine whether the client has received viable data, or whether it needs to send another pending connection request. In the case of HTTP_OK, the client safely reads the data from the HttpServer. Given an HTTP_GATEWAY_TIMEOUT code, however, the client must assume that the pending connection has been closed by one of the HTTP Proxies in the connection, and that it needs to resend the pending connection to the HttpServer. All other codes in the above sample, by default, cause the pending thread to stop.

On the server side, the Socket from the pending connection must be maintained for each client (see HttpServerWorker.java). One way of keeping track of clients is to use a Vector:

   case HttpClient.PENDING :{
     server.addClient (socket);
     break;
   }

The above code provides an additional case for the pending connection, and calls the HttpServer's addClient() method (see HttpServe.java) to store the Socket reference.

  synchronized void addClient (Socket s){
     _clients.addElement(s);
  }

To send a message back to the client, the server simply enumerates through its list of Sockets and writes out the data.

In this simplified version of the code, there is very little error handling--much more can and should be added. Another important feature that should ideally be built into the server code is a means by which to make it tolerant of slow clients. If the pending connection isn't immediately available, it's not a good idea to simply ignore the client--far better to wait a bit and see whether the "slow" client is simply taking its time in sending the pending connection.

  synchronized public void send (byte data[]){
   Enumeration elements = _clients.elements();
   while ( elements.hasMoreElements() ){ 

     Socket s = (Socket)elements.nextElement();
     try{
       DataOutputStream output = new
         DataOutputStream(new BufferedOutputStream
       (s.getOutputStream()));
       int length;
       writeResponse (output);
       output.writeInt (data.length);
       output.write (data);
       output.flush();
       output.close();
     }catch (IOException e){ 
       e.printStackTrace();
     }
     finally{
       try{
         s.close();
       }catch (IOException e){ 
    e.printStackTrace();
       }
     }
   }
   _clients.removeAllElements();
  } 

Tony Squier is a JDC tools engineer. He developed the JDC registration-management code. He invites any feedback you have about the article or the code, such as enhancements or potential bugs. If you have comments please send them to: Tony Squier

Steven Meloan is a writer, journalist, and former software developer. His work has appeared in Wired, Rolling Stone, BUZZ, San Francisco Examiner, ZDTV's "The Site," and American Cybercast's "The Pyramid."

Reader Feedback