- logback-dev - mailman3.qos.ch

[JIRA] Created: (LBCORE-207) Rotate logs at startup
by Radenko Kalajdzic (JIRA) 04 May '11

04 May '11

Rotate logs at startup ---------------------- Key: LBCORE-207 URL: http://jira.qos.ch/browse/LBCORE-207 Project: logback-core Issue Type: New Feature Components: Rolling Reporter: Radenko Kalajdzic Assignee: Logback dev list As discussed, please add a feature "rotate/roll logs at startup". The goal is to have a new log file each time the application server (re)starts. Thanks in advance -- 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-206) Typo fixes
by Bruce Mitchener (JIRA) 02 May '11

02 May '11

Typo fixes ---------- Key: LBCORE-206 URL: http://jira.qos.ch/browse/LBCORE-206 Project: logback-core Issue Type: Improvement Reporter: Bruce Mitchener Assignee: Logback dev list This spans a number of projects. I've put a pull request up at https://github.com/ceki/logback/pull/10 Let me know if you'd like the changes in some other form. -- 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

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