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 🙂

-morten

PlayFramework: New faster Groovy Template Engine

UPDATE:

Play 1 module available here: https://github.com/mbknor/faster-groovy-templates

Play 2 module available here: https://github.com/mbknor/gt-engine-play2

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 https://github.com/mbknor/play/tree/new_groovy_template_impl (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)

Benchmark

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)

minimalTemplate

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


normalTemplate

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


normalTemplateBigData

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


normalTemplateBigDataWithJavaExtensions

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


normalTemplateBigDataInTag

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


normalTemplateBiggerData

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

normalTemplate

1.2.4-rc2

new impl:

normalTemplateBigData

1.2.4-rc2

new impl:

normalTemplateBigDataInTag

1.2.4-rc2

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.

Gamedev or Insurance? Which is best?

Interesting read from a colleague of mine over at sickenger.com

Preview: DDSL – Dynamic Distributed Service Locator

Have a look at DDSL – Dynamic Distributed Service Locator over at GitHub

There you can find working code, README and example with step-by-step guide.

Official post coming later when it is more complete..

Legacy app that Plays with the future..

Enabling our legacy web application for the Future using The Play Framework

Some background

At work we have an old big web application written in some strange language originally running on a mainframe web server.

It’s kind of jsp-ish with just one big script for each page – not even close to MVC.

(Related post: Taking control over legacy code)

The application is constantly being extended so it has never been realistic to stop adding features while porting the hole application to a modern platform – and many of the developers like the JSP-feeling (just dump a new file and it works…)

Some years ago I wrote an emulator for that webserver in java (using extensive precompiling and an Open Source interpreterer). First the emulator had to be 100% backward compatible but then we switched off the mainframe webserver and only used the emulator – running in Tomcat on Windows (I know: Linux is better). We also added features to the language (like include files etc… 🙂 ) using precompiling.

The only solution I saw to make it possible to introduce modern technology in the application was to make it possible to gradually rewrite parts of the application – while the old and new parts of the app could communicate and work side by side.

Over the years I’ve created many solutions to enable our “script-kidies” to stop developing in the legacy language and start using java.. But I never got them to use it..

The Solution

In the fall of 2010 after attending JavaZone I had a breakthrough: Writing the new code in Java using the Play Framework.

Earlier today we upgraded our production environment to use the new legacy-play-integrated solution.

How we did it

As I said, all parts of the application has to be able to communicate – sharing state. The legacy application is statefull (read: session stored on server) – and the play part of the app is not.

I created an “external session store” (Lets call it ESS) – when the legacy app needs to store data in Session, it stores it in the ESS and only stores an ESS-id in the Real Session. This ESS-id is writen to a cookie.

Then when the browser accesses the play part of the application, either fullframe or using “DOM-injection” using JavaScript or using iframes, Play can read the ESS-id from the cookie (since both the legacy app-part and the play-app-part is using the same domain-namespace (fixed using reverse proxy)) – Then the play app can access the ESS server-side via REST and read/store data – In this way – both parts of the app can share data realtime server-side.

The “DOM-injection”-technique was the killer feature that made it possible to convince our Team leader that we should implement all the new functionality in Play.

It works like this: The legacy app renders the full page (with menus and stuff) leaving the “main part” empy with a <div>, then it uses JQuery to fetch a page from Play and injecting the returned DOM (read: HTML with embedded JavaScript) on that <div>. When the injected DOM is rendered, its embedded JavaScript/JQuery is executed. This way the page rendered in the users browser contains no iframes and it makes the “play-part” of the application/page totally contained. This resulted in the (partial) Play app being nice and simple using some java code server side and more HTML/JQuery client-side – since most of the backend systems served data as JSON via REST.

Conclusion

My feeling is that the development team is so happy with what the Play Framework gave us, that the only Legacy code being written in the future – is to disable old code – or linking to new functionality written in Play.

In the Future?

Maybe they can be convinced to ditch Java for Scala? I hope so..

Maven Dependency Management (Deptools)

A very good colleague of mine wrote an excellent post about my maven plugin called ‘deptools’.

You can read it on his blog

Moved from blogger.com to WordPress

I have now moved my blog away from moaxstuff.blogger.com to my own WordPress hosted by myself… Even though my posts is not that interesting, it was almost impossible to find it on google.com – You had to specific search in “blogs” to find it…