Three years with Java Simon (4)

Today I’d like to cover the rest of my Java Simon story. In the previous posts we talked hardly about the start, but the rest was actually quite quick. With Callbacks, JMX support, JDBC proxy driver and much better design we were ready to release our 2.0 version.

June 23, 2009, Java Simon 2.0, monitoring API, released

There was one major problem with this version – we needed 2 different JDKs to build it. JDBC 3 would not compile against JDK 1.6 because Java 6 required higher version of it – which we didn’t want, so we could use it on application servers without support of newer JDBC. JMX 1.2 shipped with Java 5 – on the other hand – didn’t support features we needed, mostly around MX Beans, returning more types of objects and so on. So JMX was compiled with Java 6. You can imagine the problems we had when we started using Maven as a build (though Maven still is not exclusive build tool for us).

Well… Maven. While I like the idea of it – especially dependency management is truly great – as a build tool it is incredibly in the way unless you read tons of the stuff. Originally I hosted Java Simon on repository, but then Oracle somehow made it more complicated (and malfunction altogether for a while if I recall correctly) and I decided to switch to Maven Central. That was right decision of course, but the pain behind it was just crazy. Unless you have the process mastered it takes a lot of pain to deploy your first software there. However – our clients wanted Maven repo – and I did my best to provide. I learned a lot in the process, but no one will convince me that Maven can’t be MUCH simpler. And deployment on Maven Central is just horribly bureaucratic compared to FTP upload. Guys at Sonatype do their best in support though, they probably have to answer tons of stupid questions (at least for them). After all I complained more about it previously, so let’s just skip the rest with saying that 2.5.0 version was the first on Maven Central – and someone else had to deploy it for me. 3.0.0 was delayed a lot – Maven being 95% of the reason. Now I can release (at least from that computer where release plugin doesn’t throw infamous out of bounds exception without providing reason…) and it is a tremendous relief.

Talking about 3.0.0 – release announcement was here:

Java Simon alive and kicking with 3.0.0 available

As you can read in it the biggest theme was aligning of the Java dependency – now we can build it with JDK 6 only. Aside from that it was rather just a wrap-up of all the changes in 2.x line with some bug fixes reported for 2.5. Talking about bugs and issues – this was maybe the reason why I kept working on Java Simon and eventually made all the changes that slowly but surely shape the library. And this would not be possible without users – and especially active users. Reports were coming more in bursts, often from one reporter for some time. One thing I can say with my head straight up – I was always very prompt to answer and fix where appropriate (mostly they were indeed bugs).

To talk to our users we created Java Simon Google Group shortly after version 1, but this was mostly an announcement tool. Here and there someone new asked the question though – and again, I answered as soon as possible. Luckily, Java Simon is low-profile library, so the traffic was rather negligible. To sum it up – users who had problems were my motor in the end. The main problem probably was that later we had no project to use with Java Simon. There seems to be some chance now at my current job, so I expect more enhancements.

Here and there I still change some method names (some changed in 3.1, next changes will appear in 3.2) – not that I like doing that but I rather name it properly later than never (oh, how I hate broken promises of original Java’s @deprecated!), but otherwise the core seems to be pretty stable for now. But there is still some room for improvements – especially new features:

  1. delivering more useful tools like JDBC proxy driver – that one I particularly like for its simplicity, just add “simon:” in the JDBC URL and have it on the classpath – right now monitoring part comes to my mind, charts, logging, dumps to some history DB, etc.;
  2. providing some neat Callbacks (many things from the point 1 are actually implemented thanks to these);
  3. web console where you can easily read your Simons.

Actually – there should be web console available in our next release (3.2.0) – we acquired new committer from among our users. That’s the true open source community story. 🙂 You can’t even imagine how happy I was about it.

Of course – my life is not only about Java Simon. I have a family, regular job where they’d hardly pay me for Java Simon alone, I like doing music (soon more about it too) and then I just don’t care about Simon for a few weeks, sometimes even months. Though right now I’m just taking a short break before we wrap up that 3.2.0 version – and you’ll hear about it.


Three years with Java Simon (3)

I should finish this series before it should be called “Four years with Java Simon” – but we still have some time. I’ll show you what possibilities callbacks brought to the Simon, but first I’d like to deal with our Webnode site.

