Mailing-List: contact log4net-user-help@logging.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Log4NET User" <log4net-user@logging.apache.org>
From: Nicholas Duane <nickdu@msn.com>
To: Log4NET User <log4net-user@logging.apache.org>
Subject: Re: AsyncAppender (was Re: Apache log4net Needs Help)
Thread-Topic: AsyncAppender (was Re: Apache log4net Needs Help)
Thread-Index: AQHSJ6EBt/q+SssOUUyos+xXNDtmO6DENc9o
Date: Tue, 1 Nov 2016 13:32:01 +0000
Message-ID: <BLUPR10MB0833D4DC4B52DE3C3494E9E4DBA10@BLUPR10MB0833.namprd10.prod.outlook.com>
References: <871t0x1xb0.fsf@v45346.1blu.de>
	<BAY177-W365ACFDB1CDD3DE0849DD1C4FE0@phx.gbl>	<87twdjayob.fsf@v45346.1blu.de>
	<BLUPR10MB0833BA0BFBC630F7477A818BDBF10@BLUPR10MB0833.namprd10.prod.outlook.com>
	<MWHPR10MB16770906CC838F4E115A1988BCF40@MWHPR10MB1677.namprd10.prod.outlook.com>
	<BLUPR10MB08330A4322F4C1DF8F11FCE5DBF40@BLUPR10MB0833.namprd10.prod.outlook.com>
	<cc809027-6237-0fd9-25af-9ee990726325@gmail.com>
	<BLUPR10MB0833BBCAD261EB6A3765DC47DBF70@BLUPR10MB0833.namprd10.prod.outlook.com>
	<BLUPR10MB08330DE1D7F40250573D5865DBC20@BLUPR10MB0833.namprd10.prod.outlook.com>
	<87int8oigo.fsf@v45346.1blu.de>
	<BLUPR10MB0833F0821E80952443E213ACDBC50@BLUPR10MB0833.namprd10.prod.outlook.com>
	<87k2docioq.fsf@v45346.1blu.de>
	<BLUPR10MB08330E634E3B308D2051E06EDBC50@BLUPR10MB0833.namprd10.prod.outlook.com>
	<BLUPR10MB0833B8DF84E0760BCF53A9E0DBD10@BLUPR10MB0833.namprd10.prod.outlook.com>,<87oa2ky1f0.fsf_-_@v45346.1blu.de>
In-Reply-To: <87oa2ky1f0.fsf_-_@v45346.1blu.de>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [6vO1sQ0BNROk3GoxO+n88xbWPYg7lrhw]
x-eopattributedmessage: 0
x-microsoft-exchange-diagnostics: 1;BN3NAM04HT172;5:xOqveyxg1uQA2RL2FSAkLonv7jDH6IQY2aTrDZca0SZsr+Dn3Nzq/cxzejwuKdbJiMochqHYgNkrfD9ZmjRTffQPWuWNNAC+TGYSUB1/rLNt/JUOFzgmBknW3kY+FRahf1Dgl0ISLwwTy4e7PRUBtw==;24:1qypHiUf3yPr4r1oCZGd5ZyxYzBEiKfyEBeoASNhSMWFq8NWhvHCcXz6Ogq+O/QZLKQlIAYuxvq/41FjpodXh5Kt0vFMSQ6zji4HIAJbumY=;7:hUYJ5qNxV/F0g8koDhQVcHG3fIZWbn856dc1BB/z9C9vbqzQojy1G1p0vlWEqS9zY7cpM+EDBuO7OTWI/GJjbyv8c4vYPWHI196kONh1ew8gEecNEuVRd+rjTclsV63rb6uGFfI0zNJaXRx24anRb2bHp7MOgEYe/IhCstsmu6JYcD1VKyGFdxpff/7HGHJVylAfl7L7vkkl363LoL/m9yV5Fl63KadyDBnCgl/bZzJh+zbhvmQh74IWy6xew+JPdnieSN9xqBZRGgl+Whq2TTG2HiEQmEnxuypWqYiL+tSLYqekepgQfjpxSp3QksqxaXYh2n9zvPfcYGXE3fubRMJR+hPFuc9M7dabYIOCPEo=
x-forefront-antispam-report: EFV:NLI;SFV:NSPM;SFS:(10019020)(98900003);DIR:OUT;SFP:1102;SCL:1;SRVR:BN3NAM04HT172;H:BLUPR10MB0833.namprd10.prod.outlook.com;FPR:;SPF:None;LANG:en;
x-ms-office365-filtering-correlation-id: 05f7807a-53c9-4e8e-9201-08d4025b7603
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:(1601124038)(1603103081)(1603101340)(1601125047);SRVR:BN3NAM04HT172;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:(432015012)(82015046);SRVR:BN3NAM04HT172;BCL:0;PCL:0;RULEID:;SRVR:BN3NAM04HT172;
x-forefront-prvs: 01136D2D90
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative;
	boundary="_000_BLUPR10MB0833D4DC4B52DE3C3494E9E4DBA10BLUPR10MB0833namp_"
