Hidden message in Google Code Jam

I was practicing for this year's google code jam and I found something interesting. The problem I'm talking about is All your base. I'm not going into the details of solving it, but when I took a look at the input cases for the large dataset I found a message telling you clues about the solution of the problem. Here is the input for the large dataset:
At lines 25, 26 and 27 you can read "the left most digit is a one then you count up from there" and from 28 to 34 "do not forget that the results can get very big so be careful go read the large input for year of codejam in the final from last year". For me these are clear clues about solving the problem. Also I found a reference to Portal by stating "but remember the cake is a lie", nice touch.

Be careful with aspects (AOP) and synchronization

The problem
Recently I encountered a problem while working with Spring Aspects and a synchronized block of code. After some digging I came to a conclusion: Don't forget to consider the aspects that are applied to a method while working in a multi-threaded environment. Let me explain.

The project I'm working on uses transactional behavior provided by the spring framework. This behavior is applied by AspectJ using the @Transactional annotation at compile time. I have a method that needs to be synchronized, the problem is that there are two beans that inherits from a common base class that implements the synchronized method, so there are two instances that need to be synchronized. The way we solved the problem is by using a synchronized block with an shared lock object. The class structure is show here.

After some time I found that there were some inconsistent data. There problem was that for some reason the code inside the synchronized block appeared to be executed by two different threads at the same time (no way!!!). But as I supposed in the first place it wasn't the case. The real problem was that the method was not "fully" synchronized, I mean, not all the statements in the method were inside the synchronized block. The statements applied by the @Transactional aspect were out of the block, meaning that while one thread could be after the block (i.e. committing the transaction), another thread might already be inside the synchronized block.

Let me build and example (not exactly the same but it shows the problem). Suppose the class, the aspect and the main program.

We may expect the output to be like this (one invocation after the other)

Thread-0 Before perform
Thread-0 Begin method
Thread-0 End method
Thread-0 After perform
Thread-1 Before perform
Thread-1 Begin method
Thread-1 End method
Thread-1 After perform
...

But what really happens is something like this

Thread-0 Before perform
Thread-1 Before perform
Thread-0 Begin method
Thread-0 End method
Thread-1 Begin method
Thread-0 After perform
Thread-0 Before perform
Thread-1 End method
Thread-0 Begin method
Thread-0 End method
Thread-0 After perform

as you can see the execution of the method is synchronized (i.e. only one thread can be executing the block) while the statements in the aspect can be executed by multiple threads at the same time.

The solution

To solve this problem there are two options:

First, synchronize the code which invokes the perform method, as shown here. The problem with this approach is that you need to change every invocation of the method in the client code to include the synchronization block. If you forget to do this you will be in trouble.

Second, create a private method and decorate that one (with the aspect) instead of the public method as show here. As you can see this method allows to solve the problem without changing anything in the client.

A third option can be to refactor the code in a way the synchronization is not necessary, but for now let's keep it this way.

Grails rendering plugin does not find resources

The contextPath may be lost when using the grails rendering plugin, which causes several problems. For example: the rendered PDF file has not styles applied to it.

This problem is caused by the class grails.plugin.rendering.document.RenderEnvironment of the plugin that attaches a mocked version of the original request for rendering. When RenderEnvironment copies the attributes of the original request, it omits to copy the contextPath variable, which it is used by some tags like r:layoutResources to build the path of the referenced resource (e.g CSS or Images).

There are two options to fix the bug: create a new grails.plugin.rendering.document.RenderEnvironment class in the src/groovy folder which will override the plugin class. The second option it to modify the init method in RenderEnvironment through metaClass. I chose to implement it with the metaClass option, so I created a groovy class defined as follows:

class RenderEnvironmentFix {

