feature:support random delayed compression

[OpenZYK]

At 0 o 'clock every day, a large number of machines begin to compress the log files of the previous day, resulting in the sharp rise of the disk IO of the container, which brings risk to the stability of the cloud disk. Now, the compression random delay x seconds is introduced to reduce the concentration of the compression trigger time and reduce the pressure on the disk.

        <RollingFile name="RollingFile" 
                    fileName="logs/app.log" 
                    filePattern="logs/app-%d{MM-dd-yyyy}-%i.log.gz">
           <PatternLayout>
               <Pattern>%d %p %c{1.} [%t] %m%n</Pattern>
           </PatternLayout>
           <Policies>
               <TimeBasedTriggeringPolicy interval="1" modulate="true"/>
               <SizeBasedTriggeringPolicy size="10 MB"/>
           </Policies>
           <!-- deferred compression 1s~30s -->
           <DefaultRolloverStrategy max="10" delayedCompressionSeconds="30"/>
       </RollingFile>

[github-actions]

Job	Requested goals	Build Tool Version	Build Outcome	Build Scan®
build-macos-latest	clean install	3.9.8	❌
build-ubuntu-latest	clean install	3.9.8	❌
build-windows-latest	clean install	3.9.8	❌

Generated by gradle/develocity-actions

[Mrkell76]

@

[vy]

@OpenZYK, I think the suggested feature sounds legitimate. I've skimmed through the changes, and dropped some remarks. Would you also mind providing a test and a changelog entry, please?

[vy]

Suggested change

	* Wrapper action that schedules compression for defferred execution.
	* This action wraps another action and schedules it to be executed
	* after a random defer within a specified time window.
	* Decorates an {@link Action} to execute it after a certain amount of delay.

[vy]

Suggested change

	* Creates a new DelayedCompressionAction.
	* Creates a new instance.

[vy]

Suggested change

	* @param originalAction the action to be executed with defer
	* @param originalAction the action to be executed with delay

[vy]

I think your earlier attempt, DelayedCompressionAction, fits the bill better. AFAICT, deferred waits for a condition, which does not necessarily needs to be a time, whereas delay makes it clear the involvement of time.

Once you implement this change, please update all the usages of [Dd]efer in this PR.

[vy]

Suggested change

	/**
	* Executes the action with a defer using sleep.
	*
	* @return true if the action was successfully executed
	* @throws IOException if an error occurs during execution
	*/

[vy]

What about complete == true?

[vy]

Question: Shouldn't we be receiving a range instead of an upper bound?

[vy]

@OpenZYK, TimeBasedTriggeringPolicy receives a maxRandomDelay configuration attribute — doesn't that precisely address the problem you're describing?

[OpenZYK]

TimeBasedTriggeringPolicy receives a maxRandomDelay configuration attribute — This is a parameter for scrolling files, which may cause the logs of the first day to be written to the files of the next day. Splitting files itself is not very IO expensive, but what I'm addressing here is the impact of compression on disk IO. I will add some tests based on your suggestion

[vy]

Can't we change the default behavior of the TimeBasedTriggeringPolicy.maxRandomDelay configuration attribute such that it will not affect the cut off time? That is, the roll over will happen precisely at the right time, but only the compression will honor the delay? @ppkarwasz, WDYT?

[ppkarwasz]

@vy,

I think delaying when a rollover is triggered and delaying when the asynchronous rollover actions execute should have separate configuration knobs.

The execution of asynchronous actions lives in RollingFileManager, so tying that behavior to an attribute on a specific TriggeringPolicy (or rollover strategy) feels like a layering violation.

For this PR specifically, I believe there’s a simpler and cleaner approach: instead of wrapping actions and sleeping, we could replace the ExecutorService in RollingFileManager with a ScheduledExecutorService and apply the delay at scheduling time.

[OpenZYK]

@ppkarwasz Your suggestion is great! I will follow this idea and add some test cases

[ppkarwasz]

@OpenZYK,

To be clear what I suggested was to start the AsyncAction from RollingFileManager with a delay, not to start delayed actions from within DelayedCompressAction: the rollover process has many inter-dependent actions and it is much simpler to execute them sequentially. If you execute them in parallel, you will encounter many subtle bugs.