Rampidbyter Rampid byter: A byte of my .Net developing life.

Found an interesting problem today when trying to run multiple instances of a multithreaded application. The application would run together loading the data for a while, then all of a sudden one would throw an exception from a FileStream error. It was a little confusing as the code blocks the thread were running was purely data acquisition from a DSN database connection. I dug a little deeper (opened my eyes) and the code that caused the problems was pretty obvious. The only FileStream access I could imagine that was taking place was through my Trace.WriteLineIf() statements that were outputting to an application output log file.

<system.diagnostics>

<switches>

<!-- Enable/disable profiling messages (0 = disable, 1 = enable) -->

<addname="outputTrace"value="1"/>

</switches>

<traceautoflush="true"indentsize="4">

<listeners>

<addname="traceListener"type="System.Diagnostics.TextWriterTraceListener"initializeData="TraceOutput.log"/>

<removename="Default"/>

</listeners>

</trace>

</system.diagnostics>

Based on a BooleanSwitch I was turning on and writing to Trace output log file from within the application. While building the multithreaded application I never once thought to take into account trying to keep Trace statement calls into account as possible bottlenecks. I’ve not yet figured out a work around for multiple instances of a multithreaded applications taking advantage of a Trace listener, but when I get free time I’ll be sure to look into it and post something here. It could be the same behavior for non-multithreaded apps attempting to do the same, but at least I know this application definitly has the problem. Even still these Trace statements are wrapped in Try/Catch blocks and the exception was still unhandled. The exception itself stated the problem was coming from Line ## from the Appname.exe.config file.