Recently took over a popular old days, a lot of hand magic code and found a significant lack of time to recover log. For log4j unfamiliar, but you can certainly go wrong guess logs and multi-process use the same log4j configuration related. After repeated investigation, which finally stroked clear logic. In this paper, the investigation process of recovery disk.
First, the characterization
Background story:
the project has multiple entry. That gets the message while continuing to run background processes running form, while they are constantly start and exit the process as a normal single task scheduling. In other words, the same project with multiple processes running simultaneously, and use the same log4j configuration.
Hereinafter referred to as a daemon process A, the general process is the process B. A runs continuously in the background, B short execution times.
|<----------------- A ------------------- ...... |<- B ->| |<--- B --->| |<- B ->|
Cause:
operating results and is expected to process B does not match, you need to troubleshoot the problem log positioning of B.
Amazing phenomenon:
1) There are some B log some do not, the law did not appear obvious.
2) Some B log complete, some incomplete.
3) Only the last few hours of B log, the log file is actually written into the B over a period of time will disappear.
4) history log, the vast majority date only a B log, but there are a lot of individual logs.
Second, internal
Each log pointer of A / B, respectively, are opened to append the log file, the file pointer independent of each other, each write back. Resulting in two problems:
Question 1:
due to slow write A, B fast write (business reality), so a B average in each end of the file append, and on a neighboring B, A and B will gradually cover the log until the start scrolling page.
Problem 2:
when switching to the next natural 0:00, tab start rolling, if B is running at this time there is, then A and B each have a pointer.
Reference
https://blog.csdn.net/somechange/article/details/80895507
said.
If A first written, then after two scrolling pages, A to log.yesterday write, and B to log in to write and release the handle after the task is completed and exit. The new B continue to write in the log.
If the B write first, then twice after scrolling page, A to log in to write log.yesterday B to write and release the handle after the task is completed and exit. The new B continue to write in the log.
In any case, the real log.yesterday have been covered.
|
|
day1
|
day2
|
day3
|
Day4
|
day5
|
day6
|
|---|---|---|---|---|---|---|
| Hypothesis |
A first write
|
A first write
|
B to write
|
B to write
|
A first write
|
|
| log |
day1 of A + B
|
day2 of B
|
day3 of B
|
day4 other of A + B
|
day5 other of A + B
|
day6 of B
|
| log.day1 |
|
day2 of A
|
day2 of A
|
day2 of A
|
day2 of A
|
day2 of A
|
| log.day2 |
day3 of A
|
day3 of A
|
day3 of A
|
day3 of A
|
||
| log.day3 |
day4 first B
|
day4 first B
|
day4 first B
|
|||
| log.day4 |
day5 first B
|
day5 first B
|
||||
| log.day5 |
day6 of A
|
Day D (D <= T-2) log only four cases: (T day of the current date)
① record the first D + B 1 day (D + 1 2009 There because B-day span, and the first to write B)
② record of all D + A 1-day (D + 1 2009 There because B-day span, and A written first)
③ records all uncovered B A + D-day (D + 1 day because there is no B-day span, and the D-Day B the first to write)
④ records all of the first non-B D-day (D + 1 day because there is no B-day span, and the D-Day A written first)
In line with the observed phenomenon.
done