Chronon Systems has announced a preview of Chronon Recording Server.

The Chronon Server records the internal state of your application while it's being executed and saves it to a 'recording' file. The recording can then be used to play back the entire execution of the Java program on any machine, without the need for the original environment. Thus it's almost like a "DVR for Java programs".

Chronon comes with a special time travelling debugger plugin for Eclipse which allows you to playback and recording and jump instantly to any point in the execution of your program.

This is especially useful for long running server side programs, since you don't need to set a breakpoint, like you would in a traditional debugger and wait for hours till the breakpoint is hit. You can just jump directly to, say when an exception was thrown and step 'backward' to see what caused the exception.

The Chronon Recording  Server allows you to manage the recorder on multiple jvms running on remote machines and share the recording files with your team members.

Here are some unique features:

No dealing with Log files

You dont need to scatter your program with logging statements. You can just record the entire program and play it back on any machine, thus removing the need to examine huge log files.

Record remote Java programs

Connect every computer in your organization to the Recording Server and manage the recorder on each machine.

Collaborate easily between QA and Development

With the Recording Server, QA can keep testing your Java program with the recorder running in background.  In case of any issues, the dev team can easily download the recording from the QA boxes and debug it using our time travelling debugger.

Record long running applications

Chronon Recording Server is designed to record programs that run for days, weeks and even months.  The Recording Server will take care of splitting the recording if it get too large and flushing out old recordings.

Dynamically Start and Stop Recording

The Recording Server allows you to dynamically start and stop the Chronon recorder in a running Java application.  This way you can run your application always with the recorder enabled but record only when you need to.

The beta is available for the next few weeks.

"Depends" is not the answer I am looking for. Can this be used in production? Can this recording be "what" as well as "when" or is it "everything" when the recording is triggered?

We do have people using Chronon in production.

For more details of the performance impact, you can read the relevant answer here:

http://www.chrononsystems.com/chronon-technology/

We even have dynamic start/stop functionality so if people are really cagey about performance, they can start recording only the first time they hit a bug.

Since once you hit a bug on a remote machine, you still have to reproduce the issue a lot of times to add extra logging or use a remote debugger, the ability to just reproduce the bug once and not worry about looking through or adding extra log statements is very nice to have.

I dont get the second part of your question. When you trigger the recording everything is indeed recorded but you can choose to skip portions of code like code inside 3rd party libraries if you wish.

Again, what is the performance overhead? 2%, 4% 10% on an average? Tools like Wily, JXInsight & Dynatrace are used in production environments  24/7. Catching of an occurence of customer bug in production are almot always fortuitous, unless it is a very specific issue consistently reproducible. Chronon seems like an excellent tool for QA/Dev environments, but seems sub-optimal for 24/7 Production monitoring & recording.

We dont give out performance numbers due to 2 reasons:

1. We are continuously improving the recorder so a number given now will be higher than say next month, but somebody who reads this post a month from now may get a misconception of Chronon's performance.
2. Unlike APM tools, our performance really does vary a lot depending on the program and the amount and kind of code being recorded, the amount of memory given and the number of cores alloted. We dont want to give out a number publicly and then have somebody get a completeley different experience from what we describe.

Thus for the reasons above, rather than believing a number we give out (which btw can always be made to look very nice) we encourage you to try out Chronon in your program and see if the performance suits your usage.