ThreadContext properties are appended to loggly logs as would be expected, but LogicalThreadContext and GlobalContext properties are not.

I imagine the reasoning is because log4net does not expose the keys or enumerators for these contexts, but if there is way around this, it would be a nice feature to have.

This seems to also impact accessing them in layouts using the %property{} syntax.

In other words, avoid to use ThreadPool.QueueUserWorkItem per event, because this could cause thread starvation on high-load application, which means if the application tries to log a burst of events, and the thread used to manage the send of the event waits on IO resource to complete (as it does), could cause slowness on all the application if it relies on ThreadPool as well.

This is because ThreadPool tries to avoid creating more thread than the predefined MinThreads (that by default are one per core in console app, more on asp.net app), actually it slows down the creation by a factor of 2 threads per second (this could also been changed in new framework, for sure was like that in 3.5, but whenever algorithm it is used now, its purpose is to avoid creating too much threads), the slowness could happen only on the first burst, and then if the application is really stable enqueuing the same amount of tasks, the application could perform well (this is all about the thread pool algorithm), but more often I saw application doing that with thread pool simply going mad (of course it depends on many many factors).

The following instead is a good log4net async implementation that uses a dispatcher-way, always consuming one thread, but just one to push all the events that are coming: https://github.com/logentries/le_dotnet/blob/master/src/LogentriesCore/AsyncLogger.cs

Hello,

We experience a memory leak in our WCF application when we have log4net-loggly enabled (see attached MemLeakConfig file).
MemLeakConfig.txt

Removing all references to the LogglyAppender in our config file stopped the memory leak (see attached NoMemLeakConfig file).
NoMemLeakConfig.txt

Has anyone else experienced similar? Does anyone see issues with the first config that might cause this? Does anyone have any troubleshooting suggestions?

Thanks in advance!

I am trying to use LogglyBufferringAppender with a bufferSize=2. It's posting the data to loggly. However, the logged data is not correctly parsed.

unparsed: message:["{\"timestamp\":\"2016-12-21T15:39:23.420+11:00\",\"level\":\"INFO\",\"hostName\":\"HostName\",\"process\":\"w3wp\",\"threadName\":\"11\",\"loggerName\":\"LoggerName\",\"message\":\"log message.\",\"IPAddress\":\"::1\",\"User_ID\":1,\"MaskedSessionID\":\"*****************\",\"User\":\"Mr. XXX for test test(57237)\"}","{\"timestamp\":\"2016-12-21T15:39:23.626+11:00\",\"level\":\"INFO\",\"hostName\":\"HostName\",\"process\":\"w3wp\",\"threadName\":\"11\",\"loggerName\":\"LoggerName\",\"message\":\"log message.\",\"IPAddress\":\"::1\",\"User_ID\":1,\"MaskedSessionID\":\"*****************\",\"User\":\"Mr. XXX for test test(57237)\"}","{\"timestamp\":\"2016-12-21T15:39:34.684+11:00\",\"level\":\"INFO\",\"hostName\":\"HostName\",\"process\":\"w3wp\",\"threadName\":\"11\",\"loggerName\":\"LoggerName\",\"message\":\"log message.\",\"IPAddress\":\"::1\",\"User_ID\":1,\"MaskedSessionID\":\"*****************\",\"User\":\"Mr. XXX for test test(57237)\"}"]

I have been using LogglyAppender with no issue. The reason to use LogglyBufferringAppender is to decrease the network traffic and log 2 entries in a go.

Following this pattern when putting a pattern in the ThreadContext results in an empty string. https://logging.apache.org/log4net/release/manual/contexts.html

Example of our provider:

public class RequestIdProvider : IFixingRequired
{
    public object GetFixedObject()
    {
        return ToString();
    }

    public override string ToString()
    {
        return RequestContext.RequestId ?? "";
    }
}

And how we used it:

log4net.ThreadContext.Properties["RequestId"] = new RequestIdProvider();

Using it without the provider works correctly:

log4net.ThreadContext.Properties["RequestId"] = RequestContext.RequestId ?? "";

The problem seems to be that GetFixedObject is not called because the IFixingRequired attribute (http://logging.apache.org/log4net/log4net-1.2.12/release/sdk/log4net.Core.IFixingRequired.html) is not being honored, which is required for a buffered appender.

Actually, I am using Thread.sleep(60000) to wait the transfer is completed, but it is not a good way to make sure it.

The NuGet package does not work for me under IIS, although it DOES seem to work when running under IIS Express. Yet when I build from source, it seems to work fine in both cases.

At a glance, it appears there's only been one commit since the Nuget package was built:
12cc099

Can you please update the NuGet package with the latest version?

Since .NET 4.5 HttpClient class is supported with async method SendAsync.
I think logging via http should always be async, and HttpClient is the best way to do it.
Any plans of use it in loggly?

I know log4net itself not provide .net45 version, but I can use log4net lib in compatibility mode and loggly lib in .net45 since .net45 is complete replacement of .net40

PS. Aslo I can see very small bug in lib, if I not specify Tag property in appender, it add "/tags" in url to anyway. My opinion that is should not.

You're framework leaks lots of memory on each and every call. You need to fix it.

We need to update log4net-loggly to support conversion patterns

loggly-appender not compatable with asp.net core ,
how can be use appender with asp.net core ?

Following the config example given in README, I always got 403 invalid API key. After digging a bit deeper, I found we need change the rootUrl to the value below:

<rootUrl value="http://logs-01.loggly.com/inputs" />

Not sure if this is a server side change recently ...

I just downloaded the latest version of Loggly and Bulk mode doesn't seem to work with log4net 1.2.15. Not sure why. When I used the flag

<logMode value="inputs" />

it seems to work again.