Although Java remains one of the most popular programming languages in the world, the real story these days isn’t the Java language – it’s in the underlying virtual machine. Over the last few years, the JVM has branched out beyond just traditional support for existing languages such as as JRuby or Jython. It’s entered new territory with support for new languages custom designed for ease-of-use, scalability and concurrency. These days it’s not uncommon to use the JVM to jump right into a major project built on top of Groovy or Scala.
As the only APM vendor to support Java, Ruby, Python, PHP and .NET, New Relic has always supported a wide range of technologies and platforms. And we’ve been running thousands of applications on top of JRuby for years. But in the last month we’ve put out a couple releases that are important because they highlight our increased focus on not just Java as a language, but on the JVM as an ecosystem. Specifically, these include our improved JVM metrics and our newly launched support for the Play 2 framework.
Better Support for the JVM Ecosystem
With our improved JVM metrics, we’re showing more data than ever that’s relevant to anyone running on the JVM, regardless of what programming language or framework they use. The data includes thread activity, HTTP session data, connection pool metrics, class load/unload counts, and more. And true to the New Relic spirit, we present it in a way that just makes sense. Although much of this data is derived from JMX values, we comb through them automatically for you so that you don’t have to worry about it (unless you have some advanced needs.)
To support the JVM ecosystem even further, we’ve also added Play 2 support for both Java and Scala. Although we already supported some versions of Play 1, Play 2 was quite a bit of a rewrite and embraced Scala much more extensively. To properly support Play 2, we had to tackle all sorts of new things. We added support for the Netty web server, support for Scala itself and support for the asynchronous development techniques that Play makes so easy to build with. This release is a big milestone for New Relic because it’s the first time we’ve supported two different languages (Java and Scala) with a single agent.
“We were very impressed by New Relic’s leadership in embracing an emerging asynchronous web framework in Play 2 and were thrilled to work closely with their engineering teams to integrate Play 2 into the New Relic monitoring suite.”
— Michael Bryzek, CTO & Cofounder, Gilt Groupe
Although this isn’t broad Scala support (yet!), it’s the first step in recognizing and supporting the JVM for what it really is: a large ecosystem of diverse languages, frameworks and libraries. We hope that these two features demonstrate our commitment to the JVM and give you a glimpse into our future plans at New Relic.
Have More Questions?
Q: What version of Play is supported?
A: We support Play 1.2.x and are committed to continuing support for the Play 2.x (2.0, 2.1, etc) line going forward.
Q: Do you support Java, Scala or both?
A: You can write your app in Java, Scala or a mix of both – it doesn’t matter to us. We’ll automatically trace through all the asynchronous handoff points that happen inside your Play app, regardless of your choice of language. In fact, because Play’s internals are written in Scala, we’re already doing the work of supporting a polyglot application under the covers – even if you’re writing your app in 100% Java.
Q: Do you now support any Scala application?
A: Not exactly. If you have an app written in pure Scala, or perhaps with a framework such a Lift or Finagle, we won’t automatically pick up everything like we do with Play. However, you’re welcome to utilize our Java API (which is totally compatible with Scala) to define some custom instrumentation. Specifically look towards the @Trace annotation, the NewRelic.setTransactionName() method, and NewRelic.setRequestAndResponse() method, which will allow you to turn any block of code in to a web transaction.
Q: Do you support Netty now?
A: In part. As of today, we’re not announcing full support for Netty. Anything that works for you is fully unsupported. However, Play utilizes Netty so much of the work was done. We hope to announce something more in the future.
Q: Do you support Akka?
A: Play utilizes Akka heavily for various concurrency and asynchronous operations, and as such we need to instrument it in order to trace complex, multithreaded Play transactions. However, that does not mean we generically support Akka in any environment. We continue to evaluate the best way to generically express complex async event flows and hope to share more in the future about our plans.
Q: How do you report asynchronous transactions?
A: Because a Play controller can execute multiple database and web service requests concurrently, we need to express all of those actions in an easy-to-understand way. If you’re looking at a transaction trace, take note of the “timestamp” column. It will tell you when each component ran and help you understand the concurrency of your logical transaction. In cases where multithreading and async are used under the covers (i.e., when an incoming request is routed to your Play controller), we’ll minimize that data to make it easier for you to focus on your async application code.
For aggregate metrics over time, we represent every segment of the logical transaction in a simple time-series stackchart. Each segment in the stack represents time spent in a certain logical part of the transaction. Note: With async and parallelization, the sum of the individual parts can be greater than the total transaction time.
Q: What are your plans for Scala in general?
A: We are very excited about Scala in general and are thrilled to be the first APM vendor to offer native Play 2 for Scala support. We’re continuing to evaluate other popular frameworks within the Scala ecosystem and will continue to add support for them as necessary. More importantly, we view this release as a major milestone as we now support Scala (for Play) on top of Java, Ruby, Python, PHP, and .NET.
Q: What about other JVM languages, such as Groovy?
A: Although our initial focus with this release is Scala, rest assured that we’re also considering other JVM-based languages. The good news is that most of them are compatible with our Java API, meaning that you may already be able to use them with a small amount of custom instrumentation. That said, we understand the convenience of native support for frameworks and platforms within New Relic and we’ll continue to evaluate and add support for new technologies over time.