Request Tracker
Debugger Request Tracker
Last updated
Debugger Request Tracker
Last updated
Apart from debugging the incoming request and presenting the debugger at the end of the request (Request Dock Panel), you can also navigate to /cbdebugger
and visualize the Debugger request tracker. This panel will monitor ALL incoming requests to your application: REST, SOAP, Ajax, etc.
You can execute several commands from this visualizer:
Clear all request history
Reinit ColdBox
Shutdown the debugger visualizer
Refresh the requests
Auto-refresh the requests
Produce a Java Heap Dump
Each request is also tracked and visualized according to its activated collectors.
You can use the requestTracker.storage
setting to configure where the request trackers are stored. The default values are:
memory
: The default, which stores the trackers in memory
cachebox
: Store the request trackers in a CacheBox provider via the cacheName
cacheName
: Cache region to store the profilers. The default is the template
cache region.
The debugger comes pre-configured to store a stack of 50 requests in memory. You can change this via the following setting:
If you wanted to profile even the debugger itself you can use the trackDebuggerEvents
flag if needed.
The debugger can paint requests in a different color if they are executing slower than the threshold setting shown below. Please note that the threshold is in milliseconds.
Each request tracker has a panel called ExecutionTimers
which shows all the timers the debugger was able to track during that request. You can configure it via the following settings:
The expanded
is just a simple boolen to control if the panel is open by default, which it is. The slowTimerThreshold
is in milliseconds and when a timer passes that threshold it will be painted red; like the screenshot above.
You can control if the ColdBox information panel is open or closed by default via the coldboxInfo
setting:
You can also configure the HTTP Request panel to do your bidding:
You can have the panel open or closed and even chose if the HTTP Body request will be stored or not.
Be careful to not go overboard with profiling the HTTP Body because it can be very large.
All requests that produce exceptions are also tracked and special exception collectors are activated automatically to store the produced exception:
It will store the stack trace and the tag context of the exception so you can visualize it and fix your bug. It will also have links to open the offending code in VSCode or your favorite editor right from the debugger. You can even open and navigate the tag context in your IDE from the debugger.
You can also see all the collectors and their information to the point of the exception: