Logging in Petals

Key
This line was removed.
This word was removed. This word was added.
This line was added.

Changes (12)

View Page History
To trace exchange activities into files, it is better to have a policy based on one log file per process instance instead of having one big file. One file by process instance is more human readable. So a new file handler is also provided: [{{org.ow2.petals.log.handler.PetalsFileHandler}}|#petals_file_handler].

The MONIT level permits also to dump the message exchange content using another dedicated file handler: [{{org.ow2.petals.log.handler.PetalsPayloadDumperFileHandler}}|#petals_dumper_file_handler]. It is based on the file handler '{{org.ow2.petals.log.handler.PetalsFileHandler}}' adding it capabilities to dump the payload of message exchanges. handlers:
* [{{org.ow2.petals.log.handler.PetalsPayloadDumperFileHandler}}|#petals_dumper_file_handler]. It is based on the file handler '{{org.ow2.petals.log.handler.PetalsFileHandler}}' adding it capabilities to dump the payload IN, OUT or fault of message exchanges,
* [{{org.ow2.petals.log.handler.PetalsExchangeDumperFileHandler}}|#petals_dumper_file_handler]. It is based on the file handler '{{org.ow2.petals.log.handler.PetalsFileHandler}}' adding it capabilities to dump message exchanges completely:
** message exchange info: id, interface, service, endpoint, operation, pattern, status,
** message exchange properties,
** normalized messages:
*** properties,
*** content,
*** attachments,
** fault,
** error.

h2. Default levels
| {{xxx.flows-subdir}} | {{flow-monitoring}} | The name of the directory contained in the directory {{basedir}} where log files of log records associated to process activities are written. If the value is a relative, it will be relative to the base directory. Absolute value is accepted. |
| {{xxx.logFilename}} | {{petals.log}} | The name of log files. It's a relative filename value, without directory |
where {{xxx}} is the name of the log handler: {{org.ow2.petals.log.handler.PetalsFileHandler}}, {{org.ow2.petals.log.handler.PetalsPayloadDumperFileHandler}} or {{org.ow2.petals.log.handler.PetalsPayloadDumperFileHandler}}. {{org.ow2.petals.log.handler.PetalsExchangeDumperFileHandler}}.

{tip}The Petals file handler processes all log record according to their log level and its own log level. So split files can be generated containing only traces with log level SEVERE, WARNING or INFO when the min log level is set to INFO. To have *no splitted files* (ie. no traces about process execution), you must *disable the Petals log handler*, and add the default log file handler of the JDK logging system {{java.util.logging.FileHandler}} to retain a global log file:
h2. Debugging process execution

In the previous paragraph, you see how to get traces about process instance executions. For a debugging or replaying purpose, it is interesting to get the content of messages exchanged. This is possible using another Petals file log handlers: {{org.ow2.petals.log.handler.PetalsPayloadDumperFileHandler}} and {{org.ow2.petals.log.handler.PetalsExchangeDumperFileHandler}} based on the previous file log handler {{org.ow2.petals.log.handler.PetalsFileHandler}}.

The content of the messages are dumped in the log files hierarchy defined [above|#log_file_hierarchy] in the directory dedicated to the current process instance. One dump file is created for each message sent or received containing its XML payload. The content of dump depends on the petals log handler. The path of the dump file is logged, if possible as a relative path to {{basedir}}, in the MONIT trace through a dedicated field: {{payloadContentDumpFile}}. {{dumpFile}}.

In order to dump message, this log handler needs to maintain a pool of object helping it to transform in-memory XML representation of the payload to text.
Depending on the configuration, this can impede performances: it will restrict the number of concurrent dump to disk, but the default value should be ok, only change it in case of problems.

This Petals file log handler {{org.ow2.petals.log.handler.PetalsPayloadDumperFileHandler}} has the same configuration properties than its [parent|#petals_file_handler] and extends it with the following parameters:
Thes Petals file log handlers {{org.ow2.petals.log.handler.PetalsPayloadDumperFileHandler}} and {{org.ow2.petals.log.handler.PetalsEXchangeDumperFileHandler}} have the same configuration properties than their [parent|#petals_file_handler] and extend it with the following parameters:
|| Property || Default value || Description ||
| {{xxx.dump-basedir}} | The default value is the flows sub-directory | The name of a root directory that will contain all dump files organized by flow using an intermediate sub directory associated to the flow. If the value is a relative, it will be relative to the flows sub-directory. Absolute value is accepted. |
| {{xxx.transformersPoolMaxActive}} | The default value is 8 | The maximum number of objects available to dump a message at a given moment: limit the the number of concurrent dump to disk. |
| {{xxx.transformersPoolMaxIdle}} | The default value is 8 | The maximum number of objects available and not used at a given moment: will trigger freeing of memory when exceeded. |
where {{xxx}} is the name of the log handler: {{org.ow2.petals.log.handler.PetalsPayloadDumperFileHandler}} or {{org.ow2.petals.log.handler.PetalsExchangeDumperFileHandler}}.

{note}An issue JIRA already exists to dump the whole content of messages, including properties and attachments: {jira:PETALSESBCONT-228}{note}
h2. Performances

Performances decrease when activating MONIT log level, and mainly if the log handlers {{org.ow2.petals.log.handler.PetalsPayloadDumperFileHandler}} is or {{org.ow2.petals.log.handler.PetalsExchangeDumperFileHandler}} are enabled. To reduce the performance impact, you can apply an asynchronous pattern, for example using the log handler {{java.util.logging.MemoryHandler}} linked to {{org.ow2.petals.log.handler.PetalsFileHandler}}:
{code}
handlers=java.util.logging.ConsoleHandler, java.util.logging.MemoryHandler
* and, running in [automatic mode|Starting and stopping Petals ESB installed by Debian packages],

you can disable the log handler 'console' for which all generated traces on the standard output are discarded, and used only a log handler 'file' ({{java.util.logging.FileHandler}}, {{org.ow2.petals.log.handler.PetalsFileHandler}} or {{org.ow2.petals.log.handler.PetalsFileHandler}}, {{org.ow2.petals.log.handler.PetalsPayloadDumperFileHandler}} or {{org.ow2.petals.log.handler.PetalsExchangeDumperFileHandler}} according to your needs about the [flow monitoring|Monitoring processes with their logs]).
{code}
# Configuration of the log handlers

*Solutions to try:*
* Change the log level of the log handler {{org.ow2.petals.log.handler.PetalsFileHandler}} or {{org.ow2.petals.log.handler.PetalsFileHandler}}, {{org.ow2.petals.log.handler.PetalsPayloadDumperFileHandler}} or {{org.ow2.petals.log.handler.PetalsExchangeDumperFileHandler}} and set it the value FINEST.

*Explanations:*
By default, the log configuration set a log level FINEST to the log handler 'console', and the standard output of Petals ESB container is redirected to {{/dev/null}} by the SysV init.
The global log file is the file generated by the log handler {{org.ow2.petals.log.handler.PetalsFileHandler}}, {{org.ow2.petals.log.handler.PetalsPayloadDumperFileHandler}} or {{org.ow2.petals.log.handler.PetalsPayloadDumperFileHandler}}. {{org.ow2.petals.log.handler.PetalsExchangeDumperFileHandler}}.