This because of this in the logger:
Which makes sense most of the time, but if you only perform logging from within a thread, it never gets processed and the heap slowly fills up and cannot release (or quickly in the case of a lot of log events, especially errors).
I don’t believe either ACF or LUCEE allow me to spawn child threads. However, it is concerning, since the log listeners must be active in order for you to have threaded log events. Someone must be the first (in sync) mode to issue a logging request. The only scenario where the log listener would NOT be startted to flush out the log files is that if NO requests where synchronous.
>The only scenario where the log listener would NOT be startted to flush out the log files is that if NO requests where synchronous.
That’s not quite true. If you have a lot of log events in a window of time that all happen in a background thread, while no log events happen in synchronous threads, you will experience the problem (albeit temporarily). This is because the background logging thread lasts a max 15 seconds. So, after some logging inactivity, the logging thread goes away. Next, your background thread starts logging and some time elapses before any synchronous logging happens - your queue builds up because the processor never starts.
Of course, this can be avoided by not having a situation in which you are logging like crazy 😉 But, it would be better that, should that eventuality happen, the logs get processed as normal.
I managed to hunt down the Lucee JIRA:
So we could add a server version check in here and allow it when supported? Or maybe something like this in the logger startup (or a compatibility check util singleton):
Rough idea ^^.
This has been addressed by using our completable futures
Nice one, thanks . Could you link to the issue it was addressed in the comments here so we can trace it?