Application-wide rendering side effects caused by incorrect usage of WrappedResponseHolder

[davidkron]

I recently had to do some major debugging of a hard to reproduce issue. The issue occurred mainly when rendering grails templates in the controller and retrieving them by AJAX. Sometimes (it seemed pretty random) the response to exactly the same request didn't contain any Content-Type header, which resulted in messed up pages (mainly because of missing charset).

I finally managed to reproduce the issue and discovered that the source of the problem was caused by the mail plugin's HTML rendering.

Detailed description

• the class WrappedResponseHolder from grails is involved, which holds a reference to a response in a ThreadLocal
• Because of the ThreadLocal the occurrence of the issue depends on the current worker-thread handling the request
• mail plugin restores the current response object in the WrappedResponseHolder after rendering a HTML mail, instead of the value before doing the rendering
• in the grails class WebOutputContext the method setContentType() uses the the wrapped response if available
• subsequent requests in the same worker-thread will now always have the same response object available in the WrappedResponseHolder. A render(template: ...) call in a controller will now result in a response with no Content-Type set, because the method setContentType() will be called on the old (already expired) response object

Correct usage of WrappedResponseHolder

I searched the usage of WrappedResponseHolder inside of grails. The correct pattern to use this class seems to be like this:

1. retrieve current wrapped response
2. set a new wrapped response
3. do something
4. restore wrapped response to previous value

HttpServletResponse previousWrappedResponse = WrappedResponseHolder.getWrappedResponse();
try {
   WrappedResponseHolder.setWrappedResponse(wrappedResponse);
   ...
}
finally {
    WrappedResponseHolder.setWrappedResponse(previousWrappedResponse);
}

Wrong usage in mail plugin

The code is found in the class MailMessageContentRenderer.RenderEnvironment: WrappedResponseHolder.wrappedResponse = originalRequestAttributes?.currentResponse

This line of code sets the wrapped response after the rendering. But is uses the current response instead of the previously stored value before doing the rendering.

Example project

I made an example project to reproduce and demonstrate the issue: https://github.com/davidkron/mail-plugin-renderissue

Details of the project:

• newest versions of grails and mail-plugin
• I'm using Undertow, because the issue did not occur on Tomcat, because Tomcat seems to recycle existing response objects
• worker threads are set to exactly 1 to reproduce the issue on every request
• TestController contains the code to reproduce the issue

To see the issue, run the application, call the following URLs and see the DEBUG messages in the console:

• http://localhost:8080/test
• http://localhost:8080/test/mail
• http://localhost:8080/test
• http://localhost:8080/test/template

[demon101]

@jeffbrown , as I can see the issue can be closed. PR already part of 2.0.0 version

[davidkron]

I will close this issue. In our applications we could verify that the fix is working successfully.