Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   ASP .Net (http://www.velocityreviews.com/forums/f29-asp-net.html)
-   -   Mystery Threads - How do you find out where they come from? (http://www.velocityreviews.com/forums/t732469-mystery-threads-how-do-you-find-out-where-they-come-from.html)

Mark Moeykens 09-03-2010 02:22 PM

Mystery Threads - How do you find out where they come from?
 
In this web app I’m working on there is this place that logs some information
about Thread.CurrentThread. This logging is supposed to only happen on
threads that the application spawns. The application assigns
Thread.CurrentThread.Name a name and then later logs that name into a SQL
Server table.

But sometimes when we log the thread’s name it isn’t our assigned name.
Instead it is “Thread-1” all the way up to “Thread-26”. By default
Thread.CurrentThread.Name is null so we can’t figure out where these other
threads are coming from. We can only reproduce this problem on a web server,
not locally.

Anyone know how we can find out more information on these mystery threads
and where they are coming from? I’ve explored the Thread object but can’t
seem to find any useful properties I can inspect for clues.

Thank you,
Mark Moeykens


Mark Moeykens 09-07-2010 06:36 PM

Re: Mystery Threads - How do you find out where they come from?
 
Thanks for your reply, Brian. I had forgotten all about the “Threads” window
and we immediately put it to use to observe what was happening.

From what we can see we too have a handful of <No Name> threads that get
picked up at our break points. Then as our breakpoints are hit we see some of
these <No Name> threads getting renamed automatically to “Thread-##” (we
track the renaming by the thread's ID). Our processes (IIS I guess) are
picking up and using these renamed threads. Since the thread.Name property is
write-once we cannot rename it and there is the problem. We can no longer
track the thread with an unpredictable name.


"Brian Cryer" wrote:

> "Mark Moeykens" <MarkMoeykens@discussions.microsoft.com> wrote in message
> news:7EDD6F77-A2D8-4CD3-8FCA-C5562354F878@microsoft.com...
> > In this web app I’m working on there is this place that logs some
> > information
> > about Thread.CurrentThread. This logging is supposed to only happen on
> > threads that the application spawns. The application assigns
> > Thread.CurrentThread.Name a name and then later logs that name into a SQL
> > Server table.
> >
> > But sometimes when we log the thread’s name it isn’t our assigned name.
> > Instead it is “Thread-1” all the way up to “Thread-26”. By default
> > Thread.CurrentThread.Name is null so we can’t figure out where these other
> > threads are coming from. We can only reproduce this problem on a web
> > server,
> > not locally.

>
> I'm sure that the .NET framework uses threads (the garbage collector for
> instance), plus I'd expect to see one thread for each active web-request and
> I suppose another just listening for requests. So that's three without
> thinking giving much thought.
>
> However, I'd expect you to be able to see the same behaviour locally -
> perhaps not as many threads because you might not have as many requests, but
> I'd expect you to see some. On my development PC according to the Visual
> Studio "Threads" windows I currently have 6 threads, two of which are my own
> and the other 4 show no-name. The ones with no-name I can't switch to, so I
> know I'm not generating them and I'm sure they are ones the framework has
> generated for itself.
>
> If your application is only supposed to log information about threads that
> your application spawns then you probably need a different way of telling
> apart your threads from those created by the framework. Whether the name is
> empty seems like a reasonable way, but might not be reliable in future
> because Microsoft might start to name the threads used by the framework. In
> my application to assist with debugging I always name my threads so I can
> tell at a glance what each thread is.
>
> > Anyone know how we can find out more information on these mystery threads
> > and where they are coming from? I’ve explored the Thread object but can’t
> > seem to find any useful properties I can inspect for clues.

>
> No idea, sorry :(
> --
> Brian Cryer
> http://www.cryer.co.uk/brian
>
> .
>


Mark Moeykens 09-07-2010 06:36 PM

Re: Mystery Threads - How do you find out where they come from?
 
Thanks for your reply, Brian. I had forgotten all about the “Threads” window
and we immediately put it to use to observe what was happening.

From what we can see we too have a handful of <No Name> threads that get
picked up at our break points. Then as our breakpoints are hit we see some of
these <No Name> threads getting renamed automatically to “Thread-##” (we
track the renaming by the thread's ID). Our processes (IIS I guess) are
picking up and using these renamed threads. Since the thread.Name property is
write-once we cannot rename it and there is the problem. We can no longer
track the thread with an unpredictable name.

"Brian Cryer" wrote:

> "Mark Moeykens" <MarkMoeykens@discussions.microsoft.com> wrote in message
> news:7EDD6F77-A2D8-4CD3-8FCA-C5562354F878@microsoft.com...
> > In this web app I’m working on there is this place that logs some
> > information
> > about Thread.CurrentThread. This logging is supposed to only happen on
> > threads that the application spawns. The application assigns
> > Thread.CurrentThread.Name a name and then later logs that name into a SQL
> > Server table.
> >
> > But sometimes when we log the thread’s name it isn’t our assigned name.
> > Instead it is “Thread-1” all the way up to “Thread-26”. By default
> > Thread.CurrentThread.Name is null so we can’t figure out where these other
> > threads are coming from. We can only reproduce this problem on a web
> > server,
> > not locally.

>
> I'm sure that the .NET framework uses threads (the garbage collector for
> instance), plus I'd expect to see one thread for each active web-request and
> I suppose another just listening for requests. So that's three without
> thinking giving much thought.
>
> However, I'd expect you to be able to see the same behaviour locally -
> perhaps not as many threads because you might not have as many requests, but
> I'd expect you to see some. On my development PC according to the Visual
> Studio "Threads" windows I currently have 6 threads, two of which are my own
> and the other 4 show no-name. The ones with no-name I can't switch to, so I
> know I'm not generating them and I'm sure they are ones the framework has
> generated for itself.
>
> If your application is only supposed to log information about threads that
> your application spawns then you probably need a different way of telling
> apart your threads from those created by the framework. Whether the name is
> empty seems like a reasonable way, but might not be reliable in future
> because Microsoft might start to name the threads used by the framework. In
> my application to assist with debugging I always name my threads so I can
> tell at a glance what each thread is.
>
> > Anyone know how we can find out more information on these mystery threads
> > and where they are coming from? I’ve explored the Thread object but can’t
> > seem to find any useful properties I can inspect for clues.

>
> No idea, sorry :(
> --
> Brian Cryer
> http://www.cryer.co.uk/brian
>
> .
>



All times are GMT. The time now is 07:03 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.