October 2009 - logback-dev - mailman3.qos.ch

[JIRA] Created: (LBCLASSIC-130) Multiple resource warning is not appropriate for logback-test.xml
by Jon Vincent (JIRA) 20 Oct '10

20 Oct '10

Multiple resource warning is not appropriate for logback-test.xml ----------------------------------------------------------------- Key: LBCLASSIC-130 URL: http://jira.qos.ch/browse/LBCLASSIC-130 Project: logback-classic Issue Type: Improvement Affects Versions: 0.9.14, 0.9.15, 0.9.16 Reporter: Jon Vincent Assignee: Logback dev list Priority: Minor When LBCLASSIC-85 was fixed, it also applied to logback-test.xml. Unfortunately, some IDEs (such as Eclipse) include the test classpath for all modules in a multi-module project -- which means that it's nearly impossible to avoid having multiple logback-test.xml files on the classpath if one project depends on another when running tests in Eclipse. Every test in the project will therefore emit this warning when run from the IDE. Is it possible to have the ContextInitializer only emit this warning for logback.xml, and not logback-test.xml? This would avoid a spurious/unactionable warning for developers using Eclipse. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

5 14

[JIRA] Created: (LBCORE-114) Lifecycle.stop is not called for policy objects
by Anders Wallgren (JIRA) 14 Oct '10

14 Oct '10

Lifecycle.stop is not called for policy objects ----------------------------------------------- Key: LBCORE-114 URL: http://jira.qos.ch/browse/LBCORE-114 Project: logback-core Issue Type: Bug Affects Versions: 0.9.17 Reporter: Anders Wallgren Assignee: Logback dev list TriggeringPolicy implements Lifecycle, and start is called during configuration. However, when the context is shut down, stop is not called. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 1

[JIRA] Created: (LBCORE-117) Supply an appender that collects N events on all levels and dumps them to the output when an ERROR is logged
by Aaron Digulla (JIRA) 04 Oct '10

04 Oct '10

Supply an appender that collects N events on all levels and dumps them to the output when an ERROR is logged ------------------------------------------------------------------------------------------------------------ Key: LBCORE-117 URL: http://jira.qos.ch/browse/LBCORE-117 Project: logback-core Issue Type: New Feature Components: Appender Reporter: Aaron Digulla Assignee: Logback dev list For many applications, it's not necessary to log at the levels DEBUG and TRACE all the time. In fact, we usually only do this to be able to debug ERROR events. It would be great if there was an appender that would only collect a configurable number of events internally until a message of level ERROR or above is logged. At this time, the appender should dump it's internal state to the log and reset the internal state. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 1

[JIRA] Created: (LBGENERAL-28) JMX configurator should be able to use MBeanServers with a domain name
by C Z (JIRA) 09 Apr '10

09 Apr '10

JMX configurator should be able to use MBeanServers with a domain name ---------------------------------------------------------------------- Key: LBGENERAL-28 URL: http://jira.qos.ch/browse/LBGENERAL-28 Project: logback-general Issue Type: New Feature Affects Versions: 0.9.16 Reporter: C Z Assignee: Logback dev list Currently, logback exposes an MBean to provide logging related controls via the inclusion of the following configuration: <jmxConfigurator /> However, this *always* uses the platform mbean server: MBeanServer mbs = ManagementFactory.getPlatformMBeanServer(); (can be found in class JMXConfiguratorAction, line# 54). I think it should be able to provide an option to use an MBeanServer with a specific domain, which is provided in the JMX spec. The code needs to use the following: List servers = MBeanServerFactory.findMBeanServer(agentId); and then use the first one, possibly giving a warning if there are multiple. This is crucial for our use-case, especially because we have separate MBeanServers in our web-app environment, and we need each application to use its own MBeanServer with a specific domain. So, all in all, can we add an attribute of some sort, so that we can do the following: <jmxConfigurator agentid="someMbeanServerId"/> and if this is set, the code uses: MBeanServer mbs = MBeanServerFactory.findMBeanServer(agentId).get(0); and otherwise, it does whatever it used to do. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 2

[JIRA] Created: (LBCORE-95) BurstFilter
by Ceki Gulcu (JIRA) 25 Mar '10

25 Mar '10

