Thanks a lot for the explanation, much clearer now.
Here is the JIRA: https://issues.apache.org/jira/browse/LOG4J2-1197
On Tue, Nov 10, 2015 at 11:39 PM, Remko Popma wrote:
> On Wed, Nov 11, 2015 at 2:34 PM, Benjamin Jaton
> wrote:
>
> > On Tue, Nov 10, 2015 at 6:13 PM, Remko Popma
> > wrote:
On Wed, Nov 11, 2015 at 2:34 PM, Benjamin Jaton
wrote:
> On Tue, Nov 10, 2015 at 6:13 PM, Remko Popma
> wrote:
>
> > To check my understanding: the problem is that with bufferedIO=true the
> > buffer contains log events that you want to see, but the buffer is only
> > flushed to disk when it is
On Tue, Nov 10, 2015 at 6:13 PM, Remko Popma wrote:
> To check my understanding: the problem is that with bufferedIO=true the
> buffer contains log events that you want to see, but the buffer is only
> flushed to disk when it is full (which is not frequent enough); is that
> correct?
>
Yes that
To check my understanding: the problem is that with bufferedIO=true the buffer
contains log events that you want to see, but the buffer is only flushed to
disk when it is full (which is not frequent enough); is that correct?
If you use AsyncAppender or Async Loggers, the buffer will be flushed w
And more generally, can all appenders benefit from such a setting?
Gary
On Tue, Nov 10, 2015 at 11:04 AM, Benjamin Jaton
wrote:
> Hi,
>
> I am wondering if it would make sense to have a maxDelayMillis parameter
> for the RollingFileAppender (like FlumeAppender).
>
> Use case:
> You have a web s
Hi,
I am wondering if it would make sense to have a maxDelayMillis parameter
for the RollingFileAppender (like FlumeAppender).
Use case:
You have a web server access log, you produce an HTTP request and expect to
see it (and the response) in the access logs right away-ish (or at least
control how