Age | Commit message (Collapse) | Author |
|
This commit updates logger_disk_log_h to write most log events
asynchronlously (disk_log:balog/2), but synchronously
(disk_log:blog/2) on every 20th event in the same way as logger_std_h
does. This is for efficiency reasons.
|
|
|
|
There was a lot of duplicated code in logger_std_h and
logger_disk_log_h. Most of this is now moved to logger_h_common, which
now also serves as the gen_server callback.
|
|
This function is called when a logger API function for fetching
handler configuration is called. The point is to allow the handler to
remove internal data fields that it might have stored in the
configuration database, before returning the handler configuration to
the caller.
An example of such internal data are the 'handler_pid' and 'mode_tab'
fields that logger_std_h and logger_disk_log_h store in their
configuration maps.
|
|
The new parameter to this function, SetOrUpdate, indicates how
unspecified configuration data fields shall be set. The rule is that
if SetOrUpdate equals set, then default values shall be used, and if
SetOrUpdate equals update, then existing configuration values shall be
used. Consequently, these examples now apply to logger_std_h and
logger_disk_log_h:
set_handler_config(default, config, #{sync_mode_qlen => 20}) sets the
value of sync_mode_qlen to 20, and resets all other (writable) fields
in the config map to their default values.
update_handler_config(default, config, #{sync_mode_qlen => 20}) sets
the value of sync_mode_qlen to 20, and leaves all other fields in the
config map unchanged.
|
|
When a handler process is terminated due to overload, it reads its
configuration from the configuration database, so it can be restarted
with the same configuration after a small delay. This was earlier done
in a different process, which was spawned off from the terminate
function. This caused a race condition, where in some cases, the
configuration was already removed before it could be read.
The reason for spawning off a process, is to avoid a deadlock due to
the call to logger:remove_handler/1.
This commit moves the call to logger:get_handler_config/1 back to the
handler process - to ensure that the data is still there, but keeps
the call to logger:remove_handler/1 in the spawned off process - to
avoid deadlock.
|
|
|
|
|
|
|
|
|
|
* siri/logger-fix:
[logger] Update documentation
[logger] Adjust priority settings in test
[logger] Unregister handler names before terminating
[logger] Stress overload_kill tests in disk_log handler
|
|
|
|
|
|
Conflicts:
lib/kernel/src/logger_disk_log_h.erl
|
|
|
|
|
|
|
|
Conflicts:
lib/kernel/src/logger_disk_log_h.erl
lib/kernel/src/logger_std_h.erl
|
|
And add field 'module' in handler config.
|
|
|
|
logger_std_h:filesync/1 -----> logger_std_h:sync/1
logger_disk_log_h:disk_log_sync/1 -----> logger_disk_log_h:sync/1
|
|
|
|
|
|
* peppe/peppe/kernel/logger_handler_fixes:
Various logger handler improvements and updated test cases
Make it possible to disable sync and drop mode
Conflicts:
lib/kernel/test/logger_disk_log_h_SUITE.erl
lib/kernel/test/logger_std_h_SUITE.erl
|
|
|
|
|
|
|