Category: Jetty

  • Websocket Example: Server, Client and LoadTest

    The websocket protocol specification is approaching final and the Jetty implementation and API have been tracking the draft and is ready when the spec and browsers are available.   More over, Jetty release 7.5.0 now includes a capable websocket java client that can be used for non browser applications or load testing. It is fully asynchronous and can create thousands of connections simultaneously.

    This blog uses the classic chat example to introduce a websocket server, client and load test.

    The project

    The websocket example has been created as a maven project with groupid com.example.  The entire project can be downloaded from here.   The pom.xml defines a dependency on org.eclipse.jetty:jetty-websocket-7.5.0.RC1 (you should update to 7.5.0 when the final release is available), which provides the websocket API and transitively the jetty implementation.  There is also a dependency on org.eclipse.jetty:jetty-servlet which provides the ability to create an embedded servlet container to run the server example.

    While the project implements a Servlet, it is not in a typical webapp layout, as I wanted to provide both client and server in the same project.    Instead of a webapp, this project uses embedded jetty in a simple Main class to provide the server and the static content is served from the classpath from src/resources/com/example/docroot.

    Typically developers will want to build a war file containing a webapp, but I leave it as an exercise for the reader to put the servlet and static content described here into a webapp format.

    The Servlet

    The Websocket connection starts with a HTTP handshake.  Thus the websocket API in jetty also initiated by the handling of a HTTP request (typically) by a Servlet.  The advantage of this approach is that it means that websocket connections are terminated in the same rich application space provided by HTTP servers, thus a websocket enabled web application can be developed in a single environment rather than by collaboration between a HTTP server and a separate websocket server.

    We create the ChatServlet with an init() method that instantiates and configures a WebSocketFactory instance:

    public class ChatServlet extends HttpServlet
    {
      private WebSocketFactory _wsFactory;
      private final Set _members = new CopyOnWriteArraySet();
      @Override
      public void init() throws ServletException
      {
        // Create and configure WS factory
        _wsFactory=new WebSocketFactory(new WebSocketFactory.Acceptor()
        {
          public boolean checkOrigin(HttpServletRequest request, String origin)
          {
            // Allow all origins
            return true;
          }
          public WebSocket doWebSocketConnect(HttpServletRequest request, String protocol)
          {
             if ("chat".equals(protocol))
               return new ChatWebSocket();
             return null;
          }
        });
        _wsFactory.setBufferSize(4096);
        _wsFactory.setMaxIdleTime(60000);
      }
      ...

    The WebSocketFactory is instantiated by passing it an Acceptor instance, which in this case is an anonymous instance. The Acceptor must implement two methods: checkOrigin, which in this case accepts all; and doWebSocketConnect, which must accept a WebSocket connection by creating and returning an instance of the WebSocket interface to handle incoming messages.  In this case, an instance of the nested ChatWebSocket class is created if the protocol is “chat”.   The other WebSocketFactory fields have been initialised with hard coded buffers size and timeout, but typically these would be configurable from servlet init parameters.

    The servlet handles get requests by passing them to the WebSocketFactory to be accepted or not:

      ...
      protected void doGet(HttpServletRequest request,
                           HttpServletResponse response)
        throws IOException
      {
        if (_wsFactory.acceptWebSocket(request,response))
          return;
        response.sendError(HttpServletResponse.SC_SERVICE_UNAVAILABLE,
                           "Websocket only");
      }
      ...

    All that is left for the Servlet, is the ChatWebSocket itself.   This is just a POJO that receives callbacks for events.  For this example we have implemented the WebSocket.OnTextMessage interface to restrict the call backs to only connection management and full messages:

      private class ChatWebSocket implements WebSocket.OnTextMessage
      {
        Connection _connection;
        public void onOpen(Connection connection)
        {
          _connection=connection;
          _members.add(this);
        }
        public void onClose(int closeCode, String message)
        {
          _members.remove(this);
        }
        public void onMessage(String data)
        {
          for (ChatWebSocket member : _members)
          {
            try
            {
              member._connection.sendMessage(data);
            }
            catch(IOException e)
            {
              e.printStackTrace();
            }
          }
        }
      }

    The handling of the onOpen callback is to add the ChatWebSocket to the set of all members (and remembering the Connection object for subsequent sends).  The onClose handling simply removes the member from the set.   The onMessage handling iterates through all the members and sends the received message to them (and prints any resulting exceptions).

     

    The Server

    To run the servlet, there is a simple Main method that creates an embedded Jetty server with a ServletHandler for the chat servlet, as ResourceHandler for the static content needed by the browser client and a DefaultHandler to generate errors for all other requests:

    public class Main
    {
      public static void main(String[] arg) throws Exception
      {
        int port=arg.length>1?Integer.parseInt(arg[1]):8080;
        Server server = new Server(port);
        ServletHandler servletHandler = new ServletHandler();
        servletHandler.addServletWithMapping(ChatServlet.class,"/chat/*");
        ResourceHandler resourceHandler = new ResourceHandler();
        resourceHandler.setBaseResource(Resource.newClassPathResource("com/example/docroot/"));
        DefaultHandler defaultHandler = new DefaultHandler();
        HandlerList handlers = new HandlerList();
        handlers.setHandlers(new Handler[] {servletHandler,resourceHandler,defaultHandler});
        server.setHandler(handlers);
        server.start();
        server.join();
      }
    }

    The server can be run from an IDE or via maven using the following command line:

    mvn
    mvn -Pserver exec:exec

    The Browser Client

    The HTML for the chat room simply imports some CSS and the javascript before creating a few simple divs to contain the chat text, the join dialog and the joined dialog:

    <html>
     <head>
     <title>WebSocket Chat Example</title>
     <script type='text/javascript' src="chat.js"></script>
     <link rel="stylesheet" type="text/css" href="chat.css" />
     </head>
     <body>
      <div id='chat'></div>
      <div id='input'>
       <div id='join' >
        Username:&nbsp;<input id='username' type='text'/>
        <input id='joinB' class='button' type='submit' name='join' value='Join'/>
       </div>
       <div id='joined' class='hidden'>
        Chat:&nbsp;<input id='phrase' type='text'/>
        <input id='sendB' class='button' type='submit' name='join' value='Send'/>
       </div>
      </div>
      <script type='text/javascript'>init();</script>
     </body>
    </html>

    The javascript create a room object with methods to handle the various operations of a chat room.  The first operation is to join the chat room, which is triggered by entering a user name.  This creates a new WebSocket object pointing to the /chat URL path on the same server the HTML was loaded from:

    var room = {
      join : function(name) {
        this._username = name;
        var location = document.location.toString()
          .replace('http://', 'ws://')
          .replace('https://', 'wss://')+ "chat";
        this._ws = new WebSocket(location, "chat");
        this._ws.onopen = this.onopen;
        this._ws.onmessage = this.onmessage;
        this._ws.onclose = this.onclose;
      },
      onopen : function() {
        $('join').className = 'hidden';
        $('joined').className = '';
        $('phrase').focus();
        room.send(room._username, 'has joined!');
      },
      ...

    The javascript websocket object is initialised with call backs for onopen, onclose and onmessage. The onopen callback is handled above by switching the join div to the joined div and sending a “has joined” message.

    Sending is implemented by creating a string of username:message and sending that via the WebSocket instance:

      ...
      send : function(user, message) {
        user = user.replace(':', '_');
        if (this._ws)
          this._ws.send(user + ':' + message);
      },
      ...

    If the chat room receives a message, the onmessage callback is called, which sanitises the message, parses out the username and appends the text to the chat div:

      ...
      onmessage : function(m) {
        if (m.data) {
          var c = m.data.indexOf(':');
          var from = m.data.substring(0, c)
            .replace('<','<')
            .replace('>','>');
          var text = m.data.substring(c + 1)
            .replace('<', '<')
            .replace('>', '>');
          var chat = $('chat');
          var spanFrom = document.createElement('span');
          spanFrom.className = 'from';
          spanFrom.innerHTML = from + ': ';
          var spanText = document.createElement('span');
          spanText.className = 'text';
          spanText.innerHTML = text;
          var lineBreak = document.createElement('br');
          chat.appendChild(spanFrom);
          chat.appendChild(spanText);
          chat.appendChild(lineBreak);
          chat.scrollTop = chat.scrollHeight - chat.clientHeight;
        }
      },
      ...

    Finally, the onclose handling empties the chat div and switches back to the join div so that a new username may be entered:

      ...
      onclose : function(m) {
        this._ws = null;
        $('join').className = '';
        $('joined').className = 'hidden';
        $('username').focus();
        $('chat').innerHTML = '';
      }
    };

    With this simple client being served from the server, you can now point your websocket capable browsers at http://localhost:8080 and interact with the chat room. Of course this example glosses over a lot of detail and complications a real chat application would need, so I suggest you read my blog is websocket chat simpler to learn what else needs to be handled.

    The Load Test Client

    The jetty websocket java client is an excellent tool for both functional and load testing of a websocket based service.  It  uses the same endpoint API as the server side and for this example we create a simple implementation of the OnTextMessage interface that keeps track of the all the open connection and counts the number of messages sent and received:

    public class ChatLoadClient implements WebSocket.OnTextMessage
    {
      private static final AtomicLong sent = new AtomicLong(0);
      private static final AtomicLong received = new AtomicLong(0);
      private static final Set<ChatLoadClient> members = new CopyOnWriteArraySet<ChatLoadClient>();
      private final String name;
      private final Connection connection;
      public ChatLoadClient(String username,WebSocketClient client,String host, int port)
      throws Exception
      {
        name=username;
        connection=client.open(new URI("ws://"+host+":"+port+"/chat"),this).get();
      }
      public void send(String message) throws IOException
      {
        connection.sendMessage(name+":"+message);
      }
      public void onOpen(Connection connection)
      {
        members.add(this);
      }
      public void onClose(int closeCode, String message)
      {
        members.remove(this);
      }
      public void onMessage(String data)
      {
        received.incrementAndGet();
      }
      public void disconnect() throws IOException
      {
        connection.disconnect();
      }

    The Websocket is initialized by calling open on the WebSocketClient instance passed to the constructor.  The WebSocketClient instance is shared by multiple connections and contains the thread pool and other common resources for the client.

    This load test example comes with a main method that creates a WebSocketClient from command line options and then creates a number of ChatLoadClient instances:

    public static void main(String... arg) throws Exception
    {
      String host=arg.length>0?arg[0]:"localhost";
      int port=arg.length>1?Integer.parseInt(arg[1]):8080;
      int clients=arg.length>2?Integer.parseInt(arg[2]):1000;
      int mesgs=arg.length>3?Integer.parseInt(arg[3]):1000;
      WebSocketClient client = new WebSocketClient();
      client.setBufferSize(4096);
      client.setMaxIdleTime(30000);
      client.setProtocol("chat");
      client.start();
      // Create client serially
      ChatLoadClient[] chat = new ChatLoadClient[clients];
      for (int i=0;i<chat.length;i++)
        chat[i]=new ChatLoadClient("user"+i,client,host,port);
      ...

    Once the connections are opened, the main method loops around picking a random client to speak in the chat room

      ...
      // Send messages
      Random random = new Random();
      for (int i=0;i<mesgs;i++)
      {
        ChatLoadClient c = chat[random.nextInt(chat.length)];
        String msg = "Hello random "+random.nextLong();
        c.send(msg);
      }
      ...

    Once all the messages have been sent and all the replies have been received, the connections are closed:

      ...
      // close all connections
      for (int i=0;i<chat.length;i++)
        chat[i].disconnect();

    The project is setup so that the load client can be run with the following maven command:

    mvn -Pclient exec:exec

    And the resulting output should look something like:

    Opened 1000 of 1000 connections to localhost:8080 in 1109ms
    Sent/Received 10000/10000000 messages in 15394ms: 649603msg/s
    Closed 1000 connections to localhost:8080 in 45ms

    Yes that is 649603 messages per second!!!!!!!!!!! This is a pretty simple easy test, but it is still scheduling 1000 local sockets plus generating and parsing all the websocket frames. Real applications on real networks are unlikely to achieve close to this level, but the indications are good for the capability of high throughput and stand by for more rigorous bench marks shortly.

     

     

     

  • Prelim Cometd WebSocket Benchmarks

    I have done some very rough preliminary benchmarks on the latest cometd-2.4.0-SNAPSHOT with the latest Jetty-7.5.0-SNAPSHOT and the results are rather impressive.  The features that these two releases have added are:

    • Optimised Jetty NIO with latest JVMs and JITs considered.
    • Latest websocket draft implemented and optimised.
    • Websocket client implemented.
    • Jackson JSON parser/generator used for cometd
    • Websocket cometd transport for the server improved.
    • Websocket cometd transport for the bayeux client implemented.

    The benchmarks that I’ve done have all been on my notebook using the localhost network, which is not the most realistic of environments, but it still does tell us a lot about the raw performance of the cometd/jetty.  Specifically:

    • Both the server and the client are running on the same machine, so they are effectively sharing the 8 CPUs available.   The client typically takes 3x more CPU than the server (for the same load), so this is kind of like running the server on a dual core and the client on a 6 core machine.
    • The local network has very high throughput which would only be matched by gigabit networks.  It also has practically no latency, which is unlike any real network.  The long polling transport is more dependent on good network latency than the websocket transport, so the true comparison between these transports will need testing on a real network.

    The Test

    The cometd load test is a simulated chat application.  For this test I tried long-polling and websocket transports for 100, 1000 and 10,000 clients that were each logged into 10 randomly selected chat rooms from a total of 100 rooms.   The messages sent were all 50 characters long and were published in batches of 10 messages at once, each to randomly selected rooms.  There was a pause between batches that was adjusted to find a good throughput that didn’t have bad latency.  However little effort was put into finding the optimal settings to maximise throughput.

    The runs were all done on JVM’s that had been warmed up, but the runs were moderately short (approx 30s), so steady state was not guaranteed and the margin of error on these numbers will be pretty high.  However, I also did a long run test at one setting just to make sure that steady state can be achieved.

    The Results

    The bubble chart above plots messages per second against number of clients for both long-polling and websocket transports.   The size of the bubble is the maximal latency of the test, with the smallest bubble being 109ms and the largest is 646ms.  Observations from the results are:

    • Regardless of transport we achieved 100’s of 1000’s messages per second!  These are great numbers and show that we can cycle the cometd infrastructure at high rates.
    • The long-polling throughput is probably a over reported because there are many messages being queued into each HTTP response.   The most HTTP responses I saw was 22,000 responses per second, so for many application it will be the HTTP rate that limits the throughput rather than the cometd rate.  However the websocket throughput did not benefit from any such batching.
    • The maximal latency for all websocket measurements was significantly better than long polling, with all websocket messages being delivered in < 200ms and the average was < 1ms.
    • The websocket throughput increased with connections, which probably indicates that at low numbers of connections we were not generating a maximal load.

    A Long Run

    The throughput tests above need to be redone on a real network and longer runs. However I did do one long run ( 3 hours) of 1,000,013,657 messages at 93,856/sec. T results suggest no immediate problems with long runs. Neither the client nor the server needed to do a old generation collection and all young generation collections took on average only 12ms.

    The output from the client is below:

    Statistics Started at Fri Aug 19 15:44:48 EST 2011
    Operative System: Linux 2.6.38-10-generic amd64
    JVM : Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM runtime 17.1-b03 1.6.0_22-b04
    Processors: 8
    System Memory: 55.35461% used of 7.747429 GiB
    Used Heap Size: 215.7406 MiB
    Max Heap Size: 1984.0 MiB
    Young Generation Heap Size: 448.0 MiB
    - - - - - - - - - - - - - - - - - - - -
    Testing 1000 clients in 100 rooms, 10 rooms/client
    Sending 1000000 batches of 10x50 bytes messages every 10000 µs
    - - - - - - - - - - - - - - - - - - - -
    Statistics Ended at Fri Aug 19 18:42:23 EST 2011
    Elapsed time: 10654717 ms
    	Time in JIT compilation: 57 ms
    	Time in Young Generation GC: 118473 ms (8354 collections)
    	Time in Old Generation GC: 0 ms (0 collections)
    Garbage Generated in Young Generation: 2576746.8 MiB
    Garbage Generated in Survivor Generation: 336.53125 MiB
    Garbage Generated in Old Generation: 532.35156 MiB
    Average CPU Load: 433.23907/800
    ----------------------------------------
    Outgoing: Elapsed = 10654716 ms | Rate = 938 msg/s = 93 req/s =   0.4 Mbs
    All messages arrived 1000013657/1000013657
    Messages - Success/Expected = 1000013657/1000013657
    Incoming - Elapsed = 10654716 ms | Rate = 93856 msg/s = 90101 resp/s(96.00%) =  35.8 Mbs
    Thread Pool - Queue Max = 972 | Latency avg/max = 3/62 ms
    Messages - Wall Latency Min/Ave/Max = 0/8/135 ms

    Note that the client was using 433/800 of the available CPU, while you can see that the server (below) was using only 170/800.  This suggests that the server has plenty of spare capacity if it were given the entire machine.

    Statistics Started at Fri Aug 19 15:44:47 EST 2011
    Operative System: Linux 2.6.38-10-generic amd64
    JVM : Sun Microsystems Inc. Java HotSpot(TM) 64-Bit Server VM runtime 17.1-b03 1.6.0_22-b04
    Processors: 8
    System Memory: 55.27913% used of 7.747429 GiB
    Used Heap Size: 82.58406 MiB
    Max Heap Size: 2016.0 MiB
    Young Generation Heap Size: 224.0 MiB
    - - - - - - - - - - - - - - - - - - - -
    - - - - - - - - - - - - - - - - - - - -
    Statistics Ended at Fri Aug 19 18:42:23 EST 2011
    Elapsed time: 10655706 ms
    	Time in JIT compilation: 187 ms
    	Time in Young Generation GC: 140973 ms (12073 collections)
    	Time in Old Generation GC: 0 ms (0 collections)
    Garbage Generated in Young Generation: 1652646.0 MiB
    Garbage Generated in Survivor Generation: 767.625 MiB
    Garbage Generated in Old Generation: 1472.6484 MiB
    Average CPU Load: 170.20532/800

    Conclusion

    These results are preliminary, but excellent none the less!   The final releases of jetty 7.5.0 and cometd 2.4.0 will be out within a week or two and we will be working to bring you some more rigorous benchmarks with those releases.

     

     

     

  • CometD JSON library pluggability

    It all started when my colleague Joakim showed me the results of some JSON libraries benchmarks he was doing, which showed Jackson to be the clear winner among many libraries.
    So I decided that for the upcoming CometD 2.4.0 release it would have been good to make CometD independent of the JSON library used, so that Jackson or other libraries could have been plugged in.
    Historically, CometD made use of the Jetty‘s JSON library, and this is still the default if no other library is configured.
    Running a CometD specific benchmark using Jetty’s JSON library and Jackson (see this test case) shows, on my laptop, this sample output:

    Parsing:
    ...
    jackson context iteration 1: 946 ms
    jackson context iteration 2: 949 ms
    jackson context iteration 3: 944 ms
    jackson context iteration 4: 922 ms
    jetty context iteration 1: 634 ms
    jetty context iteration 2: 634 ms
    jetty context iteration 3: 636 ms
    jetty context iteration 4: 639 ms
    Generating:
    ...
    jackson context iteration 1: 548 ms
    jackson context iteration 2: 549 ms
    jackson context iteration 3: 552 ms
    jackson context iteration 4: 561 ms
    jetty context iteration 1: 788 ms
    jetty context iteration 2: 796 ms
    jetty context iteration 3: 798 ms
    jetty context iteration 4: 805 ms
    

    Jackson is roughly 45% slower in parsing and 45% faster in generating, so not bad for Jetty’s JSON compared to the best in class.
    Apart from efficiency, Jackson has certainly more features than Jetty’s JSON library with respect to serializing/deserializing custom classes, so having a pluggable JSON library in CometD is only better for end users, that can now choose the solution that fits them best.
    Unfortunately, I could not integrate the Gson library, which does not seem to have the capability of deserializing arbitrary JSON into java.util.Map object graphs, like Jetty’s JSON and Jackson are able to do in one line of code.
    If you have insights on how to make Gson work, I’ll be glad to hear.
    The documentation on how to configure CometD’s JSON library can be found here.
    UPDATE
    After a suggestion from Tatu Saloranta of Jackson, the Jackson parsing is now faster than Jetty’s JSON library by roughly 20%:

    ...
    jackson context iteration 1: 555 ms
    jackson context iteration 2: 506 ms
    jackson context iteration 3: 506 ms
    jackson context iteration 4: 532 ms
    jetty context iteration 1: 632 ms
    jetty context iteration 2: 637 ms
    jetty context iteration 3: 639 ms
    jetty context iteration 4: 635 ms
    
  • Jetty JMX Webservice

    Jetty JMX Webservice is a webapp providing a RESTful API to query JMX mbeans and invoke mbean operations without the hassle that comes with RMI. No more arguments with your firewall admin, just a single http port.
    That alone might not be a killer feature, but Jetty JMX Webservice also aggregates multiple mbeans having the same ObjectName in the same JVM (e.g. jmx beans for multiple webapps) as well as from multiple jetty instances. That way you’ve a single REST api aggregating JMX mbeans for one or more jetty instances you can use to feed your favourite monitoring system for example.
    The whole module is in an early development phase and may contain some rough edges. But we wanted to check for interest of the community early and get some early feedback.
    We’ve started a very simple JQuery based webfrontend as a showcase on what the REST api can be used for.
    Instance Overview:
    A table showing two jetty instances.
    Or a realtime memory graph gathering memory consumption from the REST api. This is an accordion like view. You see an accordion line for each node showing the current heap used. You can open each line and get a realtime graph of memory consumption. The memory used in the accordion and the graphs are updated in realtime which is hard to show in a picture:
    Realtime memory graph
    Pretty cool. Note that this is just a showcase on how the REST api can be used.
    URLs Paths of the webservice
    /ws/ – index page
    /ws/nodes – aggregated basic node information
    /ws/mbeans – list of all aggregated mbeans
    /ws/mbeans/[mbean objectName] – detailed information about all attributes and operations this mbean offers
    /ws/mbeans/[mbean objectName]/attributes – aggregate page containing the values of all attributes of the given mbean
    /ws/mbeans/[mbean objectName]/attributes/[attributeName] – aggregated values of a specific attribute
    /ws/mbeans/[mbean objectName]/operation/[operationName] – invoke specified operation
    Examples URLs:
    /ws/mbeans/java.lang:type=Memory
    /ws/mbeans/java.lang:type=Memory/operations/gc
    How to get it running

    Here’s all you need to do to get jetty-jmx-ws running in your jetty instance and some examples how the REST api looks like and how it can be used. Should take less than 15 min.

    1. Checkout the sandbox project
      svn co https://svn.codehaus.org/jetty-contrib/sandbox/jetty-jmx-ws
    2. cd into the new directory and build the project
      cd jetty-jmx-ws && mvn clean install
    3. Make sure you got the [INFO] BUILD SUCCESS message
    4. Copy the war file you’ll find in the projects target directory into the webapps directory of your jetty instance
      cp target/jetty-jmx-ws-[version].war [pathToJetty]/webapps
    5. Access the webapp by browsing to:
      http://[jettyinstanceurl]/jetty-jmx-ws-[version]/ws/
      e.g.:
      http://localhost:8080/jetty-jmx-ws-7.4.1-SNAPSHOT/ws/
    6. You’re done. 🙂

    How to use it: Starting point

    As it is a RESTful api it will guide you from the base URL to more detailed pages. The base URL will return:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <Index>
    <mBeans>http://localhost:8080/jetty-jmx-ws-7.4.1-SNAPSHOT/ws/mbeans</mBeans>
    <nodes>http://localhost:8080/jetty-jmx-ws-7.4.1-SNAPSHOT/ws/nodes</nodes>
    </Index>

    It shows you two URLs.
    The first one will guide you through a list of mbeans which is aggregated. This means it’ll show you mbeans which do exist on ALL configured instances. mebans which exist only on a single instance will be filtered out.

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <MBeans>
    <MBean>
    <ObjectName>JMImplementation:type=MBeanServerDelegate</ObjectName>
    <URL>http://localhost:8080/jetty-jmx-ws-7.4.1-SNAPSHOT/ws/mbeans/JMImplementation:type=MBeanServerDelegate</URL>
    </MBean>
    <MBean>
    <ObjectName>com.sun.management:type=HotSpotDiagnostic</ObjectName>
    <URL>http://localhost:8080/jetty-jmx-ws-7.4.1-SNAPSHOT/ws/mbeans/com.sun.management:type=HotSpotDiagnostic</URL>
    </MBean>
    <MBean>
    <ObjectName>java.lang:type=Memory</ObjectName>
    <URL>http://localhost:8080/jetty-jmx-ws-7.4.1-SNAPSHOT/ws/mbeans/java.lang:type=Memory</URL>
    </MBean>
    SNIPSNAP - lots of mbeans
    </MBeans>

    The second URL shows you basic node information for all configured nodes:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <Index>
    <nodes>
    <name>localhost:1099</name>
    <jettyVersion>7.4.1-SNAPSHOT</jettyVersion>
    <threadCount>42</threadCount>
    <peakThreadCount>45</peakThreadCount>
    <heapUsed>41038176</heapUsed>
    <heapInit>0</heapInit>
    <heapCommitted>85000192</heapCommitted>
    <heapMax>129957888</heapMax>
    <jmxServiceURL>service:jmx:rmi:///jndi/rmi://localhost:1099/jettyjmx</jmxServiceURL>
    </nodes>
    <nodes>
    <name>localhost:1100</name>
    <jettyVersion>7.4.1-SNAPSHOT</jettyVersion>
    <threadCount>45</threadCount>
    <peakThreadCount>47</peakThreadCount>
    <heapUsed>73915872</heapUsed>
    <heapInit>0</heapInit>
    <heapCommitted>129957888</heapCommitted>
    <heapMax>129957888</heapMax>
    <jmxServiceURL>service:jmx:rmi:///jndi/rmi://localhost:1100/jettyjmx</jmxServiceURL>
    </nodes>
    </Index>

    Howto query a single mbean
    This example shows how to let you guide through the REST api to query a specific mbean. This example will guide you through to the memory mbean.

    1. From the base URL follow the link to the mbeans list:
      http://localhost:8080/jetty-jmx-ws-7.4.1-SNAPSHOT/ws/mbeans
    2. Search for the mbean name you’re looking for:
      <MBean>
      <ObjectName>java.lang:type=Memory</ObjectName>
      <URL>http://localhost:8080/jetty-jmx-ws-7.4.1-SNAPSHOT/ws/mbeans/java.lang:type=Memory</URL>
      </MBean>
    3. Open the link inside the URL tag
      http://localhost:8080/jetty-jmx-ws-7.4.1-SNAPSHOT/ws/mbeans/java.lang:type=Memory
    4. You’ll get a list of all operations which can be executed on that mbean and all attributes which can be queried:
      <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
      <MBean>
      <ObjectName>java.lang:type=Memory</ObjectName>
      <Operations>
      <ObjectName>java.lang:type=Memory</ObjectName>
      <Operation>
      <Name>gc</Name>
      <Description>gc</Description>
      <ReturnType>void</ReturnType>
      <URL>http://localhost:8080/jetty-jmx-ws-7.4.1-SNAPSHOT/ws/mbeans/java.lang:type=Memory/operations/gc</URL>
      </Operation>
      </Operations>
      <Attributes>
      <Attribute>
      <Name>HeapMemoryUsage</Name>
      <description>HeapMemoryUsage</description>
      <type>javax.management.openmbean.CompositeData</type>
      <isReadable>true</isReadable>
      <isWritable>false</isWritable>
      <uri>http://localhost:8080/jetty-jmx-ws-7.4.1-SNAPSHOT/ws/mbeans/java.lang:type=Memory/attributes/HeapMemoryUsage</uri>
      </Attribute>
      SNIPSNAP - lots of attributes cutted
      </Attributes>
      </MBean>
    5. Besides some information about all operations and attributes you’ll find URLs to invoke operations like:
      http://localhost:8080/jetty-jmx-ws-7.4.1-SNAPSHOT/ws/mbeans/java.lang:type=Memory/operations/gc
      which will invoke a garbage collection.And URLs to display the attributes’ values like:
      http://localhost:8080/jetty-jmx-ws-7.4.1-SNAPSHOT/ws/mbeans/java.lang:type=Memory/attributes/HeapMemoryUsage
      Will show you: 

      <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
      <mBeanAttributeValueJaxBeans>
      <Attribute>
      <AttributeName>HeapMemoryUsage</AttributeName>
      <NodeName>localhost:1099</NodeName>
      <ObjectName>java.lang:type=Memory</ObjectName>
      <Value>javax.management.openmbean.CompositeDataSupport(compositeType=javax.management.openmbean.CompositeType(name=java.lang.management.MemoryUsage,items=((itemName=committed,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)),(itemName=init,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)),(itemName=max,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)),(itemName=used,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)))),contents={committed=85000192, init=0, max=129957888, used=28073528})</Value>
      </Attribute>
      <Attribute>
      <AttributeName>HeapMemoryUsage</AttributeName>
      <NodeName>localhost:1100</NodeName>
      <ObjectName>java.lang:type=Memory</ObjectName>
      <Value>javax.management.openmbean.CompositeDataSupport(compositeType=javax.management.openmbean.CompositeType(name=java.lang.management.MemoryUsage,items=((itemName=committed,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)),(itemName=init,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)),(itemName=max,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)),(itemName=used,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)))),contents={committed=129957888, init=0, max=129957888, used=69793976})</Value>
      </Attribute>
      </mBeanAttributeValueJaxBeans>
    6. You can as well get an aggregated view of all attributes for an mbean by just adding attributes to the mbeans url: http://localhost:8080/jetty-jmx-ws-7.4.1-SNAPSHOT/ws/mbeans/java.lang:type=Memory/attributes
      will return: 

      <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
      <mBeanAttributeValueJaxBeans>
      <Attribute>
      <AttributeName>HeapMemoryUsage</AttributeName>
      <NodeName>localhost:1099</NodeName>
      <ObjectName>java.lang:type=Memory</ObjectName>
      <Value>javax.management.openmbean.CompositeDataSupport(compositeType=javax.management.openmbean.CompositeType(name=java.lang.management.MemoryUsage,items=((itemName=committed,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)),(itemName=init,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)),(itemName=max,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)),(itemName=used,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)))),contents={committed=85000192, init=0, max=129957888, used=30005472})</Value>
      </Attribute>
      <Attribute>
      <AttributeName>HeapMemoryUsage</AttributeName>
      <NodeName>localhost:1100</NodeName>
      <ObjectName>java.lang:type=Memory</ObjectName>
      <Value>javax.management.openmbean.CompositeDataSupport(compositeType=javax.management.openmbean.CompositeType(name=java.lang.management.MemoryUsage,items=((itemName=committed,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)),(itemName=init,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)),(itemName=max,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)),(itemName=used,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)))),contents={committed=129957888, init=0, max=129957888, used=68043064})</Value>
      </Attribute>
      <Attribute>
      <AttributeName>NonHeapMemoryUsage</AttributeName>
      <NodeName>localhost:1099</NodeName>
      <ObjectName>java.lang:type=Memory</ObjectName>
      <Value>javax.management.openmbean.CompositeDataSupport(compositeType=javax.management.openmbean.CompositeType(name=java.lang.management.MemoryUsage,items=((itemName=committed,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)),(itemName=init,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)),(itemName=max,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)),(itemName=used,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)))),contents={committed=85356544, init=24317952, max=136314880, used=52749944})</Value>
      </Attribute>
      <Attribute>
      <AttributeName>NonHeapMemoryUsage</AttributeName>
      <NodeName>localhost:1100</NodeName>
      <ObjectName>java.lang:type=Memory</ObjectName>
      <Value>javax.management.openmbean.CompositeDataSupport(compositeType=javax.management.openmbean.CompositeType(name=java.lang.management.MemoryUsage,items=((itemName=committed,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)),(itemName=init,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)),(itemName=max,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)),(itemName=used,itemType=javax.management.openmbean.SimpleType(name=java.lang.Long)))),contents={committed=92868608, init=24317952, max=136314880, used=78705952})</Value>
      </Attribute>
      <Attribute>
      <AttributeName>ObjectPendingFinalizationCount</AttributeName>
      <NodeName>localhost:1099</NodeName>
      <ObjectName>java.lang:type=Memory</ObjectName>
      <Value>0</Value>
      </Attribute>
      <Attribute>
      <AttributeName>ObjectPendingFinalizationCount</AttributeName>
      <NodeName>localhost:1100</NodeName>
      <ObjectName>java.lang:type=Memory</ObjectName>
      <Value>0</Value>
      </Attribute>
      <Attribute>
      <AttributeName>Verbose</AttributeName>
      <NodeName>localhost:1099</NodeName>
      <ObjectName>java.lang:type=Memory</ObjectName>
      <Value>false</Value>
      </Attribute>
      <Attribute>
      <AttributeName>Verbose</AttributeName>
      <NodeName>localhost:1100</NodeName>
      <ObjectName>java.lang:type=Memory</ObjectName>
      <Value>false</Value>
      </Attribute>
      </mBeanAttributeValueJaxBeans>

    Security
    It’s a webapp with some servlets. So secure it the same way you would any servlet.
    What’s next?
    There’s two more features which I didn’t describe. I will write a follow up soon describing how to use them.

    1. You can filter by nodes with QueryParams
    2. Invoke operations whith parameters
    3. Configuration for multiple instances
    4. Get JSON instead of XML by setting accept header

    If there’s interest in this project, I will also take care to write some manuals and add them to the wiki pages.

  • Jetty Overlayed WebApp Deployer

    The Jetty Overlay Deployer allows multiple WAR files to be overlayed so that a web application can be customised, configured and deployed without the need to unpack, modify and repack the WAR file. This has the benefits of:

    • The WAR file may be kept immutable, even signed, so that it is clear which version has been deployed.
    • All modifications made to customise/configure the web application are kept in a separate wars and thus are easily identifiable for review and migration to new versions.
    • A parameterised template overlay can be created that contains common customisations and configuration that apply to many instances of the web application (eg for multi-tenant deployment).
    • Because the layered deployment clearly identifies the common and instance specific components, then Jetty is able to share classloaders and static resource caches for the template, greatly reducing the memory footprint of multiple instances

    This blog is a tutorial of how to configure Jetty to use the Overlay deployer, and how to deploy multiple instances of the JTrac web application.

    Overview

    The customisation, configuration and deployment a web application bundled as a WAR file frequently includes some or all of:

    • Editing the WEB-INF/web.xml file to set init parameters, add filters/servlets or to configure JNDI resources.
    • Editing other application specific configuration files in WEB-INF/*
    • Editing container specific configuration files in WEB-INF/* (eg jetty-web.xml or jboss-web.xml)
    • Adding/modifying static content such as images and css to style/theme the webapplication
    • Adding jars to the container classpath for Datasource and other resources
    • Modifying the container configuration to provide JNDI resources

    The result is that the customisations and configurations are blended into both the container and the WAR file. If either the container or the base WAR file are upgraded to a new version, it can be a very difficult and error prone task to identify all the changes that have been made and to reapply them to a new version.

    Overlays

    To solve the problems highlighted above, jetty 7.4 introduces WAR overlays (which are a concept borrowed from the maven war plugin). An overlay is basically just another WAR files, whose contents are merged on top of the original WAR so that files may be added or replaced.

    However,  jetty overlays also allow mixin fragments of web.xml, so the configuration can be modified without being replaced

    Jtrac Overlay Example

    The jtrac issue tracking webapplication is a good example of a typical web application, as it uses the usual suspects of libs: spring, hibernate, dom4j, commons-*, wicket, etc. So I’ve used it as the basis of this example.

    The files for this demonstration are available in overlays-demo.tar.gz. This could be expanded on top of the jetty distribution, but for this tutorial we will expand it to /tmp and install the components step by step:

    cd /tmp
    wget http://webtide.intalio.com/wp-content/uploads/2011/05/overlays-demo.tar.gz
    tar xfvz overlays-demo.tar.gz
    export OVERLAYS=/tmp/overlays

    Configuring Jetty for Overlays

    Overlays support is included in jetty distributions from 7.4.1-SNAPSHOT onwards, so you can download a distribution from oss.sonatype.org or maven central(once 7.4.1 is released) and unpack into a directory.    The start.ini file then needs to be edited so that it includes the overlay option and configuration file.   The resulting file should look like:

    OPTIONS=Server,jsp,jmx,resources,websocket,ext,overlay
    etc/jetty.xml
    etc/jetty-deploy.xml
    etc/jetty-overlay.xml

    The smarts of this are in etc/jetty-deploy.xml files, which installs the OverlayedAppProvider into the DeploymentManager. Jetty can then be started normally:

    java -jar start.jar

    Jetty will now be listening on port 8080, but with no webapp deployed.   The rest of the tutorial should be conducted in another window with the JETTY_HOME environment set to the jetty distribution directory.

    Installing the WebApp

    The WAR file for this demo can be downloaded and deployed using the following commands, which essentially downloads and extracts the WAR file to the $JETTY_HOME/overlays/webapps directory

    cd /tmp
    wget -O jtrac.zip http://sourceforge.net/projects/j-trac/files/jtrac/2.1.0/jtrac-2.1.0.zip/download
    jar xfv jtrac.zip jtrac/jtrac.war
    mv jtrac/jtrac.war $JETTY_HOME/overlays/webapps

    When you have run these commands (or equivalent), you will see in the jetty server window a message saying that the OverlayedAppProvider has extracted and loaded the war file:

    2011-05-06 10:31:54.678:INFO:OverlayedAppProvider:Extract jar:file:/tmp/jetty-distribution-7.4.1-SNAPSHOT/overlays/webapps/jtrac-2.1.0.war!/ to /tmp/jtrac-2.1.0_236811420856825222.extract
    2011-05-06 10:31:55.235:INFO:OverlayedAppProvider:loaded jtrac-2.1.0@1304641914666

    Unlike the normal webapps dir, loading a war file from the overlays/webapp dir does not deploy the webapplication.  It simply makes it available to be used as the basis for templates and overlays.

    Installing a Template Overlay

    A template overlay is a WAR structured directory/archive that contains just the files that have been added or modified to customize/configure the webapplication for all instances that will be deployed.

    The demo template can be installed from the downloaded files with the command:

    mv $OVERLAYS/jtracTemplate=jtrac-2.1.0 $JETTY_HOME/overlays/templates/

    In the Jetty server window, you should see the template loaded with a message like:

    2011-05-06 11:00:08.716:INFO:OverlayedAppProvider:loaded jtracTemplate=jtrac-2.1.0@1304643608715

    The contents of the loaded template is as follows:

    templates/jtracTemplate=jtrac-2.1.0
    └── WEB-INF
        ├── classes
        │   └── jtrac-init.properties
        ├── log4j.properties
        ├── overlay.xml
        ├── template.xml
        └── web-overlay.xml

    The name of the template directory (or it could be a war) uses the ‘=’ character in jtracTemplate=jtrac-2.1.0 to separates the name of the template from the name of the WAR file in webapps that it applies to.  If  = is a problem, then -- may also be used.

    WEB-INF/classes/jtrac-init.properties – replaces the jtrac properties file with an empty file, as the properties contained within it are configured elsewhere

    WEB-INF/log4j.properties – configures the logging for all instances of the template.

    WEB-INF/overlay.xml – a Jetty XML formatted IoC file that is used to inject/configure the ContextHandler for each instances. In this case it just sets up the context path:

    
    
    
      /
    

    WEB-INF/template.xml – a Jetty XML formatted IoC file that is used to inject/configure the resource cache and classloader that is shared by all instances of the template. It is run only once per load of the template:

    
    
    
      
        true
        10000000
        1000
        64000000
      
    

    WEB-INF/web-overlay.xml – a web.xml fragment that is overlayed on top of the web.xml from the base WAR file, that can set init parameters and add/modify filters and servlets. In this it sets the application home and springs rootKey:

    
    
      
        jtrac.home
        /tmp/jtrac-${overlay.instance.classifier}
      
      
        webAppRootKey
        jtrac-${overlay.instance.classifier}
      
      
    

    Note the use of parameterisation of values such as ${overlays.instance.classifier}, as this allows the configuration to be made in the template and not customised for each instance.

    Without the overlayed deployer, all the configurations above would still need to have been made, but rather that being in a single clear structure they would have been either in the servers common directory, the servers webdefaults.xml (aka server.xml), or baked into the WAR file of each application instance using copied/modified files from the original. The overlayed deployer allows us to make all these changes in one structure, more over it allows some of the configuration to be parameterised to facilitate easy multi-tenant deployment.

    Installing an Instance Overlay

    Now that we have installed a template, we can install one or more instance overlays, which deploy the actual web applications:

    mv /tmp/overlays/instances/jtracTemplate=blue $JETTY_HOME/overlays/instances/
    mv /tmp/overlays/instances/jtracTemplate=red $JETTY_HOME/overlays/instances/
    mv /tmp/overlays/instances/jtracTemplate=blue $JETTY_HOME/overlays/instances/
    

    As each instance is moved into place, you will see the jetty server window react and deploy that instance. Within each instance, there is the structure:

    instances/jtracTemplate=red/
    ├── WEB-INF
    │   └── overlay.xml
    ├── favicon.ico
    └── resources
        └── jtrac.css
    

    WEB-INF/overlay.xml – a Jetty XML format IoC file that injects/configures the context for the instance. In this case it sets up a virtual host for the instance:

    
    
    
      
        
          127.0.0.2
          red.myVirtualDomain.com
        
      
    

    favicon.ico – replaces the icon in the base war with one themed for the instance colour.

    resources/jtrac.css – replaces the style sheet from the base war with one themed for the instance colour

    The deployed instances can now be viewed by pointing your browser at http://127.0.0.1:8080, http://127.0.0.2:8080 and http://127.0.0.3:8080. The default username/password for jtrac is admin/admin.

    Things to know and notice

    • Each instance is themed with images and styles sheets from the instance overlay.
    • Each instance is running with it’s own application directory (eg. /tmp/jtrac-red), that is set templates web-overlay.xml.
    • The instances are distinguished by virtual host that is set in the instance overlay.xml
    • The static content from the base war and template are shared between all instances. Specifically there is a shared ResourceCache so only a single instance of each static content is loaded into memory.
    • The classloader at the base war and template level is shared between all instances, so that only a single instance of common classes is loaded into memory. Classes with non shared statics can be configured to load in the instances classloader.
    • All overlays are hot deployed and dependencies tracked. If an XML is touched in an instance, it is redeployed. If an XML is touched in a template, then all instances using it are redeployed. If a WAR file is touched, then all templates and all instances dependant on it are redeployed.
    • New versions can easily be deployed. Eg when jtrac-2.2.0.war becomes available, it can just be dropped into overlays/webapps and then rename jtracTemplate=jtrac-2.1.0 to jtracTemplate=jtrac-2.2.0
    • There is a fuller version of this demo in overlays-demo-jndi.tar.gz, that uses JNDI (needs options=jndi,annotations and jetty-plus.xml in start.ini) and shows how extra jars can be added in the overlays.
  • Jetty with Spring XML

    Since the very beginning, Jetty has been IOC friendly and thus has been able to be configured with spring.  But the injecting and assembling the jetty container is not the only need that Jetty has for configuration and there are several other configuration files (eg contexts/yourapp.xml,  jetty-web.xml,  jetty-env.xml) that have needed to be in the Jetty XML configuration format.

    With the release of Jetty-7.4, the jetty-spring module has been enhanced with and XmlConfiguration Provider, so now anywhere there is a jetty xml file can be replaced with a spring XML file, so that an all spring configuration is now possible. [ But note that there is no plan to use spring as the default configuration mechanism.  For one, the 2.9MB size of the spring jar is too large for Jetty’s foot print aspirations (currently only 1.5MB for everything) ].

    Starting with spring Jetty

    First you will need a download of jetty-hightide, that includes the spring module:

    wget --user-agent=other http://repo2.maven.org/maven2/org/mortbay/jetty/jetty-hightide/7.4.0.v20110414/jetty-hightide-7.4.0.v20110414.tar.gz
    tar xfz jetty-hightide-7.4.0.v20110414.tar.gz
    jetty-hightide-7.4.0.v20110414/

    You then need to augment this with a spring jar and commons logging:

    cd lib/spring
    wget --user-agent=other http://repo2.maven.org/maven2/org/springframework/spring/2.5.6/spring-2.5.6.jar
    wget --user-agent=other http://repo2.maven.org/maven2/commons-logging/commons-logging/1.1.1/commons-logging-1.1.1.jar
    cd ../..

    and then add spring to the Jetty options by editing start.ini and adding “spring” to the OPTIONS set there:

    OPTIONS=Server,jsp,jmx,resources,websocket,ext,jta,plus,jdbc,annotations,spring

    and that’s it! Jetty is now ready to be configured with spring

    Example Jetty XML

    We can now replace the main etc/jetty.xml file with a spring version as follows:

    
    
    
      
      
        
          
            
            
          
        
        
          
            
              
            
          
        
        
          
            
              
                 
                 
              
            
          
        
        
        
        
        
        
        
      
    
    

    Note that Server bean is given the name (or alias) of “Main” to identify it as the primary bean configured by this file. This equates to the Configure element of the Jetty XML format. Note also that both the Server and Contexts ids are used by subsequent config files (eg etc/jetty-deploy) to reference the beans created here and that the ID space is shared between the configuration formats. Thus you can mix and match configuration formats.

    Example Context XML

    As another example, you can replace the contexts/test.xml file with a spring version as follows:

    
    
    
      
        
        
          
            
              
              
            
          
          
        
        
        
        
        
        
        
        
        
        
          
            www.myVirtualDomain.com
            localhost
            127.0.0.1
          
        
      
    
    

    Note that unlike jetty XML, spring does not have a GET element that allows a bean to be obtained from another bean and then configured. So the structure of this context file is somewhat different to the corresponding jetty xml file.

    Running Spring Jetty

    Running spring jetty is now exactly as for normal jetty:

    java -jar start.jar

    This uses the start.ini file and the lib directory to construct a classpath and to execute the configuration files specified (including the jetty.xml we have converted to spring). Use java -jar start.jar --help to learn more about the jetty start mechanism.

    Of course, with spring, you can also start jetty by running spring directly and using a more spring-like mechanism for aggregating multiple configuration files.

    Conclusion

    While spring and jetty XML are roughly equivalent, they each have their idiosyncrasies. The Jetty API has been developed with the jetty XML format in mind, so if you examine the full suite of Jetty XML files, you will see Getters and methods calls used to configure the server. These can be done in spring (AFAIN using helper classes), but it is a little more clunky than jetty XML. This can be improved over time by a) having spring config files written by somebody more spring literate than me; b) improving the API to be more spring friendly; c) adapting the style of configuration aggregation to be more spring-like. I’m receptive to all three and would welcome spring users to collaborate with to improve the all spring configuration of jetty.

  • Getting Started With Websockets

    The WebSockets protocol and API is an emerging standard to provide better bidirectional communication between a browser (or other web client) and a server.  It is intended to eventually replace the comet techniques like long polling.   Jetty has supported the various websocket drafts in the 7.x and 8.x releases and this blog tells you how to get started with websockets.

    You don’t want to do this!

    This blog will show you how to use websockets from the lowest levels, but I would not advise that any application programmer should follow these examples to build and application.   WebSockets is not a silver bullet and on it’s own it will never be simple to use for non trivial applications (see Is WebSocket Chat Simpler?), so my recommendation is that application programmers look toward frameworks like cometd, that private a higher level of abstraction, hide the technicalities and allow either comet long polling or websockets to be used transparently.

    So instead this blog is aimed at framework developers who want to use websockets in their own frameworks and application developers who can’t stand not knowing what is under the hood.

    Test Client and Server

    The simplest way to get started is to download a jetty aggregate jar that comes complete with a test websocket client and server.  You can do this with a browser of with the following command line wgets:

    wget -O jetty-all.jar --user-agent=demo
      http://repo2.maven.org/maven2/org/eclipse/jetty/aggregate/jetty-all/7.4.0.v20110414/jetty-all-7.4.0.v20110414.jar
    wget --user-agent=demo
      http://repo2.maven.org/maven2/javax/servlet/servlet-api/2.5/servlet-api-2.5.jar

    To run a simple test server (use –help to see more options):

    java -cp jetty-all.jar:servlet-api-2.5.jar
      org.eclipse.jetty.websocket.TestServer
      --port 8080
      --docroot .
      --verbose

    You can test the server with the test client (use –help to see more options):

    java -cp jetty-all.jar:servlet-api-2.5.jar
      org.eclipse.jetty.websocket.TestClient
      --port 8080
      --protocol echo

    The output from the test client is similar to ping and you can use the options discovered by –help to try out different types of tests, including fragmentation and aggregation of websocket frames

    Using a Browser

    Using a java client is not much use, unless you want to write a desktop application that uses websocket (a viable use).  But most users of websocket will want to use the browser as a client.  So point your browser at the TestServer at http://localhost:8080.

    The Websocket TestServer also runs a HTTP file server at the directory given by –docroot, so in this case you should see in the browser a listing of the directory in which you ran the test server.

    To turn the browser into a websocket client, we will need to server some HTML and javascript that will execute in the browser and talk back to the server using websockets.  So create the file index.html in the same directory you ran the server from and put into it the following contents which you can download from here. This index file contains the HTML, CSS and javascript for a basic chat room.

    You should now be able to point your browser(s) at the test server and see a chat room and join it.  If your browser does not support websockets, you’ll be given a warning.

    How does the Client work?

    The initial HTML view has a prompt for a user name.  When a name is entered the join method is called, which creates the websocket to the server.  The URI for the websocket is derived from the documents location and call back functions are registered for open, message and close events.   There org.ietf.websocket.test-echo-broadcast sub protocol is specified as this echos all received messages to all other broadcast connections, giving use the semantic needed for a chat room:

    join: function(name) {
      this._username=name;
      var location = document.location.toString().replace('http://','ws://').replace('https://','wss://');
      this._ws=new WebSocket(location,"org.ietf.websocket.test-echo-broadcast");
      this._ws.onopen=this._onopen;
      this._ws.onmessage=this._onmessage;
      this._ws.onclose=this._onclose;
    },

    When the websocket is successful at connecting to the server, it calls the onopen callback, which we have implemented to change the appearance of the chat room to prompt for a chat message.  It also sends a message saying the user has joined the room:

    _onopen: function(){
      $('join').className='hidden';
      $('joined').className='';
      $('phrase').focus();
      room._send(room._username,'has joined!');
    },

    Sending of a message is done by simply formatting a string as “username:chat text” and calling the websocket send method:

    _send: function(user,message){
      user=user.replace(':','_');
      if (this._ws)
        this._ws.send(user+':'+message);
    },
    chat: function(text) {
      if (text != null && text.length>0 )
         room._send(room._username,text);
    },

    When the browser receives a websocket message over the connection the onmessage callback is called with a message object. Our implementation looks for  the username and colon, strips out any markup and then appends the message to the chat room:

    _onmessage: function(m) {
      if (m.data){
        var c=m.data.indexOf(':');
        var from=m.data.substring(0,c).replace('<','<').replace('>','>');
        var text=m.data.substring(c+1).replace('<','<').replace('>','>');
        var chat=$('chat');
        var spanFrom = document.createElement('span');
        spanFrom.className='from';
        spanFrom.innerHTML=from+': ';
        var spanText = document.createElement('span');
        spanText.className='text';
        spanText.innerHTML=text;
        var lineBreak = document.createElement('br');
        chat.appendChild(spanFrom);
        chat.appendChild(spanText);
        chat.appendChild(lineBreak);
        chat.scrollTop = chat.scrollHeight - chat.clientHeight;
      }
    },

    If the server closes the connection, or if the browser times it out, then the onclose callback is called.  This simply nulls out the chat room and reverts to the starting position:

    _onclose: function(m) {
      this._ws=null;
      $('join').className='';
      $('joined').className='hidden';
      $('username').focus();
      $('chat').innerHTML='';
    }

    How Does the Server Work?

    The server side code for  this chat room is using an embedded Jetty server and is written against the jetty websocket APIs that are not part of the websocket standard.  There is not yet even a proposed standard for serverside websocket APIs, but it is a topic for consideration with the servlet 3.1 JSR.

    The test server is an extension of an embedded Jetty server, and the constructor adds a connector at the required port, creates a WebSocketHandler and a ResourceHandler and chains them together:

    public TestServer(int port)
    {
        _connector = new SelectChannelConnector();
        _connector.setPort(port);
        addConnector(_connector);
        _wsHandler = new WebSocketHandler()
        {
            public WebSocket doWebSocketConnect(HttpServletRequest request, String protocol)
            {
                ...
                return _websocket;
            }
        };
        setHandler(_wsHandler);
        _rHandler=new ResourceHandler();
        _rHandler.setDirectoriesListed(true);
        _rHandler.setResourceBase(_docroot);
        _wsHandler.setHandler(_rHandler);
    }

    The resource handler is responsible for serving the static content like HTML and javascript.  The WebSocketHandler looks for WebSocket handshake request and handles them by calling the doWebSocketConnect method, which we have extended to create a WebSocket depending on the sub protocol passed:

    _wsHandler = new WebSocketHandler()
    {
        public WebSocket doWebSocketConnect(HttpServletRequest request, String protocol)
        {
            if ("org.ietf.websocket.test-echo".equals(protocol) || "echo".equals(protocol) || "lws-mirror-protocol".equals(protocol))
                _websocket = new TestEchoWebSocket();
            else if ("org.ietf.websocket.test-echo-broadcast".equals(protocol))
                _websocket = new TestEchoBroadcastWebSocket();
            else if ("org.ietf.websocket.test-echo-assemble".equals(protocol))
                _websocket = new TestEchoAssembleWebSocket();
            else if ("org.ietf.websocket.test-echo-fragment".equals(protocol))
                _websocket = new TestEchoFragmentWebSocket();
            else if (protocol==null)
                _websocket = new TestWebSocket();
            return _websocket;
        }
    };

    Below is a simplification of the test WebSocket from the test server, that excludes the shared code for the other protocols supported. Like the javascript API, there is an onOpen,onClose and onMessage callback. The onOpen callback is passed in a Connection instance that is used to send messages. The implementation of onOpen adds the websocket to a collection of all known websockets, and onClose is used to remove the websocket. The implementation of onMessage is to simply iterate through that collection and to send the received message to each websocket:

    ConcurrentLinkedQueue _broadcast =
        new ConcurrentLinkedQueue();
    class TestEchoBroadcastWebSocket implements WebSocket.OnTextMessage
    {
        protected Connection _connection;
        public void onOpen(Connection connection)
        {
            _connection=connection;
            _broadcast.add(this);
        }
        public void onClose(int code,String message)
        {
            _broadcast.remove(this);
        }
        public void onMessage(final String data)
        {
            for (TestEchoBroadcastWebSocket ws : _broadcast)
            {
                try
                {
                    ws._connection.sendMessage(data);
                }
                catch (IOException e)
                {
                    _broadcast.remove(ws);
                    e.printStackTrace();
                }
            }
        }
    }

    Don’t do it this way!

    Now you know the basics of how websockets works, I repeat my warning that you should not do it this way – unless you are a framework developer.   Even then, you are probably going to want to use the WebSocketServlet and a non embedded jetty, but the basic concepts are the same. Note the strength of the jetty solution is that it terminates both WebSocket connections and HTTP requests in the same environment, so that mixed frameworks and applications are easy to create.

    Application developers should really look to a framework like cometd rather than directly coding to websockets themselves.  It is not that the mechanics of websockets are hard, just that they don’t solve all of the problems that you will encounter in a real world comet application.

     

  • Jetty 7.4 new features

    A release candidate of Jetty 7.4 is now available as both Jetty@eclipse and Jetty-Hightide@codehaus distributions. This release contains a number of new features which I will briefly introduce now, and make the target of more detailed blogs, webinars and wiki pages over the next few weeks:

    Jetty Overlay Deployer

    Jetty now includes a deployer that is designed to allow a war file to be customised and deployed without modifying the original WAR  file, which is kept immutable or even signed so that you know it is exactly as delivered.   A WAR file is configured by applying a series of overlays, each of which may contain:

    • A web.xml fragment to modify or add filter, servlet and other web.xml configuration.
    • static content to add or replace static content in the war
    • Classes and Jars to be added to the classpath
    • Context configuration

    Overlays can be created that are application specific, node specific or instance specific and multiple instances of the same application will share the common war and overlays.  This sharing includes classloaders and static resource caches and greatly reduces the memory footprint of multi-tenanted deployments.

    Overlays also allow easy identification of what configuration has changed in a deployed WAR, so that an overlay can be applied to an updated WAR and the configuration changes will be preserved.

    Jetty Spring

    Since almost the beginning, Jetty has had it’s own dependency injection (aka IOC)  XML configuration format, which we often refer to as jetty.xml format. This is essentially equivalent to the more popular IOC frameworks like spring XML and Jetty has also been able to be configured and run with spring.  However that approach did not allow the context.xml and jetty-env.xml files to be written in spring format, so deployments still had a mix of IOC formats.    With Jetty 7.4, the jetty XML configuration format can now detect other formats and will use the java services mechanism to look for a provider for that format.  The Jetty-spring module now provides a SpringConfigurationProcessor so that anywhere that a Jetty XML Syntax file is expected, a spring XML file can be used.

    Jetty Reverse HTTP

    There is an increasing desire to server content of client machines or to run servers from behind restrictive firewalls.  An example of this is running a jetty server on an android phone, where the 3G network prevents inbound connections.

    Jetty Reverse HTTP uses comet long polling techniques to allow a jetty server to make an outbound connection to a gateway, over which it will receive inbound requests.

    Jetty Nested

    Jetty has some compelling features, but sometimes it just is not possible to deploy Jetty. Often this is due to non technical reasons such as a corporate policy that say that only allowable container is LogicalGlassSphere or similar.

    Jetty nested makes it possible to deploy jetty within another servlet container by adding a Jetty connector that takes requests/responses from the outer container and turns them into Jetty requests and responses.  If permissions allow, Jetty may also open other connectors on other ports, so that as well as outer container requests, jetty can directly serve async HTTP and/or Websockets.

    This allows your jetty application to be consumable by corporate policies and deployment procedures, while still giving you access to most of the feature set of Jetty. [ Currently the jetty nested connector does not support non blocking asynchronous requests, but it will eventually support that when deployed in servlet 3.0 containers. ]

    Half Close support

    Jetty has long used half close when sending content bounded by EOF to avoid the situation where intermediaries handle a TCP/IP RST by discarding all buffered data.   But since Jetty is also frequently used in a client and/or proxy role, it has become important that half close is supported inbound as well as outbound.  Jetty now supports inbound half closes without an immediate close, so that outbound data can  continue to be generated and flushed.    This is also integrated with SSL and Websocket closing hand shakes.

  • Is WebSocket Chat Simpler?

    A year ago I wrote an article asking Is WebSocket Chat Simple?, where I highlighted the deficiencies of this much touted protocol for implementing simple comet applications like chat. After a year of intense debate there have been many changes and there are new drafts of both the WebSocket protocol and WebSocket API. Thus I thought it worthwhile to update my article with comments to see how things have improved (or not) in the last year.

    The text in italics is my wishful thinking from a year ago
    The text in bold italics is my updated comments

    Is WebSocket Chat Simple (take II)?

    The WebSocket protocol has been touted as a great leap forward for bidirectional web applications like chat, promising a new era of simple Comet applications. Unfortunately there is no such thing as a silver bullet and this blog will walk through a simple chat room to see where WebSocket does and does not help with Comet applications. In a WebSocket world, there is even more need for frameworks like cometD.

    Simple Chat

    Chat is the “helloworld” application of web-2.0 and a simple WebSocket chat room is included with the jetty-7 which now supports WebSockets. The source of the simple chat can be seen in svn for the client-side and server-side.

    The key part of the client-side is to establish a WebSocket connection:

    join: function(name) {
       this._username=name;
       var location = document.location.toString()
           .replace('http:','ws:');
       this._ws=new WebSocket(location);
       this._ws.onopen=this._onopen;
       this._ws.onmessage=this._onmessage;
       this._ws.onclose=this._onclose;
    },

    It is then possible for the client to send a chat message to the server:

    _send: function(user,message){
       user=user.replace(':','_');
       if (this._ws)
           this._ws.send(user+':'+message);
    },

    and to receive a chat message from the server and to display it:

    _onmessage: function(m) {
       if (m.data){
           var c=m.data.indexOf(':');
           var from=m.data.substring(0,c)
               .replace('<','<')
               .replace('>','>');
           var text=m.data.substring(c+1)
               .replace('<','<')
               .replace('>','>');
           var chat=$('chat');
           var spanFrom = document.createElement('span');
           spanFrom.className='from';
           spanFrom.innerHTML=from+': ';
           var spanText = document.createElement('span');
           spanText.className='text';
           spanText.innerHTML=text;
           var lineBreak = document.createElement('br');
           chat.appendChild(spanFrom);
           chat.appendChild(spanText);
           chat.appendChild(lineBreak);
           chat.scrollTop = chat.scrollHeight - chat.clientHeight;
      }
    },

    For the server-side, we simply accept incoming connections as members:

    public void onConnect(Connection connection)
    {
        _connection=connection;
        _members.add(this);
    }

    and then for all messages received, we send them to all members:

    public void onMessage(byte frame, String data){
       for (ChatWebSocket member : _members){
       try{
           member._connection.sendMessage(data);
       }
       catch(IOException e){
           Log.warn(e);
       }
     }
    }

    So we are done, right? We have a working chat room – let’s deploy it and we’ll be the next Google GChat!! Unfortunately, reality is not that simple and this chat room is a long way short of the kinds of functionality that you expect from a chat room – even a simple one.

    Not So Simple Chat

    On Close?

    With a chat room, the standard use-case is that once you establish your presence in the room and it remains until you explicitly leave the room. In the context of webchat, that means that you can send receive a chat message until you close the browser or navigate away from the page. Unfortunately the simple chat example does not implement this semantic because the WebSocket protocol allows for an idle timeout of the connection. So if nothing is said in the chat room for a short while then the WebSocket connection will be closed, either by the client, the server or even an intermediary. The application will be notified of this event by the onClose method being called.

    So how should the chat room handle onClose? The obvious thing to do is for the client to simply call join again and open a new connection back to the server:

    _onclose: function() {
       this._ws=null;
       this.join(this.username);
    }

    This indeed maintains the user’s presence in the chat room, but is far from an ideal solution since every few idle minutes the user will leave the room and rejoin. For the short period between connections, they will miss any messages sent and will not be able to send any chat
    themselves.

    Keep-Alives

    In order to maintain presence, the chat application can send keep-alive messages on the WebSocket to prevent it from being closed due to an idle timeout. However, the application has no idea at all about what the idle timeouts are, so it will have to pick some arbitrary frequent period (e.g. 30s) to send keep-alives and hope that is less than any idle timeout on the path (more or less as long-polling does now).

    Ideally a future version of WebSocket will support timeout discovery, so it can either tell the application the period for keep-alive messages or it could even send the keep-alives on behalf of the application.

    The latest drafts of the websocket protocol do include control packets for ping and pong, which can effectively be used as messages to keep alive a connection. Unfortunately this mechanism is not actually usable because: a) there is no javascript API to send pings; b) there is no API to communicate to the infrastructure if the application wants the connection kept alive or not; c) the protocol does not require that pings are sent; d) neither the websocket infrastructure nor the application knows the frequency at which pings would need to be sent to keep alive the intermediaries and other end of the connection. There is a draft proposal to declare timeouts in headers, but it remains to be seen if that gathers any traction.

    Unfortunately keep-alives don’t avoid the need for onClose to initiate new WebSockets, because the internet is not a perfect place and especially with wifi and mobile clients, sometimes connections just drop. It is a standard part of HTTP that if a connection closes while being used, the GET requests are retried on new connections, so users are mostly insulated from transient connection failures. A WebSocket chat room needs to work with the same assumption and even with keep-alives, it needs to be prepared to reopen a connection when onClose is called.

    Queues

    With keep-alives, the WebSocket chat connection should be mostly be a long-lived entity, with only the occasional reconnect due to transient network problems or server restarts. Occasional loss of presence might not be seen to be a problem, unless you’re the dude that just typed a long chat message on the tiny keyboard of your vodafone360 app or instead of chat you are playing on chess.com and you don’t want to abandon a game due to transient network issues. So for any reasonable level of quality of service, the application is going to need to “pave over” any small gaps in connectivity by providing some kind of message queue in both client and server. If a message is sent during the period of time that there is no WebSocket connection, it needs to be queued until such time as the new connection is established.

    Timeouts

    Unfortunately, some failures are not transient and sometimes a new connection will not be established. We can’t allow queues to grow forever and pretend that a user is present long after their connection is gone. Thus both ends of the chat application will also need timeouts and the user will not be seen to have left the chat room until they have no connection for the period of the timeout or until an explicit leaving message is received.

    Ideally a future version of WebSocket will support an orderly close message so the application can distinguish between a network failure (and keep the user’s presence for a time) and an orderly close as the user leaves the page (and remove the user’s present).

    Both the protocol and API have been updated with the ability to distinguish an orderly close from a failed close. The WebSocket API now has a CloseEvent that is passed to the onclose method that does contain the close code and reason string that is sent with an orderly close and this will allow simpler handling in the endpoints and avoid pointless client retries.

    Message Retries

    Even with message queues, there is a race condition that makes it difficult to completely close the gaps between connections. If the onClose method is called very soon after a message is sent, then the application has no way to know if that close event happened before or after the message was delivered. If quality of service is important, then the application currently has no option but to have some kind of per message or periodic acknowledgment of message delivery.

    Ideally a future version of WebSocket will support orderly close, so that delivery can be known for non-failed connections and a complication of acknowledgements can be avoided unless the highest quality of service is required.

    Orderly close is now supported (see above.)

    Backoff

    With onClose handling, keep-alives, message queues, timeouts and retries, we finally will have a chat room that can maintain a user’s presence while they remain on the web page. But unfortunately the chat room is still not complete, because it needs to handle errors and non-transient failures. Some of the circumstances that need to be avoided include:

    • If the chat server is shut down, the client application is notified of this simply by a call to onClose rather than an onOpen call. In this case, onClose should not just reopen the connection as a 100% CPU busy loop with result. Instead the chat application has to infer that there was a connection problem and to at least pause a short while before trying again – potentially with a retry backoff algorithm to reduce retries over time.

      Ideally a future version of WebSocket will allow more access to connection errors, as the handling of no-route-to-host may be entirely different to handling of a 401 unauthorized response from the server.

      The WebSocket protocol is now full HTTP compliant before the 101 of the upgrade handshake, so responses like 401 can legally be sent. Also the WebSocket API now has an onerror call back, but unfortuantely it is not yet clear under what circumstances it is called, nor is there any indication that information like a 401 response or 302 redirect, would be available to the application.

    • If the user types a large chat message, then the WebSocket frame sent may exceed some resource level on the client, server or intermediary. Currently the WebSocket response to such resource issues is to simply close the connection. Unfortunately for the chat application, this may look like a transient network failure (coming after a successful onOpen call), so it may just reopen the connection and naively retry sending the message, which will again exceed the max message size and we can lather, rinse and repeat! Again it is important that any automatic retries performed by the application will be limited by a backoff timeout and/or max retries.

      Ideally a future version of WebSocket will be able to send an error status as something distinct from a network failure or idle timeout, so the application will know not to retry errors.

      While there is no general error control frame, there is now a reason code defined in the orderly close, so that for any errors serious enough to force the connection to be closed the following can be communicated: 1000 – normal closure; 1001 – shutdown or navigate away; 1002 – protocol error; 1003 data type cannot be handled; 1004 message is too large. These are a great improvement, but it would be better if such errors could be sent in control frames so that the connection does not need to be sacrificed in order to reject 1 large message or unknown type.

    Does it have to be so hard?

    The above scenario is not the only way that a robust chat room could be developed. With some compromises on quality of service and some good user interface design, it would certainly be possible to build a chat room with less complex usage of a WebSocket. However, the design decisions represented by the above scenario are not unreasonable even for chat and certainly are applicable to applications needing a better QoS that most chat rooms.

    What this blog illustrates is that there is no silver bullet and that WebSocket will not solve many of the complexities that need to be addressed when developing robust Comet web applications. Hopefully some features such as keep-alives, timeout negotiation, orderly close and error notification can be build into a future version of WebSocket, but it is not the role of WebSocket to provide the more advanced handling of queues, timeouts, reconnections, retries and backoffs. If you wish to have a high quality of service, then either your application or the framework that it uses will need to deal with these features.

    CometD with WebSocket

    CometD version 2 will soon be released with support for WebSocket as an alternative transport to the currently supported JSON long-polling and JSONP callback-polling. cometD supports all the features discussed in this blog and makes them available transparently to browsers with or without WebSocket support. We are hopeful that WebSocket usage will be able to give us even better throughput and latency for cometD than the already impressive results achieved with long-polling.

    Cometd 2 has been released and we now have even more impressive results Websocket support is build into both Jetty and cometd, but uptake has been somewhat hampered by the multiple versions of the protocol in the wild and patchy/changing browser support.

    Programming to a framework like cometd remains the easiest way to achieve a comet application as well as have portability over “old” techniques like long polling and emerging technologies like websockets.

  • Lies, Damned Lies and Benchmarks

    Benchmarks like statistics can be incredibly misleading in ways that are only obvious with detailed analysis. Recently the apache HTTPCore project released some benchmark results whose headline results read as:

    Jetty
    HttpCore
    Linux BIO
    35,342
    56,185
    Linux NIO
    1,873
    25,970
    Windows BIO
    31,641
    29,438
    Windows NIO
    6,045
    13,076
    Looking at these results, you see that HttpCore has better throughput in all scenarios except bocking IO running on windows. More importantly, for Linux NIO the performance of Jetty is an order of magnitudes behind HttpCore!!
    So is HttpCore really an faster than Jetty and does Jetty NIO suck? For this particular benchmark, the answer is obviously YES and YES.   But the qualification “for this particular benchmark” is very important, since this benchmark is setup to places a huge penalty on  the kind of latency that jetty uses to dispatch requests. Normally latency can be traded off for throughput, but with this benchmark, adding 2ms of latency to a request is the difference between 56,000 requests/sec and 8000 requests/sec.   Jetty makes frequent latency vs throughput tradeoffs, is thus is severly penalized by this benchmark.
    [Note that I’m not saying the HttpCore team have done anything wrong and the “Lie, Damned Lies” head line is only a joking reference to the Mark Twain quote about the power of numbers to show almost anything. Our own benchmarks are biases towards our own sweet spots. This blog seeks only to explain the reasons for the results and not to criticize the HttpCore team].

    HTTP
    Server Throughput Limits

    Typically the throughput of a server is going to be limited by the minimum of one of the following factors:

    Network Bandwidth Limitations

    The total network capacity may limit the maximum throughput. If each response is 10KB in size and the network is only capable of 10MB/s, then 1024 requests per second will saturate that benchmark.  The HttpCore benchmark used 2048B messages of the localhost network, which essentially has no maximum throughput. So for the modelling of this benchmark, I have assumed a GB network, which would have a potential maximum through put of 524288 requests/sec, if it is not limited by other factors.

    CPU Limitations

    The number of request that can be processed may be limited by the available CPU power. If each request took 2ms of CPU time to process, then each CPU could only handle 500 requests per second. For the HttpCore benchmark, they had a 4 CPU box and they have very simple/efficient request handling that took less than 0.018ms per request, which results in potential maximum throughput of  4*1000/0.018 = 222,222 requests/sec, if
    it is not limited by other factors.

    Connection Limitations

    HTTP typically has 1 request outstanding per connection (except when pipelines are used (rarely)), thus the maximal throughput of the server may be limited by the sum of the maximal throughput of each connection. The maximal throughput of a HTTP connection is mostly governed by the round trip time of each request, for example if each request takes 10ms in it’s round trip, then a connection can only handle 100 requests per second. The HttpCore benchmark has requests that take 0.45ms round trip on 25 connections, which results in a potential maximum throughput of 25*1000/0.45ms = 56180 requests/second.

    HttpCore Throughput Limitation

    It can be seen from the analysis above that the HttpCore benchmark throughput is the limited at 56180 requests/second by the  number connections and the round trip time of a request over each connection. More importantly, this limit is numerically sensitive to the specific values chosen for the number of connections and latency.  The following chart shows the minimum of the 3 limitations for the HttpCore benchmark against the number of connections and additional request latency (either in network or the server):

    CPU’s 4
    CPU time per request (ms) 0.018
    Network latency (ms) 0.427
    Max requests/s by CPU 222222
    Request size 2048
    Network bandwidth (MB) 1024
    Max requests/s by bandwidth 524288

    It can be seen that the network bandwidth limitation (524288/s) is never the limiting factor. The CPU limitation (222222/s) is only applicable once the number of connections
    exceeds 125.  At the 25 connections used by the HttpCore benchmark, it can be seen that any extra latency results in a rapid reduction in throughput from almost 60000/s to less than 2000/s.

    The benchmark puts both Jetty and HttpCore on the red (25 connection) curve, but  HttpCore is on the absolute left hand side of the curve, while jetty is a few ms of latency to the right. Thus jetty, which uses extra latency (for good reasons described below), is heavily punished by this benchmark, because the benchmark happens to be on one of the steepest sections of that graph (although it looks like it could be worse at 125  connections, but I expect some other limitation would prevent HttpCore reaching 222222/s).

    Realistic Throughput limitations

    The configuration of the HttpCore benchmark do not well match the reality faced by most HTTP servers for which throughput is a concern. Specifically:

    • The localhost network has less than 1ms of round trip latency, when real internet applications must expect at least 10s if not 100s of ms of network latency.
    • A modern browser will open 6 connections to the same host, so 25 connections represent only 4 simultaneous users. The expectation for a loaded HTTP server is that it will see at least 100s if not 1000s of simultaneous connections.
    • Real connections are mostly idle and will hardly ever see a new request <1ms after a response is sent.
    • Java webservers are typically used for dynamic pages that will take more that 0.018ms to generate.  If the CPU time per request is increased to 0.15ms per request, then the CPU Limitation is reduced to 26667/s.

    The chart below is updated with these more realistic assumptions:


    CPU’s 4
    CPU time per request (ms) 0.150
    Network latency (ms) 20.000
    Max requests/s by CPU 26667
    Request size 2048
    Network bandwidth (MB) 100
    Max requests/s by bandwidth 51200
    This shows that when realistic assumptions are applied, the throughput is far less sensitive to additional latency. Above a 500 connections, the throughput is rapidly limited by available CPU and is unaffected by any extra latency in the handling of each request. Even at 125 connections, extra latency only slightly reduces throughput. This shows that there is little or no cost associated with increased latency and thus a server can consider using extra latency if it has a good reason to (see below).
    I invite you to download the spreadsheet used to generate these graphs and experiment with the assumptions, so that you can see that in many (if not most) scenarios, that throughput is not significantly sensitive to latency. It is only with the specific assumptions used by HttpCore that latency is a sensitive parameter.

    Why use Latency?

    I have demonstrated that in realistic scenarios (with many connections and some network latency), then additional latency in handling a request should not have a significant impact on throughput.   So why does Jetty have a higher latency per request than HttpCore?

    The HttpCore NIO server as configured for the benchmark used a single thread per CPU core, each allocated to a select set terminating a proportion of the connections. Each thread reads a request, writes the response and then loops back to the select set, looking for a the next connection to read the next available request. This is very efficient, but only if all requests can be handled without blocking.   If the handling the request blocks for any reason (eg writing response to slow client, waiting for DB, waiting for a synchronize lock, etc) then all the other requests from the same select set will also be blocked and throughput will be greatly reduced.   For a 4 CPU machine, it would only take 4 slow clients or 4 long DB queries to block the entire server and prevent any requests from being handled.  The HttpCore benchmark avoids this situation by having simple non blocking requests handlers and no slow clients, networks or databases etc.

    It is unacceptable in most real HTTP deployments to allow one request to block unrelated requests due to thread starvation. Thus most HTTP servers operate with at thread pool and dispatch the handling of each request to different thread from that handling the NIO select set.  Since each request is handled in a dedicated thread, then it may block without affecting other requests or reducing the throughput of the server.
    When a request is dispatched to a thread pool, it typically waits for a few ms in a job queue for a thread to be allocated to handle the request. For most realistic  scenarios this extra latency has little or no cost and significant benefit, but in the HttpCore benchmark this latency is heavily penalized as it delays the response, thus it delays the load generator sending the next request. Throughput is reduced because the client sends less requests, not because the server cannot handle them.
    Also the benchmark compared the raw HTTP components of HttpCore vs the rich servlet environment of Jetty.  Jetty will consume some extra CPU/latency to establish the servlet context which provides many benefits of functionality to the application developer. Jetty could also be configured as a simple HTTP handler and would thus use both less CPU and less latency.

    Conclusion

    The HttpCore benchmark is essentially comparing apples with oranges.  The benchmark is setup to mostly measure the raw speed of the HttpCore HTTP parsing/generating capabilities. and does not represent a realistic load test.  The Jetty configuration used has been optimized to be a general purpose application server and HTTP server for large numbers of mostly idle connections.  Given this disparity, I think it is great that Jetty was
    able to able to achieve similar and sometimes better performance in some of the scenarios. This shows that Jetty’s own HTTP parsing/generation is no slouch and that it would be interesting to compare jetty if it was stripped of it’s thread pool and servlet container.  If we find the time we may provide such a configuration.
    For anybody that really wants to know which server would be faster for them (and the different feature sets do not guide their selection), then they need to setup their own benchmark with a load generator that will produce a traffic profile as close as possible to what their real application will experience.