- logback-user - mailman3.qos.ch

MS Queue Appender
by Kathariya, Sudhik (Allianz Life Insurance Company of N) 26 Sep '18

26 Sep '18

Description I'm using JMS Queue Appender of logback and seems like I'm getting below error after the first log is sent to queue. MQJCA1021: The message producer is closed. Thanks n Regards, Sudhik Kathariya ________________________________ CONFIDENTIALITY NOTICE: The information in this message, and any files transmitted with it, is confidential, may be legally privileged, and intended only for the use of the individual(s) named above. Be aware that the use of any confidential or personal information may be restricted by state and federal privacy laws. If you are not the intended recipient, do not further disseminate this message. If this message was received in error, please notify the sender and delete it.

1 0

Logback not rolling
by nicofari 14 Sep '18

14 Sep '18

Hi all Sorry I know it's an already asked question, but I can't figure out how to configure logback to solve the problem. Here is my config: tomcat 7 under windows server 2012 logback 1.1.7 slf4j 1.7.21 java 7 logback.xml: <?xml version="1.0" encoding="UTF-8"?> <configuration scan="true" scanPeriod="10 seconds" debug="true"> <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <file>logs\logback.log</file> <rollingPolicy class="ch.qos.logback.core.rolling.FixedWindowRollingPolicy"> <fileNamePattern>logs\logback.%i.log</fileNamePattern> <minIndex>1</minIndex> <maxIndex>20</maxIndex> </rollingPolicy> <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"> <maxFileSize>10MB</maxFileSize> </triggeringPolicy> <encoder> <charset>UTF-8</charset> <pattern>%date [%thread] %-5level %logger - %msg%n</pattern> </encoder> </appender> <logger name="it.infoline" level="WARN" /> <logger name="org.flywaydb" level="OFF" /> <logger name="it.infoline.ouverture.data.LogonDatabase" level="DEBUG" /> <root level="WARN"> <appender-ref ref="FILE" /> </root> </configuration> Enabling logback debug I've seen that the root cause is the renaming: 16:05:55,728 |-INFO in c.q.l.co.rolling.helper.RenameUtil - Renaming file [logs\logback.log] to [logs\logback.1.log] 16:05:55,728 |-WARN in c.q.l.co.rolling.helper.RenameUtil - Failed to rename file [logs\logback.log] as [logs\logback.1.log]. 16:05:55,729 |-WARN in c.q.l.co.rolling.helper.RenameUtil - Please consider leaving the [file] option of RollingFileAppender empty. 16:05:55,729 |-WARN in c.q.l.co.rolling.helper.RenameUtil - See also http://logback.qos.ch/codes.html#renamingError The solution in the link (http://logback.qos.ch/codes.html#renamingError) doesn't work with FixedWindowRollingPolicy if I understand well, right ? So I tried something like this: <appender name="FILE" class="ch.qos.logback.core.rolling.RollingFileAppender"> <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy"> <fileNamePattern>C:\Infoline\WebAppConfig\log.%d{yyyy-MM-dd}.log</fileNamePattern> <maxHistory>30</maxHistory> <totalSizeCap>3GB</totalSizeCap> </rollingPolicy> <triggeringPolicy class="ch.qos.logback.core.rolling.SizeBasedTriggeringPolicy"> <maxFileSize>1KB</maxFileSize> </triggeringPolicy> <encoder> <charset>UTF-8</charset> <pattern>${HOSTNAME} %date [%thread] %-5level %logger >%X{ILSID}< - %msg%n</pattern> </encoder> </appender> With this configuration I didn't understand where the log will go. Without file option, how can I tell logback which file to use? Sorry for the trivial question but it seems I can't find a solution myself thanks in advance Nicola -- Sent from: http://logback.10977.n7.nabble.com/Users-f3.html

1 0

Re: [logback-user] Logback 1.2.3 threads getting deadlocked
by Debraj Manna 13 Sep '18

13 Sep '18

