We Keep Coding

FileHandler generate extra logs files when original log is locked

I need generate one log file by each application installed and running on websphere application server 9.
I use JUL for generate log's file. My solution was create a especific Class thas inherits from FileHandler and set logs properties by a config file.
This is my code:
//Read config file
LogManager.getLogManager().readConfiguration(LoggerJUL.class.getResourceAsStream("/Logger.properties"));
//Add handler to logger
Logger.getLogger(clazz)).addHandler(new PersonalFileHandler());
PersonalFileHandler extends FileHandler, and properties are set by configure method on FileHandler class on runtime.
In this way i achieve make one log file by application running over Websphere, without overwriting the destination of the server log.
Although I achieve part of the objective, extra files are generated if the original log file is locked, same like this: testLogs.log.0, testLogs.log.1, testLogs.log.0.1, etc.
I read many suggestions and solutions, but i can't stop this isue.
Any suggestions ?
handlers = com.mucam.xxxx.PersonalFileHandler
# Set the default formatter to be the simple formatter
com.mucam.xxxx.PersonalFileHandler.formatter = java.util.logging.SimpleFormatter
# Write the log files to some file pattern
com.mucam.xxxx.PersonalFileHandler.pattern = C:/Users/pmendez/Documents/Log/testLogs.log
# Limit log file size to 5 Kb
com.mucam.xxxx.PersonalFileHandler.limit = 5000
# Keep 10 log files
com.mucam.xxxx.PersonalFileHandler.count = 10
#Customize the SimpleFormatter output format
java.util.logging.SimpleFormatter.format = %d{ISO8601} [%t] %-5p %c %x - %m%n
#Append to existing file
com.mucam.xxxx.PersonalFileHandler.append = true

Although I achieve part of the objective, extra files are generated if the original log file is locked, same like this: testLogs.log.0, testLogs.log.1, testLogs.log.0.1, etc. I read many suggestions and solutions, but i can't stop this isue. Any suggestions ?
Since your count is set to 10 you need to specify the %g pattern to log the generation.
com.mucam.xxxx.PersonalFileHandler.pattern = C:/Users/pmendez/Documents/Log/testLogs%g.log
The pattern is absolute path so if you create multiple filehandlers it will resolve conflicts by appending unique number to the end. This is specified by the %u pattern. So if you want to move where the integer is placed in the file name you specify the %u token in the pattern.
This also means that you are creating multiple instances of your custom file handler and they are not being closed. If you want to control the number of files you either need to control the number of PersonalFileHandler you create and or share a reference to singleton PersonalFileHandler. Otherwise you need to make sure that if you explicitly create a PersonalFileHandler that you are explicit closing that PersonalFileHandler before you create a second new PersonalFileHandler.
Loggers are subject to garbage collection. The line:
Logger.getLogger(clazz).addHandler(new PersonalFileHandler());
Is subject to garbage collection unless the code elsewhere as already pinned that logger in memory. This can cause log files to be created, locked, and empty.

Do not need .0 extension log file when using logger with FileHandler from java.util.logging

Using Java.util.logging's FileHandler class to create cyclic logs. However why these logs are appended with .0 extension. .1,.2,.3 etc are fine, I only do not need .0 as my extension of file, since its confusing for the customer. Any way to achieve the same?
I am using java version java version "1.8.0_144".
FileHandler fileTxt = new FileHandler(pathOfLogFile+"_%g.log",
Integer.parseInt(prop.getProperty("MAX_LOG_FILE_SIZE")),
Integer.parseInt(prop.getProperty("NO_OF_LOG_FILES")), true);
SimpleFormatter formatterTxt = new SimpleFormatter();
fileTxt.setFormatter(formatterTxt);
logger.addHandler(fileTxt);
Name of log file is LOG_0.log. requirement is to not to have _0 on the latest file, need to be simply LOG.log.

