[jira] [Commented] (LOG4NET-528) AdoNetAppender giving .net lock

[Dominik Psenner (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4NET-528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15609569#comment-15609569
 ] 

Dominik Psenner commented on LOG4NET-528:
-

There is not enough information in this issue to allow more than just wild 
guesses. Please provide more information like stacktraces etc. Further, this 
sounds like a topic for one of the mailing lists.

> AdoNetAppender giving .net lock
> ---
>
> Key: LOG4NET-528
> URL: https://issues.apache.org/jira/browse/LOG4NET-528
> Project: Log4net
>  Issue Type: Bug
>  Components: Appenders
>Affects Versions: 1.2.15
> Environment: Windows Server 2008 R2, WCF Web Http Service, Dot Net 4.0
>Reporter: VENKATA NAGA RADHAKRISHNA SEGU
>Priority: Critical
> Fix For: 1.2.15
>
>
> Dear Sir, 
> I am using log4net adonetappender and logging web service info and error 
> messages. I am getting Dot Net Lock issue when there are more concurrent 
> users (approx 300). Please advice me what to do in this case. 
> Regards,
> Venkata



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (LOG4NET-528) AdoNetAppender giving .net lock

[VENKATA NAGA RADHAKRISHNA SEGU (JIRA)]

VENKATA NAGA RADHAKRISHNA SEGU created LOG4NET-528:
--

 Summary: AdoNetAppender giving .net lock
 Key: LOG4NET-528
 URL: https://issues.apache.org/jira/browse/LOG4NET-528
 Project: Log4net
  Issue Type: Bug
  Components: Appenders
Affects Versions: 1.2.15
 Environment: Windows Server 2008 R2, WCF Web Http Service, Dot Net 4.0
Reporter: VENKATA NAGA RADHAKRISHNA SEGU
Priority: Critical
 Fix For: 1.2.15


Dear Sir, 

I am using log4net adonetappender and logging web service info and error 
messages. I am getting Dot Net Lock issue when there are more concurrent users 
(approx 300). Please advice me what to do in this case. 

Regards,
Venkata



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

RE: Better support for logging from an Appender

[Dominik Psenner]

Appenders that log is immensely hard to implement if not separated entirely
from the normal logging. Therefore there is the loglog class. It could be a
feature to allow the configuration of loglog appenders under the
precondition that those appenders do not append events back into the
logging framework, even if events travel over remote sinks.

On 26 Oct 2016 8:40 p.m., "Joe"  wrote:

> Thanks for the response.
>
> After more thought and some tests, this idea is a non-starter.
>
> 1. Hierarchy.Logger.CallAppenders acquires a ReaderWriterLockSlim instance
> that doesn't allow recursion (the default LockRecursionPolicy.NoRecursion).
> Thus if a synchronous appender attempts to log, it will fail with a
> LogRecursionException.
>
>  I'm not sure if this behaviour is intentional.  Because when compiled for
> .NET 1.x it uses a ReaderWriterLock which *does* allow recursion.
>
> Any thoughts on this?  Should the log4net.Util.ReaderWriterLock class be
> instantiating its ReaderWriterLockSlim with LockRecursionPolicy.
> SupportsRecursion?
>
> Another point about ReaderWriterLockSlim is that it is IDisposable, which
> means that strictly speaking classes that own an instance (e.g.
> Hierarchy.Logger) should be IDisposable, and should be disposed when no
> longer used.  I doubt if this is a big deal in practice as most log4net
> objects will live until the AppDomain is unloaded.
>
> 2. Even in the asynchronous case, there is a risk of infinite recursion.
> Each Appender can ignore logging events generated by its own logger, but
> consider the following, assuming appenders want verbose logging of every
> LoggingEvent they see:
>
> - Appender A logs to logger A
> - Appender B logs to logger B
> - log4net is configured to route logging events to both appenders
>
> Every logging event received by A is logged which triggers a logging event
> to B, which logs it and triggers a log event to A, ...
>
> So back to the drawing board.
>
> My main reason for wanting this is for the case of an asynchronous
> appender, which will typically be forwarding events to a remote sink, the
> connection to which may be unreliable.
> In this case, it's desirable for errors to be logged in log4net even in a
> production environment where log4net.internal.debug is false.  Probably
> using a "once-only" logging technique which only logs the error the first
> time it occurs.
>
>
> -Original Message-
> From: Stefan Bodewig [mailto:bode...@apache.org]
> Sent: 22 October 2016 22:18
> To: Log4NET Dev
> Subject: Re: Better support for logging from an Appender
>
> On 2016-10-21, Joe wrote:
>
> > From within DoAppend, there is a flag m_recursiveGuard which should
> > prevent re-entrancy problems from a synchronous appender's Append
> > method.  For an asynchronous appender there would need to be an
> > additional check since it will want to log from a different thread.
>
> We could store some kind of flag that acts like the recursive guard inside
> the (logical) thread context and then check for its existence inside the
> LoggingEvent's properties.
>
> > The following commit will give you an idea of what I'm thinking of:
>
> > https://github.com/apache/log4net/commit/9dc3ed9ae079d9abeacdf86c380b1
> > 7efff4b3a97?w=1
>
> > Is this something we should support?
>
> Your idea works for the case where you know you are logging from inside an
> appender. There is a different way an appender might receive messages that
> originate from itself when the appender uses a library that again uses
> log4net for logging. This wouldn't get caught by your approach but a
> property on the event would work.
>
> This is just an idea, nothing I've actually tried.
>
> > BTW if you look at the above commit without the ?w=1 suffix, you'll
> > see whitespace differences in the Flush method.  I think the
> > .gitattributes file needs to add rules for converting spaces to tabs.
>
> Indentation inside the code base is a mess and I'm sure I've contributed
> to it by not using visual studio. Using .gitattributes could help if git
> was our primary SCM. For people using svn it wouldn't have any effect.
>
> Maybe we need somebody to configure VS with a "proper configuration"
> that we agree upon and re-indent the whole codebase once.
>
> Stefan
>

[GitHub] log4net issue #35: Wip/app settings

[bodewig]

Github user bodewig commented on the issue:

https://github.com/apache/log4net/pull/35
  
I've just realized there is no documentation outside of the API docs for 
the other `PatternStringConverter`s either, so yes, XML comments should be 
sufficient - and you've already provided that. I thought there was a section 
inside the manual on the web site, but don't find anything.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (LOG4NET-526) Add appSetting conversion pattern to PatternString

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4NET-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15609324#comment-15609324
 ] 

