l4g won't flush buffer?

[GoogleCodeExporter]

What steps will reproduce the problem?
I do not have a specific steps to reproduce the issue because it occurs in a 
very complicated project which I cannot share.
Sometimes the l4g won't output the error/debug messages to StdOut or whatever 
file I redirect the stream to
But if I add a fmt.Println("whatever text"), the error will appear in the 
output.
I tried to call l4g.Close(), but it doesn't help.
I think it might be buffer flush issues.
Could you please check?

Original issue reported on code.google.com by [email protected] on 7 May 2012 at 5:19

[GoogleCodeExporter]

In addition, adding fmt.Println("whatever text") even doesn't work sometimes.

Original comment by [email protected] on 7 May 2012 at 5:20

[GoogleCodeExporter]

This program can reproduce the bug:

package main

import (
    "fmt"
    "net/rpc"
    l4g "code.google.com/p/log4go"
)

func main() {
    if err := foo(); err != nil {
        fmt.Println(err)
        l4g.Error(err)
    }
//    fmt.Println("hello")
}

func foo() error {
    client, err := rpc.Dial("tcp", "127.0.0.1:6666")
    if err != nil {
        return l4g.Error(err)
    }
    defer client.Close()
    return nil
}


Two error message should be expected.
While you actually get none.

Original comment by [email protected] on 7 May 2012 at 5:40

[GoogleCodeExporter]

I have the same problem.
When I run the XMLConfigurationExample.go I get no output at all (the files are 
empty).


Running "go test code.google.com/p/log4go" gives the following output:

Testing log4go-v3.0.1
--- FAIL: TestXMLLogWriter (0.00 seconds)
    log4go_test.go:160: malformed xmllog: "<log created=\"2012/07/20 16:27:46 CEST\">\n\t<record level=\"CRIT\">\n\t\t<timestamp>2009/02/13 23:31:30 UTC</timestamp>\n\t\t<source>source</source>\n\t\t<message>message</message>\n\t</record>\n</log>\n" (186 bytes)
[07/20/12 16:27:46] [WARN] Warning: 1 []int{}
[07/20/12 16:27:46] [EROR] Error: 10 []string{}
[07/20/12 16:27:46] [CRIT] Critical: 100 []int64{}
mallocs per sl.Log((WARNING, "here", "This is a log message"): 1
[07/20/12 16:27:46] [WARN] This is a WARNING message
mallocs per sl.Logf(WARNING, "%s is a log message with level %d", "This", 
WARNING): 6
[07/20/12 16:27:46] [WARN] This is a log message with level 5
mallocs per unlogged sl.Log((WARNING, "here", "This is a log message"): 0
mallocs per unlogged sl.Logf(WARNING, "%s is a log message with level %d", 
"This", WARNING): 2
FAIL
FAIL    code.google.com/p/log4go    0.007s

I was using log4net and would really like to use log4go, therefore I would 
appreciate it a lot of you could fix this problem.

If I write many log messages the oldest ones get written. Therefore, I think 
the problem is just that syncs are not executed when the Logger.Close() 
function is called.

Ciao,
Arian

Original comment by [email protected] on 20 Jul 2012 at 2:31

[GoogleCodeExporter]

This is the same as issue #8.

The attached patch seems to fix many of these problems, particularly with 
truncated log files. However, perhaps not all manifestations are addressed.

Regards, Guy

Original comment by [email protected] on 4 Sep 2012 at 4:07

Attachments:

• issue11.patch

[GoogleCodeExporter]

This patch goes on top of the previous one.  It handles console/stdout logging 
much more faithfully.

It _is_ a bit ugly .......

Regards, Guy

Original comment by [email protected] on 4 Sep 2012 at 6:27

Attachments:

• issue11-02.patch

[GoogleCodeExporter]

Patch 3 for this issue.  Actually emit well formed XML for XML log writers.

Guy

Original comment by [email protected] on 4 Sep 2012 at 7:01

Attachments:

• issue11-03.patch

[GoogleCodeExporter]

I also noticed this bug and can't find any way around it. Even setting 
log4go.LogBufferLength = 0 doesn't seem to force the package to do synchronous 
output. That's a bit of a showstopper for me, and I can't use the package until 
that is resolved.

Original comment by [email protected] on 24 Jan 2013 at 10:20

[GoogleCodeExporter]

Same issue here. Has there been any progress on this?

Original comment by [email protected] on 16 Jul 2013 at 7:54