As to the question about log4j 1…
I looked at the RollingFileAppender in the log4j project. It only supports
rolling on file size and doesn’t support time-based rolling at all. The
RollingFileAppender in log4j-extras does support rolling on time and would get
the behavior you are looking for.
Right, I confused the syntax a bit. I should update the manual so I stop
confusing myself every time a question about rolling files comes up.
On Fri, Aug 24, 2018 at 19:25, Ralph Goers
wrote:
> That problem is because your original pattern was correct.
>
> Ralph
>
> > On Aug 24, 2018, at 4:37
That problem is because your original pattern was correct.
Ralph
> On Aug 24, 2018, at 4:37 PM, Joan Balagueró - ventusproxy
> wrote:
>
> Hello,
> No luck. I tried with DateLookup, but it doesn't work:
> filePattern="${sys:log.dir}vproxy_access.$${date:-MM-dd}" append="true"
>
Hello,
No luck. I tried with DateLookup, but it doesn't work:
I get: 2018-08-25 00:21:39,881 localhost-startStop-1 ERROR Could not create
plugin of type class org.apache.logging.log4j.core.appender.RollingFileAppender
for element RollingFile: java.lang.IllegalStateException: Pattern does not
Yes, the pattern is OK. What is meant by the reference to the SimpleDateFormat
is that you should using the pattern characters for SimpleDateFormat inside
%d{}. TimeBasedTriggeringPolicy requires the %d to figure out what the rollover
interval is. If you use ${pattern} it will be part of the
Sorry, is the pattern ok or not? Thanks, Joan.
-Mensaje original-
De: Ralph Goers [mailto:ralph.go...@dslextreme.com]
Enviado el: viernes, 24 de agosto de 2018 19:24
Para: Log4J Users List
Asunto: Re: Problem with daily rotation on log4j2 RollingFile
Matt, I don’t see anything wrong
I promise with log4j, even under this high concurrency, the rotation is
perfect. This is the config:
On Fri, 24 Aug 2018 at 12:24, Ralph Goers
wrote:
> Matt, I don’t see anything wrong with the file pattern.
>
>From the manual:
The pattern of the file name of the archived log file. The format of the
> pattern is dependent on the RolloverPolicy that is used. The
> DefaultRolloverPolicy will
It is surprising to me that it would have been any different in Log4j. I
believe it used similar logic for rolling over. I’d have to look at the code
and check though.
Ralph
> On Aug 24, 2018, at 11:32 AM, Joan Balagueró - ventusproxy
> wrote:
>
> Ok Ralph, understood. With log4j worked,
> I see you say performance in RollingRandomFile is 20-200% better than
> RollingRandom
Do you mean "RollingRandomAccessFile is 20-200% better than
RollingFile"? If so, that is correct. If you are using asynchronous
logging, I would recommend setting immediateFlush="false" (the default
value is
Ok Ralph, understood. With log4j worked, but I suppose that now the
implementation is completely different.
Just one more thing, I see you say performance in RollingRandomFile is 20-200%
better than RollingRandom. So, in what cases is it better to use RollingFile
instead of RollingRandomFile? I
No. It is impossible to guarantee that as the rollover will be triggered on one
thread while you are logging on others, so some events might happen before the
rollover process causes events to go to a new file. If you are logging at that
volume I would expect CronTriggeringPolicy and
I though of using the CronTriggeringPolicy, but I'm logging more than 10
thousands lines per second. If only one line log is not logged at the correct
file, everything will go wrong.
So using the CronTriggeringPolicy to rollover at midnight, have I the guarantee
that the last line of 20180825
Matt, I don’t see anything wrong with the file pattern.
Ralph
> On Aug 24, 2018, at 10:18 AM, Matt Sicker wrote:
>
> I don't think your filePattern value is correct. You should be using format
> specifiers from SimpleDateFormat there, not PatternLayout. Or you could put
> the date in a $${} to
I don't think your filePattern value is correct. You should be using format
specifiers from SimpleDateFormat there, not PatternLayout. Or you could put
the date in a $${} to delay expansion it looks like.
On Fri, 24 Aug 2018 at 11:30, Joan Balagueró - ventusproxy <
joan.balagu...@ventusproxy.com>
The TimeBasedTriggeringPolicy does not check for rollover on every log event to
reduce the overhead on busy systems. When you are only logging a few events you
will see it log a few records to the prior file before it checks for a
rollover. In your case you would be better off using the
Hello,
Im using RollingFileAppender with full async logging. This is the config:
%m%d{-MM-dd HH:mm:ss.SSS}%n
I started to send requests the 2018-08-22, the vproxy_access.2018-08-22 was
correctly created and
17 matches
Mail list logo
