Flirting with disaster: A dangerous use of Groovys dynamic method invocation
January 5th, 2016
An example of when not to use Groovys dynamic method invocation feature. Injection attack vulnerability.
I have a pet project that I’ve written in Grails 3. I run it on an already-busy cloud server via the fat jar. I kept the default Tomcat configuration but soon I kept getting out of memory errors. I wanted to use something more lightweight. So I started looking how to change out Tomcat for something else in Grails 3, but I couldn’t find anything. But Grails 3 is just Spring Boot, right?
I found this page on in the Spring Boot docs about changing from Tomcat to Undertow. I’ve used Undertow before and I really liked it. The documentation didn’t quite match what I had in my build.gradle
file but it was really pretty easy. I simply changed this line:compile "org.springframework.boot:spring-boot-starter-tomcat"
to this:compile "org.springframework.boot:spring-boot-starter-undertow"
And that was it — I recompiled and redeployed… and haven’t had a memory problem since. That was two months ago. The only difference I’ve seen is that dbconsole doesn’t work while running in development mode, but that’s not a big deal to me.
An example of when not to use Groovys dynamic method invocation feature. Injection attack vulnerability.
Example of clustering Grails using Docker Compose and distributing data and processing within the cluster using Hazelcast.
Test pollution can be frustrating to look into, especially when the failures are sporadic. Running your tests on the same database may also lead to problems.
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.