Re: Re: [Newsletter] Re: log4net - performance hit because UserName is fetched always

2022-02-22 Thread Davyd McColl
Hi Vladimir (to clarify, from here on "fixed" refers to being unchanging, not reverted from a broken state, and much of this message is for my own benefit as there are still large portions of log4net that I'm not well-acquainted with) I believe you're on the right track here - the added

Re: Re: [Newsletter] Re: log4net - performance hit because UserName is fetched always

2022-02-22 Thread Vladimir Vedeneev
Again not sure if this is applicable to your case, there are some discussions regarding UserName and performance in internet, like this one (with sql appender specifics) https://www.codewrecks.com/post/old/2015/03/bufferingappenderskeleton-performance-problem-in-log4net/ As a result they refer to

RE: Re: [Newsletter] Re: log4net - performance hit because UserName is fetched always

2022-02-22 Thread Denis Petker
Hi Davyd, I’m not quite sure, whether I fully understood you. Our use-case is pretty simple: we don’t use impersonating, we don’t log the username and we don’t use the username for filtering log-events etc. So we are not interested in username at all. Nevertheless, we are suffering from the

Re: [Newsletter] Re: log4net - performance hit because UserName is fetched always

2022-02-22 Thread Davyd McColl
Hi Vladimir That's a very good point - the thread could be impersonating a user (https://docs.microsoft.com/en-us/dotnet/api/system.security.principal.windowsidentity.getcurrent),   and I could imagine this being the user for an asp.net request if it's tied into windows identities. It is not

Re: [Newsletter] Re: log4net - performance hit because UserName is fetched always

2022-02-22 Thread Vladimir Vedeneev
Sorry if will be saying dumb things here, as I've seen that several years ago and have no time to review that now; but maybe that'll ring the bell for somebody I thought that UserName could be related to user name from principal (thus basically anything set in code - and can be easily different

Re: [Newsletter] Re: log4net - performance hit because UserName is fetched always

2022-02-22 Thread Dominik Psenner
I believe the caching has already been implemented but don't have any references to mention right now. On Tue, 22 Feb 2022 at 09:56, Denis Petker wrote: > Hi Davyd > > Thanks for the quick response! Agreed, I also don't think, that the > username doesn't change for a process. > If we say, that

RE: [Newsletter] [Newsletter] Re: log4net - performance hit because UserName is fetched always

2022-02-22 Thread Davyd McColl
Hi Denis Added as commit 025d7f6ac197fc8ca92c776b14d9205d6b899168 - I'll release as soon as I get the time (: -d On 2022-02-22 12:36:47, Denis Petker wrote: Hi Davyd, your patch looks good to me. It resolves my issue. Would be great if it could go into the next release. Many thanks, Denis

RE: [Newsletter] [Newsletter] Re: log4net - performance hit because UserName is fetched always

2022-02-22 Thread Denis Petker
Hi Davyd, your patch looks good to me. It resolves my issue. Would be great if it could go into the next release. Many thanks, Denis -- Denis Petker Next Generation Solutions | 8BM3 Rohde & Schwarz GmbH & Co. KG Hanomaghof 1 | 30449 Hanover Phone: +49 511 678 07 146 | Fax: +49 511 678 07 200

RE: [Newsletter] Re: log4net - performance hit because UserName is fetched always

2022-02-22 Thread Davyd McColl
Hi Denis I would imagine that the use case is for shared logging config between processes. I think that the issue could be resolved by some caching in LoggingEvent.TryGetCurrentUserName (LoggingEvent.cs:927).  I was just going to provide guidance, but it's probably quicker to just patch and

RE: [Newsletter] Re: log4net - performance hit because UserName is fetched always

2022-02-22 Thread Denis Petker
Hi Davyd Thanks for the quick response! Agreed, I also don't think, that the username doesn't change for a process. If we say, that the username isn't going to change for a process, I think there is no reason in printing the user name per log statement. However, the ticket LOG4NET-205 has