Building Blocks

Im doing something not supported. I’m serving html files through my Grails web-app running Jetty. Simply I have some static pages that will not change. I want them served uncompiled. I use the resources-first plugin to help out with serving these html files.

The files are documentation, responses if you wish, for the user. I load them using Ajax to provide standard responses for some actions. The problem is that the responses are in Swedish. Jetty only serves them in ISO-8859-1, which is its standard configuration. According to this.

The issue I have is that I can’t change it. I can’t set a system variable to change the default encoding to UTF-8, not without having to do some programming. As  a result, the easiest way for me to handle this issue is to change my HTML files to GSP files. This forces me to serve them through the Grails stack and thus demands somewhat more resources from my poor server.

I tried to see if I could configure the Jetty-server to use UTF-8 as a default encoding, but alas according to this documentation I can only change it for the URI and not the content, and the URI is already set to UTF-8.

If anyone finds out how to serve HTML through the same server as Grails but with the correct encoding let me know. Right now I have a work around that will work for the next 6 months.

Update: Apparently, hosting just HTML files with utf-8 encoding set on the file, works in the production environment. Thank you Mor.ph.

I had an idea today while working with a performance issue on the REST-service of RemoteX Applications.

In theory having a performance counter with the average execution time of SQL-queries over time. Will allow monitoring of system wide average cost for queries in the system.

That means that overtime its possible to track the changes of the execution times as they grow or shrink during normal production environment conditions. The cost for calculating the average could be relatively cheap to calculate compared to the round trip to the servers, and also the calculation could be threaded of to a different thread, so as not to disturb the worker thread that handles the request to the web server to begin with.

The idea is to examine the changes of the average query time over time, to see if performance of data access is changed between version upgrades, or hardware upgrades for that matter. There are some performance counters built into MSSql that can give data that is somewhat like this. However most of the require heavy load to see any performance upgrade or downgrade. This instead logs an average of the actual execution time for the application.

A benefit with this is that the performance is individual per application, but the actual code or counter could be reused between different applications.