Logging in Petals

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

Changes (9)

View Page History
In addition to the standard properties ({{level}} and {{formatter}}), the specific configuration properties of the Petals file handler are:
|| Property || Default value || Description ||
| {{xxx.basedir}} | The value of the system property '{{petals.log.dir}}'. If the value of the system property {{petals.log.dir}} is a relative path, an absolute path is built resolving the relative path of {{petals.log.dir}} against the current user directory | The *absolute* root directory of the log file hierarchy |
| {{xxx.basedir}} | The value of the system property '{{petals.log.dir}}'. | The root directory of the log file hierarchy. If the value is a relative path, it will be relative to the working directory from where Petals is executed. |
| {{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}} or {{org.ow2.petals.log.handler.PetalsPayloadDumperFileHandler}}.

{tip}The Petals file handler processes all log record according to their log level and its own log level. So splitted 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:
{code}
handlers=java.util.logging.ConsoleHandler, java.util.logging.FileHandler

{anchor:petals_dumper_file_handler}
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 handler: {{org.ow2.petals.log.handler.PetalsPayloadDumperFileHandler}} 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 path of the dump file is logged, if possible as a relative path to {{basedir}}, in the MONIT trace through a dedicated field: {{payloadContentDumpFile}}.

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:
|| 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}}.

Since the version 4.2 of Petals ESB, custom log handlers are supported. See the [source project code of Petals provided log handlers|https://anonymous:anonymous@svn.petalslink.org/svnroot/trunk/product/dev/prod/petals/tools-commons/petals-log] to write your own.

If you want to redirect the MONIT traces elsewhere than into log files, you can use your own log handler. Just put its JAR file and dependencies into the Petals library system-extensions directory, and configure your log handler into the logging configuration file.

h2. Enabling logging traces of the JMX server
{code}

h2. Petals ESB starts automatically started on Debian-based system

If your Petals ESB containers used in production are:
{code}

h2. Petals ESB starts manually started or installed through ZIP archive
If your Petals ESB installation does not satisfy the previous criteria (not running in automatic mode on a Debian-based system), you can improve performance decreasing the level of the log handler 'console':
{code}