[
https://issues.apache.org/jira/browse/LOG4NET-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Bodewig updated LOG4NET-151:
---
Fix Version/s: (was: 1.2.11)
1.2 Maintenance Release
Pushing it back
[
https://issues.apache.org/jira/browse/LOG4NET-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13103456#comment-13103456
]
Stefan Bodewig commented on LOG4NET-154:
Documentation on stacktracedetail
Document %stacktrace and %stacktracedetail
--
Key: LOG4NET-313
URL: https://issues.apache.org/jira/browse/LOG4NET-313
Project: Log4net
Issue Type: Sub-task
Components: Documentation
[
https://issues.apache.org/jira/browse/LOG4NET-154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13103474#comment-13103474
]
Stefan Bodewig commented on LOG4NET-154:
I've had a look at Adam's (MAX|MIN)
Hi,
LOG4NET-164 introduced a new locking strategy for FileAppender which
technically uses a System.Threading.Mutex with a name built from the log
file's name. This should allow separate processes to share a log file
without repeatedly opening and closing it.
The main remaining issue is its name
[
https://issues.apache.org/jira/browse/LOG4NET-87?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13103583#comment-13103583
]
Stefan Bodewig commented on LOG4NET-87:
---
just missing some documentation
Support
LOG4NET-164 introduced a new locking strategy for FileAppender which
technically uses a System.Threading.Mutex with a name built from the log
file's name. This should allow separate processes to share a log file
without repeatedly opening and closing it.
The main remaining issue is its name
On 2011-09-13, Dominik Psenner wrote:
LOG4NET-164 introduced a new locking strategy for FileAppender which
technically uses a System.Threading.Mutex with a name built from the log
file's name. This should allow separate processes to share a log file
without repeatedly opening and closing it.
I like InterProcessLock and would like to propose MultiProcessLock as my
favorite.
I HOPE that the documentation will indicate what a bad plan this is and
that a remoteing appender etc might be a better plan.
--
Roy Chastain
Not only, it would also appear inside the config file in order to set
the locking model of FileAppender like in the third example of
http://logging.apache.org/log4net/release/config-examples.html#fileappender
Right now it would be
lockingModel type=log4net.Appender.FileAppender+MutexLock /
Quite
Hi all,
in order to shape up for the release I diffed the 1.2.10 release ZIP
source tree against current trunk's src and used BitDiffer from
bitwidgets[1] to compare the DEBUG assemblies targeting 2.0 in binary.
The results can be found in
http://people.apache.org/~bodewig/log4net/diffs/
The
[
https://issues.apache.org/jira/browse/LOG4NET-314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13103699#comment-13103699
]
Adam Davies commented on LOG4NET-314:
-
I can add a theshold constraint if desired,
[
https://issues.apache.org/jira/browse/LOG4NET-235?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13104037#comment-13104037
]
Ron Grabowski commented on LOG4NET-235:
---
I don't think having one aspnet pattern
The signature changes from void to ICollection shouldn't break anything. Now
the configurators return a list of configuration messages. I suppose it should
return an array of a certain type instead of just ICollection. Maybe something
like ConfigurationMessage[] or LogLog[]. I lean more
I don't have any hard numbers but the last time I played around with
MinimalLock it was very very slow. I view InterProcessLock as an intermediary
between exclusive and minimal locking.
From: Dominik Psenner dpsen...@gmail.com
To: 'Log4NET Dev'
[
https://issues.apache.org/jira/browse/LOG4NET-164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13104050#comment-13104050
]
Ron Grabowski commented on LOG4NET-164:
---
I like the name InterProcessLock
using a
Can you share a config snippet showing how to use the RemotingAppender like
you've described?
What happens when one of the apps goes down? I envision the InterProcessLock as
a locking model used between two low/medium chatty apps that want to write to
the same file that may or may not be
No, I do not have a configuration, but the idea would be to setup a
logging application that would be the receiver of logging sent out from
2 or more applications using a remoting appender. Basically the same
idea as remote Syslog application.
Yes, it might be slow to log, but (other than the
On 2011-09-14, Ron Grabowski wrote:
Can you share a config snippet showing how to use the RemotingAppender
like you've described?
We used to have an extraordinally simple Windows Service at $work that
didn't do much but using log4net writing to a file and starting the
19 matches
Mail list logo
