using a named mutex for file appenders

Details

Description

About logging to the same file from 2 or more instances of an application.
As opposed to a minimallock which makes it still possible for 2 application instances to interfere. Why not use a named mutex so that the logging will wait for the lock to be released from another instance.

Ron Grabowski
added a comment - 10/Jul/08 05:57 Yep...someone already posted some code they're using:
http://www.mail-archive.com/log4net-user@logging.apache.org/msg04116.html
I think we need to get them to upload the patch to JIRA and mark it as being ok to include in the code base or else we'll have to re-implement it.

Added ProcessLock inner class alongside ExclusiveLock and MinimalLock that uses a Mutex to allows multiple processes to correctly lock to the same file without having to open and close the file for each write.

Ron Grabowski
added a comment - 08/Feb/09 20:20 Added ProcessLock inner class alongside ExclusiveLock and MinimalLock that uses a Mutex to allows multiple processes to correctly lock to the same file without having to open and close the file for each write.
ProcessLock name may need to change...MutexLock, InterProcessLock?

Stefan Bodewig
added a comment - 17/May/10 10:57 You should probably move the Mutex-releasing code of CloseFile into a finally block so it will be performed even if CloseStream fails.
Other than deciding on the name (which I'm not really good at) is there anything else that needs to b done in order to resolve this issue?

Stefan Bodewig
added a comment - 06/Sep/11 16:23 Note the patch has introduced an issue with MinimalLock that I've now resolved ( LOG4NET-311 ).
The third parameter of the create stream method that the patch adds is never used by anything - has this been intended to be used as forth paramter to the FileStream constructor?

Stefan Bodewig
added a comment - 07/Sep/11 10:25 I've added simple tests in svn revision 1166079 and made them pass. Obviously the third arg of CreateStream was expected to be used in the FileStream constructor.
So now the main remaining issue is naming (and documentation).