The eXtremeDB tracing framework allows applications to output trace and debugging information to a log file. This framework is a flexible mechanism for logging events mainly from internal operations of the eXtremeDB runtime. Sometimes, to discover the source of a problem, developers need to know not only the current application state but also some prehistory of operations. The tracing framework provides this possibility by allowing developers to view trace messages originating from inside eXtremeDB modules that are passed to a user-defined destination component, called an "appender". The main design goal of the tracing framework is to provide the lowest possible overhead when tracing is not active, and flexibility of use when it is active.
The framework uses a regular file to store messages and, by default, a synchronous method to write messages, i.e. a trace call will not return until the message is written to the output file. Also, file writes are guarded by a mutex to manage concurrency in the trace file when different threads are writing messages. As a consequence, when the default appender is used and tracing is enabled, it greatly affects performance as it serializes program execution.
If this behavior is not desired, but tracing is still needed, it is possible to use asynchronous tracing; i.e. messages are put into a queue so the tracing thread continues execution, and there is a separate tracing thread which writes the messages.
Please use the links below to view detailed explanations and examples for your development environment:
C Implementing tracing output in C xSQL Implementing tracing output with xSQL