log4j split log files with rolling appender

[Ryan Conrad]

I am trying to save the log files in a rotation of 5 files (MaxBackupIndex) and a max file size of 10KB.  For some reason with my configuration, it seems that eventhough my properties get loaded in, they do not take place (i.e. no new files ever get created, only manager.log)

Here is my properties file:

log4j.appender.logfile=org.apache.log4j.rolling.RollingFileAppender

log4j.appender.logfile.File=logs\\manager.log

log4j.appender.logfile.RollingPolicy=org.apache.log4j.rolling.TimeBasedRollingPolicy

log4j.appender.logfile.RollingPolicy.FileNamePattern=logs\\manager.%d{yyyy-MM-dd}.log.gz

log4j.appender.logfile.TriggeringPolicy=org.apache.log4j.rolling.SizeBasedTriggeringPolicy

log4j.appender.logfile.TriggeringPolicy.MaxFileSize=10240

log4j.appender.logfile.layout=org.apache.log4j.PatternLayout

log4j.appender.logfile.layout.ConversionPattern=%d %p %t %c: %m%n

I am at a loss for why it wouldn't go along with these settings, even when it loads it in.  Do I need to do something special with vertx to make it work?

-RC

[Alexander Lehmann]

Logging in vert.x is a bit tricky since you have to distinguish between files used by the platform and files used by your verticles.

If you are using log4j inside the verticle, it should find the log4j.properties file in the classpath of that verticle, but maybe it is not, if you are using the log4j log delegate in the container, the files have to be in the platform_lib directory (more or less).

I would assume that it is not actually finding the file and using something else, to validate that assumption it would be best to change the log file to another name and see if that is recognized, if it is, I could take a further look why it isn't working.

[John Oliver]

To add what Alexander has said about the issue with logging from inside verticals and not using the delegates provided by Vert.x.  One issue is that due to the class loader isolation between modules. It is possible that you will essentially end up with multiple instances of log4j all of them appending to the same file, however unaware of each other and rolling over incorrectly. I don’t know about log4j, but using logback I received data loss from my logs I believe due to this issue. I resolved this by creating a non-runnable module from which you can configure your logging and then importing the module, ensuring that you only have one logger instance. You can see the project for logback at:

https://github.com/johnoliver/vertx-logback

I am not sure it is your issue, however the symptoms of failure to rotate correctly is in common with my experience with logback.

John

[Alexander Lehmann]

Sorry, the issue is not with vert.x, the configuration doesn't work on a normal java program either.

You are using a time based rolling policy, but a size limit, which doesn't work, since the files are not different in smaller intervals than one day.
You can add .%i to your filename, this will add a timestamp to each file (currentTimeMillis) or you can use a fixed window based rolling policy.

[Ryan Conrad]

Oh yes you are right about the policies not being coherent.  i was trying out a bunch of stuff and didnt notice they couldnt go together.  So I have used the debug feature to find out that it is pulling in the correct file.

I will try your suggestion with the %i or a different policy.  I have just tried so many combinations of using the time based policy with the rollingAppenders .maxFileSize and .maxIndexSize and I have made custom classes to seperate the timebasedpolicy to just be RollingPolicy and a SizeBasedTriggeringPolicy to just trigger the size for the appender to cut it off at ( end of this post http://apache-logging.6191.n7.nabble.com/RollingFileAppender-not-working-consistently-td8582.html)

But absolutely nothing is working, so I think it could either be a permission issue???  Or that my verticles always have at least one writing to the log so that the system cant rename it?

Are there any other main reasons why a file wont be rolled over?

[Alexander Lehmann]

If the config with .%i isn't working either, its probably a classloader issue as John suspects, are you using the same log4j config on more than one verticle at the same time?

Haven't really used more than one verticle yet, but I assume that when a file is open for writing in Windows, it cannot be renamed.