BurstFilter ----------- Key: LBCORE-95 URL: http://jira.qos.ch/browse/LBCORE-95 Project: logback-core Issue Type: New Feature Reporter: Ceki Gulcu Assignee: Ceki Gulcu A filter to regulate log message bursts, useful for things like throttling the number of logs sent to an e-mail appender when the database is unavailable. See http://www.qos.ch/pipermail/logback-dev/2009-March/003921.html -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 4

[JIRA] Created: (LBCLASSIC-148) Deadlock with DBAppender
by Mel T. (JIRA) 24 Mar '10

24 Mar '10

Deadlock with DBAppender ------------------------ Key: LBCLASSIC-148 URL: http://jira.qos.ch/browse/LBCLASSIC-148 Project: logback-classic Issue Type: Bug Affects Versions: 0.917 Environment: MacBook Pro 17" Intel Core 2 Duo 2.33 GHz OS X 10.5.7 (9J61) java version "1.6.0_13" slf4j 1.5.8 c3p0 0.9.1.2 Reporter: Mel T. Assignee: Logback dev list A deadlock occurs when running the attached application. For this lock to occur, we need to: - load a configuration other than the default in java app. - not have any default logback.xml in the classpath. - have these jars in the classpath c3p0-0.9.1.2.jar logback-core-0.9.17.jar logback-classic-0.9.17.jar log4j-over-slf4j-1.5.8.jar slf4j-api-1.5.8.jar mysql.jar - Place attached the logback2.xml file in the same package as the attached MainTest class. - adapt the logback2.xml file to your DB schema. (note that you do not need to have the DB tables created for the lock to occur, but the test is more conclusive if you have a valid DB connection and schema.) - Execute this java -cp ".:../c3p0-0.9.1.2.jar:../logback-core-0.9.17.jar:../logback-classic-0.9.17.jar:../log4j-over-slf4j-1.5.8.jar:../slf4j-api-1.5.8.jar:../mysql.jar" MainTest The application should output the logger status and hang. Workaround: - Do not include log4j-over-slf4j in the classpath, - or add a default logback.xml that will be loaded first (just copy and rename logback2.xml in same default package) - or use the attached logback2-works.xml instead of logback2.xml (modify MainTest to load that file instead.) In this last one, the change is that the DB appender is only used in a logger element instead of the root. I did not spend the time to look at the cause of this locking problem as the workarounds allow me to move on. So I hope this really belong in jira, and not a config/usage error on my part. -- Mel T. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

2 11

[JIRA] Created: (LBCORE-97) Starvation on AppenderBase.doAppend
by Joern Huxhorn (JIRA) 23 Mar '10

23 Mar '10