Filed https://jira.qos.ch/browse/LOGBACK-1421 On Wed, Sep 12, 2018 at 10:44 PM ceki <ceki(a)qos.ch> wrote: > Hi Debraj, > > Can you please create a JiRA issue for the deadlock you describe? > -- > Ceki Gülcü > > > > Sent from my Samsung Galaxy smartphone. > -------- Original message -------- > From: Debraj Manna <subharaj.manna(a)gmail.com> > Date: 9/12/2018 18:21 (GMT+01:00) > To: logback-user(a)qos.ch > Subject: [logback-user] Logback 1.2.3 threads getting deadlocked > > I am observing logback 1.2.3 getting stuck with stacktrace like below . In > case the email gets truncated I am also placing the above logs in the below > gist > <https://gist.github.com/debraj-manna/d3b8de557ae3514368ab66b947d0ed14> . > > https://gist.github.com/debraj-manna/d3b8de557ae3514368ab66b947d0ed14 > > I am using java 8 > > Schedule_CISCON9K_10.22.8.7_config_OpMgr-0" #874742 prio=5 os_prio=0 > tid=0x00007fff54789000 nid=0x31f0 waiting for monitor entry > [0x00007fff0e323000] > java.lang.Thread.State: BLOCKED (on object monitor) > at > ch.qos.logback.core.util.CachingDateFormatter.format(CachingDateFormatter.java:45) > - waiting to lock <0x00000006488ca358> (a > ch.qos.logback.core.util.CachingDateFormatter) > at > ch.qos.logback.classic.pattern.DateConverter.convert(DateConverter.java:61) > at > ch.qos.logback.classic.pattern.DateConverter.convert(DateConverter.java:23) > at > ch.qos.logback.core.pattern.FormattingConverter.write(FormattingConverter.java:36) > at > ch.qos.logback.core.pattern.PatternLayoutBase.writeLoopOnConverters(PatternLayoutBase.java:115) > at > ch.qos.logback.classic.PatternLayout.doLayout(PatternLayout.java:141) > at > ch.qos.logback.classic.PatternLayout.doLayout(PatternLayout.java:39) > at > ch.qos.logback.core.encoder.LayoutWrappingEncoder.encode(LayoutWrappingEncoder.java:115) > at > ch.qos.logback.core.OutputStreamAppender.subAppend(OutputStreamAppender.java:230) > at > ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:102) > at > ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:84) > at > ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:51) > at > ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270) > at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257) > at > ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:421) > at > ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:383) > at ch.qos.logback.classic.Logger.info(Logger.java:579) > at > com.van.dataproviders.core.impl.cas.n5k.tasks.N5KSynchronousTask.doRun(N5KSynchronousTask.java:63) > at > com.van.dataproviders.core.common.impl.dataprovider.tasks.AbstractTask.run(AbstractTask.java:104) > at > com.van.dataproviders.tasker.Tasker$ScheduledTaskWrapper.run(Tasker.java:359) > at > com.google.common.util.concurrent.MoreExecutors$ScheduledListeningDecorator$NeverSuccessfulListenableFutureTask.run(MoreExecutors.java:678) > at > java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) > at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) > at > java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) > > Most thread trying to write to log are blocked on a `synchronize(this)` > lock in `CachingDateFormatter` of logback. > But another thread, which actually has the above lock (thus blocking the > other threads) is itself blocked as follows: > > "Schedule_CISCON9K_10.22.8.149_metric_OpMgr-0" #871618 prio=5 os_prio=0 > tid=0x00007fff54740800 nid=0x7e56 waiting for monitor entry > [0x00007fff15f1a000] > java.lang.Thread.State: BLOCKED (on object monitor) > at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1333) > at java.util.ResourceBundle.getBundle(ResourceBundle.java:899) > at sun.util.resources.LocaleData$1.run(LocaleData.java:167) > at sun.util.resources.LocaleData$1.run(LocaleData.java:163) > at java.security.AccessController.doPrivileged(Native Method) > at sun.util.resources.LocaleData.getBundle(LocaleData.java:163) > at sun.util.resources.LocaleData.getDateFormatData(LocaleData.java:127) > at > java.text.DateFormatSymbols.initializeData(DateFormatSymbols.java:710) > at java.text.DateFormatSymbols.<init>(DateFormatSymbols.java:145) > at > sun.util.locale.provider.DateFormatSymbolsProviderImpl.getInstance(DateFormatSymbolsProviderImpl.java:85) > at > java.text.DateFormatSymbols.getProviderInstance(DateFormatSymbols.java:364) > at java.text.DateFormatSymbols.getInstance(DateFormatSymbols.java:340) > at java.util.Calendar.getDisplayName(Calendar.java:2110) > at java.text.SimpleDateFormat.subFormat(SimpleDateFormat.java:1125) > at java.text.SimpleDateFormat.format(SimpleDateFormat.java:966) > at java.text.SimpleDateFormat.format(SimpleDateFormat.java:936) > at java.text.DateFormat.format(DateFormat.java:345) > at > ch.qos.logback.core.util.CachingDateFormatter.format(CachingDateFormatter.java:48) > - locked <0x00000006488ca358> (a > ch.qos.logback.core.util.CachingDateFormatter) > at > ch.qos.logback.classic.pattern.DateConverter.convert(DateConverter.java:61) > > Loback.xml > <configuration scan="true" debug="true"> > <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender"> > <Target>System.out</Target> > <encoder> > <pattern>%p [%d{yyyy-MM-dd HH:mm:ss,SSS}] %c{3}:[%C{1}:%M:%L] > - [%t] - %replace(%.-20480m){'[^A-Za-z0-9=<>:@ > /.,"\'\-\[\]\{\}\n\s!|]','_'}%n</pattern> > </encoder> > </appender> > > <root level="INFO"> > <appender-ref ref="CONSOLE"/> > </root> > </configuration> >

