Sharing Grails HAL and JSON Renderers
August 13th, 2015
Details a method to share Grails object marshallers across XML, JSON and HAL flavors of web services.
Where I work, a bunch of the Grails have many, many datasources. One app in particular I was brought in on because it was dropping a bunch of connections on Saturday night or Sunday morning. The app had to be restarted every Sunday morning and no one was sure why. They said that database had stayed up and one datasource was fine.
Once upon a time I used BoneCP to fix a similar problem in a Java app but a little research showed that it is no longer maintained. I asked around and was pointed to HikariCP as a good replacement.
But of course I had to re-create the original problem first. I changed the one of the datasources to be at localhost:3000
and the setup an ssh tunnel from my port 3000 to the actual datasource. I did a run-app
and tested to make sure things were fine. And then I killed the ssh connection and I got connection errors — as expected. I opened the ssh connection again while the app was up — same connection error. What I wanted it to do is to reconnect.
So I hunted down how to put HikariCP in Grails. Luckily someone had already done it for me and so I put it into my app. Note that you must have pooled = false
in your DataSource.groovy
file for all the extra datasources because you don’t want Grails’ default pooling to go — you want it to be controlled by HikariCP.
After I got HikariCP configured in the application, I redid my test… and, sure enough, when the ssh tunnel was back up, the connection was live. This should solve the Sunday Morning Problem.
Details a method to share Grails object marshallers across XML, JSON and HAL flavors of web services.
A quick introduction to Retrofit. Well cover the basics for how to convert any API into a type-safe Java interface using @GET, @POST, @QUERY, and @PARAM.
Create a mocked RESTful web service using Groovy, which allows users to test out the service without changing any data.
Mike has almost 20 years of experience in technology. He started in networking and Unix administration, and grew into technical support and QA testing. But he has always done some development on the side and decided a few years ago to pursue it full-time. His history of working with users gives Mike a unique perspective on writing software.