May 2015 - logback-user - mailman3.qos.ch

Memory leaks if messages are not being posted with AsyncAppender
by andrey.dayman 31 May '15

31 May '15

Hi. We use async net.logstash.logback.appender.LogstashTcpSocketAppender. It puts messages in buffer and sends them to Logstash occassionally. So if there are connection issues it will accumulate messages, which is expected. But we discovered that messages are huge (33 Mbs each). So we found all this data in ch.qos.logback.classic.spi.LoggingEvent.argumentArray field. We use Cassandra client called Hector, and if there is a connection issue it logs error passing a connection client as an argument. So GC cannot release this client because LoggingEvent has reference. And at this moment we already have formattedMessage, so there is no need to have argumentArray filled anymore as I understand. So the question is: why argumentArray is not being cleared after formatting the message? Is it by design? Please let me know if you know the answer! Thanks in advance! Andrey -- View this message in context: http://logback.10977.n7.nabble.com/Memory-leaks-if-messages-are-not-being-p… Sent from the Users mailing list archive at Nabble.com.

1 0

RollingFileAppender does not move the current log File
by LEROUGE Pierre 29 May '15

29 May '15

Hi everyone, I'm struggling with an weird issue on logback I've settup programaticly a rollingFileAppender like in this stackoverflow thread : Setting Logback Appender path programmatically <http://stackoverflow.com/questions/3803184/setting-logback-appender-path-pr…> But the current log file is not removed so I've got 5 archive Plus the complete log file that is still being populated. and the archives are recalculated at every line written here is the extract of code that instantiates the appender : RollingFileAppender<ILoggingEvent> rfAppender = new RollingFileAppender<>(); rfAppender.setFile(f.getAbsolutePath()); rfAppender.setName(name); rfAppender.setContext(loggerContext); FixedWindowRollingPolicy rollingPolicy = new FixedWindowRollingPolicy(); rollingPolicy.setContext(loggerContext); // rolling policies need to know their parent // it's one of the rare cases, where a sub-component knows about its parent rollingPolicy.setParent(rfAppender); rollingPolicy.setFileNamePattern(f.getAbsolutePath() + ".%i"); rollingPolicy.start(); SizeBasedTriggeringPolicy<ILoggingEvent> triggeringPolicy = new ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy<>(); triggeringPolicy.setMaxFileSize("5MB"); triggeringPolicy.start(); PatternLayoutEncoder encoder = new PatternLayoutEncoder(); encoder.setContext(loggerContext); encoder.setPattern("%d{dd/MM/yyyy HH:mm:ss.SSS} | %-10.10thread | %-20.20logger{0} | %-5level : %msg%n"); encoder.start(); rfAppender.setEncoder(encoder); rfAppender.setRollingPolicy(rollingPolicy); rfAppender.setTriggeringPolicy(triggeringPolicy); rfAppender.start(); logbackLogger.addAppender(rfAppender); the logback version used : ch.qos.logback: logback-classic: 1.1.3 It's running on Windows I really don't know why this happened If anyone have a hint on this behavior? Thank you for your time, Regards, Pierre LEROUGE

1 0

Telnet-Appender
by Max Urech 18 May '15

18 May '15

Hi, I'm looking for a TelnetAppender as it used to exist in Log4j. I saw, that there was a TelnetAppender in Logback version 0.91, but for some reason it doesn't exist in version 1.1.2. Is there no more TelnetAppender, or did I miss something? Greets, Max

3 3

logback SiftingAppender generated log files cannot be deleted untill stop the tomcat server
by mayuran satchithanantham 17 May '15

17 May '15

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

2 4

Modifing MDCPropertyMap of LoggingEvents
by Cemo 17 May '15

17 May '15

I have a layout which is generating JSON from logging events and MDC Context. MDC is great and I want to add parameters to MDC Context conditionally. For example, I would like add request information as JSON into MDC conditionally on Error Level log entries. I am not familiar with Logback internals but gave a try with Logback Filter implementation. I have used: public FilterReply decide(ILoggingEvent event) { // simplified for demo // conditionally I am putting some attributes here Map<String, String> mdcPropertyMap = event.getMDCPropertyMap(); if (event.getLevel().isGreaterOrEqual(Level.ERROR)) { mdcPropertyMap.put("demo", "demo"); } return FilterReply.ACCEPT; } I am expecting mdcPropertyMap to be cleared for each event but it does not. LoggingEvent has a internal CACHED_NULL_MAP map and its modified per touch. private static final Map<String, String> CACHED_NULL_MAP = new HashMap<String, String>(); I could not be sure but it seems a little bid buggy to me. Can someone verify this behaviour? For those who are interested why I am not using MDC.put in a Servlet Filter implementation because I am conditionally adding some attributes. Serialising HttpRequest into JSON is not cheap task but having Http Request information is giving great insights about error. Using Filter is the only way I found to add conditionally attributes so far. What I would like to use is: public FilterReply decide(ILoggingEvent event) { if (event.getLevel().isGreaterOrEqual(Level.WARN)) { MDC.put("demo", "demo"); } return FilterReply.ACCEPT; }

3 3

STUCK threads with Logback
by Kantzer, Chris E 13 May '15

13 May '15

Hello, We are getting some stuck threads in our Prod apps that seem to point to logback as the culprit. It only took a few moments to realize we have been lax with our logging statements and we were logging a huge amount of (unnecessary) lines. We are cutting back significantly the number of logged lines in the hopes that it solves the issue. My question: Is there anything else we should investigate as a possible reason for logback causing stuck threads OTHER than excessive logging? I can post the stack trace if needed. Thanks, Chris Kantzer

3 5