I am working on an ASP.NET project on VS 2010 that is completely local as of now and a strange problem keeps popping up which I can't seem to explain.
Essentially, sometimes when I perform an action that causes some sort of postback event (e.g. change the selection of a drop down list which repopulates a gridview based on the drop down list selection), the page will "flicker" like a normal postback but then result in a blank page.
Since this occured rather infrequently I decided to ignore it for the time being and focus on other aspects of the project. However, after I implement partial postbacks using AJAX, I think I may have found out what is happening.
With partial postbacks, the page now is not reloading every time a postback occurs, and I noticed that occasionally, performing an action that should cause a postback does absolutely nothing.
So my hypothesis is that somehow, the event triggered causes a postback but then gets hung up somewhere? I'm rather new to web programming so I'm at a loss at this point.
Any help would be appreciated.
Thanks
You seem to have an intermittent error that affects the large majority of your website without giving you any errors or logging. This is colloquially known as 'a huge headache'.
Here are a few steps you can take to hopefully get more information on the problem:
On your browser/client side, install a developer add-on such as Firebug that allows you to step through your AJAX/javascript as you make the calls. Watch for anything that looks odd or that might imply you are failing to address information critical for the postback. Javascript's robustness means that it can very often do things that are logically nonsense and not have a huge crash with informative errors like you would expect out of a more particular language like C#.
On the connection, install Fiddler and keep a log of all the requests and responses that go out over the line. When you manage to reproduce the error, inspect the request that went to the server very carefully to see if it's any different from others. If you get a response, investigate that too.
On the server side, try to drop a visual studio debugger into the web server instance so you have visibility on when something is hit and when it's not. If you are able to do this, you can at least see if it is getting all the way into your code when it goes to fail.
It may also help to ask if there's been any known hardware problems in your office/work space recently. It sounds really unlikely since everything else is working, but when dealing with a problem like this it's a good idea to check all your bases.
Related
I have just recently updated a web application on an IIS server, but after the update my users were receiving an incorrect input format error. This error is because the code is trying to convert a user's string input into a double which obviously doesn't work if the user passes in something like 55.5D.
Besides the bad coding practice I'm going to fix anyway, that's not the real issue. The issue is that the user was sending correct values (I watched and have input the exact same values myself) yet the program was still throwing this error. I reverted back to a previous version and the error disappeared. I haven't changed this section of code since the previous version. Anybody know what is going on here? I can't get the problem to repeat on development servers either without intentionally feeding the program bad input.
EDIT: I have tried clearing the user's and server's cache after the update, but that still received the same error, even after I put checks on the areas that were breaking (I missed some elsewhere in the code too). However, it worked great when only a few users were using it at a time, but it was breaking when many users were using it. Do ASP.NET controls have issues when many users are hitting the site?
Fully managed components in IIS do not require an application pool restart for changes to be applied. On the contrary, it will reload and JIT things again even if only web.config changes. If you are in doubt, you can always test this by including a test page with your application with a visible differentiator.
The most likely reason for your case is caching. Client-side is more likely culprit. Have you monitored http codes to verify that requests are really hitting your server and getting "live"-results (HTTP 200)?
Server-side in-process cache should be reset automatically but if you have persisted it somewhere out-of-process, they could be picked up after app upgrade..
And of course reverify that you really are testing exactly those dlls you think you are testing. If things don't make sense then verifying a wider set of assumptions can help.
We are migrating a monolithic ASP.NET MVC web application from single server to farm under load balancer. It relies heavily on Session data, so we are moving from In Process to Out, either the ASP.NET State Service or SQL Server. The behaviour I describe happens with both.
The first problem we encountered was serialization. A bunch of data is stuffed into the Session with a bunch of techniques (old program, many hands over the years). Sometimes objects with a deep graph. The answer appeared to be to attribute each class in the graph with [Serializable]. Before doing so, requests would return 500 and garbage data. After attributing all of the offending classes, 200 came back and real data. Hooray!
Except: after partially loading the home page, everything clears and the home page begins loading again. Then clears again and reloads. Infinite loop.
By merely changing back to In Process, the application behaves perfectly. Changing either to State Server or SQL Server causes the same loop to occur.
My question is not how to fix our web application - I have not provided enough details for that. My question is how do we diagnose this? Does the behaviour I describe provide a clue where we should look? Is there a way to debug/trace while under out of proc session management? Are there tools that can provide insight?
So far we have resorted to "let's try this and see if it works" Versions of "this" include adding [Serializable] to everything, dumping "I am here" to a log, rubbing lucky totems. No clues (let alone solutions) so far.
To be clear: we are not under LB yet. This is a single server and the only change we are making is switching between ( ) In process, ( ) State Server, and ( ) SQL Server So I don't think I'm worrying about Machine Key or AppDomainID yet. I'm fairly confident both State Service and SQL server are set up correctly. We've gotten past connection errors etc., and when using SQL Server there are rows in the ASPStateTempSessions table (and one in the ASPStateTempApplications table)
How can I track down this strange looping behaviour and make the app behave under Out Of Process state management the way it does when it is In Process?
Here's my predicament. I have a page in an MVC app that's displaying a list of search results via a partial view using an ajax call. The model is a List<List<string>> representing a dynamic data set, i.e., the users choose which columns they want returned and what order they come back in. All the view is doing is a nested loop which builds out the results table.
One of the potential returned fields is an image of a barcode which is being rendered by another method returning a FileContentResult. Normally this works great, it's slick and performant, to the point where I don't really notice all of the barcodes being rendered and downloaded at all, even in a data set that's hundreds of rows long.
The problem arises when I set a session variable using HttpContext.Current.Session, even something as simple as Session["thingy"] = "thingy";. When that happens there is a drastic performance hit with the barcode images. Result sets that would take a second to load fully are now suffering from image "pop in" for up to 10 seconds after the search button is hit. A few times an image has failed to load, giving an error to the effect of "the server is too busy right now".
Does anyone out there in overflowland have any insight into what could be causing this behavior? I've found a kludgy workaround but it involves unnecessary ajax calls and extra trips to the database.
So the issue was that IIS was treating requests synchronously whenever there was anything stored in the session. So all of my calls to the barcode action were waiting until the last one had finished before moving on, hence the pop-in.
The answer was in this link posted by Alexei. Oddly enough it was the most downvoted answer that provided the easiest solution. I created a new controller for my images and refactored the barcode rendering action into it, then decorated the controller with [SessionState(SessionStateBehavior.Disabled)], forcing IIS to treat any requests to the actions in the controller as asynchronous.
I was having the same issues a while ago. Fixed it by setting EnableSessionState to ReadOnly in my web.config.
I thought it might have some negative side effects but none so far. Even posted a question here in SO looking for comments.
See here: EnableSessionState = ReadOnly - possible side effects?
I have several user controls loading up in a template in an Umbraco website, and basically, there are problems with a certain template loading very slow initially (after that it loads fast). But the initial page load can take up to 5 minutes to load and the CPU on the localhost goes up very high during this. This is only on 1 specific template. I have tried a stack trace and still not able to output anything useful. Is there something in code where I can set breakpoints somehow in the code itself to see where it is spending most of it's time on the server before the page gets rendered to the client side?
I need to understand, that when the page is not cached, why it takes up to 5 minutes to render the page. How can I find this out in code? Preferably with breakpoints or some ASP.NET plugin that will help me understand why this is happening?
I have determined that it is not related to IIS 7.5, and it is NOT a System Hang! It is something in the code that is causing this.
Glimpse should provide...a glimpse into what is causing the slow initial load without requiring you to write profiling code just to troubleshoot the issue. It is certainly worth checking out before doing the latter at least.
Also, StackExchange's MiniProfiler looks promising and may be worth checking out.
The fallback option of instrumenting your code to time its execution will be more work and require code changes of course; but if that proves to be your best option to understand the slow load times, so be it.
Here is my problem:
I have just been brought onto a massive asp.net C# project and I've been charged with fixing some performance issues (not my area of expertise). More specifically after 5 - 7 redirects/ajax calls the web server stops responding and the whole page (and eventually the browser) freezes.
I don't think this is a coding issue as I've set up break points in a few pages (Page_Load method) and after the 5 requests it does not even reach the break points.
I don't believe this is related to this issue as I've increased the browser's maximum connections per server parameter and I got the same behavior. Furthermore after these 5 request in one browser IE, the application stops working in FF as well.
This is not a resource issue as the w3wp.exe process never exceeds 500MB memory.
One thing I've noticed when using Fiddler and other tools to monitor the requests is that the server takes a very long time when loading image files (png, jpg). I don't know if this is relevant.
I've enabled failed request tracing on the server and the only thing I've noticed is that some request fail with a 401 error even dough I've set Anonymous Authentication to enabled.
Here is the exact message
MODULE_SET_RESPONSE_ERROR_STATUS
ModuleName ManagedPipelineHandler
Notification 128
HttpStatus 401
HttpReason Unauthorized
HttpSubStatus 0
ErrorCode 0
ConfigExceptionInfo
Notification EXECUTE_REQUEST_HANDLER
ErrorCode The operation completed successfully. (0x0)
This message is sometimes thrown with ModuleName: ScriptModule
I have already wasted 2 days on this thing and I'm running out of ideas so any suggestions would be appreciated.
Like any large generic problem, your best bet in diagnosing the issue is to figure out how to break down the issue into smaller parts, how to hypothesize the issues, and how to validate or invalidate your hypotheses. My first inclination would be to hypothesize that the server-side processes in this particular are taking a long time, causing your client requests to block, making the whole thing seem frozen.
From there, I would attempt to replicate the long running server side processes by creating isolated client side tests - perhaps if the URLs are HTTP gets, I would test the same URLs individually. If they were HTTP posts, I'd create an isolated test form if feasible to see what happens with each request. If a long running server side process is found then you have a starting point.
If there are no long running server side processes then it may be JavaScript / client side coding issues that need to be looked into. But definitely when you're working a large, unfamiliar project, your best bet is to figure out how to break down the issue into smaller components that can then be tested
I solved the issue finally. Here is what I did:
Experimented with IIS settings and App_Pool recycling and noticed that there is nothing wrong with the way it handles requests that actually reach it.
I focused on the Http.sys module and noticed that in the log files there were a lot of Timer_ConnectionIdle and Client_Reset errors.
After some more experimentation and a lot of Google searches, I accidentally found this answer and it solved my issue. As the answer suggests the problem was caused by the AVG antivirus installed and incorrectly configured on the server.
Thanks for all the help and suggestions.
If it's ajax calls that are causing your browser to freeze, make sure they are not blocking ajax calls.
Just appending to Shan's answer, which is a good one.
First off, there is obviously a code issue as this is by no means 'normal' behavior for IIS.
That said, you must isolate it as Shan indicated. For example, given the server itself no longer accepts connections then we can pretty well eliminate javascript as the source of the problem and relegate it to being just a symptom.
Typically when a worker process spins into space like this it is due to either an infinite loop or an issue where multiple threads are trying to lock the same resource. I bet if you let it run long enough IIS itself will timeout, kill and restart the process.
With that in mind you want to look for any type of multithreaded garbage (which I highly recommend you don't do in a web server) or for anything that indicates a tight infinite loop. A loop is going to become apparent if you execute the requests individually. A multi-threaded issue will only show up if you happen to get a collision.
Run various performance counters on the web server. Also, once it locks up, let it sit that way for awhile. Once IIS performs it's own reset on the worker process go look for indicators in the event log.