Ramblings of a Software Engineer, Amusements of a Geek, Cacophony of a Guitarist, An Entropy Admirer's and an Interesting Character's Musings..
Tuesday 9 March 2010
Sunday 28 February 2010
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..
Sunday 14 February 2010
Why i turned buzz off!
Google, Why are you invading my privacy!.
I find Google's buzz a terrible breach of users privacy. They are being very cheeky, adding the ‘buzz’ feature without telling users what the hell it’s supposed to do. I never asked for one in the first place anyway, And this is my personal opinion.
I can’t be bothered to buzz around with my contacts or know what they are doing. C’mon Google !. I’ve lost some respect for you today. This is ridiculous. A very offensive approach at creating their own ‘eco’ system for the cloud trying to take the pie away from Facebook and Twitter. (Which i think they are trying to achieve with Android OS).
For me, it brought frustration more than a new found joy and i turned the buzz feature off. Thank god, they have managed to put that feature inside Gmail. And this is how i did it.
1] Open Gmail and navigate to the bottom of the page to find something similar to the below picture and click on ‘turn off buzz’.
Interesting Links
FILESTREAM Storage in SQL Server 2008.
In brief,
We often tend to have BLOB’s aka Binary Large Objects which takes memory storages ranging from MBs to GBs which may be or generally will be Images, Steaming Video , Sound etc.
Using FILESTREAM storage, we can take advantage of the NTFS file system. FILESTREAM storage can be used to store BLOB data using a combination of SQL Server 2008 and NTFS file system.
Good to know
1] Dual Programming Model Access to BLOB Data
- Transact-SQL Access2] Replication
- Win32 Streaming Access
FILESTREAM is supported by both transactional replication and merge replication, But there are limitations on the ‘size’ of data that can be sent to down level instances.3] Database snapshots
SQL Server does not support database snapshots for FILESTREAM data containers.4] Indexes on FILESTREAM data not allowed
5] FILESTREAM works on all recovery models (full, differential and log)
Something to note from the Conclusion
“FILESTREAM storage is not appropriate in all cases. Based on prior research and FILESTREAM feature behaviour, BLOB data of size 1 MB and larger that will not be accessed through Transact-SQL is best suited to storing as FILESTREAM data.”
Can you spot a tool requirement in the whitepaper ? , Well, A common scenario using SQL Server 2008 may be migrating existing BLOB data into FILESTREAM storage.There goes, A Tool to do exactly that will be a killer.
Saturday 13 February 2010
Trick for creating a ‘notification’ screen without AJAX – ASP.Net 1.1
If you are developing on ASP.Net 1.1, the first thing which makes you lose the will to live (especially, if you’re accustomed to ASP.Net Ajax) is obviously the missing AJAX framework!
There is very little you could do with ASP.Net Forms for example, displaying a notification screen when you are processing something in the background after a post pack.
Without using jQuery , Javascript XMLHttp Requests or an open source AJAX framework for ASP.Net 1.1 your probably stumped , so was i., until i found out a trick to do something similar but with a post back (oh, what the heck!, but it still works, given the fact that i can display a notification screen before i start a lengthy process on the server.)
The Trick.
0] Create a session object , let it be an instance of a class which has some properties than can be set.
1] In the Form_Load hander, invoke your lengthy process depending on a Boolean property in your session object.
3] On the dreadful postback, when you want to start the ‘lengthy process’, Set your session object’s Boolean property and do a Response.Redirect(“yourwaitingscreen.aspx”). This will show the waiting screen immediately, however you have still not started the lengthy process.
4] Finally, starting the lengthy process is easy.
Add this in your <meta> tag to “yourwaitingscreen.aspx” to do the magic.
<meta http-equiv=”refresh”; content=1 url=”your_lengthy_process_aspx_page.aspx”>
I can hear the Gotchas !!! and ahas!!! now.
The way asp.net processes the request is still synchronous., remember no AJAX either. But, we are taking advantage of the synchronous processing itself. i.e when we add the
‘<meta http-equiv=”refresh”; content=1 url=”your_lengthy_process_aspx_page.aspx”>’ line to
“yourwaitingscreen.aspx”, you are loading the page, which starts the ‘lengthy process’, but since you are already in the ‘waiting screen’, you need not do anything. you also get a progress bar with IE and Firefox etc. (bonus!!!)
Drawbacks:- postbacks and logic in your Form_Load to start the ‘lengthy process’ (can be accomplished using a session variable as discussed above)
But, that’s fairly trivial given the fact that you are telling the user that you are doing something in the background which is going to take some time. (as simple as that.) – with a progress bar inherently displayed by the browser.
Advantages
It’s maintainable because the ‘lengthy process’ can be loosely coupled with your UI or service. You can re-factor/enhance/test your code for ‘lengthy process’ in isolation, which makes it scalable and may be reusable!