Developing a metrics monitoring component seems simple, but deceptively so.
While adding a simple counter component is easy enough, more advanced functionalities (polling, filtering, exporting the results… ) are somewhat trickier to code. Also since the metrics must be read and written in parallel with the core application logic, the code will be multithreaded, which adds another challenge: concurrency is hard.
So an in-house solution is doable, but will probably take at least a few days to develop, and that’s assuming it’s bug free.
The alternative is to re-use existing libraries which neatly solve this problem by providing monitoring components such as counter, gauges, timers, and the ability to export the data via JMX. For instance:
Example: the java code below calculates as many prime numbers as possible for a specified period of time, and uses Servo’s counter and peak rate counter to keep track of the total number of primes discovered, and the maximum rate of primes discovered per second.
The metrics are automatically exposed via JMX so Java Mission Control can pick it up:
…and chart the resulting data.
The PlayFramework has been my go-to framework of choice for several months. It stands out in the crowded space of jvm web frameworks because it is (relatively) lightweight, with a short learning curve, and a focus on ease of testing both at the unit and functional level.
So far so good. However… The core logic of the framework (version 2 and up) is mostly written in Scala, and it shows:
- view templates have to be scripted using Scala
- the build tooling uses SBT, instead of the Maven/Gradle alternatives favored by the majority of Java projects
- a Scala/SBT plugin is required to compile the code in Intellij and Eclipse.
- long build times, courtesy of the Scala compiler
These annoyances (from the standpoint of a Java programmer who is not particularly interested in writing Scala code) do add up, so much so that at times this negates the productivity gains promised by the framework.
The Ninja Framework
The Ninja framework is heavily inspired by Play, with the same focus on simplicity and performance, the same functionality (both frameworks provide the same basic constructs in terms of routers, controllers, filters…). The API is also very similar.
Above all this is a pure Java (no Scala) framework so it removes all of the concerns highlighted above. So all in all it’s an easy trade-off.
Migrating from Play to Ninja
This should be fairly simple because the APIs of both frameworks are near identical. Amongst the salient points:
- create a pom.xml with Ninja framework dependencies at the root of your Play project (examples available on the NinjaFramework website)
- setup your project as a Maven project. In Intellij this is done with a right-click on the pom above and select “Add as a Maven project”
- replace all of the play.* imports by their equivalents ninja.*
- create a Java class to host the route configuration (instead of a property file in Play)
- some of the properties in the application.conf may differ from Play to Ninja – no shortcut here they have to be analysed on a case by case basis.
- (the best part) remove the scala cruft: scala plugin, build.scala, plugins.sbt, activators…
- Watch your compilation time plummet. Enjoy.