Chronon Systems has announced the beta availability of their new Chronon Recording Server, a "remote control" component of sorts for their Chronon toolsuite, now at version 1.8.7 as of Aug 15.
With it you can record the internal state of your java application while it runs, wherever it runs, then later "play back" the entire program execution to examine or debug. This playback-style debugging can be done on any other machine, or the same machine, needing nothing more than the recording file itself. Chronon Systems describes this all in one simple statement: its "DVR for Java".
Chronon (core) bundles with an Eclipse plugin that gives developers the power to playback a recording to examine the execution of the program in a debugging-style session. Like to a traditional debugger, the plugin provides rich views of data about the entire state of the application at each step, along with many additional tools to further filter and evaluate the programs execution flow.
This Time Traveling Debugger shows the full stack trace of every active thread and the exact content of memory at any point in time. You can instantly jump directly to any point, step back or forward in execution, since all the debugger tool needs to do is query the recording file like a database.
Because all state of the program is stored, the Chronon debugger can also do things which a traditional debugger cannot, like showing all values ever assigned to a particular variable, or searching for and jumping instantly to when that variable was a specific value, like 'null' for example.
The Chronon recorder runs as a java agent alongside your Java application, instrumenting the bytecode of classes loaded in memory to observe and collect data about what your Java program is doing. The data is asynchronously compressed and saved to a file on disk which can later be transferred to any computer, like a developers machine, where the "Time Traveling Debugger" just described can be used to playback and examine the program.
This may be particularly useful for long running server programs since, unlike you do with a traditional debugging tools, you don't need to set a breakpoint, find a way to reproduce the problem, and wait for hours until the breakpoint is hit. For example, one could can grab a recording file after the first occurrence of an exception, jump directly to the point of the exception and "step backward" to determine what caused the exception.
The latest addition to the toolset, the Chronon Recording Server component, allows you to manage the recorder on multiple JVMs running on remote machines and easily share the recording files among team members. In this new “server mode”, the Chronon recorder can dynamically start and stop recording in a running Java program. When something undesirable is reported about the program, a bug for example, the recording server can be instantly switched on to watch for a reproduction of the problem - no need to add logging code and redeploy or setup remote debugging sessions.
The folks at Chronon Systems quote these summary benefits about their tool suite:
- Avoid dealing with Log files: You can record the entire program and play it back on any machine, thus reducing the need to pour through large 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 the “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 release will be available free for the next few weeks. Give it a try and report your findings and feedback here.
Community comments
And the memory overhead?
by Robin van Breukelen,
Re: And the memory overhead?
by Prashant Deva,
Re: And the memory overhead?
by Nick Drew,
Re: And the memory overhead?
by Mike Bria,
Re: And the memory overhead?
by Mike Bria,
Omniscient Debugging - Configuration - Obfuscation
by Haasip Satang,
Re: Omniscient Debugging - Configuration - Obfuscation
by Prashant Deva,
Re: Omniscient Debugging - Configuration - Obfuscation
by Prashant Deva,
Chronon 2.0
by Prashant Deva,
Re: Chronon 2.0
by Mike Bria,
And the memory overhead?
by Robin van Breukelen,
Your message is awaiting moderation. Thank you for participating in the discussion.
I think this could prove very useful for some application.
Though it'd be nice if they said something meaningful about the memory overhead of the application, other than: it depends.. I can imagine that the overhead is quite substantial.
Re: And the memory overhead?
by Prashant Deva,
Your message is awaiting moderation. Thank you for participating in the discussion.
Robin,
The actual memory overhead is far lower than what you would expect for something like this.
We dont give out performance/overhead numbers due to 2 reasons:
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.
For people who are really cagey about performance, we even have dynamic start/stop functionality, so they can start recording only the first time they hit a bug.
Since usually 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.
For more details of the performance impact, you can read the relevant answer here:
www.chrononsystems.com/chronon-technology/
Omniscient Debugging - Configuration - Obfuscation
by Haasip Satang,
Your message is awaiting moderation. Thank you for participating in the discussion.
This seems to be pretty much a remake / Eclipse ready version of Bil Lewis' Omniscient Debugging idea (which can be downloaded here for everyone who's interested: www.lambdacs.com/debugger ). Anyway, it seems very well done, so thumbs up, good job (I just would have liked to see you giving some credits for this to Bil in one of the Google TechTalks where you presented that stuff a while ago already ;) )
Besides that I'm concerned about two things though:
1. Unlike other record-replay systems you need to configure upfront what should be recorded as the recorder does not automatically find every source of non-determinism, don't you? This means that you might record for days and weeks and when a bug occurs you might not be able to reproduce / analyze it because the part of code where it occurred is not configured to be recorded. Please correct me if I'm wrong here.
2. A lot of enterprise / commercial applications today are actually using code obfuscators. I don't think it is possible yet to record obfuscated applications and then debug through the non-obfuscated code using your system, is it? If this is the case, it unfortunately kinda makes it useless for a lot of companies, including ours :( (But it might be a nice feature to add though, don't you think? Let me know if you need help ;) )
Re: Omniscient Debugging - Configuration - Obfuscation
by Prashant Deva,
Your message is awaiting moderation. Thank you for participating in the discussion.
Actually the omniscent debugger project is nowhere near compared to Chronon. Omniscent was a 1 month academic research concept project while we have been working on Chronon for 4 years. If you try using both you will see the difference. I am sure for any commercial product out there, there are tons of tiny month or semester long academic projects which had the same 'concept'
About your concerns:
1. Usually the 'configuration' is just a single line which specifies the namespace of your company's code, eg - com.ibm.**.
This will record all the code of your company (say IBM) and leave out all 3rd party code, which you probably didn't have the source code for and don't want to look inside anyway most of the time. You can still come across the situation you mentioned where maybe you do want to look into 3rd party code, and you didn't record, but that is something we haven't come across yet.
2. Yes, Chronon wont work if you have obfuscated your product. However this is an issue mostly with ISVs. Almost everyone who uses the Chronon Recording Server runs it in internal staging or production servers, where there is no need to obfuscate code.
Since I mentioned ISVS, I will put a shameless plug for a special program we have running privately which allows you to embed Chronon in your application, so that you can basically put a record button in your application and have your customer start/stop recording when they run into an issue and send a full Chronon recording of the program instead of just a bunch of sparsely detailed huge log files. If you are interested for doing this with your app you can contact us at support@chrononsystems.com
All said and done, the extra line of configuration or leaving out 3rd party code from recording is still giving you far, far more information than what you currently get from log files when trying to fix a problem.
Re: Omniscient Debugging - Configuration - Obfuscation
by Prashant Deva,
Your message is awaiting moderation. Thank you for participating in the discussion.
Also the ability to 'exclude' classes from recording allow you to tightly control the performance impact of Chronon if needed.
If you dont want to record the read operation of that 1gb long file, you can skip it and keep your recording from instantly getting gigabytes large if tons of people start downloading that file or you can leave out a tight inner loop which you have already verified to be perfectly working.
Re: And the memory overhead?
by Nick Drew,
Your message is awaiting moderation. Thank you for participating in the discussion.
This seems like a productionised of the experimental Omnisicent debugger (www.lambdacs.com/debugger/).
The main constraint of that was disk volume and bandwidth.
Re: And the memory overhead?
by Mike Bria,
Your message is awaiting moderation. Thank you for participating in the discussion.
Hey there Nick,
Actually, another comment thread has pointed out the same. As Prashant (the primary guy behind Chronon) indicated there, you're laregely correct.
That project was aimed at similar goals as Chronon, although where the difference comes in it seems is that Chronon goes a good deal further to having a solid solution for those goals.
And, my 2 cents, the folks at Chronon are actively working full-time to make it better week by week, something the Omniscient Debugger project isn't at this point as far as I can tell.
Cheers,
Mike
Re: And the memory overhead?
by Mike Bria,
Your message is awaiting moderation. Thank you for participating in the discussion.
Also, and I maybe could've done a better job highlighting this in my writeup, the new "Recording Server" aspect is a pretty important distinction too.
In a nutshell, you can point the recorder to live-running, deployed apps without much trouble at all. This goes a long way to making this a true production-support tool, as well as a development tool.
Chronon 2.0
by Prashant Deva,
Your message is awaiting moderation. Thank you for participating in the discussion.
Just a little heads up, we just released Chronon 2.0.
It has this amazing feature called Post Execution Logging.
Post Execution Logging allows you to add logging after your program has executed and see the results instantly!
More details here:
chrononsystems.com/post-execution-logging
Re: Chronon 2.0
by Mike Bria,
Your message is awaiting moderation. Thank you for participating in the discussion.
Wow! I've not tried this yet, but from the looks of the video - awesome. What a great and useful idea, nice job!