By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
429,214 Members | 2,072 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 429,214 IT Pros & Developers. It's quick & easy.

thread httpContext

P: n/a
If I launch a thread within an asp.net application. Is their anyway to get
at the base threads HttpContext object.

If the thread errors I want to capture stuff like:
HttpContext.Current.Request.ServerVariables["REMOTE_HOST"]
Jun 6 '07 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Hi Chuck,

Regarding on the thread HttpContext issue you mentioned, do you mean you
want to access the HttpContext in a thread you manually started through
Thread.Start?

Based on my understanding, the HttpContext object is only associated with
those ASP.NET worker threads(pickup from thread pool when a request
coming). For those custom thread you start through Thread.Start, they're
not associated with a HttpContext object automatically. Would you provide
some further info about how to will spawn those custom threads and what
you'll do in it? Anyway, since custom thread's execution lifecycle may
beyound an ASP.NET request's server-side processing lifecycle, it is not
recommended(also unsafe) to use Httpcontext objects(like Request, Response)
in custom thread's code. If what you want to pass some unchanged
data/parameters, you can consider direclty pass them as Thread's input
parameters(State data) at startup time.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

==================================================

Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscripti...ult.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscripti...t/default.aspx.

==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

Jun 7 '07 #2

P: n/a
thanks, that's whats I figured.
I am writing a ExceptionHandler : IHttpModule
that hooks into
AppDomain.CurrentDomain.UnhandledException += new
UnhandledExceptionEventHandler(OnUhe);

incase some error occurs in a thread.

If the event does get called I'd like to know some things like
name of the server, name of the application, class that spawned the thread.
Jun 7 '07 #3

P: n/a
"Chuck P" <Ch***@newsgroup.nospamwrote in message
news:28**********************************@microsof t.com...
thanks, that's whats I figured.
I am writing a ExceptionHandler : IHttpModule
that hooks into
AppDomain.CurrentDomain.UnhandledException += new
UnhandledExceptionEventHandler(OnUhe);

incase some error occurs in a thread.

If the event does get called I'd like to know some things like
name of the server, name of the application, class that spawned the
thread.
I don't believe you can find out the class that spawned the thread, unless
you give the thread that information when you start it.

What would your ExceptionHandler module do? It can't affect the current
request, as there may not be a current request by the time the thread throws
the unhandled exception.
--
John Saunders [MVP]
Jun 7 '07 #4

P: n/a
Hi Chuck,

As you mentioned that you are registering the
AppDomain.UnhandledExceptionEvent, why did you use Httpmodule? Httpmodule
will be called at each request while AppDomain event onlyl need to be
registered once.

Also, the "UnhanddledExceptionEvent" is actually a notify event, that means
it will inform you of such an unhandled exception, but you can not do
anything to prevent the application from being ended due to the unhandled
exception.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.

Jun 8 '07 #5

P: n/a
Hi Steven,
I have bunches of asp.net applications.
Wanted to write a drop in Unhandled Exception utility we could use in all of
our applications.

In the module I monitor:
the application.Error event for UHE on the main thread.
and the AppDomain.CurrentDomain.UnhandledException for other threads.

Here is my code for the module. If their is a better way please let me know.

public virtual void Init(HttpApplication application)
{

application.Error += new EventHandler(OnError);

if (!_initialized)
{
lock (_initLock)
{
if (!_initialized)
{
if (application == null)
throw new ArgumentNullException("application");

CheckForConfigSettings();

AppDomain.CurrentDomain.UnhandledException += new
UnhandledExceptionEventHandler(OnUhe);
_initialized = true;
}
}
}
}
protected virtual void OnUhe(object sender,
UnhandledExceptionEventArgs e)
{ // threaded exceptions occur on this method

// Let this occur one time for each AppDomain.
if (System.Threading.Interlocked.Exchange(ref
_unhandledExceptionCount, 1) != 0)
return;

Exception ex = e.ExceptionObject as Exception;

ProcessTheUHE(ex);
}

protected virtual void OnError(object sender, EventArgs args)
{
HttpApplication application = sender as HttpApplication;

Exception ex = application.Server.GetLastError() as Exception;

ProcessTheUHE(ex);
}
Jun 12 '07 #6

P: n/a
Thanks for your followup Chuck,

I think your current implementation is reasonable. BTW, for the
AppDomain.UnhandledException event, you only need to register the event
handler once since the AppDomain will remain running during ASP.NET Web
application's lifecycle.

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead
This posting is provided "AS IS" with no warranties, and confers no rights.

Jun 14 '07 #7

This discussion thread is closed

Replies have been disabled for this discussion.