Hello,

I've found an issue related with the class CoreConstants:

 
/**

• Maximum number of threads to allow in a context's executor service.
  */
  // if you need a different MAX_POOL_SIZE, please file create a jira issue
  // asking to make MAX_POOL_SIZE a parameter.
  public static final int MAX_POOL_SIZE = 32;
   
  The size of the pool is causing a problem when using SizeAndTimeBasedRollingPolicy at the end of the day when the number of files in the logger is bigger than 32.

See log details of the issue:

02:00:01,852 |-INFO in c.q.l.co.rolling.helper.RenameUtil - Renaming file [/.../DEMO_LP3/USDAED.log] to [/.../DEMO_LP3/USDAED.2023-05-11.0.log2522180056964847.tmp] 02:00:01,852 |-ERROR in 
SizeAndTimeBasedFNATP [FILE-SIFT] - Appender [FILE-SIFT] failed to append. java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@398bae3b[Not completed, task = java.util.concurrent.Executors$RunnableAdapter@198af505[Wrapped task = ch.qos.logback.core.rolling.helper.Compressor$CompressionRunnable@3d7e666b]] rejected from java.util.concurrent.ThreadPoolExecutor@296f8602[Running, pool size = 32, active threads = 32, queued tasks = 0, completed tasks = 91]     at java.util.concurrent.RejectedExecutionException: Task java.util.concurrent.FutureTask@398bae3b[Not completed, task = java.util.concurrent.Executors$RunnableAdapter@198af505[Wrapped task = ch.qos.logback.core.rolling.helper.Compressor$CompressionRunnable@3d7e666b]] rejected from java.util.concurrent.ThreadPoolExecutor@296f8602[Running, pool size = 32, active threads = 32, queued tasks = 0, completed tasks = 91]     at     at java.base/java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:2065)     at     at java.base/java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:833)     at     at java.base/java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1365)     at     at java.base/java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:123)     at     at ch.qos.logback.core.rolling.helper.Compressor.asyncCompress(Compressor.java:229)     at     at ch.qos.logback.core.rolling.TimeBasedRollingPolicy.renameRawAndAsyncCompress(TimeBasedRollingPolicy.java:196)     at     at ch.qos.logback.core.rolling.TimeBasedRollingPolicy.rollover(TimeBasedRollingPolicy.java:182)     at     at ch.qos.logback.core.rolling.RollingFileAppender.attemptRollover(RollingFileAppender.java:220)     at     at ch.qos.logback.core.rolling.RollingFileAppender.rollover(RollingFileAppender.java:198)     at     at ch.qos.logback.core.rolling.RollingFileAppender.subAppend(RollingFileAppender.java:246)     at     at ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:102)     at     at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:85)     at     at ch.qos.logback.core.sift.SiftingAppenderBase.append(SiftingAppenderBase.java:122)     at     at ch.qos.logback.core.AppenderBase.doAppend(AppenderBase.java:83)     at     at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachab

The issue leaves a tmp file in the disk.
 
In order to reproduce it is just required having more than 32 files to roll with a reasonable size, if the queue of the thread pool is full then it will fail.
 
 
It would be very interesting having the possibility of defining the number of threads by configuration. I know the case I'm working on is very special, it is not comming having so many files rolling at the end of the day for the logger.
Thank you very much.