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.

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.

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.