Its been a long time coming, but Chronon 3 is finally here! 

In the next few posts, we will dive deep into what took us so long and all the technical magic that makes Chronon 3 tick. For now lets see what Chronon 3 brings us:

Features

• Enormous performance upgrade
  

The number one issues of Chronon users has been running into OutOfMemoryErrors and all of Chronon 3 is dedicated to eradicating that. The all new, rewritten from scratch Recorder is built to conserve memory. It uses off heap memory as much as possible and even then limits the amount of total data collected by the Recorder to be many times lower than that of previous versions. This graph gives you an idea of the improvement.

• 5x faster unpacking

The Unpacker is much faster too! Apart from consuming much, much less resources, it also runs 5x faster!

• Per Thread Time

With Chronon 3, we are introducing Per Thread Time, which gives each thread its own timeline, facilitating in must easier and faster debugging. Now the timeline view shows you the time and progess of the current thread instead of the whole system, giving you much more focused data. This is carried on in other views too, like the Stack view shows the current thread only instead of cluttering the view with all the threads in the system. The result of this is much more focused data and it also allows us to make the recorder more concurrent and faster.

• On Demand Split

In case you missed it, a few months back we also introduced On Demand Split in the Recording Server, allowing you to split recordings anytime, without having to wait for a split interval.

• Support for JBoss

Previously, Jboss 7 was having issues with Chronon due to OSGI classloader issues. With Chronon 3, this should be solved and you should be able to fully record your JBoss apps.

Future Updates

Now that we are done with this huge release, we will be doing much, much faster releases to keep bringing you new features. Due to time constraints for this release, we have decided not to include the 'Recorded Console' view. We think with Post Execution Logging you can achieve the same goal without cluttering your code with println() statements. However, if there is demand for it, we will bring the view back in the next update.

Renewed Trial

If you don't own a Chronon subscription and your trial has expired, dont worry! You'll get a fully renewed trial now when you download Chronon 3. Same goes for students. If your student license has expired, request your student license again and you will get a renewed one too.

Download Now

Stop waiting and go ahead and give the Chronon 3 Debugger and Recording Server  a try now!

While we get Chronon 3 ready, we thought of making an interim release with some goodies our users have been asking for:

Chronon Recording Server

Recording Server is the highlight of this release, and contains the most voted feature from our users:

On Demand Split

Now when you encounter a bug while testing/QA, no longer do you have to wait for an 'automatic split interval' or do a 'Stop Recording' which results in a lengthy 'deinstrumentation' phase and then 'Start Recording' again (which will result in another lengthy 'instrumentation' phase).

Just click the new 'Split Recording' button and a recording is created instantly on disk and the recorder keeps running!

Here is a demo video demonstrating this feature:

Make sure you get the latest version of Recording Server now!

Chronon Time Travelling Debugger

Some enhancements based on user feedback:

Timeline View

• An Id column has been added to allow easily referring to each time bookmark by an id, instead of a complex, lengthy 'time' value.
• All columns are now sortable.

Exceptions View

• An Id column has been added here too. 

Dont forget to update your debugger!

Embedded Chronon and Chronon Recorder

Plenty of bugfixes and minor performance enhancements in the Chronon Recorder for users of Embedded Chronon and Chronon Recording Server.

If you were getting a corrupt recording when using either Embedded Chronon or Chronon Recording Server, these bugfixes should now prevent that.

Also for the first time we have updated the native agents too, from version 1.0 to 1.1.0.

Do you press the 'Stop Recording' button each time your app runs into a bug and you want to examine the recording? Or do you press it once your test suites have finished running?

Turns out, that is not the way we designed the Recording Server in mind!

Recording Server Workflow

Here is a document describing the workflow of using the Chronon Recording Server:

http://chronon.onconfluence.com/display/DOC/Recording+Server+Workflow

Bugfix release for the Recording Server UI. 
This is a bit of a late announcement since the binaries have been available since middle of last week. 

If you are using v 2.x of Recording Server, then you can just update the .war file to get the new fixes.

You should no longer see screens like this anymore with v 2.3

Chronon 3 is all about performance.

We have rewritten our Recorder from the ground up to gain an order of magnitude performance improvement! The basic architecture remains the same, but under the hood its an all new engine. We turned a Yugo into a Ferrari!

No more memory issues

The biggest complaint of all users of Chronon 1 and 2 has been high memory usage and OutOfMemory errors. With Chronon 3 our main goal was to get rid of this. And I am proud to say we have blown it out of the ballpark with this one!

Chronon 3 makes absolute minimal use of your Java heap. We have shifted most of our code to native. And this time we made sure that literally every single bit of memory usage is accounted for! This means that you no longer have to fiddle with -Xmx values.

Here is a graph showing memory usage for recording entire Eclipse (namespace org.eclipse.**) with Chronon 2 and Chronon 3 (size in megabytes):