MIME-Version: 1.0
X-OriginatorOrg: outlook.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 01 Nov 2016 13:32:01.0066
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN3NAM04HT172
X-OriginalArrivalTime: 01 Nov 2016 13:32:12.0869 (UTC) FILETIME=[5A8BAF50:01D23444]
archived-at: Tue, 01 Nov 2016 13:32:45 -0000

--_000_BLUPR10MB0833D4DC4B52DE3C3494E9E4DBA10BLUPR10MB0833namp_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Got some questions around this.  I was hoping that if I put the call to Log=
Manager.Shutdown() in my application it might call Close() on all the appen=
ders.  However, that doesn't seem to be the case.  Not sure if the Flush() =
you talk about is something that might have solved my problem.


I checked over the links you provided.  One talks about implementing a queu=
e in an async appender so that each developer wouldn't have to do it.  Whil=
e that certainly sounds like a good thing to do, even this implementation w=
ould need to flush its queue, or at least do as much as it could in the tim=
e allotted, when the process shuts down.  That is the main point I'm trying=
 to bring up as my appender has its own queue but the Close() method doesn'=
t give me any significant amount of time to flush my queue and thus I'm los=
ing events.


One of the links also provides an AsyncAppender implementation which the au=
thor claims will address the problem of lost events on shutdown, but it app=
ears to use the Close() method to shutdown cleanly, which I would assume su=
ffers from the same problem I experienced.  Namely, the Close() method appe=
ars to be called from log4net by way of syncing the .NET app domain shutdow=
n event.  At that point you're not given any time to cleanup.


Thanks,

Nick

________________________________
From: Stefan Bodewig <bodewig@apache.org>
Sent: Sunday, October 16, 2016 7:32 AM
To: Log4NET User
Subject: AsyncAppender (was Re: Apache log4net Needs Help)

On 2016-10-16, Nicholas Duane wrote:

> By the way, what's the state of async appenders in log4net?

This is one of the things I'd love people to get involved in. We've got

* a simple implementation inside the sample
* https://issues.apache.org/jira/browse/LOG4NET-190
* https://issues.apache.org/jira/browse/LOG4NET-201
* https://issues.apache.org/jira/browse/LOG4NET-407

the later even made it into the 1.3 branch (that's now been
abandoned). It would be good if anybody found the time to make it work
inside the current trunk setup.

So there are few implementations. They may share the problem mentioned
here

> http://stackoverflow.com/questions/36344822/log4net-appenders-onclose-doe=
snt-seem-to-work

I haven't checked.

> Seems like log4net should not only expose a startup routine the app
> must call but also a shutdown routine, and indicate that it's
> essential it gets called.  Then log4net could shutdown the appenders
> in the shutdown routine as opposed to relying on .NET's appdomain
> shutdown logic.

There are Shutdown methods in LogManager and LoggerManager.

The patch Joe mentions that add Flush to certain appenders and to
LogManager has been added to svn trunk and will be part of 2.0.6 (which
will be the version of the next release).

Stefan

--_000_BLUPR10MB0833D4DC4B52DE3C3494E9E4DBA10BLUPR10MB0833namp_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"><!-- P {margin-top:0;margi=
n-bottom:0;} --></style>
</head>
<body dir=3D"ltr">
<div id=3D"divtagdefaultwrapper" style=3D"font-size:12pt;color:#000000;font=
-family:Calibri,Arial,Helvetica,sans-serif;">
<p>Got some questions around this.&nbsp; I was hoping that if I put the cal=
l to LogManager.Shutdown() in my application it might call Close() on all t=
he appenders.&nbsp; However, that doesn't seem to be the case.&nbsp; Not su=
re if the Flush() you talk about is something that
 might have solved my problem.</p>
