|Kato > Index > Snapshot Trigger Design|
This page will be used to record the design considerations etc for the Snapshot API . Eventually this information will end up in the formal documentation.
When triggering a dump from within a JVM various considerations need reviewed.
There are three usecases:
Existing dumps cannot be subsetted and so we need to record what is available and provide a design where that information can be used in a reasonable manner.
If we need the caller to have set specific properties, command line options etc before we can produce a dump we need to find a way to communicate this.
Since we know about existing dumps it seem sensible for the RI to codify discovery and triggering of these dumps.
The first level of optionality is by data type. We need to determine other levels of optionality or scope
The main entry point for triggering a dump will be the DumpFactory class. This class uses a singleton design pattern to create a default factory populated with auto discovered trigger classes.
The DumpFactory allows for a default trigger to be registered. By default it will be the first trigger class discovered. To allow easy use of the RI code a System property will be used to allow
overriding the the first trigger class to be loaded.
The contents of a Dump can be manipulated by creating an instance of a DumpDescriptor and setting the requirements accordingly. Note that the general principle of a descriptor is to describe the least information required. It is not desireable to have a design where data is required to not be present.
Users of the dump factory can generate a dump quickly by using the DumpFactory.getDefault().dump() method chain.
For more sophisticated usage there are various options
The matrix below outlines the data types that are available with Dumps from IBM and Sun JVMs
| Data Type
|| IBM System Dump
|| IBM Heap Dump
|| IBM other dump
|| HPROF - signal generated
|| HPROF jmx generated
|| Kato CJVMTI Dump