.Net Threading Problem

Question

Here is my code:

ThreadStart threadStart = controller.OpenFile;
Thread thread = new Thread(threadStart);
thread.Start();

In the OpenFile function my code looks like:

System.Console.Error.WriteLine("Launching");

The code in OpenFile doesn't get executed for 30 seconds exactly. It starts immediately on my machine but in our production environment it takes 30 seconds before that print statement will execute.

Is there a setting or something that might be doing this? Where would I start looking?

Answer 1

Please provide a short but complete program which demonstrates the problem. Also give us details about your production machine - hardware, OS etc.

Answer 2

Do you have the same problem if you use other threading methods (for example, Threadpool)? This would tell if it's related to this method of threading, or to all methods. Also, is that WriteLine statement the only statement in your OpenFile procedure? 30 seconds is a common timeout length so maybe that's what's happening here.

Other than that, I'm not sure why the thread handler would pause for 30 seconds before processing.

Answer 3

My first step would be to build a test version of the app that calls the OpenFile function the normal way (without using threads), and see if you still get the delay.

Answer 4

I can't reproduce this problem. The following program doesn't suffer from a 30-second delay:

using System;
using System.Threading;

namespace Net_Threading_Problem
{
    class Program
    {
        static void Main()
        {
            Controller controller = new Controller();
            ThreadStart threadStart = controller.OpenFile;
            Thread thread = new Thread(threadStart);
            thread.Start();

            thread.Join();
        }
    }

    internal class Controller
    {
        public void OpenFile()
        {
            Console.Error.WriteLine("Launching");
        }
    }
}

Could you provide some more context? Ideally, a short but complete program that demonstrates the problem.

And doesn't have any compilation errors...

Answer 5

Is controller in a separate assembly? Is that assembly digitally signed? Does the certificate have a revocation list? Is the production environment able to resolve the revocation list URL?

Answer 6

As others pointed out - first try to produce a test program which demonstrates the behavior.

If you can't, try to troubleshoot by: 1. Call the method directly, not in thread, and see how it behaves. 2. Comment out the rest of the code besides the System.Error.WriteLine line

If you still see the the delay in (1), but not in (2), then try to attach to AppDomain.AssemblyLoad Event. I have seen this happen when in the called method there is a call to a web service (it generates a serialization assembly on the fly, so it takes time), or if there is a first reference to external assembly, and it takes time to find and load it. It's very rare, but I had to deal with this, so it's worth trying.

Answer 7

Is your application having to load other assemblies into memory, assemblies which might be in memory on your computer already? .Net applications do not start up instantly, and more assemblies means more loading time. You might try pre-compiling with the Native Image Generator.

Answer 8

Maybe you are experiencing thread starvation, meaning that your thread doesn't get quantum of execution because there are threads with higher priority executing in your process. If this higher level thread is present only in your production environment and not in your testing environment this could be cause for different results.

Answer 9

Unfortunately jeremyZX answered in a comment, so it can't be voted up, but "If you're looking for an output to a log file, there may be a 30 second timeout for whichever tracelistener you're working with before entries are flushed" is well worth looking at. Any time you see a human-perceptible delay in a system, timeout-related code is one of the first things to check. Especially if you see a delay that falls upon some timeout-like integer of 10, 30, 60 seconds...

Answer 10

Sometimes output (Console, StreamWriters, etc.) can be delayed due to flushing issues. If you can, use a better logging platform such as log4net or NLog which will record the timestamp at which the method is actually called. I sometimes use the "OutputDebugString" functionality of log4net along with DebugView from SysInternals for a more realistic output although even that is susceptible to timing delays.

The issue you are describing seems like a caching or performance setting and I would suspect it is actually being called instantly.