ASF GitHub Bot commented on LOG4NET-526:


Github user JJoe2 commented on the issue:

https://github.com/apache/log4net/pull/35
  
I’ll be happy to do the unit tests and possibly the doc.   Are suitable XML 
comments enough?

Now this is added, I’ll also be thinking about the next step, which is to 
allow the PatternString converter to be used in the XML configuration file for 
properties of types other than strings.
So that I can do something like:


   
   

Should be possible: basically be applying the PatternString conversion 
before converting to the target type of the property.

From: Stefan Bodewig [mailto:notificati...@github.com]
Sent: 26 October 2016 20:43
To: apache/log4net
Cc: JJoe2; Author
Subject: Re: [apache/log4net] Wip/app settings (#35)


I've added your converter, many thanks.

Tests would be good and we need documentation before we can close 
LOG4NET-526.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on 
GitHub, or 
mute the 
thread.



> Add appSetting conversion pattern to PatternString
> --
>
> Key: LOG4NET-526
> URL: https://issues.apache.org/jira/browse/LOG4NET-526
> Project: Log4net
>  Issue Type: New Feature
>  Components: Core
>Affects Versions: 1.2.15
>Reporter: Joe
>Priority: Minor
>
> A common requirement is to be able to define a base directory for log files 
> that can be used by multiple FileAppenders.  In this way, the directory only 
> needs to be changed in one place.
> Today the typical solution is to use a PatternString with a property that is 
> set in code before log4net is configured, e.g.
>value="%property{LogDIr}MyFile.log"/>
> Suggested feature is to allow a conversion pattern that reads the base 
> directory name from an appSetting, e.g.:
>value="%appSetting{LogDIr}MyFile.log"/>



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] log4net issue #35: Wip/app settings

[JJoe2]

Github user JJoe2 commented on the issue:

https://github.com/apache/log4net/pull/35
  
I’ll be happy to do the unit tests and possibly the doc.   Are suitable 
XML comments enough?

Now this is added, I’ll also be thinking about the next step, which is to 
allow the PatternString converter to be used in the XML configuration file for 
properties of types other than strings.
So that I can do something like:


   
   

Should be possible: basically be applying the PatternString conversion 
before converting to the target type of the property.

From: Stefan Bodewig [mailto:notificati...@github.com]
Sent: 26 October 2016 20:43
To: apache/log4net
Cc: JJoe2; Author
Subject: Re: [apache/log4net] Wip/app settings (#35)


I've added your converter, many thanks.

Tests would be good and we need documentation before we can close 
LOG4NET-526.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on 
GitHub, or 
mute the 
thread.



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (LOG4NET-526) Add appSetting conversion pattern to PatternString

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4NET-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15609311#comment-15609311
 ] 

ASF GitHub Bot commented on LOG4NET-526:


Github user asfgit closed the pull request at:

https://github.com/apache/log4net/pull/35


> Add appSetting conversion pattern to PatternString
> --
>
> Key: LOG4NET-526
> URL: https://issues.apache.org/jira/browse/LOG4NET-526
> Project: Log4net
>  Issue Type: New Feature
>  Components: Core
>Affects Versions: 1.2.15
>Reporter: Joe
>Priority: Minor
>
> A common requirement is to be able to define a base directory for log files 
> that can be used by multiple FileAppenders.  In this way, the directory only 
> needs to be changed in one place.
> Today the typical solution is to use a PatternString with a property that is 
> set in code before log4net is configured, e.g.
>value="%property{LogDIr}MyFile.log"/>
> Suggested feature is to allow a conversion pattern that reads the base 
> directory name from an appSetting, e.g.:
>value="%appSetting{LogDIr}MyFile.log"/>



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] log4net pull request #35: Wip/app settings

