Tony Trinh | 30 Aug 19:08 2014
Picon

[qos-ch/logback] bcb8f5: Add release note for LOGBACK-875 fix

  Branch: refs/heads/master
  Home:   https://github.com/qos-ch/logback
  Commit: bcb8f5b869e9629f4ce2b39a1aa40227f947cb4a
      https://github.com/qos-ch/logback/commit/bcb8f5b869e9629f4ce2b39a1aa40227f947cb4a
  Author: Tony Trinh <tony19@...>
  Date:   2014-08-30 (Sat, 30 Aug 2014)

  Changed paths:
    M logback-site/src/site/pages/news.html

  Log Message:
  -----------
  Add release note for LOGBACK-875 fix

_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Tony Trinh (JIRA | 30 Aug 19:06 2014
Picon

[JIRA] (LOGBACK-875) Prudent FileAppender is stopped if a thread is ever interrupted prior to a logging call

Tony Trinh resolved LOGBACK-875 as Fixed
Change By: Tony Trinh (30/Aug/14 7:05 PM)
Status: Open Resolved
Fix Version/s: 1.1.3
Resolution: Fixed
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Tony Trinh | 30 Aug 19:01 2014
Picon

[qos-ch/logback] c63a65: Fix for LOGBACK-875

  Branch: refs/heads/master
  Home:   https://github.com/qos-ch/logback
  Commit: c63a656be51da79bc82260a3201c22ef90b1cd66
      https://github.com/qos-ch/logback/commit/c63a656be51da79bc82260a3201c22ef90b1cd66
  Author: Joe Jensen <joe.m.jensen@...>
  Date:   2014-08-12 (Tue, 12 Aug 2014)

  Changed paths:
    M logback-core/src/main/java/ch/qos/logback/core/FileAppender.java
    M logback-core/src/main/java/ch/qos/logback/core/recovery/ResilientOutputStreamBase.java
    A logback-core/src/test/java/ch/qos/logback/core/PrudentFileAppenderInterruptTest.java

  Log Message:
  -----------
  Fix for LOGBACK-875

Prevent logging on an interrupted thread from shutting down prudent file
appenders due to a FileLockInterruptedException

  Commit: 8936c0ba2cb372a75814f1b05474d8790eb9d042
      https://github.com/qos-ch/logback/commit/8936c0ba2cb372a75814f1b05474d8790eb9d042
  Author: Tony Trinh <tony19@...>
  Date:   2014-08-30 (Sat, 30 Aug 2014)

  Changed paths:
    M logback-core/src/main/java/ch/qos/logback/core/FileAppender.java
    M logback-core/src/main/java/ch/qos/logback/core/recovery/ResilientOutputStreamBase.java
    A logback-core/src/test/java/ch/qos/logback/core/PrudentFileAppenderInterruptTest.java

  Log Message:
  -----------
  Merge pull request #218 from nemecec/master

Fix for Prudent FileAppender and thread interruptions (LOGBACK-875)

Compare: https://github.com/qos-ch/logback/compare/edc0fe234078...8936c0ba2cb3
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Tomas Jurak (JIRA | 27 Aug 11:08 2014
Picon

[JIRA] (LOGBACK-1010) Cannot configure Logback autoscan in Wildfly (jboss) 8.1

Issue Type: Bug
Affects Versions: 1.1.2
Assignee: Logback dev list
Attachments: logback.xml, server.log
Components: logback-classic
Created: 27/Aug/14 11:07 AM
Description:

When configuring Logback to autoscan (watch) changes in logback.xml config file, it prints that URL pointing to file is not a file - see server.log ("URL [vfs:/content/maven-showcase.war/WEB-INF/classes/logback.xml] is not of type file")

ReconfigureOnChangeFilter prints "Will scan for changes in [[]] every 1 seconds." It do not see the file, because URL uses vfs: prefix (not file:) as it's Wildfly (jboss) virtual file system.

I've created this part of code that can convert VFS files (URLs) to real file system path (URLs)):

final ConfigurationWatchList configurationWatchList = ConfigurationWatchListUtil.getConfigurationWatchList(loggerContext);
final URL mailURL = configurationWatchList.getMainURL();
final URLConnection conn = mailURL.openConnection();
final VirtualFile vf = (VirtualFile) conn.getContent();
VFSUtils.getPhysicalURL(vf)

It uses jboss maven dependecy:
<dependency>
<groupId>org.jboss</groupId>
<artifactId>jboss-vfs</artifactId>
<version>3.2.6.Final</version>
</dependency>

If I can help anyhow (programming included) let me know.

Tomas

Environment:

Linux, Ubuntu x64, app server Wildfly 8.1, Java 8

Project: logback
Labels: wildfly jboss vfs virtual file system
Priority: Major
Reporter: Tomas Jurak
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Tigran (JIRA | 26 Aug 00:15 2014
Picon

[JIRA] (LOGBACK-1009) java.lang.NoClassDefFoundError when using embedded Jetty

Issue Type: Bug
Affects Versions: 1.1.2
Assignee: Logback dev list
Components: logback-access, logback-core
Created: 26/Aug/14 12:13 AM
Description:

I got exception java.lang.NoClassDefFoundError ch/qos/logback/access/jetty/RequestLogImpl on next code:

RequestLogImpl requestLogImpl = new RequestLogImpl();

Maven is used and logback core and access are listed as compile dependencies. In final jar, library `logback.access` exists.

Environment:

Jetty 9, Linux, Java 7

Project: logback
Labels: logging jetty
Priority: Major
Reporter: Tigran
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Picon

[JIRA] (LOGBACK-643) performance issue

I was also looking at this code because it turns out to be a relatively high CPU consumer in a test:

CPU SAMPLES BEGIN (total = 4077726) Fri Aug 22 18:54:48 2014
rank self accum count trace method
1 59.97% 59.97% 2445241 301175 io.netty.channel.epoll.Native.epollWait
2 26.54% 86.51% 1082218 301216 io.netty.channel.epoll.Native.writevAddresses
3 4.85% 91.36% 197836 301205 java.net.SocketInputStream.socketRead0
4 1.91% 93.26% 77790 301261 io.netty.channel.epoll.Native.readAddress
5 0.49% 93.76% 20139 301591 java.lang.ThreadLocal$ThreadLocalMap.getEntryAfterMiss
6 0.16% 93.92% 6606 301660 ch.qos.logback.classic.LoggerContext.getTurboFilterChainDecision_0_3OrMore

This is a real-time ad bidder handling 20Kqps on a 8-core machine, so almost all CPU goes to low-level networking, partially thanks to JVM overheads with native I/O etc. So if I disregard the top 4 methods (93.26% accum), scaling the remaining application CPU usage (6.74% -> 100%), then the 0.16% absolute CPU used by getTurboFilterChainDecision_0_3OrMore() scales to ~2.4% of all CPU usage from the rest of my app; that seems to be a high overhead for logging decisions (app has lots of logging code, but always using isXxxEnabled() guards except when the log msg is a literal string).

I noticed that the Object[] params is never used by any of the TurboFilters. I guess the params are passed because it's an extension point, somebody may write their own TurboFilter which considers the params, but maybe this could be handled in a different way (e.g., with a marker interface that tells a filter needs to receive the params).

Another inefficiency is that when you have <3 params and the logging decision is ACCEPT, the wrapper Object[] will be created twice: for example, filterAndLog_1() will first invoke getTurboFilterChainDecision_1() which creates this Object[] for invoking getTurboFilterChainDecision(), and later getTurboFilterChainDecision_1() creates its own Object[] wrapper for calling buildLoggingEventAndAppend(). This may not be very important when the event is actually logged (an extra Object[] wrapper is very small overhead compared to the full logging work), but appenders can also decide to not log, in practice I expect this to be a common scenario in apps that configure most of their loggers "open" and use the appenders as an easy on/off switch for the whole firehose.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Darshan (JIRA | 21 Aug 21:25 2014
Picon

[JIRA] (LOGBACK-530) Need to scan included files

Darshan commented on LOGBACK-530

Hi, above link is not working. I am looking for the feature which will auto reload the logback configuration for included file. Is this feature cascaded to higher versions of logback?

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Karl Moore (JIRA | 21 Aug 19:07 2014
Picon

[JIRA] (LOGBACK-890) SyslogAppender improvement with TLS

Karl Moore commented on LOGBACK-890

What happened to the TLS appender, did this get added to an extensions project?

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
KwonNam Son (JIRA | 21 Aug 11:33 2014
Picon

[JIRA] (LOGBACK-1008) ConfigurationDelegate.groovy should check AppenderAttachable not AsyncAppender

Issue Type: Bug
Affects Versions: 1.1.2
Assignee: Logback dev list
Components: logback-classic
Created: 21/Aug/14 11:33 AM
Description:

When you see ConfigurationDelegate.groovy's 136 line,

AppenderDelegate ad = clazz.name == 'ch.qos.logback.classic.AsyncAppender' ? new AsyncAppenderDelegate(appender, appenderList) : new AppenderDelegate(appender);

this line check the class is AsyncAppender.
But there is another async appender like reactor-logback's AsyncAppdener.

So this linke should changed to check if the class implements ch.qos.logback.core.spi.AppenderAttachable.

Because of this, we cannot use reactor-logback with groovy configuration.

Project: logback
Labels: groovy
Priority: Major
Reporter: KwonNam Son
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Alexander Czar (JIRA | 19 Aug 09:58 2014
Picon

[JIRA] (LOGBACK-670) SQL error logging into database after some time

No activity on this one for two years and it looks like a network or other infrastructure problem and not logbacks. As there are no details to investigate further I propose to close the issue.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev
Picon

[JIRA] (LOGBACK-905) SocketAppender is omitting CallerData

I found the other Appender also seems to have to happen to use e.g. %C (class) in a pattern to get the SocketAppender (and consolePlugin ) to be able to include caller data. Like setting includeCallerData on the SocketAppender doesn't trigger the (heavy) data collection involved itself, but having that somewhere else does.

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
_______________________________________________
logback-dev mailing list
logback-dev@...
http://mailman.qos.ch/mailman/listinfo/logback-dev

Gmane