No Time to blog.

I do not blog for money

neither do i blog for fame

all i get is pretty lame

oh! what a shame!

Google Chrome - Instant Translation

MS – Cloud Computing advances..

Interesting Read

MS Research – One Album

Microsoft One Album

More

Handling ASP.NET ‘Thread Aborted Exception’

If you would have bumped into ‘Thread Aborted Exception’ in ASP.NET apps when trying to do a lengthy server process, They would have been interesting times fore sure.

Well, Firstly ,  The ‘Thread Aborted Exception’ happens when the thread serving the request doesn't
finish for a long time. The ASP.NET hosting process aborts this thread after a certain time which can be adjusted in the ‘executionTimeout’ attribute of the ‘httpRuntime’ element in the  ‘Web.Config’ file.

<system.web>
    <httpRuntime executionTimeout="600" />
  </system.web>
By default the executionTimeout="90" seconds.

 

Although this might solve the problem , this is not a feasible solution primarily because of scalability reasons, i.e increasing the executionTimeout might decrease the throughput of your web app.

 

I did an interesting workaround this to ‘ping’ the server at intervals just short of the ‘executingTimeout’ parameter. Now, the idea is, if a process/function/routine takes enormous amount of time (which happens to raise the Thread Aborted Exception) to complete because it’s massive., break the process/function/routine into smaller chunks and ping the server at regular intervals. This can be achieved by storing the execution states in a session variable on the server.

 

Further, this will open up an opportunity to monitor the progress of your process. Say you’ve re-factored the lengthy routine which was a single function  to 10 functions. Every time you finish a function, you can update your progress on the client and continue with the next function on the server.

Advantages

1] This will avoid the ‘Thread Aborted Exception’ and

2] Progress can be monitored.

Disadvantages

1] There is an argument that any lengthy processes must not be done on the asp.net thread pool thread and that such processes should be written as a separate windows service. Well, at the end of the day it depends on your business needs. Personally, i feel you need to consider things like will the app be running on business lan or exposed to the internet , how many simultaneous users will it have ?. Will it be running on a cluster or a single server etc..