21. January 2009 11:40
Had a long running process that was kicked off from an ASP.NET page which was getting the request timeout error below:
Request timed out.
Description: An unhandled exception occurred during the execution of the current webrequest. Please review the stack trace for more information about the error andwhere it originated in the code.
Exception Details: System.Web.HttpException: Request timed out.
An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.
[HttpException (0x80004005): Request timed out.]
I knew that the SQL was not timing out because I would hgacve
I was able to solve this by adding a httpRuntime element called executionTimeout to the web.config under the system.web section. This value is in seconds and the default is 90 (for .NET 1.0 and 1.1) or 110 otherwise.
The full specification for httpRuntime can be found here.
19. September 2008 22:19
I wonder if future archaeologists will look back on us and find traces of software developers actually doing testing and debugging. As small software house, we don't have the luxury of having dedicated testers but that shouldn't mean that testing or debugging thoroughly should be any less important that wirting code.
My (brief) set of rules for testing and debugging are:
- You can't test what you can't reproduce.
- You can't test if you do not know the expected result.
- During testing, put yourself in the shoes of your audience.
- Debugging a piece of code, you have to be smarter that the person who wrote it.
Let me explain.
A manager of mine early in my career once said to me, "You can fix what you can't reproduce". I used to think nonsense, I know exactly where the error is. I can fix the error, test the code (which by the way I know will work) and viola problem solved. Of course my manager was right. I was just proving (to myself) that I could write code that would compile and pass my limited set of tests.
If you're testing an application that outputs a file to be consumed by another system, how can you test the output if you don't know what the expected result is. All you're really doing is testing that the application can output a file without generating an error.
It's all too easy as developers to perform technical testing. The application I have just tested allows me to enter data and output a file for processing wonderfully and without error. What about the user experience? Are the steps required to get the output file the most logical and the easist for non technical people. Is it intuitive and clear enough for a user with limited training?
Saying that you have to be smarter to debug code that the person who wrote it sounds plain arrogant. But to fully understand what a piece of code is doing and most (if not all) the potential side effects of the code or external factors that could affect execution of the code is no walk in the park. You have to be top of your game.
I'd be interested in hearing other thoughts that people have.
8. September 2008 15:39
Hello and welcome to my blog. To introduce myself, I am an owner and software developer at Advantech Software in Brisbane, Australia. We have been designing, developing and implementing .NET applications since 2003.
We have just gotten back from Tech.Ed which was held in Sydney this year. This year was expecially exciting as there was a lot of technology and techniques that are available for use right now (no beta releases in sight).
I'll be listing my highlights of Tech.Ed in coming posts.