Hi Mayuran,

The logic controlling this is in ch.qos.logback.core.sift.AppenderTracker I 
seem to remember I’ve had problems with this in the past, but I don’t remember 
the details now.  It’s controlled by a timeout.  Maybe there should be an 
explicit way to trigger the closing of an appender controlled by the sifting 
logic.

David

> On 17 May 2015, at 09:44, mayuran satchithanantham <[email protected]> 
> wrote:
> 
> Hi logback geeks,
> 
> We are using logback "SiftingAppender" for generating the log files based on 
> the date and other information such as cycle(Each date can have multiple 
> cycles).
> 
> Following are the sample logging file names
> 
> 20150515_1_Job1.log
> 20150515_2_Job1.log
> 
> For the above scenario we are using the following logback configuration.
> 
> <appender name="BATCH_LOGGER_APPENDER" 
> class="ch.qos.logback.classic.sift.SiftingAppender">
>     <discriminator>
>         <key>batchLoggerFileName</key>
>         <defaultValue>unknown</defaultValue>
>     </discriminator>
>     <sift>
>         <appender class="ch.qos.logback.core.FileAppender">
>             <file>${batchlog.dir}/${batchLoggerFileName}.log</file>
>             <layout class="ch.qos.logback.classic.PatternLayout">
>                 <pattern>%d{yyyy-MM-dd_HH:mm:ss.SSS} | %-5level | [%thread] | 
> %msg%n%rEx</pattern>
>             </layout>
>         </appender>
>     </sift>
> </appender>
> 
> <logger name="BATCH_LOGGER" level="INFO" additivity="false">
>     <appender-ref ref="BATCH_LOGGER_APPENDER"></appender-ref>
> </logger>
> 
> Following is the java code for logging the details to the specific logs files.
> 
> private static final Logger BATCH_LOGGER = LoggerFactory
>         .getLogger("BATCH_LOGGER");
> 
> public void info(JobInfo jobInfo, String message) {
>     MDC.put("batchLoggerFileName", jobInfo.getJobId());
>     BATCH_LOGGER.info(message);
>     MDC.remove("batchLoggerFileName");
> }
> 
> We have some other jobs that do the housekeeping of the old log files with 
> the retention of 2 days(Two day old files will be moved to another location).
> 
> But even after the job completes, we are not able to move the file. We 
> suspect that logback is holding the resource and not letting the file to move 
> or delete.
> 
> All the jobs are deployed in a single war file in apache tomcat 8 server.
> 
> Can anyone suggest how to enforce logback to release the resource after 
> logging is completed?
> 
> Regards,
> Mayuran
> _______________________________________________
> Logback-user mailing list
> [email protected]
> http://mailman.qos.ch/mailman/listinfo/logback-user

_______________________________________________
Logback-user mailing list
[email protected]
http://mailman.qos.ch/mailman/listinfo/logback-user

Reply via email to