Ratpacked: Searching Objects In The Registry

In a previous post we learned about the get and getAll methods to get objects from the registry. Ratpack also provides the first method to get objects from the registry. This method accepts a Function that is applied to the elements of a given type. The first element where the Function returns a non null value is returned encapsulated in an Optional object. If the Function returns a null value for all elements than Optional.empty() is returned.

Continue reading

Grails Goodness: Saving Server Port In A File

In a previous post we learned how to save the application PID in a file when we start our Grails application. We can also save the port number the application uses in a file when we run our Grails application. We must use the class EmbeddedServerPortFileWriter and add it as a listener to the GrailsApp instance. By default the server port is saved in a file application.port. But we can pass a custom file name or File object to the constructor of the EmbeddedServerPortFileWriter class.

Continue reading

Grails Goodness: Using Spring Cloud Config Server

The Spring Cloud project has several sub projects. One of them is the Spring Cloud Config Server. With the Config Server we have a central place to manage external properties for applications with support for different environments. Configuration files in several formats like YAML or properties are added to a Git repository. The server provides an REST API to get configuration values. But there is also a good integration for client applications written with Spring Boot. And because Grails (3) depends on Spring Boot we can leverage the same integration support. Because of the Spring Boot auto configuration we only have to add a dependency to our build file and add some configuration.

Continue reading

Use Spring classpath Resource as Tuckey UrlRewriteFilter configuration

Use Spring classpath Resource as Tuckey UrlRewriteFilter configuration

Recently I wanted to use the Tuckey UrlRewriteFilter.
It is described as: A Java Web Filter for any compliant web application server, which allows you to rewrite URLs before they get to your code.

I wanted to load my urlrewrite.xml as a Spring (classpath) resource, instead of loading it from the default location provided by the UrlRewriteFilter. The default behavior loads the configuration file from /WEB-INF/ulrewrite.xml. In my case I wanted to load it from the /src/main/resources folder, which is the root of my classpath.

With this small and easy to use decorated UrlRewriteFilter, you can load your configuration from any location. When you write a UnitTest for this decorated Filter, don’t forget to call the init() method before you call the actual doFilter(). For testing your UrlRewriteFilter rules, it is better to write an IntegrationTest, for example with the TestRestTemplate

Ratpacked: Getting Multiple Objects With Same Type From Registry

To get objects from the registry or context we specify the type of the object we want. Ratpack will find the object(s) that match the given type. If we use the get method then the last object added to the registry with the given type is returned. To get multiple objects we use the getAll method. The methods returns an Iterable with the found objects where the last added objects are returned as first elements.

Continue reading

The (non)sense of caching

I have seen several projects where the developers had implemented caching all over the place. Caches were causing a large increase of heap usage, and users were always complaining that they were not seeing the latest data.

My opinion on this is that a decision to add caching should not be taken lightly. Adding a cache means adding a lot of additional (or so-called accidental) complexity and also has a functional impact on the users.

Adding a cache raises a lot of questions that need to be answered:

  • What if cached data is updated, should the cached record be updated or evicted too?
  • What should we do in a distributed environment, use a distributed cache? Is this distributed cache scalable?
  • Do we get the performance improvements we’re expecting?
  • What is an acceptable delay for users to see the updated data?
  • How many elements should we store in the cache?
  • What eviction policy do we need when not all data fits in the cache?

Why would you want to add a cache?

  • To improve response times
  • To reduce server load and/or increase maximum server throughput

Alternatives to caching

So you want to improve performance? Caching is not your only option here. There are a lot of alternatives to caching when it comes to performance improvements, across all layers of your system. Some examples:

  • add database indices
  • optimize queries
  • use a more efficient architecture for reads: skip ORM and doing fast lane reader data access or use CQRS
  • code improvements on areas of code that are executed most often
  • fix obvious inefficiency mistakes (using list instead of set / map for example)
  • fix ‘N+1 queries to the database’ problem
  • solve network bandwidth issues by compressing http responses

Knowledge is key here. Always measure where the most time is spent (processing time * number of invocations). That is where you can potentially make the largest improvements. And measure again after making a modification to make sure it makes a difference.

Disadvantages of adding a cache

  • adding a lot of complexity
  • dependency on additional frameworks, need for additional configuration
  • (heap) memory usage increase
  • users may see stale data

Ideal areas for caching

  • When data is frequently accessed, but not often updated
  • When it does not hurt if a user sees data that is (slightly) outdated
  • In case of aggregated data, for example a lot of rows in the database, but simple representation on the client side. If your application has layers, cache close to the client.

The conclusion is that you should be careful adding caching to your application. Caching is no silver bullet. Only in certain situations it is the right way to go. Are you having performance issues? Can’t they be easily fixed by some other approach? Is it acceptable to users that they see outdated information? Maybe you should give caching a try… In any other case, don’t say I didn’t warn you…

Spocklight: Grouping Assertions

In a Spock specification we write our assertion in the then: or expect: blocks. If we need to write multiple assertions for an object we can group those with the with method. We specify the object we want write assertions for as argument followed by a closure with the real assertions. We don’t need to use the assert keyword inside the closure, just as we don’t have to use the assert keyword in an expect: or then: block.

In the following example specification we have a very simple implementation for finding an User object. We want to check that the properties username and name have the correct value.

Continue reading