- 29 Sep, 2016 1 commit
-
-
Brett Hazen authored
-
- 22 Sep, 2016 7 commits
-
-
Doug Rohrer authored
BORS seems to be out to lunch - going to merge manually after rebasing on top of master
-
Doug Rohrer authored
-
Bishop Bors authored
Restore backwards-compatible `lager_file_backend` configurations. Reviewed-by: macintux
-
Bishop Bors authored
mark for no crash log Reviewed-by: JeetKunDoug
-
Doug Rohrer authored
-
Doug Rohrer authored
The strict configuration work in 31cf6c02 prevents some backwards-compatible code in lager_file_backend from working as the configuration is rejected before it gets to the backend. This fix adds an additional guard on `check_handler_config/2` to support the `tuple` configuration structure supported by `lager_file_backend`.
-
Bishop Bors authored
Fixed legacy support for {crash_log, undefined} Reviewed-by: JeetKunDoug
-
- 15 Aug, 2016 1 commit
-
-
Joe DeVivo authored
Applications that explicitly configure lager's `crash_log` with the value `undefined` will get a really terrible crash message for all versions since 81222ca4 Diff here: https://github.com/basho/lager/commit/81222ca4869402b4b790bce3f2df40f9b2d213a0#diff-25e915f0df09d04052d2a6e85b8824f2 That message looks like this: ``` ** Generic server lager_crash_log terminating ** Last message in was rotate ** When Server state == {state,undefined, {file_descriptor,prim_file,{#Port<0.1340>,15}}, 281571,65536,10485760, [{hour,0}], 5,false} ** Reason for termination == ** {badarg,[{erlang,'++',[undefined,".3"],[]}, {lager_util,rotate_logfile,2, [{file,"_build/default/lib/lager/src/lager_util.erl"}, {line,220}]}, {lager_crash_log,handle_info,2, [{file,"_build/default/lib/lager/src/lager_crash_log.erl"}, {line,99}]}, {gen_server,try_dispatch,4,[{file,"gen_server.erl"},{line,601}]}, {gen_server,handle_msg,5,[{file,"gen_server.erl"},{line,667}]}, {proc_lib,init_p_do_apply,3,[{file,"proc_lib.erl"},{line,247}]}]} ``` This fix will allow people who use this legacy configuration to not experience production crashes at midnight after the deploy, when crash_log tries to rotate for the very first time, resulting in trying to append `.Int` to `undefined`
-
- 21 Jun, 2016 1 commit
-
-
redink authored
-
- 10 Jun, 2016 1 commit
-
-
John R. Daily authored
-
- 19 May, 2016 4 commits
-
-
Bishop Bors authored
Cleanup for test, whitespace Reviewed-by: javajolt
-
John R. Daily authored
-
John R. Daily authored
* Make lager_handler_watcher test more resilient by scanning for messages of interest rather than assuming we know exactly what messages will arrive at the test backend
-
John Daily authored
Fix get_env bug
-
- 18 May, 2016 1 commit
-
-
Bishop Bors authored
Support typed records newly exposed in OTP 19 Reviewed-by: macintux
-
- 11 May, 2016 1 commit
-
-
Alexander Petrovsky authored
-
- 10 May, 2016 1 commit
-
-
Alexander Petrovsky authored
-
- 09 Apr, 2016 1 commit
-
-
Mark Allen authored
-
- 08 Apr, 2016 2 commits
-
-
Bishop Bors authored
Incorporate an optional 'sink killer' for load shedding purposes Reviewed-by: bsparrow435
-
Mark Allen authored
-
- 07 Apr, 2016 18 commits
-
-
Mark Allen authored
-
Mark Allen authored
-
Mark Allen authored
-
Mark Allen authored
-
Mark Allen authored
-
Mark Allen authored
-
Mark Allen authored
-
Mark Allen authored
Lager logs its own application start up message. Previously this message was discarded or not received quickly enough to cause test failures, but now it seems as though it is being received and causing several test failures even though we are explicitly flushing it away. We introduce a 5 millisecond sleep for several tests to make sure the start up message is received before the flush command dumps it.
-
Mark Allen authored
Previously, was always hardcoded to the default sink name.
-
Mark Allen authored
Previously, configuration would come from application:get_env/3 or proplists:get_value/3. Now we standardize on a single format for retrieving values from the environment or from a proplist.
-
Brian L. Troutwine authored
Signed-off-by:
Brian L. Troutwine <brian.troutwine@adroll.com>
-
Brian L. Troutwine authored
Signed-off-by:
Brian L. Troutwine <brian.troutwine@adroll.com>
-
Brian L. Troutwine authored
This is, perhaps, not the most ideal setup. It still ignores other sinks but does bring logging back online after the appropriate delay. Signed-off-by:
Brian L. Troutwine <brian.troutwine@adroll.com>
-
Brian L. Troutwine authored
This test only passes when run in isolation. That is, if you run the suite solo everything is beautiful and nothing hurts. When run in the group, it fails. By inspection it seems that no trace messages are being sent and this causes the failure, for want of specific traces. Signed-off-by:
Brian L. Troutwine <brian.troutwine@adroll.com>
-
Brian L. Troutwine authored
At this point in the work, the killer will correctly stop the DEFAULT_SINK in the event of overload but our friend never comes back up and lager stops working past this point. Oops! Error message: =SUPERVISOR REPORT==== 10-Mar-2016::16:18:11 === Supervisor: {local,lager_handler_watcher_sup} Context: child_terminated Reason: killed Offender: [{pid,<0.63.0>}, {id,lager_handler_watcher}, {mfargs,{lager_handler_watcher,start_link,undefined}}, {restart_type,temporary}, {shutdown,5000}, {child_type,worker}] =SUPERVISOR REPORT==== 10-Mar-2016::16:18:11 === Supervisor: {local,lager_handler_watcher_sup} Context: child_terminated Reason: killed Offender: [{pid,<0.59.0>}, {id,lager_handler_watcher}, {mfargs,{lager_handler_watcher,start_link,undefined}}, {restart_type,temporary}, {shutdown,5000}, {child_type,worker}] =PROGRESS REPORT==== 10-Mar-2016::16:18:11 === supervisor: {local,lager_sup} started: [{pid,<0.113.0>}, {id,lager}, {mfargs,{gen_event,start_link,[{local,lager_event}]}}, {restart_type,permanent}, {shutdown,5000}, {child_type,worker}] Signed-off-by:
Brian L. Troutwine <brian@troutwine.us>
-
Sungjin Park authored
-
Mark Allen authored
-
Mark Allen authored
-
- 06 Apr, 2016 1 commit
-
-
Bishop Bors authored
Include 'none' in the log_level type Reviewed-by: macintux
-