1 1

Logback 1.2.3 threads getting deadlocked
by Debraj Manna 12 Sep '18

12 Sep '18

I am observing logback 1.2.3 getting stuck with stacktrace like below . In case the email gets truncated I am also placing the above logs in the below gist <https://gist.github.com/debraj-manna/d3b8de557ae3514368ab66b947d0ed14> . https://gist.github.com/debraj-manna/d3b8de557ae3514368ab66b947d0ed14 I am using java 8 Schedule_CISCON9K_10.22.8.7_config_OpMgr-0" #874742 prio=5 os_prio=0 tid=0x00007fff54789000 nid=0x31f0 waiting for monitor entry [0x00007fff0e323000] java.lang.Thread.State: BLOCKED (on object monitor) at ch.qos.logback.core.util.CachingDateFormatter.format(CachingDateFormatter.java:45) - waiting to lock <0x00000006488ca358> (a ch.qos.logback.core.util.CachingDateFormatter) at ch.qos.logback.classic.pattern.DateConverter.convert(DateConverter.java:61) at ch.qos.logback.classic.pattern.DateConverter.convert(DateConverter.java:23) at ch.qos.logback.core.pattern.FormattingConverter.write(FormattingConverter.java:36) at ch.qos.logback.core.pattern.PatternLayoutBase.writeLoopOnConverters(PatternLayoutBase.java:115) at ch.qos.logback.classic.PatternLayout.doLayout(PatternLayout.java:141) at ch.qos.logback.classic.PatternLayout.doLayout(PatternLayout.java:39) at ch.qos.logback.core.encoder.LayoutWrappingEncoder.encode(LayoutWrappingEncoder.java:115) at ch.qos.logback.core.OutputStreamAppender.subAppend(OutputStreamAppender.java:230) at ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:102) at ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:84) at ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:51) at ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270) at ch.qos.logback.classic.Logger.callAppenders(Logger.java:257) at ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:421) at ch.qos.logback.classic.Logger.filterAndLog_0_Or3Plus(Logger.java:383) at ch.qos.logback.classic.Logger.info(Logger.java:579) at com.van.dataproviders.core.impl.cas.n5k.tasks.N5KSynchronousTask.doRun(N5KSynchronousTask.java:63) at com.van.dataproviders.core.common.impl.dataprovider.tasks.AbstractTask.run(AbstractTask.java:104) at com.van.dataproviders.tasker.Tasker$ScheduledTaskWrapper.run(Tasker.java:359) at com.google.common.util.concurrent.MoreExecutors$ScheduledListeningDecorator$NeverSuccessfulListenableFutureTask.run(MoreExecutors.java:678) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) Most thread trying to write to log are blocked on a `synchronize(this)` lock in `CachingDateFormatter` of logback. But another thread, which actually has the above lock (thus blocking the other threads) is itself blocked as follows: "Schedule_CISCON9K_10.22.8.149_metric_OpMgr-0" #871618 prio=5 os_prio=0 tid=0x00007fff54740800 nid=0x7e56 waiting for monitor entry [0x00007fff15f1a000] java.lang.Thread.State: BLOCKED (on object monitor) at java.util.ResourceBundle.getBundleImpl(ResourceBundle.java:1333) at java.util.ResourceBundle.getBundle(ResourceBundle.java:899) at sun.util.resources.LocaleData$1.run(LocaleData.java:167) at sun.util.resources.LocaleData$1.run(LocaleData.java:163) at java.security.AccessController.doPrivileged(Native Method) at sun.util.resources.LocaleData.getBundle(LocaleData.java:163) at sun.util.resources.LocaleData.getDateFormatData(LocaleData.java:127) at java.text.DateFormatSymbols.initializeData(DateFormatSymbols.java:710) at java.text.DateFormatSymbols.<init>(DateFormatSymbols.java:145) at sun.util.locale.provider.DateFormatSymbolsProviderImpl.getInstance(DateFormatSymbolsProviderImpl.java:85) at java.text.DateFormatSymbols.getProviderInstance(DateFormatSymbols.java:364) at java.text.DateFormatSymbols.getInstance(DateFormatSymbols.java:340) at java.util.Calendar.getDisplayName(Calendar.java:2110) at java.text.SimpleDateFormat.subFormat(SimpleDateFormat.java:1125) at java.text.SimpleDateFormat.format(SimpleDateFormat.java:966) at java.text.SimpleDateFormat.format(SimpleDateFormat.java:936) at java.text.DateFormat.format(DateFormat.java:345) at ch.qos.logback.core.util.CachingDateFormatter.format(CachingDateFormatter.java:48) - locked <0x00000006488ca358> (a ch.qos.logback.core.util.CachingDateFormatter) at ch.qos.logback.classic.pattern.DateConverter.convert(DateConverter.java:61) Loback.xml <configuration scan="true" debug="true"> <appender name="CONSOLE" class="ch.qos.logback.core.ConsoleAppender"> <Target>System.out</Target> <encoder> <pattern>%p [%d{yyyy-MM-dd HH:mm:ss,SSS}] %c{3}:[%C{1}:%M:%L] - [%t] - %replace(%.-20480m){'[^A-Za-z0-9=<>:@ /.,"\'\-\[\]\{\}\n\s!|]','_'}%n</pattern> </encoder> </appender> <root level="INFO"> <appender-ref ref="CONSOLE"/> </root> </configuration>

