At the entrance to the main content is: from ch. Qos. Logback. Core. Rolling. The RollingFileAppender# subAppend method to check the source code, there are two core content: 1.ch.qos.logback.core.rolling.TriggeringPolicy#isTriggeringEvent2.ch.qos.logback.core.rolling.TimeBasedRollingPolicy#rol lover

For example, we now have the following logback.xml configuration. Log files are split and gz-compressed hourly based on time. So how does it work?

If you want to analyze how this works, first open the RollingFileAppender class, go to the entry, and look at the 200 + lines of this class at a glance to find the core method, as follows

As can be seen, isTriggeringEvent will be judged when appending the file. If true, rollover will be executed. Otherwise, file content will be appended directly.

isTriggeringEvent

The timeBasedFileNamingAndTriggeringPolicy here is an interface, in the start method of TimeBasedRollingPolicy classes, judgment, if is empty, Assignment as DefaultTimeBasedFileNamingAndTriggeringPolicy

Well, then!

See ch. Qos. Logback. Core. Rolling. The DefaultTimeBasedFileNamingAndTriggeringPolicy# isTriggeringEvent

nextCheck

Chase code (see the statement and references), will eventually to ch. The qos. Logback. Core. Rolling. The helper. RollingCalendar# innerGetEndOfNextNthPeriod

The logic here is that the time is incremented according to periodicityType, so how is this value assigned? Following the code to see the call to this method, there are two calls, one where we just clicked in, and following the code up the other leads to the computePeriodicityType method, which evaluates the periodicityType value.

computePeriodicityType

This one is interesting. Why is that? In the configuration file, there is only one time format, so how to calculate the period type, if it is implemented by yourself, how to implement this function? Let’s look at how logback is implemented.

The core logic is that if the date format configured in XML is empty, an error is returned; Will not empty, according to the unit of time since the childhood to judge (milliseconds – > seconds – > – > hour – – > – > > day week month), according to the format the date set in XML format, take a current time, again the time units according to the current traversal, plus 1, determine whether two dates are equal, if not equal, it returns the current traversal time units.

PS: 1. Ch. Qos. Logback. Core. Rolling. The TimeBasedFileNamingAndTriggeringPolicyBase# will set values in the start, here not spread; 2. If the trigger condition is met, the system calculates the next trigger time and the underlying logic is the same

Pay attention to

Rollover is event-driven rather than time-driven. If the rollover is configured on a daily basis, the segmentation may not be triggered at 00:00. The segmentation can be determined only when logs are generated. In summary, late but late.

rollover

ch.qos.logback.core.rolling.RollingFileAppender#rollover

As you can see, ReentrantLock implements control thread synchronization logic to ensure that only one is ready to perform the Rollover operation. 1. Close the stream; 2.rollover; 3. Open a new log file. Here we focus on Rollover’s logic. ch.qos.logback.core.rolling.TimeBasedRollingPolicy#rollover

RenameRawAndAsyncCompress method finally will call to compressor. The asyncCompress

As you can see,CompressionRunnableTo achieve theRunnableScheduledExecutorService is a thread pool that can perform repeated or delayed tasks and then perform compression.

1. Thread pool; 2. ScheduledExecutorService and timer

compress

Since the background has been confirmed at the beginning, using GZ compression, so focus on the logic of GZ compression. ch.qos.logback.core.rolling.helper.Compressor#gzCompress

That’s all the core logic is. Callrt.jarIn theGZIPOutputStreamTo compress. No more.

other

Other implementations are also available. Logback is only responsible for date output and split, and Linux crontab periodically executes tar or zip.

reference

Logback official website – TimeBasedRollingPolicy