<p><br>
</p>
<p>I checked over the links you provided.&nbsp; One talks about implementin=
g a queue in an async appender so that each developer wouldn't have to do i=
t.&nbsp; While that certainly sounds like a good thing to do, even this imp=
lementation would need to flush its queue,
 or at least do as much as it could in the time allotted, when the process =
shuts down.&nbsp; That is the main point I'm trying to bring up as my appen=
der has its own queue but the Close() method doesn't give me any significan=
t amount of time to flush my queue and
 thus I'm losing events.</p>
<p><br>
</p>
<p>One of the links also provides an AsyncAppender implementation which the=
 author claims will address the problem of lost events on shutdown, but it =
appears to use the Close() method to shutdown cleanly, which I would assume=
 suffers from the same problem I
 experienced.&nbsp; Namely, the Close() method appears to be called from lo=
g4net by way of syncing the .NET app domain shutdown event.&nbsp; At that p=
oint you're not given any time to cleanup.</p>
<p><br>
</p>
<p>Thanks,</p>
<p>Nick<br>
</p>
<br>
<div style=3D"color: rgb(0, 0, 0);">
<div>
<hr tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"x_divRplyFwdMsg" dir=3D"ltr"><font style=3D"font-size:11pt" face=
=3D"Calibri, sans-serif" color=3D"#000000"><b>From:</b> Stefan Bodewig &lt;=
bodewig@apache.org&gt;<br>
<b>Sent:</b> Sunday, October 16, 2016 7:32 AM<br>
<b>To:</b> Log4NET User<br>
<b>Subject:</b> AsyncAppender (was Re: Apache log4net Needs Help)</font>
<div>&nbsp;</div>
</div>
</div>
<font size=3D"2"><span style=3D"font-size:10pt;">
<div class=3D"PlainText">On 2016-10-16, Nicholas Duane wrote:<br>
<br>
&gt; By the way, what's the state of async appenders in log4net?<br>
<br>
This is one of the things I'd love people to get involved in. We've got<br>
<br>
* a simple implementation inside the sample<br>
* <a previewremoved=3D"true" id=3D"LPlnk722907" href=3D"https://issues.apac=
he.org/jira/browse/LOG4NET-190">
https://issues.apache.org/jira/browse/LOG4NET-190</a><br>
* <a previewremoved=3D"true" id=3D"LPlnk479229" href=3D"https://issues.apac=
he.org/jira/browse/LOG4NET-201">
https://issues.apache.org/jira/browse/LOG4NET-201</a><br>
* <a previewremoved=3D"true" id=3D"LPlnk350403" href=3D"https://issues.apac=
he.org/jira/browse/LOG4NET-407">
https://issues.apache.org/jira/browse/LOG4NET-407</a><br>
<br>
the later even made it into the 1.3 branch (that's now been<br>
abandoned). It would be good if anybody found the time to make it work<br>
inside the current trunk setup.<br>
<br>
So there are few implementations. They may share the problem mentioned<br>
here<br>
<br>
&gt; <a previewremoved=3D"true" id=3D"LPlnk352932" href=3D"http://stackover=
flow.com/questions/36344822/log4net-appenders-onclose-doesnt-seem-to-work">
http://stackoverflow.com/questions/36344822/log4net-appenders-onclose-doesn=
t-seem-to-work</a><br>
<br>
I haven't checked.<br>
<br>
&gt; Seems like log4net should not only expose a startup routine the app<br=
>
&gt; must call but also a shutdown routine, and indicate that it's<br>
&gt; essential it gets called.&nbsp; Then log4net could shutdown the append=
ers<br>
&gt; in the shutdown routine as opposed to relying on .NET's appdomain<br>
&gt; shutdown logic.<br>
<br>
There are Shutdown methods in LogManager and LoggerManager.<br>
<br>
The patch Joe mentions that add Flush to certain appenders and to<br>
LogManager has been added to svn trunk and will be part of 2.0.6 (which<br>
will be the version of the next release).<br>
<br>
Stefan<br>
</div>
</span></font></div>
</div>
</body>
</html>

--_000_BLUPR10MB0833D4DC4B52DE3C3494E9E4DBA10BLUPR10MB0833namp_--