Return back to the blog

Chronon Recording Server Architecture

Posted by Prashant Deva on July 1, 2011

Here are some details on the architecture of the Chronon Recording Server which recently went into beta.

As shown in the diagram above:

Per Machine:

Each machine being recorded can have a number of jvms running. Each jvm has a recorder attached to it.

Each machine also has a ‘controller’ service running on it.


The controller is the heart of the communications mechanism in the Recording Server product. There is a controller service running on each machine which is controlled by the recording server web ui. The web ui talks to the controller which in turn talks to any of the jvms being recorded on that machine.

Server + UI:

The ‘server’ portion and the web based UI of the server sit on a separate machine and talk to the controller of each machine that is connected to the recording server.

Design implictaions

This design was chosen because:

The recordings are stored locally on the machines being recorded. This reduces network traffic.

Fault Tolerance
Any machine can go down without affecting any other machine.

·         If any of the machines being recorded go down, they don’t affect communication or recordings of any other machine.

·         If the Recording Server goes down, each of the machines being recorded still continue doing what they were last directed, since the recorders are controlled by the Controller service.
Thus all activity like flushing old recordings or splitting a recording after a time interval still keeps happening as it was scheduled when the recording server goes down.