[asfgit]

Github user asfgit closed the pull request at:

https://github.com/apache/log4net/pull/35


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (LOG4NET-526) Add appSetting conversion pattern to PatternString

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/LOG4NET-526?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15609299#comment-15609299
 ] 

ASF GitHub Bot commented on LOG4NET-526:


Github user bodewig commented on the issue:

https://github.com/apache/log4net/pull/35
  
I've added your converter, many thanks.

Tests would be good and we need documentation before we can close 
LOG4NET-526.


> Add appSetting conversion pattern to PatternString
> --
>
> Key: LOG4NET-526
> URL: https://issues.apache.org/jira/browse/LOG4NET-526
> Project: Log4net
>  Issue Type: New Feature
>  Components: Core
>Affects Versions: 1.2.15
>Reporter: Joe
>Priority: Minor
>
> A common requirement is to be able to define a base directory for log files 
> that can be used by multiple FileAppenders.  In this way, the directory only 
> needs to be changed in one place.
> Today the typical solution is to use a PatternString with a property that is 
> set in code before log4net is configured, e.g.
>value="%property{LogDIr}MyFile.log"/>
> Suggested feature is to allow a conversion pattern that reads the base 
> directory name from an appSetting, e.g.:
>value="%appSetting{LogDIr}MyFile.log"/>



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[GitHub] log4net issue #35: Wip/app settings

[bodewig]

Github user bodewig commented on the issue:

https://github.com/apache/log4net/pull/35
  
I've added your converter, many thanks.

Tests would be good and we need documentation before we can close 
LOG4NET-526.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

RE: Better support for logging from an Appender

[Joe]

Thanks for the response.

After more thought and some tests, this idea is a non-starter.

1. Hierarchy.Logger.CallAppenders acquires a ReaderWriterLockSlim instance that 
doesn't allow recursion (the default LockRecursionPolicy.NoRecursion).  Thus if 
a synchronous appender attempts to log, it will fail with a 
LogRecursionException.

 I'm not sure if this behaviour is intentional.  Because when compiled for .NET 
1.x it uses a ReaderWriterLock which *does* allow recursion.
   
Any thoughts on this?  Should the log4net.Util.ReaderWriterLock class be 
instantiating its ReaderWriterLockSlim with 
LockRecursionPolicy.SupportsRecursion?

Another point about ReaderWriterLockSlim is that it is IDisposable, which means 
that strictly speaking classes that own an instance (e.g. Hierarchy.Logger) 
should be IDisposable, and should be disposed when no longer used.  I doubt if 
this is a big deal in practice as most log4net objects will live until the 
AppDomain is unloaded. 

2. Even in the asynchronous case, there is a risk of infinite recursion.  Each 
Appender can ignore logging events generated by its own logger, but consider 
the following, assuming appenders want verbose logging of every LoggingEvent 
they see:

- Appender A logs to logger A
- Appender B logs to logger B
- log4net is configured to route logging events to both appenders

Every logging event received by A is logged which triggers a logging event to 
B, which logs it and triggers a log event to A, ...

So back to the drawing board.

My main reason for wanting this is for the case of an asynchronous appender, 
which will typically be forwarding events to a remote sink, the connection to 
which may be unreliable.
In this case, it's desirable for errors to be logged in log4net even in a 
production environment where log4net.internal.debug is false.  Probably using a 
"once-only" logging technique which only logs the error the first time it 
occurs.


-Original Message-
From: Stefan Bodewig [mailto:bode...@apache.org] 
Sent: 22 October 2016 22:18
To: Log4NET Dev
Subject: Re: Better support for logging from an Appender

On 2016-10-21, Joe wrote:

> From within DoAppend, there is a flag m_recursiveGuard which should 
> prevent re-entrancy problems from a synchronous appender's Append 
> method.  For an asynchronous appender there would need to be an 
> additional check since it will want to log from a different thread.

We could store some kind of flag that acts like the recursive guard inside the 
(logical) thread context and then check for its existence inside the 
LoggingEvent's properties.

> The following commit will give you an idea of what I'm thinking of:

> https://github.com/apache/log4net/commit/9dc3ed9ae079d9abeacdf86c380b1
> 7efff4b3a97?w=1

> Is this something we should support?

Your idea works for the case where you know you are logging from inside an 
appender. There is a different way an appender might receive messages that 
originate from itself when the appender uses a library that again uses log4net 
for logging. This wouldn't get caught by your approach but a property on the 
event would work.

This is just an idea, nothing I've actually tried.

> BTW if you look at the above commit without the ?w=1 suffix, you'll 
> see whitespace differences in the Flush method.  I think the 
> .gitattributes file needs to add rules for converting spaces to tabs.

Indentation inside the code base is a mess and I'm sure I've contributed to it 
by not using visual studio. Using .gitattributes could help if git was our 
primary SCM. For people using svn it wouldn't have any effect.

Maybe we need somebody to configure VS with a "proper configuration"
that we agree upon and re-indent the whole codebase once.

Stefan