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

For quite a while now I’ve been a subscriber to O’Reilly Safari bookself. It contains a lot of useful books on a wide range of technical and programming topics.

Although there is a good selection of material on the site, I haven’t really made the best use of it until now, since it has in general been less accessible than other web resources (it has just been easier to google for material than navigate to the O’Reilly site, log in, find the right page, search for books etc.). This devalued the whole Safari experience.

However, there is now a search bar plugin for safari (available from the tools page) which allows you to treat Safari as a search engine, and makes its contents available from the search box integrated with your browser toolbar. This innovation is the killer feature for Safari, in my opinion. Suddenly it makes the Safari content as accessible as the rest of the web. Suddenly, I don’t seem to have enough slots in my Safari bookshelf account any more, and the subscription fee seems quite reasonable.

There are some advantages in generating a jnlp file for a webstart application from a .jsp. If you do this, you can dynamically generate the jnlp content (e.g. URLs, system properties, startup parameters) based upon the applications current deployment settings or environment.

However, as usual there are gotchas. IE often fails to recognise the webstart app, even if you set the content-type properly to application/x-java-jnlp-file.

To get it to go, you have to also use the http header Content-Disposition

Inserting the following into the jsp seems to solve this problem for us, and improve the chance that the browser does not cache the jnlp contents:

We had a problem connecting to a tomcat service using HttpClient 3.1 on my current project. After a lot of hunting I tracked this down to the URI class in Apache HttpClient failing to parse the port number correctly. Several of our servers have been mis-configured with hostnames which have underscores. It seems the underscores cause the URI parsing to fail. (See bug report)

The effect is that although a connection is attempted to the correct host, the port information is lost and the connection defaults to use the http standard port 80. In some situations – e.g. there is a production server process on port 80 and a qa instance on another non-standard port (not that it would be an especially good idea to run both environments on the same server!), this could be dangerous!!

The interesting aspect of this is that in fact domain names with underscores are invalid. However a lot of software applications (e.g. browsers) will accept host names with underscores, in an attempt to be lenient. So really this is not a ‘bug’ as such, although the real issue is that the failure to parse the URI should result in an exception which details the failure. At present a connection may be silently made to the wrong port.

Sometimes this leniency in interpreting specifications leads to a lot of problems. If browsers did not accept underscores in domain names, our mis-configured servers would likely have been renamed a long time ago, and we would not now have this problem.

Have you added the magic </distributable> element to the top of your web application’s web.xml?

How nodes in the cluster are identified

Tomcats in the cluster identify themselves on a multicast address
So you should see an entry in each tomcat’s catalina.out, for every other tomcat which joins the cluster.

If this is working, it is likely that your multicast setup for the cluster is functioning OK, and the tomcats know about one another.
So the problem must be to do with replicating the session information within the cluster after each request, which takes place via TCP

How session data is replicated

Check your </distributable> tag in the web.xml again.
Unless this is there, the cluster will not even try to replicate the session information for the web app.

By the way, the default jsp-examples web app does not have the distributable tag set up by default – you have to add it if you want to use jsp-examples for testing

Each time the session information is updated, you should see an entry in the localhost.log for each tomcat in the cluster, indicating that the session attributes have been added

How to test it is working

Well you can use the cart example in the jsp-examples web app to check that the cart contents still remain after you kill tomcats in the cluster.

Here is a JSP you can also use, which shows the host you are connected to and the session id

The continuous build for my current project was failing occasionally due to problems undeploying a web application from Tomcat 5.5. Tomcat was holding locks on a jar file within WEB-INF/lib, preventing the web app from being undeployed or deleted

It seems there is a workaround for this, at least for test systems (I don’t think this technique is recommended for production use)
Within the context.xml in the tomcat conf dir, you can add antiJARLocking=”true” antiResourceLocking=”true”

This will cause tomcat to deploy webapps into a .\temp directory and in theory take no locks on the files.
It seems over time the contents of the temp dir can build up, so it may be necessary to do some pruning occasionally.

However, for continuous build servers this may at least solve the immeditate problem with undeploying apps.