  static void doFixWithMetaclass(){
    grails.plugin.rendering.document.RenderEnvironment.metaClass.init {
    originalRequestAttributes = RequestContextHolder.getRequestAttributes()
    def renderRequest = new MockHttpServletRequest(applicationContext.getServletContext())
    renderRequest.contextPath = originalRequestAttributes.contextPath
    renderRequestAttributes = GrailsWebUtil.bindMockWebRequest(
                               applicationContext, 
                               renderRequest, 
                               new MockHttpServletResponse())

    if (originalRequestAttributes) {
      renderRequestAttributes.controllerName = originalRequestAttributes.controllerName
    }
 

    def renderLocale

    if (locale) {
      renderLocale = locale
    } else if (originalRequestAttributes) {
      renderLocale = RequestContextUtils.getLocale(originalRequestAttributes.request)
    }

    renderRequestAttributes.request.setAttribute(

        DispatcherServlet.LOCALE_RESOLVER_ATTRIBUTE, 

        new FixedLocaleResolver(defaultLocale: renderLocale))

    renderRequestAttributes.setOut(out)

    WrappedResponseHolder.wrappedResponse = renderRequestAttributes.currentResponse
  }
}

It is a clone of the code in RenderEnvironment, but it also copies the contextPath to the mocked request.

To apply the patch invoke RenderEnvironmentFix.doFixWithMetaclass() from the Bootstrap.groovy file.

As a example consider an application named book and a BookController with actions:

def index() {
  render(template: "hello")
}

def pdf(){
  renderPdf(template: "hello")
}

and template _hello.gsp:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html>
<head>
<r:require module="style" />
<r:layoutResources />
</head>
<body>
  <h1 class="title">Title should be blue</h1>
</body>
</html>

where module "style" includes resource "/css/style.css" and it is defined:

h1.title{
  color: blue;
}

Without the patch the generated html for rendering the PDF looks like:

...
<link href="/static/css/style.css" type="text/css" rel="stylesheet" media="screen, projection, print" />
...

clearly the path for the style.css file is wrong which will cause the PDF file to be rendered without applying the styles.

After applying the patch the generated html for rendering looks like:
...
<link href="/book/static/css/style.css" type="text/css" rel="stylesheet" media="screen, projection, print" />
...

PS: Do not forget to define grails.serverURL because the rendering plugin uses it.

Using rendering plugin in Grails

I use the grails rendering plugin to create PDF versions of pages. It is a very useful plugin, unfortunately I've encountered an error with tags containing the id attribute, the problem is reported as:

org.w3c.dom.DOMException: NOT_FOUND_ERR: An attempt is made to reference a node in a context where it does not exist .

Why this happen? I don't know but thankfully I found this post about the same problem. As it is stated in the post one can resolve the problem by using the system property xr.load.configure-features=true, but it does not say where it can be placed within the code or if it is a configuration parameter of the application.

According to the documentation of flying saucer (the underlying implementation of rendering), specifically the class Configuration.java, one can define the configuration parameters via a properties file defined by the system property xr-conf or directly redefining the xr.* variable in the command line using the argument -Dxr.*=param.

But in grails that wouldn't be appropiated because the code base is shared and everyone with access to the code would need to define the variable.

Fortunately grails provides a simple way to add system properties programmatically at application startup. This can be done in the Bootstrap.groovy file, in this case the line to make the rendering plugin would be: System.setProperty("xr.load.configure-features", "true").

So to make simple, in order to use the rendering plugin with tags with id attributes use System.setProperty("xr.load.configure-features", "true") in Bootstrap.groovy.

Grails memory leak

I'm developing a Grails based application recently and I've came across several "problems" of the framework itself.

One of them was related to a process that needed to persist a lot of objects (300000). As it is explained here a memory leak could occur when a lot of objects are saved without cleaning the hibernate session and the DomainClassGrailsPlugin.PROPERTY_INSTANCE_MAP (which holds the validation results).

An additional advice about this is to make sure the process in charge of saving the data is run on a separate thread, different from the thread request. If it is executed using the request thread the DomainClassGrailsPlugin.PROPERTY_INSTANCE_MAP.get().clear() doesn't have any effect as the errors will be saved in the thread request instead, thus possibly causing an out of memory error.

Ivy settings to work behind an authenticated Proxy

You need to set ANT_OPTS to

-Dhttp.proxyHost=proxyserver -Dhttp.proxyPort=port -Dhttp.proxyUser=user -Dhttp.proxyPassword=password -Dhttps.proxyHost=proxyserver -Dhttps.proxyPort=port

or you can pass these arguments to the JVM.

Enable Grails recompile feature

When developing in Grails under a custom environment using

-Dgrails.env=custom_environment

the recompilation feature is disabled. In order to enable it again for a certain environment the flag

-Ddisable.auto.recompile=false

needs to be specified.

If you want to also support GSP reloading, specify the flag

-Dgrails.gsp.enable.reload=true