April 2011 - logback-dev - mailman3.qos.ch

[JIRA] Created: (LBCORE-205) SocketAppender is causing a classloader leak
by Joern Huxhorn (JIRA) 13 May '11

13 May '11

SocketAppender is causing a classloader leak -------------------------------------------- Key: LBCORE-205 URL: http://jira.qos.ch/browse/LBCORE-205 Project: logback-core Issue Type: Bug Components: Appender Affects Versions: 0.9.28 Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Maven home: /opt/local/share/java/maven3 Java version: 1.6.0_24, vendor: Apple Inc. Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: en_US, platform encoding: MacRoman OS name: "mac os x", version: "10.6.7", arch: "x86_64", family: "mac" Tomcat 7.0.12 Reporter: Joern Huxhorn Assignee: Logback dev list Priority: Critical A classloader leak is caused by SocketAppender which prevents webapps from being properly undeployed and garbage collected. Steps to reproduce: 1.) Download and start Lilith. A server needs to be running and accepting the connection of the SocketAppender. Otherwise the leak will not happen. 2.) Build the webapp at https://github.com/huxi/lilith/tree/master/sandbox/logback-access-sandbox You can toggle the warning by removing or adding the SocketAppender in logback.xml. 3.) Deploy the webapp on Tomcat 7.0.12. 4.) Produce some events by accessing the webapp. 5.) Undeploy the webapp. 6.) Click on "Find leaks". Clicking on "Find leaks" causes the following message to be emitted: The following web applications were stopped (reloaded, undeployed), but their classes from previous runs are still loaded in memory, thus causing a memory leak (use a profiler to confirm): /lb-access-sandbox Unfortunately, there is no other information in any log file. The above warning message disappears if the logback-classic SocketAppender is removed from the configuration. I stumbled upon this issue while fixing http://sourceforge.net/apps/trac/lilith/ticket/96 -- 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 3

Source Code of Logback Console Plugin where?
by Michael Vorburger 28 Apr '11

28 Apr '11

Hello Logbackers, Is the source code for the Logback Console Plugin on version control somewhere (GitHub?), or only (publicly) available in the ch.qos.logback.eclipse_*.zip downloadable from http://logback.qos.ch/dist/ ? The page says that "Unfortunately, the console plugin is somewhat outdated. It expects logback version 0.9.9. It will be upgraded in the coming weeks.". Assuming that is actually a problem to use it to connect to a runtime with a more recent Logback version (or is it not and would actually work; haven't tried!), we may (!) be able to dedicate a bit of time to help doing something about that - thus the question with which source to start from. Thanks, Michael _______________________ Michael Vorburger http://www.vorburger.ch

1 0

[JIRA] Commented: (LBCORE-4) The insertion of a percent symbol causes the Parser to crash
by Selen Schabenberger (JIRA) 26 Apr '11

26 Apr '11

