Category Archives: Java

ActiveMQ made easy for Dropwizard

If you are planing to use Apache ActiveMQ (JMS) in your Dropwizard application, dropwizard-activemq-bundle might be a perfect match.

dropwizard-activemq-bundle combines the simplicity of Dropwizard with the powers of ActiveMQ.

activemq-5.x-box-reflectionSince most modern applications uses JSON these days, dropwizard-activemq-bundle uses Dropwizard’s Jackson-integration to automatically serialize and deserialize your POJOs to and from JSON.

dropwizard-activemq-bundle uses pooled connections to ActiveMQ and contains multiple important Health-Checks.

For more detailed information and examples, check out dropwizard-activemq-bundle on github.

DDSL plugin for Dropwizard 0.7.0

News 24. April 2014: New version of DDSL-Dropwizard-Plugin with Dropwizard 0.7.0 support is released.

DDSL – Dynamic Distributes Service Locator – enables your applications to be discovered by other applications or reverse-proxies like nginx without any manual reconfiguration. DDSL uses Apache Zookeeper to make Service Discovery possible in a distributed way without any single point of failure.

When using DDSL you can automatically scale your system up by just starting a new instance of one of your applications on some random machine, since the built-in Load-balancer in DDSL will automatically start sending traffic to it.

I have recently created and release a DDSL plugin for Dropwizard which makes it really easy to add the functionality to your existing Dropwizard-applications.

If you are more into Play Framwork, choose the 1.x-module or 2.x-plugin, and you can of course use it in any of your X-technology Java- or Scala-applications.

If you have any questions or comments, please comment here on this blog or contact me via github or twitter.

Play 1 module: Faster Groovy Templates

GT-Engine is a new implementation of the default groovy template engine in Play Framework 1. GT-Engine is faster and uses less memory.

You can now use GT-Engine in Play 1 using the module faster-groovy-templates which is a drop-in-plugin replacing the default template implementation.

UPDATE: The module is now available in the Play Framework module repository

There also exists a Play 2 module that makes it more easy for you to port your Play 1 application to Play 2.0.

Announcing Groovy Template support for Play Framework 2.0

I have just released a beta version of the Groovy Template module for Play Framework 2.0 called gt-engine-play2.

The current project-status is Beta as of 24. january 2012.

It is based on the gt-engine described in this blog post.

It should be feature complete (for Java) but please have a look at the readme file over at github – and the issues-list. When you find new issues, please report them via github.

Please try it out and start porting you Java Play 1.x app to Play 2.0 🙂


PlayFramework: New faster Groovy Template Engine


Play 1 module available here:

Play 2 module available here:

Why re-implement the Groovy Template Engine?

Play Framework version 1.x default template engine is based on Groovy. Play 2.0 has a new template system based on Scala but we want to make it possible to migrate from Play 1.x to 2.0 without having to rewrite all of your old Groovy Templates.

When investigating how to use the Groovy template engine code from Play 1.x in Play 2.0 it turned out to be difficult since the implementation is really tight coupled with the entire Play 1.x code base.

This made me start a (too big) project to re-implement the entire Groovy Template Engine making sure it was not using any of the other Play code. This would make it possible to use the exact same implementation in Play 2.0. It aims to be 100 % compatible with existing templates/applications.

When doing this reimplementation I have managed to make it faster (and using a little less memory i think 🙂 ). I’ll probably write another blogpost later about how it is implemented but basically I precompile the template source down to both java and as little groovy code as possible. See at the bottom for benchmark results.

I think the new implementation is feature-complete (But Beta) and we’re using it in development at work. But there is still work to do:

  • checking/making sure I have not broken too much api 🙂
  • improve/clean api/code
  • Moving the code to external project so Play only uses a jar-file
  • Add code to Play 2.0 to use the groovy engine.

(New feature: If you add ‘save-gttemplate-source-to-disk = true’ to application.conf, the generated java and groovy source code is dumped to disk so you can step-debug it if you want.)

The current source (Based on Play 1.2.4-RC2) can be found (UPDATE: Remember to use the correct branch ‘new_groovy_template_impl’).

Please try it out and report any problems or suggestions/thoughts.

Some limitations regarding Groovy code snipits %{ ..code.. }%:

  • You can no longer use partial-program-flow-code like this:
    %{ if( expression) { }% or %{ myList.foreach() { }%
  • Instead you have to use:
    #{if expression} or #{list myList}
  • Also you cannot use def or declare type when creating variables if you want it to be visible outside the script-block. (Not a limitation anymore)


The following benchmark results are not scientific at all but I made them just to try to show the difference between old and new implementation. It is based on Play 1.2.4-RC2.

The test application can be found at github

This is how I performed the tests

I started Play like this: play run –%prod -XX:CompileThreshold=10

I used CompileThreshold to shorten the needed jvm warm up time.

For each speed-benchmark i restarted play, ran 14000 request using ab (40 concurrent), then did another 14000 request and recorded the stats.

For memory-benchmarks I restarted Play, then recorded heap usage with jvisualvm during the first 14000 requests. All GC settings are default.

Detailed info about the speed benchmark can be found here.

Google spreadsheet with useful numbers can be found here.

Each test shows two numbers:

  • requests pr second
  • total “rendering time” for all 14000 requests. (total time for test minus total time for noTemplate-test: Shows aprox time spent with rendering without time spent in framework itself)


ab -k -c 40 -n 14000 http://localhost:9000/application/minimalTemplate


Requests pr second

1.2.4-rc2 6526 r/s
new impl 7141 r/s
Improvement 1.09X

Total “Rendering time”

1.2.4-rc2 0.362 seconds
new impl 0.208 seconds
Improvement 1.74X


ab -k -c 40 -n 14000 http://localhost:9000/application/normalTemplate

Requests pr second:

1.2.4-rc2 1674 r/s
new impl 2801 r/s
Improvement 1.67X

Total “Rendering time”

1.2.4-rc2 6.57 seconds
new impl 3.24 seconds
Improvement 2.03X


ab -k -c 40 -n 14000 http://localhost:9000/application/normalTemplateBigData

Requests pr second:

1.2.4-rc2 323 r/s
new impl 524 r/s
Improvement 1.62X

Total “Rendering time”

1.2.4-rc2 41.438 seconds
new impl 24.935 seconds
Improvement 1.66X


ab -k -c 40 -n 14000 http://localhost:9000/application/normalTemplateBigDataWithJavaExtensions

Requests pr second:

1.2.4-rc2 290 r/s
new impl 434 r/s
Improvement 1.50X

Total “Rendering time”

1.2.4-rc2 46.336 seconds
new impl 30.464 seconds
Improvement 1.52X


ab -k -c 40 -n 14000 http://localhost:9000/application/normalTemplateBigDataInTag

Requests pr second:

1.2.4-rc2 310 r/s
new impl 460 r/s
Improvement 1.48X

Total “Rendering time”

1.2.4-rc2 43.236 seconds
new impl 28.658 seconds
Improvement 1.51X


ab -k -c 40 -n 14000 http://localhost:9000/application/normalTemplateBiggerData

Requests pr second:

1.2.4-rc2 35 r/s
new impl 56 r/s
Improvement 1.60X

Total “Rendering time”

1.2.4-rc2 388.032 seconds
new impl 245.809 seconds
Improvement 1.58X

Memory info



new impl:



new impl:



new impl:

Some last words

I hope this info was useful (It actually took a long time to perform the tests and write this blog 🙂 ). Also, I hope you download the custom play version and help me find problems not yet found.