Object Definitions Blog

For the last year and a half I have been hard at work at a new open source project jtimeseries.

This has finally made it onto sourceforge!

So what can you do with this jtimeseries thing?

Quite a lot, already. Let me explain how this project was conceived….

Initially, I was looking for a java based API which I could use to capture metrics for a Swing application I was working on. Rather than store the raw values I was collecting, I needed a way to capture, for example, the mean value of a certain measurement over a time period (e.g. the mean price latency over the last five minutes, or the 90th percentile heap memory). As well as capturing and storing the stats, I also needed ui visualizer components to enable viewing of the data, and wanted to also show the stats collected via an embedded web server in the application.

how about storing the data?

A logical extension once the core API was up and running was to provide a lightweight database component to persist the timeseries data on the server side, in a round robin file format (noting here that there is no java api for rddtool presently, which gave me ample license to write one myself I think!). The server can store stats from multiple sources – and you can subscribe to view the series from the ui.

collecting stats from jmx

The other really neat feature of the database, is that it can be configured to read in metrics data directly via the jmx management service of a running java app. This means that you can capture details, such as the memory and cpu load of your other java components without having to change their code and re-release them! You just need to have the jvm jmx management feature enabled, so that you can point a jconsole at the app and see values.

New release

So that’s how it all came about. We now have a stable release, 1.0.10, which you can find here

At present I am consulting for a company which now has two instances of the timeseries server, currently maintaining nearly 50,000 time series, which provide stats on the performance of dozens of our production and UAT components going back over a few months. The benefits of this are massive. It’s easy to spot performance problems before they become a major issue. Most importantly, before a release takes place, it’s easy to see from the stats whether a new component version has worse performance than its predecessor – without even having to fire up the profiler.

I’ll be adding more documentation on jtimeseries over the next couple of weeks

We were developing some stylesheets to convert xml to html in Stylus Studio and had the problem that IE would render them fine, but when we used Firefox/Opera we only saw plain text.

If you are also experiencing this problem you are probably missing the xsl:output element:

When the XSL processor sees this instruction it will generate a meta data element similar to the following in the resulting html header, which sets the content type to text/html. This lets the browser know to treat the resulting text as html:

The problem is – some XSL processors (e.g. Saxon ) appear to generate this meta data item even if the xsl:output is absent – by detecting the html tags in the document. It appears that the processor built into IE has this feature, so IE correctly interprets the html, even without the xsl:output. Firefox, however, does not.

Recently I was faced with a directory full of XML files containing test data. The tests were all failing due to a couple of unwanted elements within each test file.

The question – how to write an xsl stylesheet to remove the offending elements.
After some head scratching the following script seemed to do the trick

This recreates the original xml file exactly, minus any elements called badElement
How does it work?

Well the first part is called an identity transform. This template matches every input node in the source document, (elements attributes and content_, and copies it to the output tree.

The second template matches only on elements called badElement. Clearly, the badElement in the source document will match both the identity transform template and the badElement template. . The XSL specification defines behaviour when a source node matches multiple templates. Essentially, each template has an associated priority. In general, a more specific match gets a higher priority by default, which is why in this case the badElement node is processe by the badElement template rule. This rule does nothing – it has not output and does not contain an apply-templates, effectively supressing its child nodes too. Which is why the badElement and its child nodes are effectively filtered out from the target document.

If in doubt over which template will take priority, it is actually possible to specify a priority value explicitly as an attribute to the template declaration in the xsl stylesheet.