A full buffer should not log any errors about fluency HOT 3 OPEN

@frosiere I got your point. But, whether to move the log to DEBUG level or remove it depends on the use case. Also introducing a configuration to change the log level would be like whack-a-mole for other logs.

How about handling the issue on logging configuration side like this?

build.gradle

    implementation 'ch.qos.logback:logback-classic:1.4.11'
    implementation 'org.slf4j:slf4j-api:2.0.9'
    implementation 'org.codehaus.janino:janino:3.1.10'

logback.xml

        <filter class="ch.qos.logback.core.filter.EvaluatorFilter">
            <evaluator>
                <expression>return message.startsWith("emit() failed due to buffer full");</expression>
            </evaluator>
            <OnMismatch>NEUTRAL</OnMismatch>
            <OnMatch>DENY</OnMatch>
        </filter>

This isn't so robust, but very flexible so you can customize it if needed.

from fluency.

Thanks for the reply. Logging an error can only lead to an infinite loop until we recover. This seems a weird behavior. I may use the proposal but we have multiple applications handled by multiple teams so, it would avoid it.
So, moving this log entry to the debug level seems the only viable solution to me.

from fluency.

How to handle BufferFullException is up to the application. For instance, the application can avoid calling Fluency.emit() for a while after catching BufferFullException thrown from Fluency.emit(). This option makes sense since Fluency can't buffer log data anymore and what the application can do is only waiting forever or dropping new log data. It may result in some log lost, but I think it's a trade-off needs to be weighed.

I need to consider the balance between various use cases and the simplicity of the design and implementation of Fluency. So, unfortunately, I won't move forward on the option you suggested to change the log level, which some organizations have already depended on.

from fluency.