In the schedule_flush method, a Thread is created (I assume) to prevent blocking by handling the scheduling logic asynchronously in an external thread.
Unfortunately, the call to thread.join has the side effect of blocking execution until the Thread is done sleeping and completed its call to flush.
Within a Rail application, this has the side effect of increasing the response time of every request by (calls to logger) * @flush_interval. (Indeed our response times increased nearly 30% the week we upgraded this gem.)
It's important to note that by not calling thread.join it's possible the program may exit without executing the contents of the thread. However, in this case it's simply scheduling a call to flush, where flush is already called explicitly on at_exit so the risk of buffer data loss is quite low considering the performance benefits.
In the schedule_flush method, a Thread is created (I assume) to prevent blocking by handling the scheduling logic asynchronously in an external thread.
Unfortunately, the call to
thread.join
has the side effect of blocking execution until the Thread is done sleeping and completed its call toflush
.Within a Rail application, this has the side effect of increasing the response time of every request by
(calls to logger) * @flush_interval
. (Indeed our response times increased nearly 30% the week we upgraded this gem.)It's important to note that by not calling
thread.join
it's possible the program may exit without executing the contents of the thread. However, in this case it's simply scheduling a call toflush
, whereflush
is already called explicitly onat_exit
so the risk of buffer data loss is quite low considering the performance benefits.