September 2018 - logback-user

Logback => TLS/SSL => Syslog ?
by Otis Gospodnetić 21 Feb '19

21 Feb '19

Hi, Does Logback support sending logs to Syslog servers via TLS/SSL? I have a feeling Logback doesn't have a SyslogAppender that can send data using TLS. I say that because I don't see a mention of "syslog" on http://logback.qos.ch/manual/usingSSL.html and I see http://jira.qos.ch/browse/LOGBACK-890 that mentions TLSSyslogAppender, but it looks like this never ended up in Logback. I've only found it committed here: https://github.com/balabit/logback/commit/e0d89de2536e0925a6c816a50793f6a74… Could anyone please clarify? Thanks, Otis -- Monitoring * Alerting * Anomaly Detection * Centralized Log Management Solr & Elasticsearch Support * http://sematext.com/

2 1

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