Polyglot

Polyglot

The next examples demonstrate the usage of Jolokia with various different clients. The samples check for memory and performs some action if the used heap memory exceeds a certain threshold. No error handling was included in order to focus on the Jolokia logic.

Bash

Jolokia can be contacted withot any client library directly from a Bash script. This example checks, that the Memory used doesn't exceeds 90% of the available memory, and if so, restarts the Tomcat server (without any error handling, though):

#!/bin/bash
base_url="http://localhost:8080/jolokia"
memory_url="${base_url}/read/java.lang:type=Memory/HeapMemoryUsage"
used=`wget -q -O - "${memory_url}/used" | sed 's/^.*"value":\([0-9]*\).*$/\1/'`
max=`wget -q -O - "${memory_url}/max" | sed 's/^.*"value":\([0-9]*\).*$/\1/'`
usage=$((${used}*100/${max}))
if [ $usage -gt 90 ]; then 
  /etc/init.d/tomcat restart
  sleep 120
fi

Perl

Using the jmx4perl client library, this can be done even simpler in Perl (and in this case with a single HTTP request):

#!/usr/bin/perl
use JMX::Jmx4Perl;
use strict;
my $jmx = new JMX::Jmx4Perl(url => "http://localhost:8080/jolokia");
my $memory = $jmx->get_attribute("java.lang:type=Memory","HeapMemoryUsage");
if ($memory->{"used"} / $memory->{"max"} > 0.9) {
    system("/etc/init.d/tomcat restart");
    sleep(120);
}

Javascript

The JSON based Jolokia protocol fits perfectly in the Javascript world. Jolokia provides a Javascript client library which makes it a piece of cake to access JMX information directly from within the browser. A variant of the memory example above looks in Javascript like this:

var j4p = new Jolokia("/jolokia");
j4p.request(
 {
   type: "read",
   mbean: "java.lang:type=Memory",
   attribute: "HeapMemoryUsage"
 },{
   success: function(resp) {
      if (resp.value.used / resp.value.max > 0.9) {
         alert("Memory exceeds 90% threshold");
      }
   }
 });

Java

The Jolokia agents can be accessed from Java as well. The biggest different to JSR-160 client interfaces is, that Jolokia has a typeless approach. The disadvantage is of course, that the type of the exposed attribute or operation return value has to be known, but the big advantage is, that no Java type information for custom types (== custom Java classes) is required on the client side.

The example above implemented in Java looks like:

import org.jolokia.client.*;
import org.jolokia.client.request.*;
import java.util.Map;

public class JolokiaSample {
    
    public static void main(String[] args) throws Exception {
        J4pClient j4pClient = new J4pClient("http://localhost:8080/jolokia");
        J4pReadRequest req = new J4pReadRequest("java.lang:type=Memory",
                                                "HeapMemoryUsage");
        J4pReadResponse resp = j4pClient.execute(req);
        Map<String,String> vals = resp.getValue();
        int used = Integer.parseInt(vals.get("used"));
        int max = Integer.parseInt(vals.get("max"));
        int usage = (int) (used * 100 / max);
        if (usage > 1) {
            System.out.println("Memory usage exceeds 90% (used: " + used + 
                               " / max: " + max + " = " + usage + "%)");
        }
    }
}

Roadmap

In fact, serving non-java environments is one of the most outstanding strengths of Jolokia. The focus for the future evolution of Jolokia is to provide more client libraries. Top on the list are Groovy and Scala. If you like to add a client library in your favourite language, go ahead, we would be happy to include it. Currently, the tendency is to keep JVM based languages (+ Javascript) under the Jolokia umbrella, but support for others (like jmx4perl) hosted elsewhere is in our focus as well. But well, let's see ;-).

Next