I am facing some weird issue in the log4j in my project.
A brief on my project structure is, we have many services where each service is a small java project. All these services write logger statements to one logger file ex eie_odm.log,
While writing to the log file, the general and expected format sample is as the below,
[Info] 2017-10-01 20:00:56,950 - com.abc.xyz.Class SERVICE_NAME1 "Into the main flow".
But rarely the logger is sometimes terminated in between and other service comes and writes its own statement, something like below
[Info] 2017-10-01 20:00:56,950 - com.abc.xy[Info] 2017-10-01 20:01:45,547 - com.abc.xyz.Class SERVICE_NAME2 "Into the main flow".
here the time stamp is for illustration purpose only,
Please help me why this behavior and kindly show the solution to the same.
I'm only moderately familiar with Log4j but in my experience it has always been one log file per process.
If that doesn't work for you I see two possible workarounds:
Log4j supports socket appenders. You could create a logging server that other programs can connect to whose job it is is to act as a traffic cop to make sure only one message gets written to the log file at a time. This might get tricky when a log message has associated data with it such as a stack trace. Two drawbacks I see here is that this log server then becomes a critical point of failure of your collection of various applications, and the log server would need to be smart enough to buffer large amounts of messages when they come in faster than they can be written to disk.
Another approach would be to have each program log to its own log file and then when you want to view the files have a utility that aggregates them together in time-stamp order (note time-stamps are not guaranteed to be unique). This approach somewhat depends on how often a person (or process) needs to view or get access to an aggregated log. This is the more robust solution because each process is only dependent on its own logger and an aggregator could be written to deal with rolling log files which is typical to many installations (though dealing with rolling log files in an aggregator is a bit tricky).
On one project I put a filter between the log statements so that log messages all ended up on a single line. This meant that things like stack traces had their new-lines converted into the two characters "\n" so that a viewer/aggregator didn't need to deal with multi-line messages and converting them back to a multi-line message if needed was trivial.
Either way, one thing I would recommend is to have the time-stamp and class name output before the [INFO] so that the file can easily be sorted.