Replies: 5 comments 22 replies
-
hey, i don't mind adding this to the bounded queue. |
Beta Was this translation helpful? Give feedback.
-
@brendene this is done in #271 Also you should no longer need to recompile quill library. You will have to recompile your See https://github.com/odygrd/quill/blob/bounded_queue/examples/CMakeLists.txt#L76 and https://github.com/odygrd/quill/blob/bounded_queue/examples/example_bounded_queue_blocking.cpp Let me know if that works for you if you can use |
Beta Was this translation helpful? Give feedback.
-
Hello again and thanks for the patch! I think there is a subtle interaction when the backend worker is able to write some data (i.e. not fully blocked) and simultaneously there are a lot of messages being logged. When running in blocking bounded mode I didn't expect memory allocations but I noticed there were many, I think this is because Here is a sample piece of code to trigger the OOM killer:
|
Beta Was this translation helpful? Give feedback.
-
Ah, now I understand, I see what you mean by messages can still be out of order, here is a simple repro that still is under the
|
Beta Was this translation helpful? Give feedback.
-
Hello! Thanks again for the great library. Would it be possible to prevent a busy loop if a user tries to log to a full bounded queue? (i.e a configurable sleep in https://github.com/odygrd/quill/blob/master/quill/include/quill/Logger.h#L205) Use case is that the program output is piped to less, the less buffer is full and then a full CPU core is spinning while waiting for the user to scroll through more lines of output. |
Beta Was this translation helpful? Give feedback.
-
Hello and thanks again for the library! Would you consider a logging mode where log messages are not dropped and the queue is non allocating? i.e. blocking
A use case would be stress testing a webserver that uses quill for logging. When the webserver is running in real time, logs are flushed to disk and the queue isn't growing. However, if you are stress testing the webserver with a preset load and piping the output to
less
eventually the pipe buffer fills up and the quill backend thread isn't able to drain so the queue gets larger and larger until the system possibly runs out of memory.I realize this isn't in the spirit of a low latency logger but it would be nice to be able to utilize the same logging code (perhaps with a config option that enables/disables it) without adding quill::flush() everywhere.
Beta Was this translation helpful? Give feedback.
All reactions