Smaller Recording file size

The Recording file size of Chronon 3 should on avg be 90-95% smaller than that of Chronon 2.

Here is a comparison of recording file size for the startup of eclipse, recording the entire org.eclipse.** namespace (size in megabytes). Note that eclipse has a lengthy, cpu intensive startup so its a good stress test. 

Increased Concurrency

Chronon 3 pulls out all the stops to make sure your applications retain all of their concurrency. Highly concurrent applications will instantly see a very noticeable huge performance boost.

Logless Data Center

With the high performance of Chronon 3, you can have the Chronon recorder running all the time. This means you can have for the first time a Logless Data Center!

Consider this, with Chronon on all the time, you no longer need log files or log statements cluttering up your code. If something breaks, just pull out the Chronon recording and put in Post Execution Logging statements wherever you want.

Getting your hands on the beta

To get the beta, please fill out the form here.

We are opening the beta so you test the performance of Chronon 3 on your applications.

Since this is still beta, the recordings made from the Chronon 3 recorder will not open in the Chronon Debugger for now. You will need to use the Chronon Recording Server to record your applications. The only change would be that you would replace the recorder.jar in your Recording Server installation from v2 to v3.

If your existing Recording Server evaluation has expired, dont worry, we will give you a new one.

We would request providing some contact info so we can be in touch with you throughout the beta.

Please provide either a phone number or a skype id , or anything else (put it in the comments section). If providing a phone number, dont forget putting the country code.

Any spam/incorrect entries will be discarded.

We have just updated the Chronon Recording Server to version 2.1.0.296 with an emergency bugfix update.

The update can be downloaded from the download page on our website:
https://chrononsystems.com/download/

Bug Details

The bug occurs when a recording is 'split' at preset time intervals (eg 1 hour), by the Recording Server and results in a corrupt recording.

The bug is inside the Chronon Recorder and during a 'split' can produce an invalid recording, which will throw an exception during the unpack phase. If you try to unpack the recording inside eclipse, the Chronon eclipse plug-in will show an error saying the recording is corrupt. The exception/error will show itself near the end of the unpack phase ( ie, after atleast 90% of the way through).

Fix

To fix the bug, download the latest recording server zip file and just replace the recorder.jar files in your recording server installation with the updated version in the new recording server zip.

The current recorder .jar version with the bugfix is 2.1.0.296. If you are using that version or higher, then you are fine, otherwise you need to update.

ACKNOWLEDGMENT 

Our thanks to Steven M, who reported this issue. We fully support your reporting of issues and we appreciate it when people work with us to identify and solve the problem.

Now that the Chronon Recording Server is out of beta, here are some changes we made to it based on a lot of feedback from our customers to improve the experience for everyone:

Installation Experience

The complex installation procedure of the Recording Server was among the biggest complaints during the beta period, so we sought to make it much more simpler.

The complaints centered around an understanding of the various ports used for communication and the high amount of configuration needed. We have cut down on both in this release.

The biggest change we made was with respect to the Recording Server .war file itself. During the beta period, you had to put a special configuration file to tell the Recording Server which port to listen on. This was confusing in many ways:

• The xml file with the context parameter was specific to the container, so you had to figure out how to pass the context parameter for your specific container.
• The mention of port itself was confusing to a lot of people. They couldn't differentiate between the port used for accessing the web ui in the container and the port at which the recording server was listening. We would get frequent complaints like "I configured port 80 for the recording server, but when I type localhost:80/recordingserver nothing happens". And we would have to explain that the web ui was still running at the port of the container it was deployed on, eg localhost:8080/recordingserver. But by this time it was all too confusing for the user.

We have made the experience much simpler now, by removing the need for the xml file entirely. Now you just deploy the .war file normally in your container. When the recording server is first accessed, it will ask the user to specify a port to listen for controllers.

(download)

Click here to download:

recording-server-improvements-since-beta-kgDivfvvjBytndFIqFth.zip (252 KB)

This has multiple benefits:

1. No xml file needed to configure the port. Its all done in the UI and can also be changed directly from the UI at any point.
2. Since the user accessed the recording server web UI the first time using the port of the container in which it was deployed, eg by using localhost:8080/recordingserver, he no longer has confusions as to differentiating between the port at which to access the UI and the port at which the Recording Server listens.
3. Since the UI explicitly states that the port the user is specifying is the one at which the recording server will be listening to controllers, when editing the controller config file, the user knows exactly which port number to use.

Result - Install in < 2 mins

We have even made a video of the recording server installation along with 2 controllers. The video is < 2 mins in length and goes to show how simple it is to install the recording server now.

Running Controller without admin privileges

Another issue during the beta period was some people not having admin access to install the controller and instead of getting admin permission, they wanted to quickly evaluate the product. We have now updated the documentation to show how to use the Controller temporarily without requiring administrator privileges. 

Thread Dump

