threadabortexception and web services

[=?Utf-8?B?RXRoYW4gU3RyYXVzcw==?=]

Hi,
I am running a web service which sometimes throws exceptions. I have a
lot of error trapping within the web service, but I have missed the current
problem. I am working on the current issue, but there even when I get this
fixed, there may be others I have not thought of. My immediate problem is
that the web service seems to throw a threadabortexception to the client when
it has an uncaught exception (I may be wrong. I am a bit confused about what
is being thrown and what is being caught and by whom) and I can't seem to
actually stop the threadabortexception. That is, I can catch it, and my error
handling is recording it approiately, but it still goes through and displays
an raw error for the client.
I have done some looking and threadabortexception seems to automatically
rethrow
(http://msdn2.microsoft.com/en-us/library/system.threading.threadabortexception.aspx)!
Anyone know the correct way to actually catch and stop a
threadabortexception?
Thanks!
Ethan

[Willy Denoyette [MVP]]

"Ethan Strauss" <Et**********@discussions.microsoft.comwrote in message
news:EB**********************************@microsof t.com...

Sorry about the empty post. I don't know what happened...
Anyway, There should be only a single thread running at the time the error
has been thrown. The Web Service creates exactly two threads and then calls
the following
if ((!NTThread.Join(TimeOut)|| !RefSeqThread.Join(TimeOut)))
{
//Code to deal with time outs
}
The ThreadAbortException is being called after this point in the code.
I do not ever call thread.abort.
I do not create any more threads.
I think that means that both of those threads should be synchronized. Right?
Could one somehow be sneaking past this point without me realizing? Any other
ideas?
I may just patch it with a "Thread.ResetAbort", but I would prefer to get to
the root of the issue if I can.
Thanks!
Ethan

"Dave Sexton" wrote:

>Hi Ethan,

You should prevent the ThreadAbortException in the first place by not
killing the thread before it ends on its own.

You can use EventWaitHandles to synchronize threads. One can be used to
signal to a worker thread that it should stop gracefully by returning to the
caller, but the worker thread must periodically check the wait handle by
calling WaitOne(timeout).

Another option is to call Thread.ResetAbort, but if you do then you should
probably throw a different exception after cleaning up shared state, if
necessary. See the example in the link that you posted.

--
Dave Sexton
http://davesexton.com/blog

"Ethan Strauss" <Et**********@discussions.microsoft.comwrote in message
news:1E**********************************@microso ft.com...

Hi,
I am running a web service which sometimes throws exceptions. I have a
lot of error trapping within the web service, but I have missed the
current
problem. I am working on the current issue, but there even when I get this
fixed, there may be others I have not thought of. My immediate problem is
that the web service seems to throw a threadabortexception to the client
when
it has an uncaught exception (I may be wrong. I am a bit confused about
what
is being thrown and what is being caught and by whom) and I can't seem to
actually stop the threadabortexception. That is, I can catch it, and my
error
handling is recording it approiately, but it still goes through and
displays
an raw error for the client.
I have done some looking and threadabortexception seems to automatically
rethrow
(http://msdn2.microsoft.com/en-us/library/system.threading.threadabortexception.aspx)!
Anyone know the correct way to actually catch and stop a
threadabortexception?
Thanks!
Ethan

Look at Roman's suggestion, probably your webrequest takes too long to finish, and the
hosting process decided to unload the AD. Unloading an AD means aborting all thread running
inside it.

Willy.

[Dave Sexton]

Hi Ethan,

Anyway, There should be only a single thread running at the time the error
has been thrown. The Web Service creates exactly two threads and then
calls
the following
if ((!NTThread.Join(TimeOut)|| !RefSeqThread.Join(TimeOut)))
{
//Code to deal with time outs
}
The ThreadAbortException is being called after this point in the code.
I do not ever call thread.abort.
I do not create any more threads.
I think that means that both of those threads should be synchronized.
Right?

No. Synchronization means that shared state can be accessed safely by
multiple threads, usually with locks, or that their execution is
synchronized so that they can run in a controlled, serial manner, usually
with wait handles.

It's possible that the threads are synchronized, but it's not implicit just
by calling Join. All that does is block the calling thread until the joined
thread ends. Afterwards, your code does the same for another thread. In
the meantime, the threads could be messing up all sorts of shared state if
they aren't properly synchronized.

Could one somehow be sneaking past this point without me realizing? Any
other
ideas?

If you're specifying a time out value that elapses before one of the threads
ends, then yes. In your "code to deal with time outs", are you ending the
threads somehow or does the executing thread just continue on about its
business? I'm curious to knows what code goes there.

I may just patch it with a "Thread.ResetAbort", but I would prefer to get
to
the root of the issue if I can.

Roman's suggestion may be correct, as Willy pointed out, but to solve the
problem you're either going to have to use Thread.ResetAbort or increase the
timeout period for the request.

Is the client receiving the ThreadAbortException or some timeout exception?

I believe that a timeout indicates that your error may be related to the
AppDomain being unloaded, as was suggested by Willy, since the web service
won't wait for the abort exception; otherwise, I would assume that it's your
code causing the abort and not the service timing out since the service
would be expecting a response and instead receive the abort exception.

--
Dave Sexton
http://davesexton.com/blog

[Willy Denoyette [MVP]]

"Ethan Strauss" <Et**********@discussions.microsoft.comwrote in message
news:E7**********************************@microsof t.com...

Everyone, Thanks for all your help on this. This is the first time I have
ever done anything with threads and clearly it has complexities :-)

I am sure I am not running into timeout issues. This web service takes a
long time to run and I am tracking time outs quit carefully.

I think it has something to do errors causing AppDomian.Unload and that
calling thread.abort as was suggested earlier.

Don't worry about it. I will try to do some more reading.
Ethan

"Dave Sexton" wrote:

>Hi Ethan,

Anyway, There should be only a single thread running at the time the error
has been thrown. The Web Service creates exactly two threads and then
calls
the following
if ((!NTThread.Join(TimeOut)|| !RefSeqThread.Join(TimeOut)))
{
//Code to deal with time outs
}
The ThreadAbortException is being called after this point in the code.
I do not ever call thread.abort.
I do not create any more threads.
I think that means that both of those threads should be synchronized.
Right?

No. Synchronization means that shared state can be accessed safely by
multiple threads, usually with locks, or that their execution is
synchronized so that they can run in a controlled, serial manner, usually
with wait handles.

It's possible that the threads are synchronized, but it's not implicit just
by calling Join. All that does is block the calling thread until the joined
thread ends. Afterwards, your code does the same for another thread. In
the meantime, the threads could be messing up all sorts of shared state if
they aren't properly synchronized.

Could one somehow be sneaking past this point without me realizing? Any
other
ideas?

If you're specifying a time out value that elapses before one of the threads
ends, then yes. In your "code to deal with time outs", are you ending the
threads somehow or does the executing thread just continue on about its
business? I'm curious to knows what code goes there.

I may just patch it with a "Thread.ResetAbort", but I would prefer to get
to
the root of the issue if I can.

Roman's suggestion may be correct, as Willy pointed out, but to solve the
problem you're either going to have to use Thread.ResetAbort or increase the
timeout period for the request.

Is the client receiving the ThreadAbortException or some timeout exception?

I believe that a timeout indicates that your error may be related to the
AppDomain being unloaded, as was suggested by Willy, since the web service
won't wait for the abort exception; otherwise, I would assume that it's your
code causing the abort and not the service timing out since the service
would be expecting a response and instead receive the abort exception.

--
Dave Sexton
http://davesexton.com/blog

The asp.net hosting process keeps track of the web request running time, if it exceeds a
certain threshold, it will tear down the Application Domain which implies threadAbort
injections in all AD related threads. So, I'm pretty sure this is your issue.

Willy.