It was three years back (January 13th, 2009) when I posted on our Webnode site that we need some better web for presentation than our project site on Google Code. But then we found we can’t post bunch of HTML files (Javadoc) on Webnode – and with mime-types SVN props we can do that on Google Code… oh, how quickly things change.

Webnode site could be good if Java Simon gained some bigger momentum on our side – more committers and contributors, people writing blogs or tutorials or success stories (or not so success stories too if they can help :-)). But this did not happen and I felt as rather annoying obligation to update this site. Especially because the edit functionality is on a separate URL – editing a Wikipedia page or a blog post on WordPress is always just one click away – but not so on Webnode.

Three years later I decided to redirect on our Google+ page because it is so much easy to update, posting even very short posts is not inappropriate (which would be on a blog) and it’s just so much closer to my way of living on the Internet right now. I’ll go through and it will soon be a matter of past.

Last time I discussed some changes from version 1 to version 2. And to preserve the little from Webnode site that has any “historical” value I hereby copy one blog post covering just these differences:

Major changes in the core of the Java Simon v2
2009-01-28 14:30
While there are some important extensions to the Java Simon (JMX, Spring integration, etc.) there are a few important changes in the core part of the API that are probably even more important. If you’ve already managed to use Java Simon 1 I strongly suggest that you use version 2 even in its alpha stages. The thing is:

  • If your project is finished or close to finish (month or two) stay with version 1.
  • If your project continues and you’re just experimenting with Simon, definitely use version 2! There is v2-alpha1 which is basically rework of the v1 after a few changes in Stopwatch. If there is newer alpha out (check Featured Downloads on the right on our project page) take that one of course, because it contains more features from v2.
  • Version 2 is planned to be out during March or April 2009, which is really soon.

Now what are the changes and why we made them?

  • Important change happened in the Stopwatch. While in the v1 it contained various start/stop methods that took care of multi-threaded environment now it has only one start method and this start doesn’t return this anymore but it returns new Split object instead. You have to take care of the Split object, you have to take care of your multi-threading, you have to call stop method on the Split. This makes our code safer as the Stopwatch doesn’t contain internal maps that were prone to memore-leaks if client forgot to stop some split. Thanks to Erik van Oosten and his great Java Simon evaluation.
  • Based on the same post we changed sample methods so that they return Java Bean objects now instead of the field.
  • While in v1 you had to use SimonManager now you can use non-static Manager implementation directly. SimonManager still stays your favourite convenient class full of static methods, of course. 😉 This allows to have multiple separeated Simon hierarchies which may be handy in Java EE environment.
  • To provide some extensibility for the API we introduced Callback interface. This allows to hook onto various events and process these events in any way you want – to log them, send JMX notifications, whatever.

There are more features to come with version 2 and I covered only those in the core part of the API. Stay tuned, download, use, test, let us know what you think. 🙂

Now let’s take a look at those Callbacks. Based on good-old Observer pattern, Callback is a listener that performs some actions on various events. First question was where the Callback should be registered – and we decided that Manager will hold its Callbacks. We didn’t want to scatter Callbacks across various Simons because typical usage would lead to a situation where many Simons call (and point to) the same Callback. We rather decided we will centralize Callback management on a Manager (that is per Manager of course) and bring some way how to filter events based on Simon name for instance.

