We have updated the Chronon Eclipse plugin to support the Google GWT plugin. You need GWT plugin version 2.4.2 or higher for the Chronon plugin to be enabled for it.
With the GWT support:
You can record GWT applications easily in development mode.
The GWT ‘Development mode’ view has the Chronon ‘blue’ stop button that is enabled when you are recording a GWT application. Make sure to use that instead of the ‘red’ button to stop your GWT applications, otherwise the recording wont be saved properly.
The bug occurs when a recording is ‘split’ at preset time intervals (eg 1 hour), by the Recording Server and results in a corrupt recording.
The bug is inside the Chronon Recorder and during a ‘split’ can produce an invalid recording, which will throw an exception during the unpack phase. If you try to unpack the recording inside eclipse, the Chronon eclipse plug-in will show an error saying the recording is corrupt. The exception/error will show itself near the end of the unpack phase ( ie, after atleast 90% of the way through).
To fix the bug, download the latest recording server zip file and just replace the recorder.jar files in your recording server installation with the updated version in the new recording server zip.
The current recorder .jar version with the bugfix is 18.104.22.1686. If you are using that version or higher, then you are fine, otherwise you need to update.
Our thanks to Steven M, who reported this issue. We fully support your reporting of issues and we appreciate it when people work with us to identify and solve the problem.
Since the Chronon recorder uses bytecode instrumentation to record your java applications, I thought I would list some of the tools we use to help us with it:
The de-facto Java framework for bytecode manipulation. The ASM framework is the fastest, most flexible and well known framework around for doing bytecode manipulation. At the time of writing its the only framework that supports the Java 7 class file format. If you are trying to choose a framwork for bytecode manipulation, stop, just learn and use ASM.
Bytecode Outline plugin
This eclipse plugin can automatically show you the bytecode for java file open in your editor. It can also show the corresponding ASM code that would be needed to generate the said bytecode. It will help you understand both bytecodes and the ASM framework better.
jClassLib Bytecode Viewer
This free tool, made by the same guys who make JProfiler, is the most comprehensive way to view your generated .class files. It can show you the bytecodes individually for a method along with things like the local variable table, exceptions table, constant pool, etc. Its a must have, in my opinion, if you are fiddling around with Java byetcodes in any way.
This may sound like self promotion, but I remember the time before Chronon was born and each time we would run into issues with the generated bytecode, (which btw you will at some point too, no matter how hard you try not to), it would take hours trying to use the standard debugger or littering our code with println() statements everywhere before we found the root cause. Now if we find any error in the generated bytecode, we just look at the Chronon recording of the executed code in the Time Travelling Debugger and can find root cause in minutes.
Since Chronon requires running on JVM 6, we do get people time to time asking “Does that mean Java 5 is not supported?”.
It seems some people still don’t understand that you can run Java 5 code on JVM 6. The JVMs are, and have always been, fully backward compatible.
This also means, that you can still write your code as Java 5 and even use JVM 5 to compile and build your application, but during deployment you can choose JVM 6 instead of JVM 5 and gain all the advantages of using a more recent JVM while making sure your code still can, if really needed, run on JVM 5.
Disadvantages of JVM 5
The JVM 5 is over 7 years old. It was even End Of Life’d over 2 years ago. That means it won’t be receiving any more updates, so if you run into a jvm bug, tough luck… On Macs, its not even possible to install JVM 5 unless you use some hacks.
Frankly, why anyone would use a a 7 year old technology which won’t receive any new updates, when a perfectly good alternative is available, is beyond me!
Advantages of JVM 6
The JVM 6 has been with us for > 5 years now and is still very much under active development. It has had 29 updates so far and is used by millions. It has much better performance than JVM 5 and the vast number of updates have ensured it is pretty damn stable.
At this point it baffles me that enterprises are sticking with a 7 year old, discontinued technology which has a perfectly good replacement which performs better and gets active updates. JVM 5 is the new IE 6 and like IE 6, it would be good for everyone if it was completely eradicated from this world.
Now that the Chronon Recording Server is out of beta, here are some changes we made to it based on a lot of feedback from our customers to improve the experience for everyone:
The complex installation procedure of the Recording Server was among the biggest complaints during the beta period, so we sought to make it much more simpler.
The complaints centered around an understanding of the various ports used for communication and the high amount of configuration needed. We have cut down on both in this release.
The biggest change we made was with respect to the Recording Server .war file itself. During the beta period, you had to put a special configuration file to tell the Recording Server which port to listen on. This was confusing in many ways:
The xml file with the context parameter was specific to the container, so you had to figure out how to pass the context parameter for your specific container.
The mention of port itself was confusing to a lot of people. They couldn’t differentiate between the port used for accessing the web ui in the container and the port at which the recording server was listening. We would get frequent complaints like “I configured port 80 for the recording server, but when I type localhost:80/recordingserver nothing happens“. And we would have to explain that the web ui was still running at the port of the container it was deployed on, eg localhost:8080/recordingserver. But by this time it was all too confusing for the user.
We have made the experience much simpler now, by removing the need for the xml file entirely. Now you just deploy the .war file normally in your container. When the recording server is first accessed, it will ask the user to specify a port to listen for controllers.
This has multiple benefits:
No xml file needed to configure the port. Its all done in the UI and can also be changed directly from the UI at any point.
Since the user accessed the recording server web UI the first time using the port of the container in which it was deployed, eg by using localhost:8080/recordingserver, he no longer has confusions as to differentiating between the port at which to access the UI and the port at which the Recording Server listens.
Since the UI explicitly states that the port the user is specifying is the one at which the recording server will be listening to controllers, when editing the controller config file, the user knows exactly which port number to use.
Result – Install in < 2 mins
We have even made a video of the recording server installation along with 2 controllers. The video is < 2 mins in length and goes to show how simple it is to install the recording server now.
Running Controller without admin privileges
Another issue during the beta period was some people not having admin access to install the controller and instead of getting admin permission, they wanted to quickly evaluate the product. We have now updated the documentation to show how to use the Controller temporarily without requiring administrator privileges.
The Recorder Status panel in the Recording Server now has a button to get a Thread Dump of the application being recorded. Can come in handy if your application freezes for some reason or if you just want to know what is going in all those threads.
Recording for long periods of time
We even made a big change with the recorder to allow running it for long periods of time.
Previously we were using a custom thread local mechanism which needed you to specify the total number of threads created in advance. This was set by default to a high number like 5000. However, there are many programs out there that do not use thread pooling and would create and destroy threads, moving the thread id number to cross whatever ‘max’ value you put.
Thus we decided to use a different algorithm now, which completely removes the need for specifying a max value. You can create and destroy as many new threads as you want now!
This has made the configuration simpler both in the Recording Server UI and the Chronon Eclipse plugin, since there are no longer any fields needed for specifying maximum threads.
The Step Forward button in Chronon, when it reaches the end of a method, doesn’t perform an automatic ‘step out’ like your regular debugger. Instead you have to click the ‘Step Out’ button manually.
The reason we don’t have the ‘Step Forward’ button automatically do a ‘Step Out’ is apparently due to the presence of the ‘Step Backward’ button.
Consider this scenario:
Stepping forward at the end of a method Steps Out of it.
Now when the user presses the Step Backward button:
Should we go back inside the method we came out of, or
Should we ‘step back’ in the current method we just stepped out to.
The undefined semantic of the Step Back button in this case could cause confusion to the user if we took either of those choices, but the user expected the another.
We wanted to keep the semantic of the ‘Step Back’ button to do exactly the opposite of what the ‘Step Forward’ button does.
So in this case, to keep that semantics of Step Back intact, we limited the Step Back and Step Forward to only step inside a single method call and requiring the user to press the ‘Step Out’ button explicitly.
Although considering all the advantages Chronon offers over a regular debugger or logging, pressing the Step Out button is hardly an inconvenience, we made it even easier with the introduction of Keyboard Shortcuts.
The peeves that developers mentioned were really related to the fluidity and smoothness of the debugging experience when you only have to keep track of pressing a single button.
Keeping this in mind, if you use keyboard shortcuts for stepping within Chronon, the Step Out button is only a key away. Also you will notice the speed and fluidity when stepping using keyboard shortcuts is far, far smoother than using a regular debugger since we are not executing any code. Thus stepping over say a method that contains the bulk of your program’s execution in Chronon would happen instantly compared to a regular debugger where you would notice pauses.
I think the above post does a good job explaining the rational behind the behavior of the Step Forward button. The keyboard shortcuts introduced recently in Chronon do a good job of keeping the fluidity of the debugging experience and you will find the experience butter-smooth compared to using a regular debugger even with the extra hassle of pressing a different key for step out.
Lets get this straight. Currently the only real way to debug long running, server side applications, is by looking at log files. Yet, logging in its current form is fundamentally broken.
What’s wrong with logging currently?
The paradox of logging:
You put a logging statement at a piece of code where you ‘think’ might be a bug.
Because you already thought about the bug at that place, you already hardened the code there.
In real life, errors happen where you least expected them to
Thus, what really happens is, you never end up putting a log statement where the error actually ends up occurring.
Apart from the above paradox which occurs due to the fact that you are basically trying to predict errors in advance, logging has other evils:
It clutters up your code and hides actual logic.
Its a huge distraction from actual coding.
Log levels - Not only do you need to think of the log statements, but also the ‘level’ of logging. Talk about predicting errors, this practically needs you to be Nostradamus…..
Also it is just real fun to figure out a bug from a long running server which has a ginormous log file.
Whats good then?
That said, there is something good about logging after all.
If in the miraculous case, you do get your log statements positioned exactly right, looking at a log file can give you a quick overview of the execution of your program.
Chronon 2.0 and Post Execution Logging
With Chronon 2.0, we are reinventing logging, just like we reinvented the debugger only a few months ago.
The Post Execution Logging functionality in Chronon 2.0 allows you to add logging to a program after it has executed.
Yes, you read that right. You can actually add logging after your code’s execution!
Not only that:
You can access all your variables (just like in regular logging statements)
You will the results of the log execution instantly without having to wait for the program to rexecute fully!
In true Chronon fashion, clicking on a line of log output will take you directly to the point in time when that statement was output, so you can see the entire state of your program and use the step back functionality to find the root cause of your issue.
That also means you can finally get rid of all those logging statements in your program that are cluttering up your code and focus only on developing your software.
If all this still sounds crazy to you, see the video below to see Post Execution Logging in action.