|
|
Right Java tools for J2EE, Web Service, Grid and more |
| |Home | Products | Documents | Downloads | Purchase | Support | Company | Partners | Contact | |
Table of Contents
LimpidDebugger is a reader and interpreter for LimpidLog.
LimpidDebugger functions like a regular debugger. But it uses complete different mechanism. LimpidDebugger reads records of LimpidLog and replays the records to simulate what had happed at the runtime of the application. The original runtime envirnment for the application is not required during replay. LimpidDebugger is a GUI tool, just like any other GUI debugger. The main differences from regular GUI debugger are:
There is no need to hard code log statement for LimpidLog. You log as needed at the runtime of your application.
LimpidDebugger and LimpidLog are particularly useful if you do not control the execution of the application and/or you can not debug the application. For example, a J2EE application runs at a data center, a Java application runs at your client site.
See Prerequisite in Installation for general prerequisite.
The application must be compiled with debug information. Otherwise, GUI debuggers will not work.
When you run your application, you need to invoke LimpidLog with -javaagent option. You may need to configure LimpidLog's to register/deregister classes of your interest. You need to use database as the logProxy of LimpidLog. During the execution of the application, log records are generated into the database. See LimpidLog for detailed information.
Then, start LimpidDebuggere to debug the application. You do not need the runtime environment (environment variables, libraries, application servers, ...). If you set application specific environment, the environment will be ignored. You need source code only. It is similar to investigation for problems of a commercial airplane: the data is recorded when the airplane was flying. The analysis is preformed in a lab later.
A project is a set of data. It is for your convenience. You can save it and open it later.
When LimpidDebugger is started, it automatically opens a default project. The name of the project is the time it is created in the format of yyyymmddhhmmss, for example. 20061018202715.project. You can rename it from menu item Save as project.
The log database may contain more data than needed for your debugging. So you need to set debug period.
The from time is inclusive, while the to time is exclusive.
This is an advanced topic.
The facility of Export case is useful when you may want send your debug case to someone else.
This facility exports the following data:
All data will be in a zip file in your selected folder. The file name is exportCase.zip. All temporary files in the procedure are deleted.
The importer will unzip exportCase.zip to a working directory, then select exportCase.project. The importer may need to modify the database URL according to your working directory name. You may need to add Source Path according to your working directory name.
Note: To make things easier, make the export case as small as possible by:
The Export case facility is under Project menu.
Migrate data from file to database
When you use LimpidLog to generate log data, you have choice of Database or File. If you recorded data into a File, not database when used LimpidLog, you must choose option fileLogMachineReading be true. A facility is available to migrate data from a file into database.
Migrate data from file to database is for debugging, not recording. Data is migrated to a temporary database. Do not migrate data from file to a LimpidLog-live database. Otherwise, the live data will be messed with historical data (the data in the file).
Data integration is very important.
Do not modify log database.
The versions of your source code must match the log records.
Security
Users need sufficient privileges on the log database.
When you input password on the database parameter panel, it does not show literally. When you save it, it will be saved as plain text. If you have security concerns, do not save your password by specify your preference on the Preference Panel. The default value is not save user name, nor password.
See Security guideline for logins of SuperArch for detailed information.
LimpidDebugger is thread safe. More than one person can work on the data at the same time. It read the database only, never write to the database.
The log records must be in a continuous execution session
This is an advanced topic. This issue happens rarely.
If the log data, which you are working on, is not from continuous execution session, you may see unexpected result.
Suppose you have a straight forward Java program which has 5 lines. The program started at 20:00, but the program was interrupted or you deregistered the class on LimpidLog when the execution went to line 2. So there was no information after line 2. One minute later, at 20:01, the program run again, or you re-registered the class. The information about the execution of the program resumed. So, there are two execution sessions: one at 20:00, the other from 20:01. If you debug the program start from 20:00, LimpidDebugger will step to line 1 of 20:00 and line 2. Then jumps to line 1 of 20:01. Although the data is correct history data, but the data may not be suitable for debugging. To avoid this issue, start your debug session at 20:01, not 20:00.
You need to pay attention to the status line at the bottom of the Source Code Panel. It tells you information about the file and information about the record. That information may give you some clues.