How Chronon Recording Server Acts As Tivo For Java

Since it's release, the Chronon Time Travelling Debugger  has struck me as one of the most innovative tools available for Java developers. Chronon have been busy adding to their offerings: their latest Recording Server can be described as "a Tivo or Software DVR for Java". With a tagline like that, I had to find out more from Prashant Deva, founder and CEO of Chronon.

DZone: What is the recording server adding to the initial Chronon product?
 
Prashant Deva: Well we already had a powerful Time Travelling debugger and a 'flight data recorder' which allowed you to record and replay any Java progam. With the addition of the Recording Server, we now have the full stack of Chronon ready to record, replay and easily debug any Java application running on any machine, for any duration of time.

The Chronon Recording Server turns Chronon into essentially a TiVo or Software DVR of sorts for Java.

You can easily record Java applications running on any remote machine and play the recording back on any other machine if the Java application encounters a bug or runs into any issues. The Recording Server makes it easy to manage the Chronon recorder on remote machines and allows you to easily share the recordings between team members.

So for example, a QA  machine can have the Recording Server configured to record its applicationss and if the QA person ever runs into a bug he can simply inform the programmer to download the recording corresponding to his machine. The developer in turn can then reproduce and debug the issue instantly on his machine using our Time Travelling Debugger. This also means that the developer can do away with the hassle of looking at huge log files.

The Recording Server is also built to allow recording of long running server side programs that run for days, weeks or months at a time. It will automatically take care of splitting the recording if its size gets too large.

The Chronon Recorder now also has the ability to dynamically start and stop recording in a running Java application. This way if for some reason, performance or otherwise you do not want to be recording all the time, you can start/stop the recording dynamically from the Recording Server dashboard without pausing the running Java program. When the recording is stopped, all extra resources consumed by the recorder are discarded, including any instrumentation.


DZone: Can the server generate reports?

Prashant Deva: Reporting doesn't make sense in the context of the Recording Server. We are not an APM tool. The Recording Server's job is to allow controlling the recorder and sharing recordings. You can use the time travelling debugger to then browse the entire execution of the program.

DZone: What does the server run on?

Prashant Deva: The architecture of the Recording Server looks like this:




Each machine being recorded can have a bunch of jvms running, with a recorder attached to each.

The machine each also have a 'controller' service running on them. The 'controller' is the real brain and is responsible for communicating with the individual jvms and the Recording Server.

The recordings are stored locally on each machine, so there is no extra network traffic when a program is being recorded. This also means that if any machine goes down, including the recording server, it wont affect the recording on any other machine.

The Recording Server runs on a separate machines and communicates only with the controller of each machine. Thus when you ask for a recording say 42 on say machine A for jvm B, the Recording Server will contact the controller for machine A and ask it for recording 42 of jvm B.

The Controllers create 'client' connections to the Recording Server, which can be listening on port 80 or 443. Thus no extra firewall configurations are required on any machine that will be recorded.



DZone:  Does reporting to the server slow down the running application?

Prashant Deva: The slowdown really depends on the 'amount of execution' being recorded. Thus, you can have a multi million line JavaEE program which mostly waits for IO from the database or network and it will have an almost negligible performance hit than a small 10 line program which runs in a tight loop.
Also we allow people to configure what they can record. By default, we discourage recording 3rd party library code. Since you didn't write it, you cannot debug it anyway. Thus the response time of most applications wont be affected much.