Starvation on AppenderBase.doAppend ----------------------------------- Key: LBCORE-97 URL: http://jira.qos.ch/browse/LBCORE-97 Project: logback-core Issue Type: Bug Components: Appender Affects Versions: 0.9.15 Reporter: Joern Huxhorn Assignee: Logback dev list Priority: Critical Attachments: AppenderBaseLock.patch The problem we are facing here is that several threads are trying to obtain the object monitor of the exact same resource, namely the Appender. The assumption that multiple threads waiting for ownership of a monitor would receive the monitor in the order that they tried to acquire it is simply incorrect. This is documented behavior. See the last paragraph of [1]: "Likewise, no assumptions should be made about the order in which threads are granted ownership of a monitor or the order in which threads wake in response to the notify or notifyAll method. An excellent reference for these topics is Chapter 9, "Threads," in Joshua Bloch's book Effective Java Programming Language Guide. " The documentation of Object.notifyAll() [2] states the following: "[..] The awakened threads will compete in the usual manner with any other threads that might be actively competing to synchronize on this object; for example, the awakened threads enjoy no reliable privilege or disadvantage in being the next thread to lock this object." The documentation in [5] also lists the following as a weak-spot of Built-in Synchronization in J2SE 1.4.x: "No way to alter the semantics of a lock, for example, with respect to reentrancy, read versus write protection, or fairness." In LBCORE-96 Ceki stated the following: "Logback is using the standard synchronization mechanism found in the JDK. You are saying that that mechanism is unsuitable which, truth be told, sounds quite suspicious." Yes, it's unsuitable in this situation because obtaining the object monitor is not guaranteed to be fair. It's not working in a "first come, first serve" manner. I assumed that, too, but it isn't the case. I had the exact same problem in Lilith some time ago because I made exactly this very same wrong assumption. Fairness of object monitor lock acquisition seems to be logical and a "good thing" but it's not specified that way, and for good reasons. Without fairness in place, the VM can optimize the execution of an application much better. A context switch is a costly operation for a CPU so performance is increased significantly if such a switch can be omitted. Concerning a test-case, this would be pretty hardcore to implement since it's 100% implementation dependent. One implementation *may* handle the locking of object monitors fairly while others don't. Therefore I'll try the following first: I assume I could convince you that object monitor acquisition (OMA) is not fair. If we take that for granted the following scenario should show my point: There are 4 Threads (e.g. 4 Threads handling concurrent webapp-requests) that have one single chokepoint, the appender. Since OMA isn't fair, it's possible that only some of those threads can work at all (see [3]). Exactly that is happening right now in our webapp running on a 4-core Solaris on JDK6. My next assumption is that we both agree that this isn't acceptable behavior. Logging should be handled "first come, first served" so that if Thread A is waiting to append an event and Thread B is waiting to append an event subsequently, the actual appending order should be A, then B. This is currently not the case. It *may* be the case but there is no guarantee of it. One could even argue that the logging system is working incorrectly (aside from the starvation problem) because events are appended in a different order than the actual execution of the logger call. The only way to prevent this is the introduction of fairness into the locking process. The way to do this is to use ReentrantLock [4]. >From the ReentrantLock javadoc: "The constructor for this class accepts an optional fairness parameter. When set true, under contention, locks favor granting access to the longest-waiting thread. Otherwise this lock does not guarantee any particular access order. Programs using fair locks accessed by many threads may display lower overall throughput (i.e., are slower; often much slower) than those using the default setting, but have smaller variances in times to obtain locks and guarantee lack of starvation." This is exactly what is absolutely necessary for a logging framework. Logging must *NOT* be able to introduce a starvation problem into a multi-threaded application! And it does exactly that right now. I doubt that the performance will decrease in a significant manner due to the use of a fair ReentrantLock but even if this would be the case it would be necessary anyway. Otherwise, appending simply isn't working correctly. [1] http://java.sun.com/j2se/1.5.0/docs/guide/vm/thread-priorities.html [2] http://java.sun.com/javase/6/docs/api/java/lang/Object.html#notifyAll() [3] http://en.wikipedia.org/wiki/Starvation_(computing) [4] http://java.sun.com/javase/6/docs/api/java/util/concurrent/locks/ReentrantL… [5] http://java.sun.com/developer/technicalArticles/J2SE/concurrency/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

13 75

[JIRA] Created: (LBCORE-93) FlushingPolicy
by Ceki Gulcu (JIRA) 18 Mar '10

18 Mar '10

FlushingPolicy -------------- Key: LBCORE-93 URL: http://jira.qos.ch/browse/LBCORE-93 Project: logback-core Issue Type: New Feature Reporter: Ceki Gulcu Assignee: Logback dev list Let flushing be a settable policy of WriteAppender. Thus, the user would be able to set the FlushingPolicy of a WriterAppender or any derived class which would allow you to flush the underlying output stream according to any criteria available to the shouldFlush() method (see below), including time. Here is the relevant interface: interface FlushingPolicy { booelan shouldFlush(LoggingEvent e); } We could easily imagine a policy flushing on every warning or error in addition to special markers. For example, Marker FLUSH = MarkerFactory.getMarker("FLUSH"); logger.info(FLUSH, "finished serving request {}", request.getId()); -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 1

[JIRA] Created: (LBCORE-113) SMTPAppender should have support for avoiding flooding
by Ceki Gulcu (JIRA) 03 Mar '10

03 Mar '10

SMTPAppender should have support for avoiding flooding ------------------------------------------------------ Key: LBCORE-113 URL: http://jira.qos.ch/browse/LBCORE-113 Project: logback-core Issue Type: New Feature Reporter: Ceki Gulcu Assignee: Logback dev list -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

1 1

[JIRA] Created: (LBCORE-109) FileAppender writing to a shared (networked) file system
by Ceki Gulcu (JIRA) 03 Mar '10

03 Mar '10

FileAppender writing to a shared (networked) file system -------------------------------------------------------- Key: LBCORE-109 URL: http://jira.qos.ch/browse/LBCORE-109 Project: logback-core Issue Type: Bug Affects Versions: 0.9.9, 0.9.10, 0.9.11, 0.9.12, 0.9.13, 0.9.14, 0.9.15 Reporter: Ceki Gulcu Assignee: Logback dev list FileAppender writing to a shared (networked) file system with lost networked connection. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.qos.ch/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

3 7