We have taken over some .NET 1.1 Windows Service code that spawns threads to read messages off a queue (SeeBeyond eGate JMS queue, but that is not important) and in turn spawns threads to process the message in the target application service. We are continually encountering logic and design decisions that is puzzling us to no end. Here is one example, where the message (lsMessage) has been retrieved from the queue and ready for processing
if(lsMessage != null)
{
// Initialize a new thread class instance, pass in message
WorkerThread worker = new WorkerThread(lsMessage);
Process:
// Start a new thread to process the message
Thread targetWorker = new Thread(new ThreadStart(worker.ProcessMessage));
if(targetWorker != null)
{
targetWorker.Priority = ThreadPriority.Highest;
targetWorker.Name = "Worker " + queueKey.ToString();
targetWorker.Start();
// wait for worker thread to join back in specified period
bool isFinished = targetWorker.Join(SYNC_THREAD_TIMEOUT);
string message = worker.replyMsg;
if ( !isFinished ) // BF is timeout
{
targetWorker.Abort();
// [obscure developer name] 25/10/2004: calling Join() to wait for thread to terminate.
// for EAI listener threads problem, ensure no new thread is started
// before the old one ends
targetWorker.Join();
// prepare reply message
string errorMsg = string.Format("EAIMsg {0}: BF is timeout. Send sync message back to caller.", worker.messageKey);
log.Debug(errorMsg);
message = worker.GenErrorCode(message, errorMsg);
}
// Commit message
MQ.ReceiverCommit(queueKey, worker.messageKey, false);
// Send back the response to the caller
MQ.RespondSend(queueKey, message);
}
else
{
log.Debug(string.Format("Fail to start worker thread to process sync message. Thread returned is null. Sleep for {0} milliseconds.", LIMIT_RESOURCE_SLEEP));
Thread.Sleep(LIMIT_RESOURCE_SLEEP);
goto Process;
}
}
Please ignore the use of label and goto for the moment; that is not the question. Our bewilderment is the check whether the Thread object is null right after instantiation. The else statement below seems to suggest the previous developers have encountered situations like this before. Of course, the original developers are long gone. So we would like to know, can the CLR really instantiate an object after the call to the constructor and return a null? We have no knowledge of such a possibility.