Mystery Threads - How do you find out where they come from?
in [ASP .NET]
|
Prev: Will running Windows .exe from ASP.NET web page cause memoryprob
Next: Will running Windows .exe from ASP.NET web page cause memory
From: Mark Moeykens on 3 Sep 2010 10:22 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
From: Brian Cryer on 3 Sep 2010 12:30 "Mark Moeykens" <MarkMoeykens(a)discussions.microsoft.com> wrote in message news:7EDD6F77-A2D8-4CD3-8FCA-C5562354F878(a)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
From: Mark Moeykens on 7 Sep 2010 14:36
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(a)discussions.microsoft.com> wrote in message > news:7EDD6F77-A2D8-4CD3-8FCA-C5562354F878(a)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 > > . > |