Here are some details on the architecture of the Chronon Recording Server which recently went into beta.
As shown in the diagram above:
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.
This design was chosen because:
The recordings are stored locally on the machines being recorded. This reduces network traffic.
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.