C# threading in ASP.Net

  • Thread starter Thread starter JimD
  • Start date Start date
J

JimD

Is this safe? Any pitfalls? I have done threading in regular C# apps,
but haven't had a needs to do threading in ASP.Net, until now.

The issue I have ran into is this: Our corporate portal application
displays the logged in users 10 most recent emails from Exchange via
WebDav. The current code is in legacy VB6 and needs to be ported
*really* bad. Exchange 2003 has an issue where it only allows a max of
256 WebDav connections from one account. We used one "master" account
to authenticate against Exchange that could read any users mailbox. We
have 1,000's of employees and we exceeded the 256 connection limit. So
we added another "master" user with read access and then a third and we
round-robin between those.

The main issue is that we are getting some exchange bug where if
exchange goes down or has an issue during a request, the WebDav code
blocks until the portal timeout occurs and no one can get into the
portal. Employees need to always be able to get into the portal, even
if email is down. The portal is the gateway to most corporate apps for
all the non-technical users. The portal is PeopleSoft Portal. The way
PeopleSoft creates the home page with all the "pagelets" is that the
PeopleSoft Portal goes and makes the requests for the pages in the
background like a proxy server. It then puts all the pieces together
and runs the HTML through HtmlTidy to "fix" the broken HTML (remove
multiple <head><body> etc). Not the best method, but I cannot change
that. So if one of the "pagelets" takes too long, the whole stinking
PeopleSoft portal home page times out and prevents login.

I need to change it so that users can get into the portal even if there
is a timeout. I already ported the code to C# to do all the WebDav. I
get the emails back fine. I set the timeout property on the
HttpWebRequest object to 5 seconds. However, I need to be certain that
the method will always return in 5 seconds or less so I do not want to
only rely on the timeout property of the HttpWebRequest object.

I was going to write a wrapper function that creates a new thread. That
function in the thread does all the WebDav stuff. If that thread hasn't
returned in 5 seconds, the wrapper function just calls abort and returns
an empty XML response.

Will I run in to any threading issues with threading under ASP.Net? Is
the timeout property of the HttpWebRequest object *dependable*? Or
should I do the threading approach?

Thanks for any feedback,

Jim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
There's no place like 127.0.0.1
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
JimD
Central FL, USA, Earth, Sol
 
JimD,

I don't see why you would use another thread. If you are getting the
response, and you set the timeout for five seconds, an exception should be
thrown indicating that the timeout occured.

Also, you have asked if the timeout property of the HttpWebRequest class
is dependable. Is there any reaosn why you would think it isn't?

Hope this helps.
 
Nicholas said:
Also, you have asked if the timeout property of the HttpWebRequest class
is dependable. Is there any reaosn why you would think it isn't?

Well, we currently set the timeout to 10 seconds in the legacy VB6 COM
object that handles the WebDav communication. The COM object uses the
MSXML2.ServerXMLHTTP object. When Exchange locks the request, it is a
hard lock and the request never returns and 90 seconds later the whole
portal login times out because the email pagelet never finished since
the COM object never returned. The email pagelet and COM object are
both legacy VB6/ASP that I am happily moving to C#/.Net.

Our admins have worked with MS on this issue. I think we will get a
patch, some day....

However, until then we need our portal to be functional and not timeout
due to an Exchange WebDav issue.

Since the request made by the MSXML2.ServerXMLHTTP object gets locked
and doesn't honor the timeout value, I was thinking that the same thing
could happen with the HttpWebRequest object.
Hope this helps.

Thanks,

Jim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
There's no place like 127.0.0.1
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
JimD
Central FL, USA, Earth, Sol
 
Jim,

Well, it depends on whether it is an issue with the Exchange server (or
rather, IIS which is hosting WebDAV for exchange) or the ServerXMLHTTP
object.

I believe that the timeout property of the HttpWebRequest object is
going to properly tell you if something timed out.

Of course, you could always ^try^ it rather easily, no? What happens
when you try?>
 
Nicholas said:
Of course, you could always ^try^ it rather easily, no? What happens
when you try?>

I haven't tried it yet. I want to get as many test case scenarios
together as possible. The admins have to come in at night since they
cannot just pull the plug on our production Exchange. I don't want the
poor guys to have to keep coming in to try dozens of small changes.

The issue with Exchange only happens when Exchange goes down or has some
error. So to do a real test, the admins have to pull the plug on
exchange and see if any of the current requests timeout.

We have an isolated test environment. However, we do not have our
PeopleSoft portal in the test environment because it is a big complex
beast and people were having too many issues getting it to run. We also
switched to an Exchange cluster, which we do not have in the test
environment due to hardware costs.

I want to give the admins multiple tests so they can come back to me and
say test case A or B or C worked the best, use that one.

Thanks for the help Nicholas,

Jim
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
There's no place like 127.0.0.1
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
JimD
Central FL, USA, Earth, Sol
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top