The JADE 2022 release meets tomorrow’s business demands.
We currently use the CardSchema functionality for generating detailed stack dumps when an unexpected exception occurs.
However, the dumps produced are generally quite large which can be difficult to navigate/understand when diagnosing complex problems. As it can take a while to produce the stack dump, during which the current process may be locking contentious objects, our system is setup to abort the current transaction beforehand to minimize impact on other processes, however this can invalidate contents needed to diagnose a problem.
What would be useful is if the platform provided the means for taking a more compact/native dump, storing all objects referred to by the current stack with enough information needed to open the dump using the JADE debugger in another system, where the schemas/source code may not necessarily match the originating system exactly (not even the class/property numbers). To debug such a dump file, we'd need a way of opening/debugging from the IDE.
To resolve the problem referred to above, where we currently abort a transaction to release any locks, what would be ideal is if the platform could abort the current transaction as far as all other processes are concerned to allow them to continue but defer aborting the transaction within the current process until the dump has been created so its contents will still reflect the current state of the transaction/persistent objects when the exception occurred.
Kevin Saul
Currently we do not plan to do this, but we do plan a major review of the debugger and we will link this JEDI to that review. I will move this to Closed.
Sounds like you've got the gist of it, but don't think it can be broken into smaller pieces per the points stated as the fundamental objective would be to supersede the CardSchema approach with a platform-level approach.
Determining what objects to include could be based on either options specified at runtime or configuration. A light weight mini-dump strategy may be to include objects which are just a small number of steps followed directly from the current stack. A more heavy weight strategy may be to include all objects referenced by the current stack. A simpler strategy, albeit requiring more disk space, may be to copy the entire object cache.
Regardless of what strategy is used, even with a heavy weight approach, navigating the contents would become straight-forward with the ability to inspect the contents using the debugger as if we'd used process.debug directly when the exception occurred.
In order to query the contents of a dump file, it would be useful to have a new RootSchema class to act as the facade for opening/querying the contents (i.e. 'JadeDumpFile'), without necessarily needing to open the debugger (though it may be via this class that the debugger could be started like process.debug). Being able to easily query what/where/where the exception occurred, methods at top of the call stack, current user/application, etc, would simplify what we currently have to do when collating large numbers of exceptions (for which we currently have to parse the exception stack dump files, which can break if/when the CardSchema file format changes).
This seems quite a large piece of work. Can we break it down into smaller pieces and maybe make things easier for you in the interim? If I understand correctly, there are two main problems:
1. CardSchema dumps take a long time
2. CardSchema dumps are hard to understand
And what you're suggesting is to save the call stack, source code, and associated objects as a package that can be opened by another system's debugger?
If I have you right, one immediate question would be how to select which objects to include? As in, how many steps should we follow the references?