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 javasimon.org 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 javasimon.webnode.com 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());
       sw.start().stop();

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.

Open letter to Java Simon users

I bet there are people who are not on our mail group or watching Java Simon page on Google+. Roughly three years after the first official release we have another really good release.

I’m really proud about our newest Java Simon release (3.1.0) and I decided to share the mail written to javasimon@googlegroups.com also here on my blog:

Dear Java Simon users

Firstly – version 3.1.0 was released on New Year’s Day – more about it
on our project site:
http://code.google.com/p/javasimon/

We announced it also on our new stream on Google+ (it should be
available for non-google users too):
https://plus.google.com/b/115141838919870730025/115141838919870730025/posts/ZpmYGp9F2yp

Secondly – about Google+ – we decided to pull down our Webnode site
because it was a bit cumbersome to maintain and add new posts there.
Instead we are moving to the aforementioned Google+ page.

Direct link: https://plus.google.com/115141838919870730025/posts
Short link: http://gplus.to/javasimon
Or just use our domain! http://javasimon.org/ or http://www.javasimon.org/

This way it should be easier for us to post more often even smaller
facts about your favourite monitoring library. 🙂

Thirdly – Happy New Year to you all, update and share your thoughts, I
feel very well about the last release. We’re working on 3.2 already,
with our new commiter (Gerald) we should be able to deliver simple
embeddable web console too, so there is a lot to be looking forward
to.

Best regards and wishes

Richard “Virgo” Richter

You are welcome – and encouraged – to add Google+ page into your circles of course. And once more – Happy New Year – as this is my first post here in 2012. 🙂

Three years with Java Simon (2)

This is continuation of the previous post where we somehow got to version 1.0 – that was December 2008.

Working on our first version of Java Simon I learned a lot from my colleagues too. While we shared our views all the time on the OSS library we somehow did even better than on our common (resource limited) projects. We also knew that library must be even cleaner and better than some Information System developed once – often without proper support budget. One guy insisted on finals whenever possible (which I’m not fan of) and he also vigorously refactored methods with boolean flags – and I originally disliked this change. In Simon interface we had methods like:

Map<String, String> sample(boolean reset);

Now we have much cleaner two methods instead of using boolean parameter – not to mention that we have Sample object instead of Map used in early versions:

Sample sample();
Sample sampleAndReset();

Not that we don’t have any method with boolean flag – but the most prominent one is rather management one compared to sample methods:

void setState(SimonState state, boolean overrule);

Generally I don’t like using boolean flag parameters because they are hard to read when you see just plain code. If they are replaced with enums (where suitable) readability goes up instantly. If they are split to two methods – especially when one of them is rather default (like the sample without reset) – even better.

Working on an OSS library (or any other library – even a private one) you have to think way harder (or rethink more often) how to organize your interface, packages and all. I personally hate backward compatibility as an ultimate decision and we knew that we will change the interface here and there. If you want to upgrade then just go through your code and change those few things you have to change! Or don’t upgrade. (I’ll not go on about the whole myth of compatiblity and how often it is not completely true.)

That’s why we decided to release version 1.0 quite soon (December 2008, we started the project in August 2008) and find out what is missing. Version 2.0 followed quite quickly – in January 2009 we had the first alpha (quite stable though) and we decided to focus solely on this without any support for 1.0. The reason was that the Stopwatch behaviour changed quite a lot – for the better.

In 1.0 HalloWorld looked something like this:

SimonStopwatch stopwatch = SimonFactory.getStopwatch("org.javasimon.HelloWorld-stopwatch");
stopwatch.start();
System.out.println("Hello world, " + stopwatch);
stopwatch.stop();
System.out.println("Result: " + stopwatch);

Most important feature was that both start and stop were called on the Stopwatch. Now you may wonder what would happen if you started stopwatch twice and stopped it twice as well. It depended… though – honestly – I don’t remember exactly. Stopwatch had thread-local variable that remembered start timestamp (nanoseconds of course) and stop was expected to be called in the same thread. Double start and stop was illegal operation. Now this implied two serious limitations. The first was potential memory leak on the thread-local variable if you (client programmer) failed (or forgot) to stop the stopwatch. The second was that you couldn’t stop the stopwatch in a different thread.

This was troublesome design and happened to be resolved soon after 1.0 release. Our new HelloWorld looked (and still looks) like this:

Stopwatch stopwatch = SimonManager.getStopwatch("org.javasimon.examples.HelloWorld-stopwatch");
Split split = stopwatch.start();
System.out.println("Hello world, " + stopwatch);
split.stop();
System.out.println("Result: " + stopwatch);

Now the client programmer is fully responsible for working with the Split, there is no thread-local and the worst thing that may happen to the stopwatch is that its “actual” count will go up and up (and so indicate some problem with missing stops). Split will be garbage collected – unless stored by the programmer (his fault anyway ;-)).

Another important features coming with 2.0 were JMX support (MX Bean) and Callbacks – these allowed programmer to hook on various events. But more about these in my next post, right?

Personal Log

I’m not sure if I should add “(1)” into the title or not but let’s deal with the content first – before I decide to write another personal log. I just feel like to write something from my everyday life. Yet not so everyday, because today it finally happened – Roger Federer matched Pete Sampras with his Grand Slam titles + he completed career Grand Slam. In open era only Rod Laver and Andre Agassi did that before – and only Andre (and Roger now) on three different surfaces (on the other hand – Rod did it in one year and so he is the only man with the true Grand Slam in open era).

Funny – I became Roger’s fan when his star seemed to diminish. I didn’t care about tennis that much – mostly because of the lack of TV in my household. In 2005 I somehow accidentally saw him winning the US Open against Agassi (who also handed him Roland Garros trophy today!). Later I started to watch him in 2007 which was his last domination year. In 2008 he left the first place to Nadal who waited for this for a long time (just another statistical record) and barely managed to stay #2 – mostly because the mononucleosis in the start of the year. At least he won US Open (again ;-)). However 2009 doesn’t look so bad at all! Nadal showed hell of a fight in Australian Open and he is now clearly all-around player (after winning Wimbledon 2008 and hard court AO 2009 who can doubt it?). Roland Garros seemed to be ill-fated for Federer, but he managed to win it – while the biggest favourite lost to Robin Söderling who managed to pull it through to the final. And lose against Roger Federer. Who knows how it would end against Nadal. Nadal lost last clay final to Federer though – but it was only best of three and French Open – that’s just completely different motivation. Whatever the Roger’s way to this success was – he is there – between those few who won each of Grand Slam titles. Congratulations.


As a funny addition – here is a vid with some Barca fan entering the court during today’s match 🙂

But tennis is not the only thing I live with. To make the post rather shorter I’ll touch other things sort of telegraphically. 🙂 I mentioned REAPER digital audio workstation (DAW) in my previous posts (and also in my YouTube videos I wanted to wrap-up here). Big thing is that REAPER v3 was released. Actually it’s 3.02 currently – which is a good thing because Cockos (developer of the software) started to fix things quickly. If you’re in music business (especially home recording/computer based recording with strong emphasis on audio+MIDI), you should try Reaper because it’s slick, small, fast yet powerful DAW. I also found incredible VST instrument… more than that actually. Free Kore Player by Native Instruments along with their free Kore Soundpack Compilation Vol.1 is something you simply have to have (yes, I know the registration and activation process is annoying, but it’s worth it). I found some great sounds there, one patch with rock drums (through 6 octaves, 3 full sets!) and another Latino drums – and much more!… man, this is incredible deal for 0 money and I’m happy that NI supports also music fans who can’t afford expensive solutions – or maybe just wanna taste how it is to do some music and not make living of it.

Other than that? Well, business as usual, socialists took the most EU parliament chairs in for our country. I’ll just pay my taxes on, with thieves like our Slovak non-liberal, private-equity-backed socialists I’m pretty sure my money won’t get to poor people anyway (not in the same extent like it did with rightists, which is funny paradox). And maybe people will see one day. I don’t care anymore – although elections are my sacred obligation. World-wide crisis is far from over, well – I rather care about present and little things around. My wife, my son… or my tortoise 🙂 (see it how it can flip from its back!). Or Roger’s triumph on Roland Garros for that matter.

Well and now I should finally do something about JavaSimon or its second version will never reach final. So see you later. 🙂

Java Simon 1.0, monitoring API, released

It is some time ago when we wanted to use JaMON API to add some monitoring capabilities to our applications. After a few we found it to lack some featrues – especially it was difficult to organize monitors. Hence we decided to create our own alternative that brings two features JaMON can’t provide – monitors organized in a tree hierarchy (similar to JDK14 logging API) and nanosecond precision (which bind us to JDK 1.5 or higher – which we see as no problem for most newly developed applications).

That’s how Java Simon API was born – the project is hosted on Google Code: http://code.google.com/p/javasimon/

Short description from our page:

Java Simon is a simple monitoring API that allows you to follow and better understand your application. Monitors (familiarly called Simons) are placed directly into your code and you can choose whether you want to count something or measure time/duration. Access to Simons is provided via static SimonManager.

We hope all necessary documentation is there and it will be extended in the future for sure. Aside from core functionality featuring standard stopwatch/counter monitor types we provide Simon JDBC proxy driver featuring these monitors – so you can check how various JDBC calls perform, pin down slowest selects, etc. Driver is JDBC 3 compliant with data source implementations available and it was tested with Glassfish/XA datasource with Oracle as the underlying database.

What can typical Stopwatch do?

  •  it can measure time splits, parallel measurement is supported;
  • it provides total time, number of time splits, tracks max/min time, time stamp when extremes were measured, deviation, …;
  • and like every Simon it tracks first/last usage time stamp and features like enable/disable/reset are also available.

Why we brought in a new API when there is JaMON available? Well, we tried it with JaMON but than we wanted to crucial things that JaMON doesn’t provide:

  • as said – we wanted to measure time in nanoseconds (hence JDK 1.5 or higher is required);
  • we wanted all monitors to be organized somehow – so we implemented tree hierarchy similar to java.util.logging API – this provides powerful features like enable/disable/reset of the whole subtrees of this monitor hierarchy.

Version 1.0 contains core functionality and we realize it lacks many important features in the bigger picture of application monitoring. Our plans in the future covers:

  • Declarative Simon configuration.
  • JMX access to Simons, their values and enable/disable features.
  • Sampling, collecting, agregating with persistence backend (file/DB).
  • …and probably more, but not all in the next major release. 😉