Simple example of Simon is in our CallbackExample:

    SimonManager.callback().addCallback(new CallbackSkeleton() {
           public void onStopwatchStart(Split split) {
               System.out.println("\nStopwatch " + split.getStopwatch().getName() + " has just been started.");

           public void onStopwatchStop(Split split) {
               System.out.println("Stopwatch " + split.getStopwatch().getName()
                   + " has just been stopped (" + SimonUtils.presentNanoTime(split.runningFor()) + ").");

       Stopwatch sw = SimonManager.getStopwatch(SimonUtils.generateName());

When you work with Simon (last two lines) you don’t care about Callbacks – they will be called. Their configuration can be based on some configuration and they should do whatever you want to hook on various Simon events.

BTW: If you use Java Simon 3.1 method onStopwatchStop is still called stopwatchStop. This is quite serious flaw and poor choice of method name on my part (and I’m terribly sorry for that). While this method doesn’t show it clearly, there was another method – clear (now onManagerClear). This method is called – as you may guess from the new name – when clear method on the manager is called. Let me explain composite callbacks first to show you the whole problem…

To add more callbacks to the manager is all right but if you want to filter Simons (by name, for instance) that fire an event on a Callback you actually need to do it in the event itself. Or wrap the Callback into another one – that is exactly what FilterCallback idea is all about. Another thing is that you may need to call various callbacks for the same filter – to group them – and that is what composite callback does – holds more callbacks (children) and relays the event to all of them. There is no interface CompositeCallback – instead all these methods are on Callback already, but they are not implemented in the CallbackSkeleton for instance (used in the example above). There is one implementation called CompositeFilterCallback – and you probably can guess what it does. It can hold more callbacks and call them when the common configured filter is passed. See CallbackFilteringExample for simple use case.

Now guess how people tried to remove callbacks from composite callback. It’s just a collection of callbacks after all, right? Ah, method “clear” must do exactly what I need here. But it didn’t. And if you didn’t implement this event method (which is not very common, but JmxRegisterCallback is nice example where it is very handy) it simply did nothing. There was method to remove one callback, but not all of them (this one was in SimonUtils). This is all finally fixed with version 3.2 – all names are much better and removeAllCallbacks is in the Callback interface.

JMX is nice example why we needed callbacks just as much as we wanted to offer them to our users. There are two ways how to access Simons via JMX – you can use single point MX bean, or let Simon instantiate MX beans per Simon. The latter however requires some actions when Simon is created, destroyed or the whole manager is cleared. I mentioned JmxRegisterCallback already – check how it’s done there. Now the Simon manager knows about Callback mechanism – but it doesn’t have to know about JMX – or anything else you want to drive by these events.

Split introduction and Callbacks are two very important changes that happened in version 2 – and these things are now well proven and will probably last (though some names can change as will happen in version 3.2 :-)). Next time I’ll try to wrap up the rest of the story.

Three years with Java Simon (1)

If you wonder what that Java Simon is just check the project site (previously on Google Code). It all started when we got back from TheServerSide Java Symposium in Prague in 2008. One of the many talks given there was about JAMon (don’t mix it with jamon – the text template engine) – simple monitoring API that allowed you to code your monitors into your application and obtain the results later.

JAMon guys used Jarep to store and graph results and what I liked the most was the story how these results available over a long time helped them when they needed it. Story went something like: “We found out that the performance of our web-shop started to be unacceptable sooner then originally calculated. Graph showed us that there was sudden jump half a year ago and since then the application performed worse. Luckily we had also work plan from IT stuff that revealed that the same day new JDBC driver was installed – and that was the reason.” Bottom line – without data you just don’t know. I liked that and it went pretty much along the lines Kirk Pepperdine says all the time – you need proof, you need data, you just need to know – don’t guess. Actually most wise people say that, but I remember Kirk and also that JAMon/JARep story when it comes to performance and monitoring.

A colleague of mine tried to use JAMon for our work project but he was not happy about the API. He was missing some management hierarchy – and that’s how idea of a tree hierarchy (not much different from java.util.logging for instance) for Simons started. Another issue was timer based on ms (JAMon is compatible with J2SE 1.4), I didn’t like that at all. So many things may happen in a single ms – not to mention most Windows changed the timer ever 10 or 16 ms. We decided to write our stopwatch facility and over one August weekend I wrote some basics (our first commits) and we started building on it. We can’t measure anything – like JAMon tries – we focused solely on Stopwatch and Counter. Three years later I’m happy about it – Stopwatch being probably 90% (or more) of all used Simons. Originally I wanted to give our users some way to add another kinds of Simons, but soon I realized how messy it would all become.

JAMon was in version 2.7 when we started the Simon project and the page looked exactly how it looks right now. We finished the first version in December, we were happy about most of it, we cared for the code and for the Javadoc too – and I think it was really obvious from the look at the project. These are ideas we still care for and quality Javadoc is undisputed part of the project.

TSS press release: Java Simon 1.0, monitoring API, released

Simon gained some initial attention and one particular developer even blogged a few times about us – check Evaluating Simon – Java monitoring or other Erik’s posts related to monitoring. Funny – later I’ve heard the name Erik van Oosten mentioned by my colleagues working with Wicket, but I’m 2 years ahead of the story. That’s just how it is with active people. His posts were most appreciated and he also provided AOP based Spring integration. Now – years later – even I use it in our current project (though it went through a few fixes, but the code is essentially still Erik’s).

Soon we discovered that the first version had a few serious issues and redesign was necessary. But more about that in the next installment some other time.