[ http://jira.qos.ch/browse/LBCORE-4?page=com.atlassian.jira.plugin.system.is… ] Selen Schabenberger commented on LBCORE-4: ------------------------------------------ This issue is still reproducable in release 0.9.21 if the policy (FixedWindowRollingPolicy) is defined programmatically. FileNamePattern class is converting all backslashes to slashes in its contructor; therefore it is not possible to assign a file name pattern with an escaped percent sign. Is it a restriction or a bug? > The insertion of a percent symbol causes the Parser to crash > ------------------------------------------------------------ > > Key: LBCORE-4 > URL: http://jira.qos.ch/browse/LBCORE-4 > Project: logback-core > Issue Type: Bug > Components: Pattern > Affects Versions: unspecified > Environment: Operating System: All > Platform: All > Reporter: Sébastien Pennec > Assignee: Logback dev list > Priority: Blocker > > When inserting the percent char twice, so that it appears in the PatternLayout output, a number format exception is thrown. > It does not prevent from using normally the PatternLayout. > trace: > ERROR in ch.qos.logback.core.joran.spi.Interpreter@131f71a - Exception in Action for tag <layout>8:14 java.lang.NumberFormatException: For input string: "% %" > java.lang.NumberFormatException: For input string: "% %" > at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) > at java.lang.Integer.parseInt(Integer.java:447) > at java.lang.Integer.parseInt(Integer.java:497) > at ch.qos.logback.core.pattern.FormatInfo.valueOf(FormatInfo.java:70) > at ch.qos.logback.core.pattern.parser.Parser.T(Parser.java:84) > at ch.qos.logback.core.pattern.parser.Parser.E(Parser.java:51) > at ch.qos.logback.core.pattern.parser.Parser.Eopt(Parser.java:107) > at ch.qos.logback.core.pattern.parser.Parser.E(Parser.java:55) > at ch.qos.logback.core.pattern.parser.Parser.Eopt(Parser.java:107) > at ch.qos.logback.core.pattern.parser.Parser.E(Parser.java:55) > at ch.qos.logback.core.pattern.parser.Parser.Eopt(Parser.java:107) > at ch.qos.logback.core.pattern.parser.Parser.E(Parser.java:55) > at ch.qos.logback.core.pattern.parser.Parser.Eopt(Parser.java:107) > at ch.qos.logback.core.pattern.parser.Parser.E(Parser.java:55) > at ch.qos.logback.core.pattern.parser.Parser.Eopt(Parser.java:107) > at ch.qos.logback.core.pattern.parser.Parser.E(Parser.java:55) > at ch.qos.logback.core.pattern.parser.Parser.Eopt(Parser.java:107) > at ch.qos.logback.core.pattern.parser.Parser.E(Parser.java:55) > at ch.qos.logback.core.pattern.parser.Parser.Eopt(Parser.java:107) > at ch.qos.logback.core.pattern.parser.Parser.E(Parser.java:55) > at ch.qos.logback.core.pattern.parser.Parser.Eopt(Parser.java:107) > at ch.qos.logback.core.pattern.parser.Parser.E(Parser.java:55) > at ch.qos.logback.core.pattern.parser.Parser.parse(Parser.java:31) > at ch.qos.logback.core.pattern.PatternLayoutBase.start(PatternLayoutBase.java:76) > at ch.qos.logback.core.joran.action.AbstractLayoutAction.end(AbstractLayoutAction.java:75) > at ch.qos.logback.core.joran.spi.Interpreter.callEndAction(Interpreter.java:289) > at ch.qos.logback.core.joran.spi.Interpreter.endElement(Interpreter.java:152) > at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:633) > at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.scanEndElement(XMLNSDocumentScannerImpl.java:719) > at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(XMLDocumentFragmentScannerImpl.java:1685) > at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:368) > at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:834) > at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764) > at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:148) > at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1242) > at javax.xml.parsers.SAXParser.parse(SAXParser.java:375) > at ch.qos.logback.core.joran.JoranConfiguratorBase.doConfigure(JoranConfiguratorBase.java:125) > at ch.qos.logback.core.joran.JoranConfiguratorBase.doConfigure(JoranConfiguratorBase.java:101) > at ch.qos.logback.core.joran.JoranConfiguratorBase.doConfigure(JoranConfiguratorBase.java:84) > at ch.qos.logback.core.joran.JoranConfiguratorBase.doConfigure(JoranConfiguratorBase.java:77) > at mainPackage.ConfigTester.main(ConfigTester.java:21) -- 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 0

[JIRA] Created: (LBCORE-204) The logback-core tests are very, very fragile / not working at all for me.
by Joern Huxhorn (JIRA) 23 Apr '11

23 Apr '11

The logback-core tests are very, very fragile / not working at all for me. -------------------------------------------------------------------------- Key: LBCORE-204 URL: http://jira.qos.ch/browse/LBCORE-204 Project: logback-core Issue Type: Bug Affects Versions: 0.9.29 Environment: Apache Maven 3.0.3 (r1075438; 2011-02-28 18:31:09+0100) Maven home: /opt/local/share/java/maven3 Java version: 1.6.0_24, vendor: Apple Inc. Java home: /System/Library/Java/JavaVirtualMachines/1.6.0.jdk/Contents/Home Default locale: en_US, platform encoding: MacRoman OS name: "mac os x", version: "10.6.7", arch: "x86_64", family: "mac" Reporter: Joern Huxhorn Assignee: Logback dev list I just executed 'mvn clean install' on e4aa27eb1dae6b6278ab139444d769edf1280411 (current master) five times in a row and these are the results: =================================================================================================== Results : Failed tests: smoke(ch.qos.logback.core.FileAppenderResilienceTest) smoke(ch.qos.logback.core.recovery.RecoveryCoordinatorTest) test3Zip(ch.qos.logback.core.rolling.SizeBasedRollingTest) Tests in error: withCompression_FileBlank_NoRestart_2(ch.qos.logback.core.rolling.TimeBasedRolling2Test) getAppenderBoom(ch.qos.logback.core.spi.AppenderAttachableImplLockTest) detachAppenderBoom(ch.qos.logback.core.spi.AppenderAttachableImplLockTest) Tests run: 302, Failures: 3, Errors: 3, Skipped: 2 =================================================================================================== Results : Failed tests: smoke(ch.qos.logback.core.recovery.RecoveryCoordinatorTest) test3Zip(ch.qos.logback.core.rolling.SizeBasedRollingTest) Tests run: 302, Failures: 2, Errors: 0, Skipped: 2 =================================================================================================== Results : Failed tests: test3Zip(ch.qos.logback.core.rolling.SizeBasedRollingTest) Tests run: 302, Failures: 1, Errors: 0, Skipped: 2 =================================================================================================== Results : Failed tests: smoke(ch.qos.logback.core.recovery.RecoveryCoordinatorTest) test3Zip(ch.qos.logback.core.rolling.SizeBasedRollingTest) Tests run: 302, Failures: 2, Errors: 0, Skipped: 2 =================================================================================================== Results : Failed tests: test3Zip(ch.qos.logback.core.rolling.SizeBasedRollingTest) Tests in error: getAppenderBoom(ch.qos.logback.core.spi.AppenderAttachableImplLockTest) Tests run: 302, Failures: 1, Errors: 1, Skipped: 2 =================================================================================================== Our Jenkins server (also Mac OS X 10.6.7) behaves similarly erratic so it's not just some weird problem on my machine. Please let me know how I can help you resolve these problems. On a side note: logback-classic is failing, too, (after I've built logback-core with -DskipTests) but only very rarely. Results : Failed tests: durationOfDisabledLog_NoParameters(ch.qos.logback.classic.LoggerPerfTest) Tests run: 368, Failures: 1, Errors: 0, Skipped: 10 -- 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 0

[GIT] Logback: the generic, reliable, fast and flexible logging framework. branch, master, updated. v_0.9.28-37-ge4aa27e
by git-noreply＠pixie.qos.ch 19 Apr '11

19 Apr '11

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Logback: the generic, reliable, fast and flexible logging framework.". The branch, master has been updated discards b5914a4afe4887e0d22a085ca8435cc0d60e8b07 (commit) discards 6db2f74bec21015ce88c54376e4b4b1c2a5214c8 (commit) This update discarded existing revisions and left the branch pointing at a previous point in the repository history. * -- * -- N (e4aa27eb1dae6b6278ab139444d769edf1280411) \ O -- O -- O (b5914a4afe4887e0d22a085ca8435cc0d60e8b07) The removed revisions are not necessarilly gone - if another reference still refers to them they will stay in the repository. No new revisions were added by this update. Summary of changes: .../logback/core/recovery/RecoveryCoordinator.java | 10 ++-- .../core/recovery/ResilientFileOutputStream.java | 8 +--- .../core/recovery/ResilientOutputStreamBase.java | 40 ++++++++----------- .../core/recovery/ResilientSyslogOutputStream.java | 10 +---- .../core/recovery/RecoveryCoordinatorTest.java | 6 +-- .../core/spi/AppenderAttachableImplLockTest.java | 2 +- logback-site/src/site/resources/logback-2011.ppt | Bin 285696 -> 281600 bytes 7 files changed, 28 insertions(+), 48 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

[GIT] Logback: the generic, reliable, fast and flexible logging framework. branch, master, updated. v_0.9.28-39-gb5914a4
by git-noreply＠pixie.qos.ch 19 Apr '11

19 Apr '11

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "Logback: the generic, reliable, fast and flexible logging framework.". The branch, master has been updated via b5914a4afe4887e0d22a085ca8435cc0d60e8b07 (commit) via 6db2f74bec21015ce88c54376e4b4b1c2a5214c8 (commit) from e4aa27eb1dae6b6278ab139444d769edf1280411 (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- http://git.qos.ch/gitweb/?p=logback.git;a=commit;h=b5914a4afe4887e0d22a085c… http://github.com/ceki/logback/commit/b5914a4afe4887e0d22a085ca8435cc0d60e8… commit b5914a4afe4887e0d22a085ca8435cc0d60e8b07 Merge: 6db2f74 e4aa27e Author: Ceki Gulcu <ceki(a)qos.ch> Date: Tue Apr 19 14:36:09 2011 +0200 Merge branch 'master' of git.qos.ch:/logback http://git.qos.ch/gitweb/?p=logback.git;a=commit;h=6db2f74bec21015ce88c5437… http://github.com/ceki/logback/commit/6db2f74bec21015ce88c54376e4b4b1c2a521… commit 6db2f74bec21015ce88c54376e4b4b1c2a5214c8 Author: Ceki Gulcu <ceki(a)qos.ch> Date: Tue Feb 22 13:53:53 2011 +0100 improved recovery in ResilientOutputStreamBase diff --git a/logback-core/src/main/java/ch/qos/logback/core/recovery/RecoveryCoordinator.java b/logback-core/src/main/java/ch/qos/logback/core/recovery/RecoveryCoordinator.java index 25bfb7b..e879008 100644 --- a/logback-core/src/main/java/ch/qos/logback/core/recovery/RecoveryCoordinator.java +++ b/logback-core/src/main/java/ch/qos/logback/core/recovery/RecoveryCoordinator.java @@ -21,7 +21,7 @@ public class RecoveryCoordinator { private long backOffCoefficient = BACKOFF_COEFFICIENT_MIN; private static long UNSET = -1; - private long currentTime = UNSET; + private long injectedTime = UNSET; long next = System.currentTimeMillis()+getBackoffCoefficient(); public boolean isTooSoon() { @@ -34,13 +34,13 @@ public class RecoveryCoordinator { } } - void setCurrentTime(long forcedTime) { - currentTime = forcedTime; + void injectTime(long injectedTime) { + this.injectedTime = injectedTime; } private long getCurrentTime() { - if(currentTime != UNSET) { - return currentTime; + if(injectedTime != UNSET) { + return injectedTime; } return System.currentTimeMillis(); } diff --git a/logback-core/src/main/java/ch/qos/logback/core/recovery/ResilientFileOutputStream.java b/logback-core/src/main/java/ch/qos/logback/core/recovery/ResilientFileOutputStream.java index 27331e2..9a60570 100644 --- a/logback-core/src/main/java/ch/qos/logback/core/recovery/ResilientFileOutputStream.java +++ b/logback-core/src/main/java/ch/qos/logback/core/recovery/ResilientFileOutputStream.java @@ -28,7 +28,7 @@ public class ResilientFileOutputStream extends ResilientOutputStreamBase { throws FileNotFoundException { this.file = file; this.os = new FileOutputStream(file, append); - this.presumedClean = true; + this.presumedUp = true; } public FileChannel getChannel() { @@ -43,6 +43,12 @@ public class ResilientFileOutputStream extends ResilientOutputStreamBase { return file; } + // A successful WRITE operation confirms recovery + @Override + boolean isRecoveryConfirmingOperation(OpType opType) { + return opType == ResilientOutputStreamBase.OpType.WRITE; + } + @Override String getDescription() { diff --git a/logback-core/src/main/java/ch/qos/logback/core/recovery/ResilientOutputStreamBase.java b/logback-core/src/main/java/ch/qos/logback/core/recovery/ResilientOutputStreamBase.java index 8cb9b6d..8d7be5b 100644 --- a/logback-core/src/main/java/ch/qos/logback/core/recovery/ResilientOutputStreamBase.java +++ b/logback-core/src/main/java/ch/qos/logback/core/recovery/ResilientOutputStreamBase.java @@ -1,13 +1,13 @@ /** * Logback: the reliable, generic, fast and flexible logging framework. * Copyright (C) 1999-2010, QOS.ch. All rights reserved. - * + * * This program and the accompanying materials are dual-licensed under either * the terms of the Eclipse Public License v1.0 as published by the Eclipse * Foundation - * + * * or (per the licensee's choosing) - * + * * under the terms of the GNU Lesser General Public License version 2.1 as * published by the Free Software Foundation. */ @@ -15,6 +15,7 @@ package ch.qos.logback.core.recovery; import java.io.IOException; import java.io.OutputStream; +import java.io.WriteAbortedException; import ch.qos.logback.core.Context; import ch.qos.logback.core.status.ErrorStatus; @@ -24,6 +25,8 @@ import ch.qos.logback.core.status.StatusManager; abstract public class ResilientOutputStreamBase extends OutputStream { + enum OpType {WRITE, FLUSH;} + final static int STATUS_COUNT_LIMIT = 2 * 4; private int noContextWarning = 0; @@ -33,11 +36,11 @@ abstract public class ResilientOutputStreamBase extends OutputStream { private RecoveryCoordinator recoveryCoordinator; protected OutputStream os; - protected boolean presumedClean = true; + protected boolean presumedUp = true; final private boolean isPresumedInError() { // existence of recoveryCoordinator indicates failed state - return (recoveryCoordinator != null && !presumedClean); + return (recoveryCoordinator != null && !presumedUp); } public void write(byte b[], int off, int len) { @@ -50,7 +53,7 @@ abstract public class ResilientOutputStreamBase extends OutputStream { try { os.write(b, off, len); - postSuccessfulWrite(); + postSuccessfulWrite(OpType.WRITE); } catch (IOException e) { postIOFailure(e); } @@ -66,7 +69,7 @@ abstract public class ResilientOutputStreamBase extends OutputStream { } try { os.write(b); - postSuccessfulWrite(); + postSuccessfulWrite(OpType.WRITE); } catch (IOException e) { postIOFailure(e); } @@ -77,7 +80,7 @@ abstract public class ResilientOutputStreamBase extends OutputStream { if (os != null) { try { os.flush(); - postSuccessfulWrite(); + postSuccessfulWrite(OpType.FLUSH); } catch (IOException e) { postIOFailure(e); } @@ -88,19 +91,22 @@ abstract public class ResilientOutputStreamBase extends OutputStream { abstract OutputStream openNewOutputStream() throws IOException; - final private void postSuccessfulWrite() { - if (recoveryCoordinator != null) { + + abstract boolean isRecoveryConfirmingOperation(OpType opType); + + final private void postSuccessfulWrite(OpType opType) { + if (recoveryCoordinator != null && isRecoveryConfirmingOperation(opType)) { recoveryCoordinator = null; statusCount = 0; addStatus(new InfoStatus("Recovered from IO failure on " - + getDescription(), this)); + + getDescription(), this)); } } void postIOFailure(IOException e) { addStatusIfCountNotOverLimit(new ErrorStatus("IO failure while writing to " - + getDescription(), this, e)); - presumedClean = false; + + getDescription(), this, e)); + presumedUp = false; if (recoveryCoordinator == null) { recoveryCoordinator = new RecoveryCoordinator(); } @@ -120,15 +126,15 @@ abstract public class ResilientOutputStreamBase extends OutputStream { } addStatusIfCountNotOverLimit(new InfoStatus( - "Attempting to recover from IO failure on " + getDescription(), this)); + "Attempting to recover from IO failure on " + getDescription(), this)); // subsequent writes must always be in append mode try { os = openNewOutputStream(); - presumedClean = true; + presumedUp = true; } catch (IOException e) { addStatusIfCountNotOverLimit(new ErrorStatus("Failed to open " - + getDescription(), this, e)); + + getDescription(), this, e)); } } @@ -141,7 +147,7 @@ abstract public class ResilientOutputStreamBase extends OutputStream { if (statusCount == STATUS_COUNT_LIMIT) { addStatus(s); addStatus(new InfoStatus("Will supress future messages regarding " - + getDescription(), this)); + + getDescription(), this)); } } diff --git a/logback-core/src/main/java/ch/qos/logback/core/recovery/ResilientSyslogOutputStream.java b/logback-core/src/main/java/ch/qos/logback/core/recovery/ResilientSyslogOutputStream.java index d3c3822..4fe6d9a 100644 --- a/logback-core/src/main/java/ch/qos/logback/core/recovery/ResilientSyslogOutputStream.java +++ b/logback-core/src/main/java/ch/qos/logback/core/recovery/ResilientSyslogOutputStream.java @@ -31,7 +31,7 @@ public class ResilientSyslogOutputStream extends ResilientOutputStreamBase { this.syslogHost = syslogHost; this.port = port; super.os = new SyslogOutputStream(syslogHost, port); - this.presumedClean = true; + this.presumedUp = true; } @Override @@ -43,7 +43,13 @@ public class ResilientSyslogOutputStream extends ResilientOutputStreamBase { OutputStream openNewOutputStream() throws IOException { return new SyslogOutputStream(syslogHost, port); } - + + // A successful FLUSH operation confirms recovery + @Override + boolean isRecoveryConfirmingOperation(OpType opType) { + return opType == ResilientOutputStreamBase.OpType.FLUSH; + } + @Override public String toString() { return "c.q.l.c.recovery.ResilientSyslogOutputStream@" diff --git a/logback-core/src/test/java/ch/qos/logback/core/recovery/RecoveryCoordinatorTest.java b/logback-core/src/test/java/ch/qos/logback/core/recovery/RecoveryCoordinatorTest.java index 1d30e5c..82d20bb 100644 --- a/logback-core/src/test/java/ch/qos/logback/core/recovery/RecoveryCoordinatorTest.java +++ b/logback-core/src/test/java/ch/qos/logback/core/recovery/RecoveryCoordinatorTest.java @@ -31,8 +31,10 @@ public class RecoveryCoordinatorTest { @Test public void smoke() { + rc.injectTime(now); + rc.isTooSoon(); // this will update the "next" field assertTrue(rc.isTooSoon()); - rc.setCurrentTime(now+RecoveryCoordinator.BACKOFF_COEFFICIENT_MIN+1); + rc.injectTime(now + 5*RecoveryCoordinator.BACKOFF_COEFFICIENT_MIN); assertFalse(rc.isTooSoon()); } @@ -41,7 +43,7 @@ public class RecoveryCoordinatorTest { long offset = RecoveryCoordinator.BACKOFF_COEFFICIENT_MIN; int tooSoonCount = 0; for(int i = 0; i < 16; i++) { - rc.setCurrentTime(now+offset); + rc.injectTime(now + offset); if(rc.isTooSoon()) { //System.out.println("is too soon at "+(offset)); diff --git a/logback-core/src/test/java/ch/qos/logback/core/spi/AppenderAttachableImplLockTest.java b/logback-core/src/test/java/ch/qos/logback/core/spi/AppenderAttachableImplLockTest.java index e9e1130..a32f4dd 100644 --- a/logback-core/src/test/java/ch/qos/logback/core/spi/AppenderAttachableImplLockTest.java +++ b/logback-core/src/test/java/ch/qos/logback/core/spi/AppenderAttachableImplLockTest.java @@ -50,7 +50,7 @@ public class AppenderAttachableImplLockTest { private AppenderAttachableImpl<Integer> aai = new AppenderAttachableImpl<Integer>(); @SuppressWarnings("unchecked") - @Test(timeout = 1000) + @Test(timeout = 2000) public void getAppenderBoom() { Appender<Integer> mockAppender1 = EasyMock.createStrictMock(Appender.class); diff --git a/logback-site/src/site/resources/logback-2011.ppt b/logback-site/src/site/resources/logback-2011.ppt index aa3d289..f720bed 100644 Binary files a/logback-site/src/site/resources/logback-2011.ppt and b/logback-site/src/site/resources/logback-2011.ppt differ ----------------------------------------------------------------------- Summary of changes: .../logback/core/recovery/RecoveryCoordinator.java | 10 ++-- .../core/recovery/ResilientFileOutputStream.java | 8 +++- .../core/recovery/ResilientOutputStreamBase.java | 40 +++++++++++-------- .../core/recovery/ResilientSyslogOutputStream.java | 10 ++++- .../core/recovery/RecoveryCoordinatorTest.java | 6 ++- .../core/spi/AppenderAttachableImplLockTest.java | 2 +- logback-site/src/site/resources/logback-2011.ppt | Bin 281600 -> 285696 bytes 7 files changed, 48 insertions(+), 28 deletions(-) hooks/post-receive -- Logback: the generic, reliable, fast and flexible logging framework.

1 0

[JIRA] Created: (LBCLASSIC-262) Memory leak with class "LRUMessageCache" on Websphere 6.1.0.13
by François Petitit (JIRA) 12 Apr '11

12 Apr '11

Memory leak with class "LRUMessageCache" on Websphere 6.1.0.13 -------------------------------------------------------------- Key: LBCLASSIC-262 URL: http://jira.qos.ch/browse/LBCLASSIC-262 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.24 Environment: Websphere 6.1.0.13 64bits on AIX, using bundled IBM JVM 5.0 Service Refresh 6 (5.0 SR6) build pxxnndevifx-20071025 ([http://www.ibm.com/developerworks/java/jdk/aix/j564/fixes.html#SR6] Reporter: François Petitit Assignee: Logback dev list When the application runs on WAS, the subject LRUMessageCache grows constantly. We are unable to reproduce the problem on development environment: perhaps because we can not stress enough the application, or because we don't use Websphere and IBM JVM. We suspect [LBCLASSIC-255] to be a possible cause of the problem. We will try to deploy a new version of the application with the patch delivered for [LBCLASSIC-255] and see if it fixes the problem, but not before days because of environment problems. Thanks. -- 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 0

[JIRA] Created: (LBCLASSIC-259) ERROR: URL [jar:file:/something.jar!/logback.groovy] is not of type file
by Evgeny Goldin (JIRA) 12 Apr '11

12 Apr '11

ERROR: URL [jar:file:/something.jar!/logback.groovy] is not of type file ------------------------------------------------------------------------ Key: LBCLASSIC-259 URL: http://jira.qos.ch/browse/LBCLASSIC-259 Project: logback-classic Issue Type: Bug Affects Versions: 0.9.28 Reporter: Evgeny Goldin Assignee: Logback dev list Please, see this thread: http://qos.ch/pipermail/logback-user/2011-March/002234.html. When *{{"logback.groovy"}}* is packed in a jar file, Logback displays an error message when it starts: {code} 20:36:58,117 |-INFO in ch.qos.logback.classic.LoggerContext[default] - Found resource [logback.groovy] at [jar:file:/C:/Users/evgeny/.m2/repository/.../gcommons-0.5.3-SNAPSHOT.jar!/logback.groovy] 20:36:58,122 |-ERROR in ch.qos.logback.core.joran.spi.ConfigurationWatchList@139d891 - URL [jar:file:/C:/Users/evgeny/.m2/repository/../gcommons-0.5.3-SNAPSHOT.jar!/logback.groovy] is not of type file 20:36:58,401 |-INFO in ch.qos.logback.classic.gaffer.ConfigurationDelegate@b92dc2 - About to instantiate appender of type [ch.qos.logback.core.ConsoleAppender] 20:36:58,402 |-INFO in ch.qos.logback.classic.gaffer.ConfigurationDelegate@b92dc2 - Naming appender as [CONSOLE] {code} Not only that it warns about something that is not an error, it causes other info messages to be displayed as well, which I'd like to avoid and start application silently. -- 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

4 4

[JIRA] Created: (LBCORE-168) Locking issues when prudent logging to a (windows) clustered storage device on owner-switch
by alex (JIRA) 08 Apr '11

08 Apr '11

Locking issues when prudent logging to a (windows) clustered storage device on owner-switch ------------------------------------------------------------------------------------------- Key: LBCORE-168 URL: http://jira.qos.ch/browse/LBCORE-168 Project: logback-core Issue Type: Bug Components: Appender Affects Versions: 0.9.24 Environment: Windows Server 2003 Enterprise edition Reporter: alex Assignee: Logback dev list Priority: Blocker We have a clustered windows environment (2 nodes) and each node is logging to the same file which is stored on a clustered storage device (prudent is set to true) Logging works great until we switch the owner of the storage device where the logs are being written to at which point one of two things happens: - one or both servers go into a sort of deadlock state, meaning the code that logs just hangs indefinatly. it seems the safeWrite() in FileAppender may be to blame because of the "lock()" statement (note that a jvm reboot will fix this problem). I have been able to reproduce this locked state and verify that it is the lock() by trying to get a lock on the log file in the same jvm but without using logback code. This code will hang as well. - if there is no deadlock, any log written after the switch will just vanish into thin air (I have no idea where the outputstream points to when you start switching the owner) I have no idea how this can be fixed without resorting to a reload/reboot of our servers (which is not an option in production). We used to log synchronously, but then each thread that called logback would hang resulting in a massive amount of idling threads, so now we log asynchronously (this was already an option in the system we built around it) which gives us one advantage: we never write concurrently to the same file, although different nodes may write serially. As a temporary work around I am thinking to implement a simple appender that opens/closes the outputstream for each write (performance is less of an issue) and that does not implement locking. -- 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 4

[JIRA] Created: (LBCORE-203) TimeBasedRollingPolicy with MinIndex and MaxIndex attributes
by Muyen Lee (JIRA) 06 Apr '11

06 Apr '11

TimeBasedRollingPolicy with MinIndex and MaxIndex attributes ------------------------------------------------------------ Key: LBCORE-203 URL: http://jira.qos.ch/browse/LBCORE-203 Project: logback-core Issue Type: Improvement Components: Rolling Affects Versions: 0.9.28 Reporter: Muyen Lee Assignee: Logback dev list Priority: Minor Issue LBCORE-16 didn't really solve the problem. The MaxHistory can specified how many days logs get deleted but it is still possible to create too many index files in a day. Therefore, it is better to have a maxIndex attributes as well. -- 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 0