A few days ago WildFly 9 was released and one of the highlight for sure is the support of HTTP/2.0 in the Undertow web subsystem. As Hawkular has recently moved to use WildFly 9 (from 8.2) as its underlying server, it was sort of natural to try to use http2 for connections from the Hawkular-Wildfly-Monitor client to the server.
One peculiarity here is that in my case the monitor client is running inside the Hawkular server, but at the end it does not matter if it is running inside a standalone WildFly server or inside the Hawkular server.
The setup
Greg Autric has written a blog post, that shows how to set up Http2 in WildFly with the offline CLI, which also works well in the Hawkular case.
As the question came up: that setup also includes the https setup inside WildFly.
The only thing that is a bit problematic in the post is that setting JAVA_OPTS before starting the server will ignore all the settings from standalone.conf, which in the current Hawkular version will prevent a correct start of the bus broker (because the IPv4Only flag is lost).
So in my opinion it is better to modify standalone.conf to *add* those options to the other options that are already there:
JAVA_OPTS="-Xms64m -Xmx512m -XX:MaxPermSize=256m -Djava.net.preferIPv4Stack=true"
JAVA_OPTS="$JAVA_OPTS -Xbootclasspath/p:/opt/hawkular-1.0.0.Alpha3-SNAPSHOT/alpn-boot-8.1.3.v20150130.jar"
JAVA_OPTS="$JAVA_OPTS -Djboss.modules.system.pkgs=$JBOSS_MODULES_SYSTEM_PKGS -Djava.awt.headless=true"
Now when I start the Hawkular server and try to connect with FireFox on the https port, I get the warning about the self signed certificate, but can connect and get the UI over a Http2 connection as described in Greg's post.
Running the OkHttpClient
As said before, the WildFly monitor client is a subsystem inside the WildFly server. I wrote a bit of client code, that is running in the subsystem (shortened):
OkHttpClient httpClient;
httpClient = new OkHttpClient();
// DO NOT USE IN PRODUCTION, allow all hostnames
httpClient.setHostnameVerifier(new NullHostNameVerifier());
setKeystore(httpClient); // Use custom ssl factory
String uri = "https://...:8443/";
Request request = new Request.Builder()
.url(uri)
.addHeader("Accept", "application/json")
.get()
.build();
// sync execution just for the post
Response resp = httpClient.newCall(request).execute();
System.out.println(resp.toString());
Fail?
This code works well except for the fact that is always uses Http(s)/1.1 and never Http2 as you can see from the output of the last println statement:
Response{protocol=http/1.1, code=204, message=....}
I was playing around with various options up to a point where I thought, I have to extract the code to a standalone Java SE class to better debug it in isolation.
I wrote the class, set the bootclasspath, ran it and it worked perfectly:
Response{protocol=h2, code=204, message=....}
So what is the difference? I removed the bootclasspath setting for ALPN, reran and the connection fell back to http/1.1.
Which is kinda strange as my client subsystem is running inside the very same WilFly server, that is running Undertow and which is able to serve http2 requests and where I added the ALPN classes through JAVA_OPTS earlier.
Now remember that WildFly is using their own classloader system (jboss-modules), which is pretty powerful in isolating deployments and classes and restricting their visibility and/or leakage into areas where they should (not) be seen.
And this in fact is what happened here as well.
Success!
So I had to explicitly add the ALPN classes to my module.xml file for the monitoring client subsystem:
<module xmlns="urn:jboss:module:1.3" name="${moduleName}">
<resources>
<resource-root path="clients-common.jar"/>
[...]
<resource-root path="okhttp.jar"/>
<resource-root path="okio.jar"/>
</resources>
<dependencies>
<!-- modules required by any subsystem -->
<module name="javax.api"/>
[...]
<system export="true">
<paths>
<!-- Needed for HTTP2 and SPDY support-->
<path name="org/eclipse/jetty/alpn"/>
</paths>
</system>
</dependencies>
</module>
From the above snippet, you can see that the okhttp and okio jars are packaged in the module and are made available to my client code as well.
Now that the module.xml has been adjusted, as is well and my subsystem is using Http2 :-)