The Recorder Status panel in the Recording Server now has a button to get a Thread Dump of the application being recorded. Can come in handy if your application freezes for some reason or if you just want to know what is going in all those threads.

(download)

Click here to download:

recording-server-improvements-since-beta-adusJgwwAnlEyIhgwrFe.zip (68 KB)

Recording for long periods of time

We even made a big change with the recorder to allow running it for long periods of time.

Previously we were using a custom thread local mechanism which needed you to specify the total number of threads created in advance. This was set by default to a high number like 5000. However, there are many programs out there that do not use thread pooling and would create and destroy threads, moving the thread id number to cross whatever 'max' value you put. 

Thus we decided to use a different algorithm now, which completely removes the need for specifying a max value. You can create and destroy as many new threads as you want now!

This has made the configuration simpler both in the Recording Server UI and the Chronon Eclipse plugin, since there are no longer any fields needed for specifying maximum threads.

(download)

Click here to download:

recording-server-improvements-since-beta-GnohkalFgmFuJpAgGJok.zip (48 KB)

Today we are updating the Chronon Recording Server to 1.7.

Apart from the obvious download related bug fix, this release contains 2 new features:

1. Active Heap Info

Now you can see the heap size of the application you are recording. 
Note that for performance reasons, the heap size is updated only every 5 seconds.

2. Better Recorder Start/Stop Progress Info

Now when you start/stop the recorder on your application:

1. The progress bar is more accurate
2. You can see exactly which class is being instrumented 

Upgrading

Since this release required changes to the communication protocol, if you are upgrading your existing Recording Server installation, you will need to update all 3 components : recorder, controller and recordingserver.war

If you arent already using the Chronon Recording Server, go get it now!

The Problem

Last week we had a big issue on our hands. A lot of people trying out the Chronon Recording Server beta were reporting they were getting corrupt files when they would download a recording from the Recording Server UI. The issue was occurring at random. Sometimes the files would be corrupt and sometimes not. And try as we might we just weren't able to reproduce the issue on our end. We looked through our code and made a bit of change to what we thought could have been the issue and sent out the updated binaries, just hoping the issue was fixed.

But luck wasn't on our side, our blind, shot-in-the-dark fix did not work and we were getting overwhelmed with support requests of corrupt downloads. On our end we were trying everything possible, like introducing lag, reducing bandwidth, adding more machines,etc; but nothing was able to reproduce the issue on our end.

Solution

Then finally it struck me. We would use Chronon to debug Chronon!

I asked one of our customers to take the Chronon Recorder and use it to record the Chronon Recording Server. Thus the next time he ran into the corrupt download issue, he simply took the Chronon recording of the Chronon Server and sent it over to me. Once we had the Chronon recording it was only a matter of minutes till we drilled down to the root cause and solved the issue!

Conclusion

This was one of first times we ourselves experienced the power of having a tool like Chronon. Had it not been for the Chronon Recorder we would still be pulling our hair trying to reproduce the issue and then debug it. Our customers would have continued to grow unhappier with our product, our credibility would be on the decline and it would eventually affect our revenues. If you have had to support products out in the field, you know how it is when an unhappy customer calls you about an issue and you have to make him go through all these hoops to try to figure out the root cause, making him even more unhappy in the process, till he eventually just gives up your product altogether.

With Chronon, all this just vanishes! The customer in this case just sent us the recording and no other communication was needed. We have the bug fixed now and tests in place. If you are a company that prides itself on customer support or, like Chronon Systems, pretty much depends on it to drive sales and revenue, then with Chronon you have an invaluable tool that can literally change the public perception of your company. As far reaching as this may sound, we can stand behind this statement now since last week we got to experience this for ourselves.

We have decided to deprecate the developer mode a little bit. It is now used only by the eclipse plugin while recording from within eclipse.

The Chronon Recording Server is now the official way for Recording outside Eclipse.

The reasons for doing so are:

1. The developer mode config files were hard to create with the many configuration options.
   The server mode config file require only a 'name' value.
2. The process of creating the config, doing the recording, transferring the recording to the local machine to debug was too manual.
   This is exactly what the Recording Server was designed to eliminate.
3. Developer mode didnt support dynamic start/stop or support for long running programs.
   Turns out people who did want to record outside eclipse wanted exactly that. They wanted to skip the long initialization of their web servers and start recording after the web server had initialized and they wanted to record for long periods of time. This is exactly what the Recording Server was designed for.
4. No easy way to organize and view remote recordings.
   With the Recording Server you can easily view all the recordings for every java application on every machine.

While the Recording Server may require a bit of an initial setup due to the need to install the Controller process on each machine, even this takes less than a minute and needs to be done only once.  

Thus due to all the benefits described above we believe the Recording Server is the way to move forward for recording outside of Eclipse. It removes all the manual process which was previously required and replaces it with a nice, clean and easy to use GUI.