We are currently getting the following exception:

 

Exception has been thrown by the target of an invocation. IdeaBlade.Util.IdeaBladeException: Unable to initialize PersistenceManager The type initializer for 'IdeaBlade.Util.TraceFns' threw an exception. ---> System.TypeInitializationException: The type initializer for 'IdeaBlade.Util.TraceFns' threw an exception. ---> System.IO.IOException: The process cannot access the file 'C:\Microster\Instance\DexToNet\DebugLog_1.xml' because it is being used by another process.     at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)     at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)     at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options)     at System.IO.StreamWriter.CreateFile(String path, Boolean append)     at System.IO.StreamWriter..ctor

 

This error is not reproducible on a consistent basis, but let me give you a quick run down of the architecture and what I suspect is the problem.

 

We have an application which gets instantiated multiple times, and then a software load balancer sends requests to available instances. It looks as though sometimes when these instances of the application are being created, the internal code inside the TraceFns that determines which debug file to write to grabs the same name as another instance. This means that one of the instances can't write to the debug because another instance has a lock on it.

 

When logging is turned off, it appears to work ok (which is to be expected).

 

Is there a way to override the way that the TraceFns chooses the debug file. I know it's set in config, but all instances run from the same location and hence have the same config file. The logic inside the TraceFns is smart enough to append an _x to the end of the file name if it is already there. The problem is of course when both instances check at exactly the same time and append _x (where x is the same number).

 

The other option we have is to change the way we create our instances, and put a delay between each instantiation. But that is a messy workaround which affects performance and doesn't give us any guarantees that the error won't occur.

 

Cheers

 

Jacob