1 0

Deadlocks with logback /RollingFileAppender
by Manoj Khangaonkar 11 Sep '18

11 Sep '18

Hi, This has posted by many other in the past as is evident from google search. LOGBACK-891 is a one open JIRA that points to this issue. Under heavy load, a multi threaded Java service deadlocks and hangs. And all there threads are blocked in LOG.info calls. One log call seems to hold a lock. Every other log call is waiting on that lock. I have posted a stack snippet from my thread dump on LOGBACK-891 Is anybody who encountered this issue still on the mailing list ? If so, are there any suggestions or work arounds. Are there any best practices for using logback Loggers in a multithreaded program. Committers, Most prior jira or discussions - seem to end with "This cannot happen. We need a test case ". Is that still the status of this issue ? The issue is real and I could try to produce a test case that mirrors my case. But just so as to not reinvent the wheel, if any learning or fixes came out of prior reports of deadlocks, can you please share them. regards

1 0

Logback file is empty
by Charalambides, Chryssanthi 22 Aug '18

22 Aug '18

Hello all, I am trying to figure out why logback is not writing to a file. It creates the file okay, but it is not writing anything to it. I have the following programmatic configuration in my java code. This just reads a properties file and sets system properties out of the logback values so they can be read from the configuration.xml file. It also configures the logger from logback_configuration.xml instead of the default logback.xml private static void initLogback() { Map<String,String> logbackProperties = new HashMap<>(); PropertyDeluxe properties = RenoProperties.getProperties(); for (String key : properties.getKeys()) if (key.startsWith(RenoProperties.LOGBACK_PROPERTY_PREFIX)) logbackProperties.put(key,properties.getString(key)); //set system properties out of the logback values so we can reference them from the configuration file for (String key : logbackProperties.keySet()) System.setProperty(key,logbackProperties.get(key)); //configure the logger from the logback_configuration.xml. Default is logback.xml LoggerContext lc = new LoggerContext(); try { JoranConfigurator configurator = new JoranConfigurator(); configurator.setContext(lc); lc.reset(); configurator.doConfigure(properties.getString(RenoProperties.LOGBACK_CONFIG_FILE_PROPERTY)); } catch (JoranException je) { je.printStackTrace(); } StatusPrinter.printInCaseOfErrorsOrWarnings(lc); } Here are the values defined in the property file. Where base.dir is passed in through the command line as "@@base.dir=C:/project_work/reno" @@scenario.dir = base.dir/scenarios/scenario.name @@_outputs.dir = scenario.dir/outputs logback.config.file = base.dir/resource/code/java/logback_configuration.xml logback.file.main = _outputs.dir/logs/java_main.log logback.level = info And here is the logback_configuration.xml <configuration scan="true" debug="true"> <appender name="FILE" class="ch.qos.logback.core.FileAppender"> <file>${logback.file.main}</file> <append>true</append>  <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"> <Pattern> %d{HH:mm:ss} [%-30.-30thread] %-5level %-25.25logger{25} - %msg%n </Pattern> </encoder> </appender> <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"> <pattern> %d{HH:mm:ss} %green([%-5.-5thread]) %-5level %-25.25logger{25} - %msg%n </pattern> </encoder> </appender> <root level="${logback.level}"> <appender-ref ref="FILE" /> <appender-ref ref="STDOUT" /> </root> </configuration> I’ve looked everywhere and nothing really stands out. Can anyone see what I’ve missed? Thank you Chryssa

1 0

Lilith 8.2.0 has been released!
by Jörn Huxhorn 09 Aug '18

09 Aug '18

This version of Lilith demands Java 8 update 181 or higher and will says so if you try to start it with an older version. It has also been built and tested with Java 10.0.2. You can still receive event from previous versions so if your application is still running Java 7 or lower just keep using the 0.9.44 artifacts. Keep in mind that Java SE 7 End of Public Updates has already been reached. See http://lilithapp.com/releases/8.2.0.xhtml for details.

1 0

Logback does not change log level in runtime
by Neda Danilovic 03 Aug '18

03 Aug '18

Hello, I use logback for my android app. This is my logback.xml file <configuration debug="true" scan="true" scanPeriod="2 seconds"> <include file="${EXT_DIR}/Download/XXX/assets/logbackincludedfile.xml" /> <root level="${root.level:-DEBUG}"> <appender-ref ref="logcat" /> <appender-ref ref="logstash" /> <appender-ref ref="rollingLogFile" /> </root> logbackincludedfile.xml <included> <property name="root.level" value="DEBUG" /> </included> But it can not change log level in runtime. I have to restart my android app and then it works. What should I do, to make it work in runtime? I use logback-android com.github.tony19:logback-android:1.1.1-12 Regards, Neda -- Neda Danilović

1 0

The MDCPropertyMap has been already set for this event Exception
by Chen Jian 28 Jun '18

28 Jun '18

Hi - I have wrote an appender which use `setMDCPropertyMap` to inject some fields to LoggingEvent. It’s fail to working with other build-in appender (e.g. ch.qos.logback.core.FileAppender) Exception: java.lang.IllegalStateException: The MDCPropertyMap has been already set for this event. Regards, Jian

1 0

Logs going over the limit specified in logback.xml
by Nazila Massoodi 20 Jun '18

20 Jun '18

Hi logback folks, I see one application log goes over the limit specified in logback.xml file intermittently (maxFileSize=300MB, minIndex=1, MaxIndex =10). It happens to the first log and then it stabilizes with sub-sequence files. Has anyone seen this issue before? Any ideas why this happens? Snippet from logback.xml: <appender name="NEW-APPENDER-FOR-JETTY" class="ch.qos.logback.core. rolling.RollingFileAppender"> <file>../log/jetty_ERR_WARN.log</file> <rollingPolicy class="ch.qos.logback.core.rolling. FixedWindowRollingPolicy"> <fileNamePattern>../log/jetty_ERR_WARN_%i.log</fileNamePattern> <minIndex>1</minIndex> <maxIndex>3</maxIndex> </rollingPolicy> <triggeringPolicy class="ch.qos.logback.core.rolling. SizeBasedTriggeringPolicy"> <maxFileSize>200KB</maxFileSize> </triggeringPolicy> <encoder> <pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} %-5level [%thread] %logger{36} - %msg%n</pattern> </encoder> </appender> <logger name="org.eclipse.jetty" additivity="false">  <level value="WARN" />  <appender-ref ref="NEW-APPENDER-FOR-JETTY"/> </logger> Thanks, Nazila

1 0