DESCRIPTION

Implements the standard reader process to the standard logfile merger inviso_lfm .

The reader process reads logfiles belonging to the same set (normally one node) in chronological order and delivers logged trace messages one by one to the output process. Before any trace messages are delivered, the inviso_lfm_tpreader implementation reads the entire trace information file (if in use) and builds a database over pid-to-alias associations.

The inviso_lfm_tpreader implementation is capable of considering that an alias may have been used for several processes during different times. An alias may also be in use for several pids at the same time, on purpose. If a process has generated a trace message, all associations between that pid and aliases will be presented as the list PidMappings in the message sent to the output process.

EXPORTS

handle_logfile_sort_wrapset(LogFiles) -> FileList2

Types

LogFiles = [{trace_log, FileList}]
FileList = FileList2 = [FileName]
FileName = string()

Only one {trace_log, FileList} tuple is expected in LogFiles , all other tuples are ignored. FileList must:

*

contain one single file name, or

*

a list of wraplog files, following the naming convention <Prefix><Nr><Suffix> .

Sorts the files in FileList in chronological order beginning with the oldest. Sorting is only relevant if FileList is a list of wraplogs. The sorting is done on finding the modulo-counter in the filename and not on filesystem timestamps.

This function is exported for convenience should an own reader process be implemented.

THE TRACE INFORMATION FILE PROTOCOL

The format of a trace information file is dictated by the meta tracer process. The inviso_lfm_tpfreader implementation of a reader process understands the following trace information entries. Note that the inviso_rt_meta trace information file is on binary format prefixing every entry with a 4 byte length indicator.

{Pid, Alias, alias, NowStamp} :

Pid = pid()
Alias = term()
NowStamp = term() , but in current implementation as returned from erlang:now/0

This message indicates that from now on shall Pid be associated with Alias .

{MaybePid, Alias, unalias, NowStamp} :

MaybePid = pid() | undefined
Alias = term()
NowStamp = term() , see above

This message indicates that, if MaybePid is a pid, this pid shall no longer be associated with Alias . If it is undefined , all associations with Alias from now shall be considered invalid.

Also note that there are many situations where unalias entries will be missing. For instance if a process terminates without making explicit function calls removing its associations first. This is seldom a problem unless the pid is reused.