You'll have to add more information about how your are setting up your FileHandler. Include code and or logging.properties file.
Most likely you are creating multiple open file handlers and are simply not closing the previous one before you create the next one. This can happen due to bug in your code or that you are simply not holding a strong reference to the logger that holds your FileHandler. Another way to create this issue is by create two running JVM processes. In which case you have no option but to choose the location of the where the unique number is placed in your file name.
Specify the %g token and %u in your file pattern. For example, %gfoo%u.log.
Per the FileHandler documentation:
If no "%g" field has been specified and the file count is greater than one, then the generation number will be added to the end of the generated filename, after a dot.
[snip]
Normally the "%u" unique field is set to 0. However, if the FileHandler tries to open the filename and finds the file is currently in use by another process it will increment the unique number field and try again. This will be repeated until FileHandler finds a file name that is not currently in use. If there is a conflict and no "%u" field has been specified, it will be added at the end of the filename after a dot. (This will be after any automatically added generation number.)
Thus if three processes were all trying to log to fred%u.%g.txt then they might end up using fred0.0.txt, fred1.0.txt, fred2.0.txt as the first file in their rotating sequences.
If you want to remove the zero from the first file only then the best approximation of the out of the box behavior would be to modify your code to:
If no LOG_0.log file exists then use File.rename to add the zero to the file. This changes LOG.log -> LOG_0.log.
Trigger a rotation. Results in LOG_0.log -> LOG_1.log etc. Then LOG_N.log -> LOG_0.log
Use File.rename to remove the zero from the file. LOG_0.log -> LOG.log
Open your file handler with number of logs as one and no append. This wipes the oldest log file and starts your new current one.
The problem with this is that your code won't rotate based on file size during a single run.

Simply use logger name as filename (Don't include %g in it). The latest file will be filename.log. Also note that the rotated files will have the numbers as extension.

Java Logger not rotating log files

I'm using Tomcat 8.0.21 on RHEL 7. In my Java code I'm logging to a text file with java.util.logging.Logger.
There is always only one log file. If I restart Tomcat the logging starts again from that moment and all previous logs are gone.
I added %g to file name as instructed here but it only adds 0 to file name and no rotation occurs.
Here is my code to create the FileHandler. strFilePath value is for example "/tmp/mylog.log". LogFormatter is my own class.
// Need to set format with own formatter class to get plain text to one line (default format is XML).
FileHandler file_handler = new FileHandler(strFilePath);
file_handler.setFormatter(new LogFormatter());
logger.addHandler(file_handler);
On my Windows 7 laptop logs rotate fine using the same code and Tomcat version.
How can I enable Java Logger log file rotation on my RHEL server?
Edit: I guess I could just add timestamp to file name when constructing FileHandler. I'm going to try that.

The FileHandler only rotates when the limit is exceeded (or unable to lock the file). If you want to rotate files by time then you have to code for that. If you want to just trigger a rotation then just create a throw away file handler with a limit of zero bytes before you open your actual file handler.
new FileHandler(pattern, 0, 1, false).close();

This is not a perfect solution but I think I won't lose old logs when I construct the FileHandler this way:
FileHandler file_handler = new FileHandler(strFilePath.replace("<timestamp>", new SimpleDateFormat("yyyy-MM-dd'T'hh:mm:ss").format(new Date())));
I have "<timestamp>" string in the file name and that gets replaced here. I think a new log file is only created when I restart Tomcat so the log files might get big. But this is the best I've come up so far.

Log4j Issue RollingFileAppender maxBackupIndex, maxSize, gap between index

I’m using log4j (1.2.14) for logging external data. It is information that could not be sent over the network to other applications.
I have a RollingFileAppender with maxSize and maxBackupIndex.
The logging process works fine. The process creates files as:
file.out
file.out1
file.out2
..
..
file.out[maxBackupIndex]
The problem is that I have another process periodically (when the logging process is off) send and delete (locally) some file to another location.
For example:
original files list:
file.out
file.out1
file.out2
file.out3
file.out4
The process sends and deletes file.out1, file.out2.
new files list:
file.out
file.out3
file.out4
Now, the logging process starts again.. Then log4j maintains the “gap” of 2 files… log4j creates:
file.out
file.out1
file.out4 (content of file.out3)
file.out5 (content of file.out4)
The problem is when maxBackupIndex is reached. Log4j not completes the gap with free space and begins overwriting the contents of my older files.

Doubt in FileAppender in log4j API

I have created java program which will process different file which coming to the particular folder.In my program, I need to create log file for each incoming file for logging exception for that file. I have used the below code for that. Problem i am facing is for 1st file it creates log file and logging exception. When second file file comes, it create separate log file and logs the 2nd file's exception and meantime it logs the 2nd file's exception along with first file's exception in first file's log file. I do not want like 2nd file's exception to be append in 1st file's log file. How to do that?
private Appender myAppender;
private Logger logger = Logger.getLogger(ConfigFileReader.class.getName());
//filename is dynamic based on the incoming file
myAppender = new FileAppender(new AppXMLLayout(),filename+".log",true);
logger.addAppender(myAppender);

When you add the appender for new file you need to remove the appender for the earlier file using removeAppender. In short once your processing of first file finishes remove the appender.